This will be useful for IncludeCleaner.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
thanks, LG in general, just a couple polishing touches
clang-tools-extra/clangd/IncludeCleaner.cpp | ||
---|---|---|
147 | this returns true even after inserting mainfile id, is that intended? I suppose it won't hurt too much, but means we'll go one step further for macros. | |
156 | can you lift the isSelfContainedHeader into SourceCode.h and make use of it in both places (while updating the signature to accept a PP, through which you can access the SM). | |
163 | we already have access to SM from the members, can you do the same for PP (stash as a member during construction) rather than plumbing at each call? | |
clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp | ||
351 | is this part of the check even relevant? let's drop this completely? | |
356 | maybe make this an UnorderedElementsAre, do we have any ordering guarantees in this API's contract? |
The ReferencedFiles is designed to make add() as cheap as possible, and do any per-file logic after folding the fileIDs together.
This keeps that loop tighter and also isolates the complexity of the symbol vs file logic.
Any reason we can't do that here?
clang-tools-extra/clangd/IncludeCleaner.cpp | ||
---|---|---|
252–267 | This comment seems a bit unclear:
Maybe something like: // If a header is not self-contained, we consider its symbols a logical part of the including file. // Therefore, mark the parents of all used non-self-contained FileIDs as used. // Perform this on FileIDs rather than HeaderIDs, as each inclusion of a non-self-contained file is distinct. | |
262 | it seems like we'd be better off storing the "is-self-contained" in the IncludeStructure and looking up the HeaderID here rather than asking the preprocessor. That way we rely on info that's better obtained at preamble build time. | |
clang-tools-extra/clangd/SourceCode.h | ||
331 | This helper checks e.g. for "don't include me", which is going to read source code of preamble files - we shouldn't do that, it's too slow and racy to do for every file in the preamble. (It would be nice to handle those cases at some point, if we want to do that we need to do it at preamble build time and record the results in the IncludeStructure) |
Resolve most comments.
clang-tools-extra/clangd/IncludeCleaner.cpp | ||
---|---|---|
262 | I am slightly confused: we don't really have the IncludeStructure here and it is logically detached from the IncludeStructure processing. We'd still have to unroll the chain of FIDs in here, so the only difference would be querying IncludeStructure data for the cached isSelfContainedHeader value, is that right? Why is obtaining that info at preamble build time better? |
clang-tools-extra/clangd/IncludeCleaner.cpp | ||
---|---|---|
262 | the call-site has access to ParsedAST, hence the IncludeStructure. I believe the main reasoning behind Sam's suggestion is performing these lookups once while building the preamble and sharing it afterwards (we can even do the IO there). | |
clang-tools-extra/clangd/SourceCode.cpp | ||
56 | no need for static here (and other places below) | |
clang-tools-extra/clangd/SourceCode.h | ||
333 | i'd suggest AllowIO rather than ExpensiveCheck | |
clang-tools-extra/clangd/index/SymbolCollector.cpp | ||
281–282 | can you also delete this and the other helpers? | |
clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp | ||
347 | looks like a debug artifact |
Thanks, this mostly LG now.
I'd consider splitting out the new infra change (IncludeStructure) from the feature change (include-cleaner treatment).
In case the latter causes some problems...
clang-tools-extra/clangd/Headers.cpp | ||
---|---|---|
92 | nit: at the file exit time -> at file exit time | |
clang-tools-extra/clangd/Headers.h | ||
65 | Why redundantly track this on Inclusion? It's already available via IncludeStructure.SelfContained.contains(*HeaderID) | |
128 | Maybe it's neater just to pass the CompilerInstance& - there's no other practical way to use this. | |
158 | I think i'd prefer to see this private with an isSelfContained accessor, because the representation isn't the only sensible one. Case in point: almost all headers in practice are self-contained, so in fact storing the set of non-self-contained headers seems preferable. | |
clang-tools-extra/clangd/SourceCode.cpp | ||
53 | these helpers are 1000 lines away from the only place they're used, please move them closer | |
clang-tools-extra/clangd/SourceCode.h | ||
330 | This still doesn't really describe the situation:
I'd rather say: |
[clangd] IncludeCleaner: Attribute symbols from non self-contained headers to their parents
When a symbol comes from the non self-contained header, we recursively uplift
the file we consider used to the first includer that has a header guard. We
need to do this while we still have FileIDs because every time a non
self-contained header is included, it gets a new FileID but is later
deduplicated by HeaderID and it's not possible to understand where it was
included from.
Thanks!
clang-tools-extra/clangd/Headers.h | ||
---|---|---|
167 | could consider friend class RecordHeaders, either is ugly, up to you |
clang-tools-extra/clangd/Headers.h | ||
---|---|---|
167 | That was the original problem I had the public field in the previous iteration: RecordHeaders is defined in anonymous namespace, so IIUC I can not friend it from here unless I make it a subclass or somehow visible from here, otherwise it wouldn't work, would it? Is there any clean way to do the friend here? |
clang-tools-extra/clangd/Headers.h | ||
---|---|---|
167 | No, you need to move it out of the anonymous namespace. Which is part of the ugliness, though not harmful in practice. (If you're worried about namespace pollution you can make it a nested class of IncludeStructure. You have to forward declare it in the header. In that case you don't have to friend it) |
Get rid of the setter in IncludeStructure.
clang-tools-extra/clangd/Headers.h | ||
---|---|---|
167 | I see, thanks! |
Why redundantly track this on Inclusion? It's already available via IncludeStructure.SelfContained.contains(*HeaderID)