This is an archive of the discontinued LLVM Phabricator instance.

[analyzer] Prefer returns values to out-params in CheckerRegistry.cpp
ClosedPublic

Authored by Szelethus on Nov 11 2018, 2:17 PM.

Details

Summary

This bugged me for a long time, so it's time to put an end to it: collectCheckers was cryptic and hard to understand. This is done by

  • Renaming collectCheckers to getEnabledCheckers
  • Changing the functionality to acquire all enabled checkers, rather then collect checkers for a specific CheckerOptInfo (for example, collecting all checkers for { "core", true }, which meant enabling all checkers from the core package, which was an unnecessary complication).
  • Removing CheckerOptInfo, instead of storing whether the option was claimed via a field, we handle errors immediately, as getEnabledCheckers can now access a DiagnosticsEngine. Realize that the remaining information it stored is directly accessible through AnalyzerOptions.CheckerControlList.
  • Fix a test with -analyzer-disable-checker -verify accidentally left in.

Diff Detail

Event Timeline

Szelethus created this revision.Nov 11 2018, 2:17 PM
Szelethus updated this revision to Diff 173584.Nov 11 2018, 2:17 PM

Also, remove diags::note_suggest_disabling_all_checkers.

MTC added a comment.Nov 12 2018, 5:47 AM

I'm totally fine with this patch personally. However I am not familiar with this part, so can't give substantial help :).

lib/StaticAnalyzer/Core/CheckerRegistry.cpp
49–90

I just curious about the reason why you move the CheckerInfoSet from the parameter passing by reference to the return value, keep the number of parameter at a lower value? Or make the code at the caller cite cleaner?

Thanks for taking a look! ^-^

lib/StaticAnalyzer/Core/CheckerRegistry.cpp
49–90

Both, actually. From what I've seen, out-params usually lead to much harder to comprehend code.

Szelethus set the repository for this revision to rC Clang.

Might as well make it a method.

include/clang/Basic/DiagnosticFrontendKinds.td
177

@NoQ what does this option even do? Can you think of some legitimate uses?

Also, remove diags::note_suggest_disabling_all_checkers.

Isn't that a separate revision? Given that removing existing options is often questionable, I'd much rather see this patch separated.

Also, remove diags::note_suggest_disabling_all_checkers.

Isn't that a separate revision? Given that removing existing options is often questionable, I'd much rather see this patch separated.

This isn't an option, just a note :)

NoQ added inline comments.Nov 12 2018, 12:01 PM
include/clang/Basic/DiagnosticFrontendKinds.td
177

rC216763 is the commit in which it was added and the commit message sounds useful. I never understood how exactly are people using it, but it sounds as if they are trying to skip analysis of certain files by appending a flag that disables checkers to the build(?!) command of those files.

Szelethus added inline comments.Nov 12 2018, 12:07 PM
include/clang/Basic/DiagnosticFrontendKinds.td
177

Okay, let's move this to another revision then.

Szelethus updated this revision to Diff 173745.Nov 12 2018, 1:12 PM
Szelethus edited the summary of this revision. (Show Details)

Restored the discussed note.

NoQ added a subscriber: alexfh.Nov 30 2018, 3:40 PM

The code looks good, but i vaguely remember that we might accidentally break clang-tidy integration that uses this API to enable/disable specific checkers via -checks=-analyzer-....

*summons @alexfh*

*advanced summoning*

alexfh added a comment.Dec 4 2018, 3:46 AM
In D54401#1315354, @NoQ wrote:

The code looks good, but i vaguely remember that we might accidentally break clang-tidy integration that uses this API to enable/disable specific checkers via -checks=-analyzer-....

*summons @alexfh*

It's hard to tell without trying. Could you build and test clang-tools-extra with this patch? There should be a test for the relevant functionality in clang-tidy.

In D54401#1315354, @NoQ wrote:

The code looks good, but i vaguely remember that we might accidentally break clang-tidy integration that uses this API to enable/disable specific checkers via -checks=-analyzer-....

*summons @alexfh*

It's hard to tell without trying. Could you build and test clang-tools-extra with this patch? There should be a test for the relevant functionality in clang-tidy.

It compiles without problem, and check-all doesn't produce a single clang-tools-extra failure. Yay!

alexfh accepted this revision.Dec 6 2018, 6:43 AM
In D54401#1315354, @NoQ wrote:

The code looks good, but i vaguely remember that we might accidentally break clang-tidy integration that uses this API to enable/disable specific checkers via -checks=-analyzer-....

*summons @alexfh*

It's hard to tell without trying. Could you build and test clang-tools-extra with this patch? There should be a test for the relevant functionality in clang-tidy.

It compiles without problem, and check-all doesn't produce a single clang-tools-extra failure. Yay!

Then I have no concerns.

This revision is now accepted and ready to land.Dec 6 2018, 6:43 AM

Thanks! I'll commit in a couple days to give some breathing room for anyone who'd object.

Szelethus closed this revision.Dec 15 2018, 8:24 AM

Commited in rC349274.