-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[analyzer] Set and display CSA analysis entry points as notes on debugging #84823
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,30 +1,43 @@ | ||
// RUN: %clang_analyze_cc1 -fblocks -analyzer-display-progress %s 2>&1 | FileCheck %s | ||
// RUN: %clang_analyze_cc1 -fblocks -verify %s 2>&1 \ | ||
// RUN: -analyzer-display-progress \ | ||
// RUN: -analyzer-checker=debug.ExprInspection \ | ||
// RUN: -analyzer-output=text \ | ||
// RUN: | FileCheck %s | ||
|
||
#include "Inputs/system-header-simulator-objc.h" | ||
|
||
static void f(void) {} | ||
void clang_analyzer_warnIfReached(); | ||
|
||
// expected-note@+2 {{[debug] analyzing from f}} | ||
// expected-warning@+1 {{REACHABLE}} expected-note@+1 {{REACHABLE}} | ||
static void f(void) { clang_analyzer_warnIfReached(); } | ||
|
||
@interface I: NSObject | ||
-(void)instanceMethod:(int)arg1 with:(int)arg2; | ||
+(void)classMethod; | ||
@end | ||
|
||
@implementation I | ||
-(void)instanceMethod:(int)arg1 with:(int)arg2 {} | ||
+(void)classMethod {} | ||
// expected-warning@+1 {{REACHABLE}} expected-note@+1 {{REACHABLE}} | ||
-(void)instanceMethod:(int)arg1 with:(int)arg2 { clang_analyzer_warnIfReached(); } | ||
|
||
// expected-warning@+1 {{REACHABLE}} expected-note@+1 {{REACHABLE}} | ||
+(void)classMethod { clang_analyzer_warnIfReached(); } | ||
@end | ||
|
||
// expected-note@+1 3 {{[debug] analyzing from g}} | ||
void g(I *i, int x, int y) { | ||
[I classMethod]; | ||
[i instanceMethod: x with: y]; | ||
[I classMethod]; // expected-note {{Calling 'classMethod'}} | ||
[i instanceMethod: x with: y]; // expected-note {{Calling 'instanceMethod:with:'}} | ||
|
||
void (^block)(void); | ||
block = ^{}; | ||
block(); | ||
// expected-warning@+1 {{REACHABLE}} expected-note@+1 {{REACHABLE}} | ||
block = ^{ clang_analyzer_warnIfReached(); }; | ||
block(); // expected-note {{Calling anonymous block}} | ||
} | ||
|
||
// CHECK: analyzer-display-progress.m f | ||
// CHECK: analyzer-display-progress.m -[I instanceMethod:with:] | ||
// CHECK: analyzer-display-progress.m +[I classMethod] | ||
// CHECK: analyzer-display-progress.m g | ||
// CHECK: analyzer-display-progress.m block (line: 22, col: 11) | ||
// CHECK: analyzer-display-progress.m block (line: 35, col: 11) |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a tiny bit worried that decl-with-issue and uniquing-location/decl are already too much to ask from the client of this interface (cf. #79398 and #80371), maybe we shouldn't be adding more stuff to this interface. It looks like you have a nice solution that doesn't force each checker to fill it in manually. But if we, say, plug clang-tidy into this interface (a long-term dream of mine that never materialized unfortunately, and that's entirely on me) then they'll have a lot of trouble filling this in.
Given that you seem to be mostly interested in path-sensitive reports, could it be easier to simply extract the decl simply pull the decl from the first path piece? (Yes, we have a Decl in every path piece.) (I'm pretty sure the first piece is always in the entry-point function, because at the very least you'll have a "Calling..." event before you inline a call.) (Or just take any path piece and find the top-level location context.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also had similar concerns as you, for similar reasons.
I'm indeed only interested in CSA issues. I also want to support the
check::ASTCodeBody
callback, from checkers can only emitBasicBugReports
, and not path sensitive ones - but notice that its fairly easy to get thedecl-with-issue
for them, it'sD
.Due to this, and for the fact that we have some downstream legacy checkers that does something like this and only emits
BasicBugReports
, I opted for taking this in the ctor.Do you have specific suggestions or scenarios to consider?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, this is a debug feature. Debug features are great but it's probably ok to have them slightly incorrect or incomplete if it means that they're no longer associated with increased complexity, with paying for something we don't use.
Out of those AST checkers, how many are emitting diagnostics outside of the entry function / decl-with-issue function? If you append
to every message bubble, would that entirely cover all your needs?
I can easily see how there could be a checker that always warns outside of the entry function. If that's the case then it's probably incredibly useful for debugging to quickly know which entry function inspired the warning. But at the same time I'm not sure I can think of a good example when the same information wouldn't be useful for the user as well; maybe the users could benefit from a user-facing note too? (Somewhat similarly to how Clang explains template instantiation stack when diagnosing problems in individual template instantiations. (Something we cannot mimic in static analysis tools because the instantiation stack is already lost.))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBH I'm pretty discontent with my implementation. This was basically the third attempt and the so far the cleanest - but it's still bad. The whole diagnostic pipeline is just a mess.
Do you imply I should relax the PathDiagnostic ctor precondition to allow nullptr entry point decls?
From the name
Path
I judged, the entry point must be always present.I'm not sure what "bubble" refers to, but if it's a synonym for "note" or "message", then yes - plus:
The entry point decl would be also beneficial for a primitive caching mechanism to know what reports we need to invalidate if a given decl changes across subsequent static analyzer runs on different git commits. I'll present the idea at EuroLLVM next week, but the gist of it is basically that we associate each diagnostic with a decl, hash that decl; and if subsequent runs hash that decl to the same value, then we can replay the diagnostic and skipping the entry point. To achieve this, we of course need to know the entry point.
I'm natural for having these notes (or a slightly differently phrased notes) denoting the start of the analysis.
If you think it would be genuinely useful, I could add it.