This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Add config option for fast diagnostics mode
ClosedPublic

Authored by kadircet on Jan 30 2023, 6:14 AM.

Diff Detail

Event Timeline

kadircet created this revision.Jan 30 2023, 6:14 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 30 2023, 6:14 AM
Herald added a subscriber: arphaman. · View Herald Transcript
kadircet requested review of this revision.Jan 30 2023, 6:14 AM
sammccall added inline comments.Feb 1 2023, 5:31 AM
clang-tools-extra/clangd/ConfigFragment.h
243

I think "Diagnostics.Mode" is too vague a name.

I expect this to be a rollout flag that we remove in the medium term (either deciding to stick to the old or new behavior), so maybe something ultra-specific like`AllowStalePreamble: yes/no`?
(Preamble is jargon, maybe there's something better, but again I don't think we should plan for this to be really "user-visible")

kadircet updated this revision to Diff 494003.Feb 1 2023, 10:33 AM

Wire up the feature and add some test cases

kadircet added inline comments.Feb 1 2023, 10:45 AM
clang-tools-extra/clangd/ConfigFragment.h
243

i actually feel like there's some value in keeping this around. some users value correctness of their diagnostics too much, and option isn't really costly to implement. why do you think we should stick to one or the other?

sammccall added inline comments.Feb 2 2023, 5:09 AM
clang-tools-extra/clangd/ConfigFragment.h
243

some users value correctness of their diagnostics too much

First, citation needed! (People *claiming* that they value correctness when they actually prefer latency seems common based on our past optimizations).

Second, this is a fine-grained knob that probably doesn't yield a useful correctness/latency tradeoff. If it trades off a lot of correctness, we probably want to leave it off by default and at that point we should delete the feature. If it trades off only a little correctness, then most people will want it and *disabling it won't significantly improve diagnostics correctness* as most errors come from non-configurable tradeoffs made elsewhere.

There's a sweet spot where this trades off just the critical amount of correctness to make it a difficult call, I just think it's unlikely we'll hit that. (I'm optimistic about this being mostly unnoticeable).


Regardless, if this is a long-lived option, it's more important to have a good name. AllowStalePreamble seems clearly better than Mode but maybe we could come up with something better - I just don't think it matters that much if the option is short-lived.

clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp
555

comment doesn't seem to apply here (and below)

clang-tools-extra/clangd/unittests/PreambleTests.cpp
608

hmm, this convert-then-assert-eq is harder to debug when there are unexpected diagnostics than matchers, I think. Might be better to follow what DiagnosticTests does here?

652

nit: embedded newlines are hard to read and inconsistent with other tests. rawstrings?

658

it's unclear what the behavior is here: do we get a diagnostic with no range, or a bad range that's being filtered out, or no diagnostic at all?

(The presence/absence of the diagnostics is important to test, independent of the locations)

666

assert the behavior instead of describing it in a comment?

nridge added a subscriber: nridge.Feb 4 2023, 7:13 PM
kadircet marked 5 inline comments as done.Feb 6 2023, 9:23 AM
kadircet added inline comments.
clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp
555

oops, copy pasting is hard. just dropped them.

clang-tools-extra/clangd/unittests/PreambleTests.cpp
608

not sure what you mean by that. when things go wrong this prints the expected and actual ranges, which is pretty much all we care about from this logic's perspective.

658

well, sent out D143197. we were not generating any diagnositcs at all, because we couldn't figure out the headerid for patched include. i guess these improvements/fixes to the preamble patching deserves its own patch, whether or not we chose to improve things.

666

done. this test was checking so many things at once. made it simpler by getting rid of the macro def from the preamble and checking for it (the #undef issue) only in the next test.

kadircet updated this revision to Diff 495159.Feb 6 2023, 9:23 AM
kadircet marked 2 inline comments as done.
  • Address comments
kadircet updated this revision to Diff 495407.Feb 7 2023, 1:01 AM
  • Update tests after discussions in D143096 to be line-oriented, rather than being directive-oriented.

The code looks good, but I have a very hard time following the tests.

clang-tools-extra/clangd/unittests/PreambleTests.cpp
228

nit: seems clearer at this point to clone the TU and overwrite Code

608

I care about the diagnostic messages/codes too, otherwise I can't understand what the assertions are about (especially on failure, but even just reading the code I can't tell what is being tested)

627

nit: "preamble" vs "code" is a confusing distinction when we're using both as code.
Spelling out the inputs would be IMO clearer than pasting strings together, tests don't need to be DRY

658

what exactly is being tested here?
"removals" suggests we're dropping includes but think we're not.
Is the comment change significant, or the whitespace change in the directive, or both?
The code looks OK, what's the diagnostic being emitted?

659

raw strings

667

raw strings

676

raw strings

680

what is the warning for BARXYZ?

This comment says the diagnostic shouldn't be pointing at FOO inside baselinepreamble (which I assume means the first FOO) but it already isn't - did you mean "should"? This is probably just two FIXMEs.

683

named ranges?

698

nit: at the correct coordinates in NewCode? (the diagnostic already points at NewCode)

kadircet updated this revision to Diff 495879.Feb 8 2023, 10:15 AM
kadircet marked 10 inline comments as done.
  • Use raw string literals
  • Make tests more expressive by mentioning diagnostic names
clang-tools-extra/clangd/unittests/PreambleTests.cpp
627

Spelling out the inputs would be IMO clearer than pasting strings together, tests don't need to be DRY

Done.

658

what exactly is being tested here?

so this test is all about diagnostics that are emitted as part of the main file AST built, specifically the ones that are emitted on ranges inside the preamble.
the particular diagnostics on include directives are coming from include-cleaner.

"removals" suggests we're dropping includes but think we're not.

idea is checking that translation logic works as intended when the preamble bounds got smaller.

Is the comment change significant, or the whitespace change in the directive, or both?

comment change is insignificant, it's just to make sure we are making preamble bounds smaller, could as well be another include.
whitespace change is insignificant since we're moving the whole directive around (2nd line to 0th line). it was to make it more explicit. happy to hide if you think that's confusing.

The code looks OK, what's the diagnostic being emitted?

unused-include diag as mentioned above. couldn't really find any diagnostics that are emitted (or contain notes that are pointing) to an include directive.

680

what is the warning for BARXYZ?

redefinition of FOO, it's emitted at location of B then we turn it into a range inside clangd by lexing the token. hence it's expanded into the full token range.

This comment says the diagnostic shouldn't be pointing at FOO inside baselinepreamble (which I assume means the first FOO) but it already isn't - did you mean "should"? This is probably just two FIXMEs.

sorry that's my bad english. i was trying to say it shouldn't point at BARXYZ and should point at FOO instead.

kadircet updated this revision to Diff 495889.Feb 8 2023, 10:56 AM
  • Insert missing include
sammccall accepted this revision.Feb 16 2023, 10:31 AM
sammccall added inline comments.
clang-tools-extra/clangd/unittests/PreambleTests.cpp
227–228

now there's only one variable used for both - just rename it instead?

This revision is now accepted and ready to land.Feb 16 2023, 10:31 AM
This revision was automatically updated to reflect the committed changes.
kadircet marked an inline comment as done.

One of your patches likely introduced UB https://lab.llvm.org/buildbot/#/builders/85/builds/14558
Can you please take a look?

FYI, @kstoimenov

One of your patches likely introduced UB https://lab.llvm.org/buildbot/#/builders/85/builds/14558
Can you please take a look?

Thanks a lot Vitaly and sorry for not noticing this myself :(
This sounds to me like a bad consequence between an empty stringref and memorybuffers. I've put together https://reviews.llvm.org/D144706 to make sure we can prevent this from happening in the library, but getting it reviewed will probably take time.
In the meanwhile I've sent out https://reviews.llvm.org/D144708 to stop the bleeding.