-
Notifications
You must be signed in to change notification settings - Fork 90
Adding Static Analysis and other checks to clang-tidy #810
Changes from all commits
d28757c
e2d1836
de52636
237ab82
d001d40
0547491
2aad17b
de18941
0d3fe1b
8dbc625
cf87d70
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -102,7 +102,11 @@ extern "C" | |
| { | ||
| for (int i = increment; i < 0; i++) | ||
| { | ||
| (void)callable->Release(); | ||
| if (0 == callable->Release()) | ||
| { | ||
| assert(-1 == i && "Attempting to decrement reference count below zero!"); | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: I'm not sure I like this pattern, though honestly there isn't anything functionally wrong here. It just seems odd that this assert message would show up only if the reference count was updated with a decrement value less than -1, where if the decrement is exactly -1 (our compiler's QIR default) on an item of 0 references then the assert from within
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm totally with you on our scenario. But looks like the static analyzer has considered a different scenario and complained for a possible released (dangling) pointer dereference. I'll try to tell what I remember. Let's consider a Before this change, the value I agreed with the complaint from the static analyzer and tried to prevent the UB with an assert (in green line 107). I don't state that my change is the best fix (e.g. the
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, that's a great point! I had incorrectly assumed |
||
| break; | ||
| } | ||
| } | ||
| } | ||
| } | ||
|
|
||
This file was deleted.
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.
Is it worthwhile that we use same style for variable names? In the passes code, we use snake case for variables.
Uh oh!
There was an error while loading. Please reload this page.
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 believe everybody would benefit from the same coding style in QIR RT and Passes. I personally don't have particular preference. I'm fine with camelBack or snake_case or other.
Added #817.