Clang will now search through the framework includes to identify
the framework include path to a file, and then suggest a framework
style include spelling for the file.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
50 ms | x64 debian > LLVM.Bindings/Go::go.test |
Event Timeline
This looks pretty nice to me, but I'm not convinced it's a good idea to include the umbrella header heuristic.
clang/lib/Lex/HeaderSearch.cpp | ||
---|---|---|
783–787 | Nice! No good deed goes un-punished: it should be possible to add a diagnostic test? | |
1863 | Seems like it'd be more consistent with the existing IsSystem to expand the callsites as if (... && CheckDir(...)) { if (IsSystem) *IsSystem = whatever; IsFramework = whatever; } instead of taking a param here. (And honestly the CheckDir() && IsSystem thing is confusing, so it'd help) | |
1895 | Nice comment, very helpful! Just wanted to check you're sure the versioned one is the symlink and the unversioned one is the real folder, rather than the other way. (Plausible, just surprising to me) | |
1913 | nit: /*IsFramework=*/, one star no spaces | |
1966 | This heuristic looks iffy to me, it's not just trying to help the caller insert the right header, but tell them they want a different one for style reasons. The first example framework in https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html doesn't include an umbrella header of this form. Moreover, non-framework libraries have umbrella headers too, this seems like an orthogonal concern best caught in some other way. |
clang/lib/Lex/HeaderSearch.cpp | ||
---|---|---|
783–787 | I couldn't seem to get it to generate a warning for a subframework, for both there and in double-quotes.m under Modules, so instead I added a simple test to headersearch for the sub framework case and made sure the fix it in double-quotes.m was OK for the existing cases | |
1895 | Yep, $ readlink /Applications/Xcode_13.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk | |
1966 | See https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/IncludingFrameworks.html, it's common to use this umbrella header (especially for Apple SDKs) and some frameworks require it (as opposed to including the header directly), thus I think this default makes sense even if it isn't 100%. Any other ideas on how we can help here? I guess if we had FS access we could see if the umbrella header exists... |
Thanks, test seems sensible.
I remain unconvinced that the umbrella stuff belongs here.
Maybe pull it out of this patch and send it separately if you want to discuss further, or get more opinions?
clang/lib/Lex/HeaderSearch.cpp | ||
---|---|---|
1966 | I get that it's often a good idea/mandatory to include the umbrella header (for many libraries, not just frameworks), but it's not this function's job to choose which file to include, it's to find the best spelling of the file that was requested. Similarly it doesn't check if the filename is "bits/shared_ptr.h" and suggest <shared_ptr> instead.
It depends what you're trying to achieve, maybe write a clang-tidy check instead? Or if this is something the compiler itself needs to care about, write a separate function to do the heuristic correction. | |
clang/test/Modules/double-quotes.m | ||
27 | it's hard to understand the context of how these headers are named, is there any other text on the line you can include in the CHECK? |
clang/lib/Lex/HeaderSearch.cpp | ||
---|---|---|
1955 | nit: I don't think these strings need to be so big, framework includes are a fairly uncommon case probably? |
clang/lib/Lex/HeaderSearch.cpp | ||
---|---|---|
1955 | nvm, not sure where I got that idea. |
Nice!
No good deed goes un-punished: it should be possible to add a diagnostic test?
There are some under clang/test/Preprocessor/*framework*