-
Notifications
You must be signed in to change notification settings - Fork 341
[IncludeTree] Support -frewrite-includes with include-tree #8531
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[IncludeTree] Support -frewrite-includes with include-tree #8531
Conversation
@swift-ci please test |
clang/lib/Lex/PPDirectives.cpp
Outdated
Callbacks->InclusionDirective( | ||
HashLoc, IncludeTok, Filename, isAngled, FilenameRange, FER, | ||
/*SearchPath=*/"", /*RelativePath=*/"", /*SuggestedModule=*/nullptr, | ||
/*ModuleImported=*/false, FileCharacter); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the case of PPCachedActions::SpuriousImport
(see below), I think we might have a module import that should be passed in here. CC @jansvoboda11
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't the new change make the callback twice now for the spurious import case? I'm not understanding this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes? Maybe I don't fully understand the spurious import. I thought your previous comment is about that it is both modular include and textual include.
In the context of rewriter, this actually don't matter because it is not adding in spurious import, but if we can get the callback correctly, we should do that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jansvoboda11 can you clarify what callback would be expected here for a spurious import? I would think we'd get a single callback, but maybe I'm misunderstanding.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know off the top of my head. Let's try replicating whatever Clang does for implicit modules in this situation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at implicit build, the inclusion only gets a textual header callback. Update to match that behavior.
clang/lib/Lex/PPDirectives.cpp
Outdated
CharSourceRange FilenameRange = | ||
CharSourceRange::getCharRange(FilenameTok.getLocation(), CharEnd); | ||
bool isAngled = | ||
GetIncludeFilenameSpelling(FilenameTok.getLocation(), Filename); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a case for if (is_style_posix(BackslashStyle) && LangOpts.MicrosoftExt)
where we call llvm::sys::path::native
on the path we pass into the callback normally, should we also do that here?
300d1a5
to
d63075a
Compare
@swift-ci please test |
@swift-ci please test llvm |
@swift-ci please test windows platform |
Add necessary PPCallbacks for include directives when the input file is include tree so -frewrite-includes can generate the correct output. rdar://125719747
d63075a
to
3e8158f
Compare
@swift-ci please test |
@swift-ci please test llvm |
@swift-ci please test windows platform |
Add necessary PPCallbacks for include directives when the input file is include tree so -frewrite-includes can generate the correct output.
rdar://125719747