Ignored diagnostics were only checked after level adjusters and assumed
it would stay the same for the rest. But it can also be modified by
FeatureModules.
Details
- Reviewers
sammccall - Commits
- rG204014ec7557: [clangd] Fix feature modules to drop diagnostics
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/clangd/Diagnostics.cpp | ||
---|---|---|
732–733 | If I'm reading this right:
The new scheme seems functionally correct, but it potentially constructs more Diags. Question is, is it ever enough to care about performance? I believe *warnings in headers* are ultimately filtered out by the adjuster and are now extra work/allocations after this patch. Mostly this only affects preamble (exceptions: things like llvm tablegen includes) which is already slow, maybe it doesn't matter. If you want to avoid regressing it, I'd suggest keeping the early bail out here, but instead of setting LastPrimaryDiagnosticWasSuppressed, just construct an empty Diag and set its level to Ignored. Rest of the logic can stay the same I think. Doesn't seem like much extra code, but if you don't think it's worthwhile that's fine too of course. | |
789 | (Hmm, the isExcluded case seems like it belongs next to the level adjuster logic rather than at the end.) |
clang-tools-extra/clangd/Diagnostics.cpp | ||
---|---|---|
732–733 | I also had the same hesitation, but it looked like this is only suppressing diags based on config and tidy suppression comments (ones from header are still handled at flush). So didn't feel like a big deal, But still it can be regression in cases when these diags have some complicated fixes attached to them (we'll compute them just for dropping on the floor). The main reasoning for dropping the early exit was because I wanted the logic to look more uniform between diagcb and adjusters (to not think about it again when the day comes and we merge the two). So how do you feel about filling in the diagbase in any case (which has some string copies, especially around diag message), then running Adjuster, DiagCB and isExcluded, and after that we perform early return before adding fixes or running include fixer? | |
789 | i agree, but didn't want to raise eyebrows :P moving it next to adjuster logic. |
- Bail out early before filling in diag info
- Move isExcluded check into handleDiagnostics, rather than handling it during
flushing
LG, I'm a bit sad to see we're not able to skip much work in the diagnostics-outside-main-file case but that's a separate patch.
If I'm reading this right:
The new scheme seems functionally correct, but it potentially constructs more Diags. Question is, is it ever enough to care about performance?
I believe *warnings in headers* are ultimately filtered out by the adjuster and are now extra work/allocations after this patch. Mostly this only affects preamble (exceptions: things like llvm tablegen includes) which is already slow, maybe it doesn't matter.
If you want to avoid regressing it, I'd suggest keeping the early bail out here, but instead of setting LastPrimaryDiagnosticWasSuppressed, just construct an empty Diag and set its level to Ignored. Rest of the logic can stay the same I think.
Doesn't seem like much extra code, but if you don't think it's worthwhile that's fine too of course.