This is an archive of the discontinued LLVM Phabricator instance.

[libtooling][clang-tidy] Fix diagnostics not respecting and highlighting fed SourceRanges
ClosedPublic

Authored by whisperity on Mar 15 2021, 9:13 AM.

Details

Summary

Fixes bug #49000.

Currently, when a diagnostic in Clang-Tidy is produced as diag(Var->getLocation(), "foo %0") << "bar" << Var->getSourceRange();, the source range specified to be highlighted is discarded, i.e.

x.cpp:21:18: warning: foo bar [blah-blah-checker]
void fun(int I, int J, int K) {}
             ^

is created instead of producing a full highlight:

x.cpp:21:18: warning: foo bar [blah-blah-checker]
void fun(int I, int J, int K) {}
         ~~~~^

This creates a discrepancy between warnings generated in Clang::Sema which work properly, and in Tidy.
This patch fixes the issue by making sure Clang-Tidy's logic of decoupling ranges from the SourceManager and rendering them later respects custom ranges that are fed into a diagnostic.

Diff Detail

Event Timeline

whisperity created this revision.Mar 15 2021, 9:13 AM
whisperity requested review of this revision.Mar 15 2021, 9:13 AM

NFC I originally wrote a Release Notes entry about this, which I forgot to commit before I generated the patch file I uploaded, this is fixed now.

whisperity added a subscriber: sammccall.
whisperity retitled this revision from [libtooling][clang-tidy] Fix diagnostics not handlings SourceRange highlights to [libtooling][clang-tidy] Fix diagnostics not respecting and highlight fed SourceRanges.Mar 15 2021, 9:24 AM
whisperity retitled this revision from [libtooling][clang-tidy] Fix diagnostics not respecting and highlight fed SourceRanges to [libtooling][clang-tidy] Fix diagnostics not respecting and highlighting fed SourceRanges.

Thank you for looking into this!

It looks like there are some unit test failures from the change: https://buildkite.com/llvm-project/premerge-checks/builds/29754#a9b04ab5-e326-4ff1-beea-773f21a33349

Strange because I specifically ran both check-clang and check-clang-tools locally, but will look into this.

Strange because I specifically ran both check-clang and check-clang-tools locally, but will look into this.

Turns out there is a check-clang-extra-unit too, and it looks like those test TUs either didn't compile for me at all (as in, it was not commanded to compile them), or I messed something up during the rebase.
(But TIL we finally have some semblance of pre-merge checking instead of always reverting commits! ๐Ÿ˜‹)

'll update the patch soon. Gonna do a clean build and a clean check, just in case....

What's the outlook on the executive decision... changing the schema in libToolingCore... is such even allowed? I'm venturing into parts unknown here.

whisperity edited the summary of this revision. (Show Details)
whisperity added a subscriber: compositeprimes.

Fixed a test file that I originally missed to align with the changes.

Strange because I specifically ran both check-clang and check-clang-tools locally, but will look into this.

Turns out there is a check-clang-extra-unit too, and it looks like those test TUs either didn't compile for me at all (as in, it was not commanded to compile them), or I messed something up during the rebase.
(But TIL we finally have some semblance of pre-merge checking instead of always reverting commits! ๐Ÿ˜‹)

Yes, it's actually been catching some useful things lately, too, which is nice!

What's the outlook on the executive decision... changing the schema in libToolingCore... is such even allowed? I'm venturing into parts unknown here.

I think @alexfh will have to make the final call, but I think the changes here look reasonable. I have no idea if we've made stability guarantees about the schema though.

I'm giving my LGTM, but not accepting the review because I'd like to hear from Alex before this lands.

Eugene.Zelenko added inline comments.
clang-tools-extra/docs/ReleaseNotes.rst
78

Please use sing back-ticks for non-language constructs.

Again LGTM, but see what alex says.

clang-tools-extra/clang-tidy/ClangTidy.cpp
135โ€“137

nit: Elide braces.

278โ€“280

nit: Elide braces.

clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
81โ€“84

nit: Elide braces.

whisperity changed 2 blocking reviewer(s), added 1: alexfh; removed 1: klimek.Mar 16 2021, 11:52 AM
whisperity added a comment.EditedMar 16 2021, 12:00 PM

@aaron.ballman Could you please help me understand this pre-merge buildbot? It says that Debian failed, with the following message:

[15/1038] Running lint check for sanitizer sources...
FAILED: projects/compiler-rt/lib/CMakeFiles/SanitizerLintCheck
cd /mnt/disks/ssd0/agent/llvm-project/build/projects/compiler-rt/lib && env LLVM_CHECKOUT=/mnt/disks/ssd0/agent/llvm-project/llvm SILENT=1 TMPDIR= PYTHON_EXECUTABLE=/usr/bin/python3.8 COMPILER_RT=/mnt/disks/ssd0/agent/llvm-project/compiler-rt /mnt/disks/ssd0/agent/llvm-project/compiler-rt/lib/sanitizer_common/scripts/check_lint.sh
The following differences between the ABI list and the implemented custom wrappers have been found:

Should I be worried because of this, or is this that the patch started building when the main branch was broken? I haven't touched compiler-rt at all. Neither anything that deals with the sanitizers. And this fail is "earlier" than the previous one where I indeed missed a test file's update. (Previous fail was at ninja action multiple hundreds, this is 15.)

And it talks about a lot of stuff like fork and such that is really really out of scope for the patch itself.

@aaron.ballman Could you please help me understand this pre-merge buildbot? It says that Debian failed, with the following message:

[15/1038] Running lint check for sanitizer sources...
FAILED: projects/compiler-rt/lib/CMakeFiles/SanitizerLintCheck
cd /mnt/disks/ssd0/agent/llvm-project/build/projects/compiler-rt/lib && env LLVM_CHECKOUT=/mnt/disks/ssd0/agent/llvm-project/llvm SILENT=1 TMPDIR= PYTHON_EXECUTABLE=/usr/bin/python3.8 COMPILER_RT=/mnt/disks/ssd0/agent/llvm-project/compiler-rt /mnt/disks/ssd0/agent/llvm-project/compiler-rt/lib/sanitizer_common/scripts/check_lint.sh
The following differences between the ABI list and the implemented custom wrappers have been found:

Should I be worried because of this, or is this that the patch started building when the main branch was broken? I haven't touched compiler-rt at all. Neither anything that deals with the sanitizers. And this fail is "earlier" than the previous one where I indeed missed a test file's update. (Previous fail was at ninja action multiple hundreds, this is 15.)

And it talks about a lot of stuff like fork and such that is really really out of scope for the patch itself.

Rule of thumb: If the test failures don't seem related to the contents of your patch, they can usually be disregarded as its likely something on trunk that is causing the failure.

whisperity marked 4 inline comments as done.

[NFC] Fixed nits and code formatting.

aaron.ballman accepted this revision.Apr 9 2021, 4:57 AM

This continues to LGTM, so I'm accepting it. If @alexfh has any remaining concerns, hopefully he can raise them quickly or we can handle them post-commit. Thanks!

whisperity removed 1 blocking reviewer(s): alexfh.Apr 10 2021, 7:44 AM
This revision is now accepted and ready to land.Apr 10 2021, 7:44 AM