-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Option not playing nice with ref type #16754
Comments
The real cause is that The Option*[T] = object
when T is SomePointer:
val: T
else:
val: T
has: bool
Option*[T] = object
val: T
has: bool too early. @Araq, I need your input on the right approach to fix it |
Not sure why you say it isn't ARC specific. It works fine with the default GC, but it appears to evaluate |
@PMunch I think for a non-compiler dev it is ARC specific, but for a compiler developer that is misleading as it's not an ARC bug but a type graph bug with different consequences depending on which GC you use. |
Ah I see what you mean. So fixing it would mean ARC would work and non-ARC would actually use the pointer is |
This issue bit me recently in the context of defining a Norm model: https://forum.nim-lang.org/t/8853 |
maybe similar to #14758 |
ARC generates bad C code for
Option
of a nested ref type.Example
Current Output
Possible Solution
Not sure what causes this, possibly related to #14387 and #9566, but this only happens for ARC. A workaround is to split the type:
Additional Information
The text was updated successfully, but these errors were encountered: