Incorrect type inference for bit_not on unsigned integer

[gladiatorcasino]

Aim

The return type of the bit_not operator is not correctly inferred when used on an unsigned integer.
Given the statement:

let a: u32 = 3 & !1;

The type of 3 is inferred to be Field, and the type of !1 is inferred to be bool. Both of these are incorrect. The compiler throws an error message complaining that the & operator is operating on two imcompatible types: Field and bool.

Without the !1 part, i.e., let a: u32 = 3 & 1;, the compiler correctly infers all the data types and the compilation succeeds.

Expected Behavior

The compiler should correctly handle the bitwise not operator and infer the type as unsigned integer.

Bug

Run nargo new bit_not and replace the contents of src/main.rs with the following:

fn main() {
    let a: u32 = 3 & !1;
}

Run nargo check and observe the following error message:

warning: unused variable a
  ┌─ /home/gladiatorcasino/bit_not/src/main.nr:2:9
  │
2 │     let a: u32 = 3 & !1;
  │         - unused variable
  │

error: Expected type bool, found type Field
  ┌─ /home/gladiatorcasino/bit_not/src/main.nr:2:23
  │
2 │     let a: u32 = 3 & !1;
  │                       -
  │

error: Types in a binary operation should match, but found Field and bool
  ┌─ /home/gladiatorcasino/bit_not/src/main.nr:2:18
  │
2 │     let a: u32 = 3 & !1;
  │                  ------
  │

Error: Aborting due to 2 previous errors

Location:
    crates/nargo_cli/src/cli/mod.rs:79:5

To Reproduce

1. Run nargo new bit_not and replace the contents of src/main.rs with the code above.
2. Run nargo check.

Installation Method

Binary

Nargo Version

nargo 0.10.5 (git version hash: 9fe4cfd, is dirty: false)

Additional Context

No response

Would you like to submit a PR for this Issue?

No

Support Needs

No response

[TomAFrench]

Confirming this issue still exists in master.

[TomAFrench]

There's a good chance this is fixed by @michaeljklein's recent work. Will check today.

Edit: it wasn't

[asterite]

This seems to be working fine now. I think it's because we now let ! dispatch to a trait and so !1 will make 1 be any integer type that supports the ! operator.

To see the deduced types, with inlay hints:

[asterite]

Reopening to add a regression test.