This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Emit ChangeAnnotation label and description for include-cleaner diagnostics.
Needs ReviewPublic

Authored by hokein on Apr 28 2023, 4:26 AM.

Details

Reviewers
kadircet

Diff Detail

Event Timeline

hokein created this revision.Apr 28 2023, 4:26 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 28 2023, 4:26 AM
Herald added a subscriber: arphaman. · View Herald Transcript
hokein requested review of this revision.Apr 28 2023, 4:26 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 28 2023, 4:26 AM

VSCode UI:

  • missing-include

  • unused-include

kadircet added inline comments.May 2 2023, 12:32 AM
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.

hokein added inline comments.May 4 2023, 12:53 AM
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).

hokein updated this revision to Diff 522067.May 15 2023, 12:12 AM
hokein marked 3 inline comments as done.

address comments and polish implementations.

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

hokein updated this revision to Diff 532117.Jun 16 2023, 6:06 AM
hokein marked 2 inline comments as done.

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.

  • For Fix.Edits, as you pointed out in another comment, we can sort it by (range, newText), to make the case where multiple #includes insertion are at the same place better;
  • For Fix.Annotations, this is a bit hard to do a sort afterward as we construct the ID + Annotation, but luckily the final order doesn't matter there, we only need a deterministic order to make lit test happy.

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.