We already have the structure internally, we just need to expose it.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
clangd/Diagnostics.cpp | ||
---|---|---|
185 ↗ | (On Diff #193708) | NIT: the comment looks open to misinterpretation, "no structured link" refers to the fact the clients don't support it, but could be read that we don't know which notes correspond to a main diagnostic. Maybe rephrase to something link "If the client does not support structured links …"? |
280 ↗ | (On Diff #193708) | NIT: maybe call OutFn and return here to avoid checking for EmitRelatedLocations again? |
clangd/SourceCode.cpp | ||
310 ↗ | (On Diff #193708) | NIT: seems unrelated. Maybe revert? |
unittests/clangd/DiagnosticsTests.cpp | ||
62 ↗ | (On Diff #193708) | Maybe omit the std::tie()-based comparison altogether? |
259 ↗ | (On Diff #193708) | maybe use testPath() here to avoid PP directives? |
clangd/Diagnostics.cpp | ||
---|---|---|
271 ↗ | (On Diff #193708) | Maybe vlog? This is what we use for dropped diagnostics, should probably stick to the same level with dropped notes (even though the dropped notes probably come up less often in practice). |
clangd/Protocol.cpp | ||
---|---|---|
280 ↗ | (On Diff #193708) | s/CodeActions/RelatedInfoSupport/ |
clangd/Protocol.cpp | ||
---|---|---|
280 ↗ | (On Diff #193708) | copy-paste detected? :-))) |
clangd/Diagnostics.cpp | ||
---|---|---|
280 ↗ | (On Diff #193708) | Yeah, I don't really see this as an improvement - it reduces the nesting, but makes the relation of conditions to code more confusing, I think. |
unittests/clangd/DiagnosticsTests.cpp | ||
259 ↗ | (On Diff #193708) | Done - this requires changing the actual paths but it doesn't seem to matter. |
clangd/Diagnostics.cpp | ||
---|---|---|
417 ↗ | (On Diff #195707) | It's more readable than full path - e.g. if the main TU is foo.cc and includes foo.h, this is "foo.h". It's true that if we want to flatten as another pass, we're not going to make use of this information. I'd rather change that in the flatten-as-another-pass patch, so we can see whether the damage to output is worth the refactoring. |
271 ↗ | (On Diff #193708) | As with the other comment - you're right, and we'll drop these if we refactor - I don't think there's any need to drop them now, though. |
Discussed further offline - it's not clear that expressing the flattening as LSP diagnostic -> LSP diagnostic is better than the current Diag -> LSP diagnostic.
So that followup probably won't happen, and there isn't that much to be gained from "unifying" the behavior in !AbsFile or File!=AbsFile cases.