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
Fix Issue 18688 - Constructors shouldn't have implicit super call if it throws #8100
Conversation
Thanks for your pull request and interest in making D better, @RazvanN7! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please see CONTRIBUTING.md for more information. If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment. Bugzilla references
Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub fetch digger
dub run digger -- build "master + dmd#8100" |
@@ -0,0 +1,43 @@ | |||
class A |
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.
Please add:
// https://issues.dlang.org/show_bug.cgi?id=18688
test/compilable/test18688.d
Outdated
} | ||
} | ||
|
||
void main() {} |
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.
Not needed for compile-only tests
@WalterBright Done. Thank you! |
jenkins is failing, but when inspecting the problem looks like all the tests pass. I find the matter puzzling... Later edit: I restarted the tests, hope this will solve the case |
If you look at the log (button at the top right), you can see:
It's some variation of:
In short: it's due to dlang/ci using cheap preemptible GCE instances which can get terminated while the build runs. |
Windows failure is unrelated -> braddr/d-tester#71 |
The problem with this is that if an
assert(false);
is encountered the scope of the function in which the assert is located is marked ashalt
no matter where the assert is located. Let's take for example the bug report:When
this(1)
is semantically analyzed, the scope is not updated to reflect that a constructor call is issued because it is considered that the line is not reachable, due to theassert(false)
. This is obviously wrong since the code is reachable in some situations. The fix makes it so that the scope is updated to reflect that a this/super call is issued even if inside a halt scope.