[libc++] Diagnose when header search paths are set up incorrectly
An issue I often see in codebases compiled for unusual platforms is
that header search paths are specified manually and are subtly wrong.
For example, people will manually add `-isystem <some-toolchain>/usr/include`,
which ends up messing up the layering of header search paths required by
libc++ (because the C Standard Library now appears *before* libc++ in
the search paths). Without this patch, this will end up causing
compilation errors that are pretty inscrutable. This patch aims to
improve the user experience by diagnosing this issue explicitly.
In all cases I can think of, I would expect that a compilation error
occur if these header search paths are not layered properly. This
should only provide an explicit diagnostic instead of failing due
to seemingly unrelated compilation errors.
Differential Revision: https://reviews.llvm.org/D131441
NOKEYCHECK=True
GitOrigin-RevId: 8cedff10a18d8eba9190a645626fa6a509c1f139
diff --git a/include/cstring b/include/cstring
index 37c92e1..42bbe73 100644
--- a/include/cstring
+++ b/include/cstring
@@ -58,8 +58,17 @@
#include <__assert> // all public C++ headers provide the assertion handler
#include <__config>
+
#include <string.h>
+#ifndef _LIBCPP_STRING_H
+# error <cstring> tried including <string.h> but didn't find libc++'s <string.h> header. \
+ This usually means that your header search paths are not configured properly. \
+ The header search paths should contain the C++ Standard Library headers before \
+ any C Standard Library, and you are probably using compiler flags that make that \
+ not be the case.
+#endif
+
#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
# pragma GCC system_header
#endif