Rust: Prune CFG for obviously impossible true/false edges
#17602
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| /** | ||
| * A completion that represents evaluation of an expression | ||
| * with a Boolean value. | ||
| */ | ||
| class BooleanCompletion extends ConditionalCompletion, TBooleanCompletion { | ||
| BooleanCompletion() { this = TBooleanCompletion(value) } | ||
|
|
||
| override predicate isValidForSpecific(AstNode e) { | ||
| private predicate isValidForSpecific0(AstNode e) { |
Check warning
Code scanning / CodeQL
Candidate predicate not marked as `nomagic` Warning
hvitved
changed the title
true/false edgestrue/false edges
| private predicate isBooleanConstant(AstNode n, Boolean value) { | ||
| n.(LiteralExpr).getTextValue() = value.toString() | ||
| or | ||
| isBooleanConstant(n.(ParenExpr).getExpr(), value) |
There was a problem hiding this comment.
This looks a little odd. What about parentheses around other expressions? I'd have expected something like:
...
or
parent = any(BlockExpr be | e = be.getStmtList().getTailExpr())
or
parent = any(ParenExpr pe | e = pe.getExpr())
There was a problem hiding this comment.
Actually, the ParenExpr case is a workaround for now; once we add ConditonalSplitting a la Ruby, we will only need the LiteralExpr case, and edges out of ParenExpr, BlockExpr, etc will then be restricted via splitting.
There was a problem hiding this comment.
Makes sense, I was just surprised to see that ParenExpr was handled differently than BlockExpr. The control flow of {{{expr}}} isn't very different from (((expr))).
| override predicate isValidForSpecific(AstNode e) { | ||
| this.isValidForSpecific0(e) and | ||
| ( | ||
| isBooleanConstant(e, value) |
There was a problem hiding this comment.
I would have expected some logic in the last() predicate of a LiteralExprTree that restricts the outgoing edge for a boolean literal to matching ConditionalCompletion.
There was a problem hiding this comment.
That happens automatically via the completionIsValidFor predicate.
There was a problem hiding this comment.
It's not really "automatic", is it? You either handle it explicitly in isValidForSpecific or in LiteralExprTree . Either way should be fine, I just have a slight preference for handling it in LiteralExprTree. In the end it is a matter of "taste", so let's leave it the way you prefer.
In preparation for #17525.
For now, only recognize simple (parenthesized) Boolean literals.