-
-
Notifications
You must be signed in to change notification settings - Fork 267
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
Fixed issue #426 — dtor / destructor not called for (rvalue) struct used in opApply #427
Conversation
Just laying down the ground work before fixing issue 426.
…ariables in a try/finally expression.
… it is required (i.e. there are actually some destructor calls that are needed to be put into finally)
…alue) struct used in opApply
Yep, I had limited it to TOKcall's myself. As you also get cases (mostly TOKcomma's) where asserts could be thrown during the initialisation of the temporary, so the temporary is left in an invalid state, and because of finally { } the destructor is called on the temporary despite never being initialised! |
@ibuclaw, thanks again. Per your suggestion, I had limited it to TOKCall's as well. I didn't have to special-case TOKcomma's, though. |
oh, TOKcomma special case is just makes the codegen neater, and is not needed. |
Fixed issue #426 — dtor / destructor not called for (rvalue) struct used in opApply
replace rt.qsort with libc wrapper
This probably caused #795. |
Fixing the bug turned out to be a lot more work than I expected.
The first obstacle I encountered was that
IRLandingPad
class we use to generate exception handling code expected finally block to be dmdfe'sStatement
. Which temp variables destructor calls are not. So in order to fix the issue, I had to extendIRLandingPad
API a little bit to have more control over eh codegen.Once I had the updated API at my disposal, I made the first attempt at fixing the issue. I followed @ibuclaw suggestion and wrapped the destructor calls in
Expression::toElemDtor
in try-finally. While it fixed the issue at hand, the number of generated landing pads had been highly increased. Essentially, it was not possible to write any code without triggering eh codegen.And here goes the third part of my patch. As you probably guessed, the majority of
Expression::toElemDtor()
calls does not need to call any destructors. Previously, we had a classical chicken-and-egg problem: in order to decide whether or not a try-finally is required, we needed a number of temporary variables, but to get it, we had to run the expression codegen at which point we had to know whether a try-finally is required. As a solution, I created anExpression
tree walker that looks for the temporary variables before the codegen.