Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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`? |
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? |
clang-tools-extra/clangd/ConfigFragment.h | ||
---|---|---|
243 |
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 | ||
605 | 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? | |
649 | nit: embedded newlines are hard to read and inconsistent with other tests. rawstrings? | |
655 | 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) | |
663 | assert the behavior instead of describing it in a comment? |
clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp | ||
---|---|---|
555 | oops, copy pasting is hard. just dropped them. | |
clang-tools-extra/clangd/unittests/PreambleTests.cpp | ||
605 | 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. | |
655 | 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. | |
663 | 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. |
- 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 | ||
---|---|---|
225 | nit: seems clearer at this point to clone the TU and overwrite Code | |
605 | 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) | |
624 | nit: "preamble" vs "code" is a confusing distinction when we're using both as code. | |
655 | what exactly is being tested here? | |
656 | raw strings | |
664 | raw strings | |
673 | raw strings | |
677 | 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. | |
680 | named ranges? | |
695 | nit: at the correct coordinates in NewCode? (the diagnostic already points at NewCode) |
- Use raw string literals
- Make tests more expressive by mentioning diagnostic names
clang-tools-extra/clangd/unittests/PreambleTests.cpp | ||
---|---|---|
624 |
Done. | |
655 |
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.
idea is checking that translation logic works as intended when the preamble bounds got smaller.
comment change is insignificant, it's just to make sure we are making preamble bounds smaller, could as well be another include.
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. | |
677 |
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.
sorry that's my bad english. i was trying to say it shouldn't point at BARXYZ and should point at FOO instead. |
clang-tools-extra/clangd/unittests/PreambleTests.cpp | ||
---|---|---|
224–225 | now there's only one variable used for both - just rename it instead? |
One of your patches likely introduced UB https://lab.llvm.org/buildbot/#/builders/85/builds/14558
Can you please take a look?
FYI, @kstoimenov
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.
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")