Skip to content

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

Closed
wants to merge 17 commits into from

Conversation

foobles
Copy link
Contributor

@foobles foobles commented Apr 15, 2020

This will allow code like this to function at compile time, partially implementing #1332:

const x: ?i32 = get_some_optional();
const y: ?i32 = get_another_optional();
if (x == y) {
    do_a_thing();
}

if (x != y) {
    do_another_thing();
}

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 given op1/op2->base, or bin_op_instruction->base.base for the source_instr parameter.

foobles added 15 commits April 13, 2020 17:20
…; 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.
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.
@foobles foobles changed the title Compile-time comparison of optionals Compile-time comparison of optionals (== / !=) Apr 15, 2020
@mikdusan
Copy link
Member

One thing I am not completely sure about: when calling ir_analyze_optional_value_payload_value(), I am not sure if it should be given op1/op2->base, or bin_op_instruction->base.base for the source_instr parameter.

foo.zig

export fn entry() void {
    var oa: ?u32 = 999;
    var a = oa orelse 0;
    if (oa) |uw| {}
}

ir_analyze_optional_value_payload_value seems to be a pretty rare call, so trapping for ir_analyze_unwrap_optional_payload instead the above source code hits 3 times:

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

@foobles
Copy link
Contributor Author

foobles commented Apr 15, 2020

@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.

@foobles foobles closed this Apr 19, 2020
@foobles
Copy link
Contributor Author

foobles commented Apr 19, 2020

This did not have intended behavior. I will be back soon with a correct version also with runtime support.

@foobles foobles deleted the compare-optionals branch April 19, 2020 07:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants