-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Compile-time comparison of optionals (== / !=) #5044
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
Conversation
…; allowed comparison of optionals of comparable types, but actual implementation not complete
…types. added failing test to ensure it is hit. ensured nullable pointer comparison still works as before.
… takes the ops as parameters directly. Will be useful when recursing.
…s (assertion error)
… building an instruction
Before, it reassigned to op1/op2->value and directly accessed op1/op2->value.data.x_optional. The reassignment was likely incorrect, and accessing x_optional directly is incorrect in some edge cases. Using ir_analyze_optional_value_payload_value both creates a new value and handles those cases on its own.
|
source_instr | line:col | base_ptr | line:col |
---|---|---|---|
999 |
2:20 | var |
2:5 |
orelse |
3:16 | var |
2:5 |
if |
4:15 | var |
2:5 |
so I'd say bin_op_instruction
is good for source_instr
@mikdusan Alright, I fixed it. I also added error checking after the unwraps, which after looking in the other code that uses the function, seems necessary. |
This did not have intended behavior. I will be back soon with a correct version also with runtime support. |
This will allow code like this to function at compile time, partially implementing #1332:
Which currently only works for optional pointers.
I will work on making this runtime soon.
One thing I am not completely sure about: when calling
ir_analyze_optional_value_payload_value()
, I am not sure if it should be givenop1/op2->base
, orbin_op_instruction->base.base
for thesource_instr
parameter.