[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