Details
- Reviewers
kadircet
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/clangd/IncludeCleaner.cpp | ||
---|---|---|
445 | what about just taking in llvm::ArrayRef<const Inclusion *> UnusedIncludes and having a TextEdit dropInclude(const Inclusion&); that we can use in here & inside generateUnusedIncludeDiagnostics? That way we can just use the spelling inside the inclusion to generate the label, without all the extra logic. | |
485 | i think rather than a single diag info, we should actually store a set of them now, right? as we want to surface not only the "first" use of a header, but all. (possibly with some trimming). | |
514 | i don't think line information is as useful (as there's no structured link to it). what about something like: label: `Include "foo.h"` description: `Provides 'X', 'Y', 'Z', ...` | |
550 | sorry for missing it during last review, but this should actually be if (!UnusedIncludes.empty() && !MissingIncludeDiags.empty()) as even if we have only 1 fix for each category, we should still show the fix all. probably it deserves a fix in a separate patch. |
clang-tools-extra/clangd/IncludeCleaner.cpp | ||
---|---|---|
550 | good catch, send a fix in https://reviews.llvm.org/D149822. (it turns out more tricky than we thought, only changing the if is not enough, I added some unittests for it). |
I have polished the implementation about the fix-all for missing-include diagnostics, please take a look on the new code.
thanks, mostly LG. I think we need to be a little careful when generating insertions for all the missing includes though.
clang-tools-extra/clangd/IncludeCleaner.cpp | ||
---|---|---|
166–170 | what do we gain by preserving the insertion order here exactly? in generateMissingIncludeDiagnostics, we already traverse using the order of MissingIncludeDiagInfos and inside addAllMissingIncludes the order we preserved here (diagnostic order) doesn't really make much sense, we probably should generate fixes in the order of insertion location, or header spelling. so what about just using a DenseMap ? | |
183 | nit: maybe inline into the call site | |
309 | we might still have symbols with the same name (ns1::Foo vs ns2::Foo), they'll show up the same in the final annotation. since we're already sorting by name, we might as well deduplicate after sorting and store just a SmallVector here | |
332 | we might generate multiple insertions to same location here e.g. insert a.h and b.h at the top of the file. LSP says that order reported by the server will be preserved. hence we should actually make sure our edits are ordered by spelling. | |
clang-tools-extra/clangd/IncludeCleaner.h | ||
44 ↗ | (On Diff #522067) | can you put definition out-of-line ? |
clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h | ||
71 ↗ | (On Diff #522067) | // Unqualified name of the symbol |
rebase, and address review comments
clang-tools-extra/clangd/IncludeCleaner.cpp | ||
---|---|---|
166–170 | The reason was that we need a deterministic-order for visting MissingIncludeEdits, otherwise that batch-fix lit test might fail from time to time. particularly, in addAllMissingIncludes, we generate a Fix by iterating MissingIncludeEdits, we construct the Fix.Edits, and Fix.Annotations.
The other alternative is to switch MissingIncludeEdits to a vector<{Header, TextEdit}> sorted by the TextEdit, but in generateMissingIncludeDiagnostics, we need to lookup from a Header, then this means we have to do a linear scan which doesn't feel good. | |
309 | you're right, done. | |
332 | Good catch, this seems like an existing problem today. Sorting these edits by spelling header is one solution, I'm planning to do it in this patch, added a FIXME. |
what do we gain by preserving the insertion order here exactly?
in generateMissingIncludeDiagnostics, we already traverse using the order of MissingIncludeDiagInfos and inside addAllMissingIncludes the order we preserved here (diagnostic order) doesn't really make much sense, we probably should generate fixes in the order of insertion location, or header spelling.
so what about just using a DenseMap ?