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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
