-
-
Notifications
You must be signed in to change notification settings - Fork 594
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
Issue 24118 - ICE / regression from 2.103.1 - segfault on CTFE only code in 2.104.2 and 2.105.0 #15578
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 run digger -- build "stable + dmd#15578" |
Is this issue not that we are generating code at all in __ctfe if statements? |
Also commit message looks wrong |
Nope, ctfe block is not generated, but template instances from it are. |
0a0dc37
to
f1ea63e
Compare
I thought we fixed that oof |
(This is another thing that a dependency graph would help with, more on that shortly) |
f1ea63e
to
6b131cf
Compare
6b131cf
to
ce6e3f6
Compare
@maxhaton ok with this fix? |
It looks ok although if possible having the tracegc && needsCodegen pattern as a variable would be good, if you can think of a clean way of doing it. |
ce6e3f6
to
d3fe235
Compare
@maxhaton Done. |
…ly code in 2.104.2 and 2.105.0
d3fe235
to
0f76973
Compare
The problem here is that when a lambda is passed to a template instance, the lambda call is inlined in the template instance. The context of the lambda is __ctfe so the compiler decides to not create a lowering for it, however, the template instance is still generated (without the lowering) thus causing the current regression.
A general solution would be to mark template instances as not needing code generation when instantiated from a speculative context, however, this is not easy to implement given the current caching strategy of template instances.
Until we fix that, we need to bail out of not generating the compiler hook call to avoid ices in e2ir.