Previously, the Framework name was only set if the file
came from a header mapped framework; now we'll always
set the framework name if the file is in a framework.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks for splitting this out from the other patch. This feels subtle and I don't think I know enough about frameworks to review.
@cishida made a recent change here which @jansvoboda11 reviewed - I'm guessing they'd know what to do here.
clang/lib/Lex/HeaderSearch.cpp | ||
---|---|---|
1039–1040 | The comment here explicitly say "in a header map and". Unfortunately it doesn't say why, and I don't know enough to guess. |
Cyndy and Jan, hopefully ya'll are the right reviewers here? We're using this Framework information to know to compute framework style includes in https://reviews.llvm.org/D117056 for clangd, please LMK if this is a bad idea and we should do something else.
My understanding for the header map restriction is because headermaps are generally emitted once for a framework build and only consumed to build such framework and this struct information is only queried during this.
It sounds like for the clangd support, you're not as interested in what framework is being built, but the name of the framework when included via framework style in any context. Is that correct? It seems fine to extend its use cases. @jansvoboda11 What do you think?
Yep, exactly, for clangd, we want to know when a header is included via a framework style include (although maybe it would be better to know if a header is actually apart of a framework regardless of the spelling to import it?) so we can generate a proper framework style include for symbols in the framework. That lets us suggest an include of <UIKit/UIKit.h> for UIView, for example.
I followed up about this approach with folks more familiar with SourceKit and seems fine, so LGTM. I'd wait a day to see if Jan has any concerns.
clang/lib/Lex/HeaderSearch.cpp | ||
---|---|---|
1039–1040 | nit/reminder: This should be updated now |
clang/lib/Lex/HeaderSearch.cpp | ||
---|---|---|
1039–1040 | Updated, LMK if you have any suggestions on the wording here. |
clang/lib/Lex/HeaderSearch.cpp | ||
---|---|---|
1039–1040 | LGTM |
The comment here explicitly say "in a header map and". Unfortunately it doesn't say why, and I don't know enough to guess.