feat: prefix operator overload trait dispatch

[asterite]

Description

Problem

Resolves #5000

Summary

Allows impl Not and impl Neg to be picked up at runtime.

Note that this doesn't work yet at comptime: I'd prefer to do it in a separate PR (mainly to keep PR smaller, but also because I'm not sure how to test it).

Additional Context

None.

Documentation

Is documentation needed for this?

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[jfecher]

Note that this doesn't work yet at comptime: I'd prefer to do it in a separate PR (mainly to keep PR smaller, but also because I'm not sure how to test it).

You can test it with a comptime block:

struct MyType {}

impl Neg for MyType { ... }

fn main() {
    comptime {
        let value = MyType {};
        let _result = -value;
    }
}

[jfecher]

Spoke on slack - looks like there's a panic with this PR when we try to do assert_eq(!0, 1);:

The application panicked (crashed).
Message:  attempt to shift left with overflow
Location: compiler/noirc_evaluator/src/ssa/acir_gen/acir_ir/acir_variable.rs:691

[asterite]

Sounds good! But... I don't know how to fix it. When there's !0 we can't determine the type of 0. It can be any integer type, including Field. The problem is that there's no ! for Field.

Maybe in when !0 is found, the type variable for 0 should go from "polymorphic integer or field" to "polymorphic integer". Would that make sense?

[asterite]

I think I got it working, it now produces this error:

error: Types in a binary operation should match, but found Field and u32
  ┌─ /Users/asterite/Sandbox/noir_programs/one/src/main.nr:3:5
  │
3 │     assert_eq(!0, num);
  │     ------------------

That said, I'm not sure that I did it right as I'm learning how things are done. I'll push a commit for this.

That's with this program:

fn main() {
    let num: Field = 0;
    assert_eq(!0, num);
}

[jfecher]

When there's !0 we can't determine the type of 0. It can be any integer type, including Field.

It should not be able to be any integer type including field since the usage of a bitwise ! should restrict it to only an integer type

Maybe in when !0 is found, the type variable for 0 should go from "polymorphic integer or field" to "polymorphic integer". Would that make sense?

Exactly - there may be some difficulties though. Notably since we allow overloading ! for any type now we probably won't want to narrow TypeVariableKind::Normal to only an integer. That'd prevent using it with an overloaded impl in certain cases. It may help to look at a check that is done for the bit shifting operators that can also be overloaded. That check is here: https://github.com/noir-lang/noir/blob/master/compiler/noirc_frontend/src/elaborator/types.rs#L1004-L1017

[jfecher]

error: Types in a binary operation should match, but found Field and u32
  ┌─ /Users/asterite/Sandbox/noir_programs/one/src/main.nr:3:5
  │
3 │     assert_eq(!0, num);
  │     ------------------

Looks like the lhs and rhs types are being switched here for some reason. I'd expect !0 to be the u32 and num to be the Field but otherwise this is the error I'd expect when using a Field variable with a u32 literal here.

The switched lhs & rhs positions are probably an existing bug, you don't need to worry about that one.
... although I should probably log it to fix later

[asterite]

Looks like the lhs and rhs types are being switched here for some reason

I also noticed that but I thought it was an existing bug. But then if I do this:

fn main() {
    let num: Field = 0;
    let zero: u32 = 0;
    assert_eq(!zero, num);
}

it says "Types in a binary operation should match, but found u32 and Field", so maybe what I did is wrong and it ends up changing the incorrect types?

[jfecher]

it says "Types in a binary operation should match, but found u32 and Field", so maybe what I did is wrong and it ends up changing the incorrect types?

Possibly, I'll take a look at the prefix operator method again

Edit: I think it is just an existing bug that is happening to show itself now that more type variables are involved in prefix operations. Since we can bind to integer type variables now instead of just bool by default.

[jfecher]

assert_eq(!0, -1) no longer panics at me.

We do issue a "-1 is out of bounds for u32" error, but this makes sense to me and is what I'd expect.