Fixed issue #426 — dtor / destructor not called for (rvalue) struct used in opApply #427
+167
−65
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.