[PATCH] D18641: [PP] Handle #include_next after include found relative to current one same as GCC
Dmitry Polukhin via cfe-commits
cfe-commits at lists.llvm.org
Wed Apr 27 05:09:02 PDT 2016
DmitryPolukhin added a comment.
In http://reviews.llvm.org/D18641#413277, @rsmith wrote:
> 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 effectively get the current Clang behavior (because relative-looking paths would be found in the relevant include search path rather than as relative paths).
The same is true for Clang with my patch i.e. use clang -iquote to get almost old behavior. So IMHO on the system where Clang is a replacement for GCC it is better to be GCC compatible in such basic things as include behavior.
> Is there some way we can gain confidence we're not breaking things here?
I don't know how we can get such confidence without committing code and see if any issues arrive. On systems where GCC is default compiler I tested my patch on wide range of scenarios and there were no problems.
Please let me know if you would like to proceed with this patch or I should abandon it.
http://reviews.llvm.org/D18641
More information about the cfe-commits
mailing list