Skip to content

Conversation

rdmarsh2
Copy link
Contributor

This PR adds a new getSyntheticDestructor predicate to Stmt and Expr, and adds destructors to the IR. Currently only the Stmt relation is populated by the extractor.

@github-actions github-actions bot added the C++ label Jan 12, 2024
Copy link
Contributor

@MathiasVP MathiasVP left a 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 😄

Comment on lines +61 to +64
/**
* Gets the `n`th compiler-generated destructor call that is performed after this expression, in
* order of destruction.
*/
Copy link
Contributor

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).

Copy link
Contributor

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) {
Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe getImplicitDestructor instead?

Copy link
Contributor

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?

Comment on lines 24 to 30
result = expr.getParentWithConversions()
or
result.(Destructor).getADestruction() = expr
or
result.(Expr).getASyntheticDestructor() = expr
or
result.(Stmt).getASyntheticDestructor() = expr
Copy link
Contributor

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?

Comment on lines 753 to 756
(
call instanceof ConstructorCall or
call instanceof DestructorCall
) and
Copy link
Contributor

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.

@rdmarsh2 rdmarsh2 force-pushed the rdmarsh2/cpp/first-class-destructors branch from 99b4e63 to 278b22c Compare January 19, 2024 17:30
@rdmarsh2 rdmarsh2 changed the title C++: First-class destructors in AST and IR C++: First-class destructors in AST Jan 23, 2024
Copy link
Contributor

@MathiasVP MathiasVP left a 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)?

Comment on lines +61 to +64
/**
* Gets the `n`th compiler-generated destructor call that is performed after this expression, in
* order of destruction.
*/
Copy link
Contributor

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 🙈

@rdmarsh2
Copy link
Contributor Author

The failing test is in the internal repo, so I'll need to open a PR there and do a synchronized merge.

@rdmarsh2 rdmarsh2 marked this pull request as ready for review January 24, 2024 18:35
@rdmarsh2 rdmarsh2 requested a review from a team as a code owner January 24, 2024 18:35
@rdmarsh2 rdmarsh2 added the depends on internal PR This PR should only be merged in sync with an internal Semmle PR label Jan 24, 2024
@rdmarsh2 rdmarsh2 force-pushed the rdmarsh2/cpp/first-class-destructors branch from 64769a1 to 0bc0231 Compare January 24, 2024 18:53
Copy link
Contributor

@MathiasVP MathiasVP left a 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
Copy link
Contributor

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:

/**
* `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`.
*/

Copy link
Contributor Author

@rdmarsh2 rdmarsh2 Jan 24, 2024

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.

Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C++ depends on internal PR This PR should only be merged in sync with an internal Semmle PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants