Page MenuHomePhabricator

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

Authored by DmitryPolukhin on Mar 31 2016, 5:06 AM.

Details

Reviewers
rsmith
Summary

GCC clears current search position in the include directories list used
for #include_next if current header was found using relative paths.
Before this patch Clang kept current position from previous header
included from directories list. Both approaches make sense but I thin it
is better to be GCC compatible in this question. See added test-case for
the example.

Also update warning text to give better understanding what happened.
Previous one about absolute path was incorrect and confusing.

Diff Detail

Event Timeline

DmitryPolukhin retitled this revision from to [PP] Handle #include_next after include found relative to current one same as GCC.
DmitryPolukhin updated this object.
DmitryPolukhin added a reviewer: rsmith.
DmitryPolukhin added a subscriber: cfe-commits.

Richard, friendly ping, PTAL!

rsmith edited edge metadata.EditedApr 26 2016, 6:47 PM

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).

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

include/clang/Basic/DiagnosticLexKinds.td
268–269

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.

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.

DmitryPolukhin abandoned this revision.May 26 2016, 7:54 AM

It seems that there is no interest in this patch, abandon.