-
Notifications
You must be signed in to change notification settings - Fork 1.8k
C++: First-class destructors in AST #15318
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
C++: First-class destructors in AST #15318
Conversation
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 started reviewing this before I noticed it was a draft. Sorry! Feel free to ignore my comments if you're still working all these things out 😄
/** | ||
* Gets the `n`th compiler-generated destructor call that is performed after this expression, in | ||
* order of destruction. | ||
*/ |
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 think it would be good to have an example here (specifically, for when there are multiple destructors attached to an element).
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 think this would still be good, but given that we don't actually generate any such destructor calls yet this can wait 🙈
* Gets the `n`th compiler-generated destructor call that is performed after this expression, in | ||
* order of destruction. | ||
*/ | ||
DestructorCall getSyntheticDestructor(int n) { |
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.
Could we avoid using the term "synthetic" in the public API? I don't actually know why the relational is using this term, because I don't think there's anything more "synthetic" about these destructor calls than other things in the AST
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.
Maybe getImplicitDestructor
instead?
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.
Sounds good to me. Maybe even getImplicitDestructorCall
since this is really the call to the destructor?
result = expr.getParentWithConversions() | ||
or | ||
result.(Destructor).getADestruction() = expr | ||
or | ||
result.(Expr).getASyntheticDestructor() = expr | ||
or | ||
result.(Stmt).getASyntheticDestructor() = expr |
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 ever the case that an expr
has multiple parents with these new cases included?
( | ||
call instanceof ConstructorCall or | ||
call instanceof DestructorCall | ||
) and |
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.
The comment above here is no longer correct, right? i.e., this part:
// Don't bother with destructor calls for now, since we won't see very many of them in the IR
// until we start injecting implicit destructor calls.
99b4e63
to
278b22c
Compare
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 think this all LGTM, @rdmarsh2! I think we can just take this out of draft and merge it (after accepting the test changes)?
/** | ||
* Gets the `n`th compiler-generated destructor call that is performed after this expression, in | ||
* order of destruction. | ||
*/ |
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 think this would still be good, but given that we don't actually generate any such destructor calls yet this can wait 🙈
The failing test is in the internal repo, so I'll need to open a PR there and do a synchronized merge. |
64769a1
to
0bc0231
Compare
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.
LGTM! I don't think we should put any change notes here until we properly support destructor calls associated with expressions
# 619| Type = [PointerType] const char * | ||
# 619| ValueCategory = prvalue | ||
# 620| getStmt(4): [ReturnStmt] return ... | ||
# 620| getImplicitDestructorCall(0): [DestructorCall] call to ~String |
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.
This can be done in a separate PR, but I wonder if we should print these in the order in which they should be called, which is from the highest to the lowest index:
codeql/cpp/ql/lib/semmlecode.cpp.dbscheme
Lines 1122 to 1127 in 32a2ea1
/** | |
* `destructor_call` destructs the `i`'th entity that should be | |
* destructed following `element`. Note that entities should be | |
* destructed in reverse construction order, so for a given `element` | |
* these should be called from highest to lowest `i`. | |
*/ |
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.
They already are - I reversed the indexes from the dbscheme order in getImplicitDestructorCall
, so index 0 should be the first to be destructed.
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 see now. I was clearly not reading the code correctly 🤦 . Thanks for clarifying.
This PR adds a new
getSyntheticDestructor
predicate toStmt
andExpr
, and adds destructors to the IR. Currently only theStmt
relation is populated by the extractor.