[PATCH] D18641: [PP] Handle #include_next after include found relative to current one same as GCC

[Richard Smith via cfe-commits]

rsmith added a comment.

I'm a little concerned about the possibility of this breaking uses of this feature on platforms where Clang is the system compiler. For instance, this pattern would be broken by your change:

  // stddef.h
  #include "stddef-helper.h"
  
  // stddef-helper.h
  #include_next <stddef.h>

Conversely, I don't think any important library is likely to be relying on the GCC behavior, because compilations with "gcc -I-" would get the current Clang behavior (because relative-looking paths would be found in the relevant include search path rather than as relative paths).

Is there some way we can gain confidence we're not breaking things here?


================
Comment at: include/clang/Basic/DiagnosticLexKinds.td:268-269
@@ -267,4 +267,4 @@
   "the #__include_macros directive is only for internal use by -imacros">;
-def pp_include_next_absolute_path : Warning<
-  "#include_next with absolute path">,
+def pp_include_next_without_state : Warning<
+  "#include_next without previous state, searching from the beginning of the include directories list">,
   InGroup<DiagGroup<"include-next-absolute-path">>;
----------------
Can you distinguish between the two cases here and give better diagnostics for both?

  "#include_next in file found by relative path, searching from [...]"
  "#include_next with absolute path, searching from [...]"

would be an improvement on this.


http://reviews.llvm.org/D18641