Fix #419 by disallowing bitwise operations on fields during type checking

[jfecher]

Related issue(s)

Resolves #419

Description

Summary of changes

This PR makes it a type error to use any of &, |, ^, <<, or >> on a Field type. The error message suggests users cast to a sized integer type beforehand.

In the case the operand types for a bitwise operator are still unknown, this PR introduces a delayed type error that is checked when the function as a whole is finished. This allows for cases like let x: u8 = 2 << 3; to be valid as the types of 2 and 3 are later resolved to u8, while still keeping ambiguous cases invalid. If the types are still ambiguous when the function is finished type checking, an error is issues explaining type annotations are needed to know how many bits to perform the bitwise operations on.

Test additions / changes

None

Checklist

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt with default settings.
• I have linked this PR to the issue(s) that it resolves.
• I have reviewed the changes on GitHub, line by line.
• I have ensured all changes are covered in the description.

Additional context

The delayed type error mechanism added by this PR is a workaround over splitting PolymorphicInt into PolymorphicInt and PolymorphicIntOrField which turned out to be more work.

[jfecher]

Example of what these errors look like:

error: Bitwise operations are invalid on Field types. Try casting the operands to a sized integer type first.
  ┌─ /.../src/main.nr:4:20
  │
4 │     let b: Field = a << 4;
  │                    ------

error: The number of bits to use for this bitwise operation is ambiguous. The type of at least one operand should be specified before this point
  ┌─ /.../src/main.nr:6:14
  │
6 │     let _c = 2 << 4;
  │              ------

error: aborting due to 2 previous errors
exit 1

[vezenovm]

I think PR is good. I left one question but it is non-blocking. When CI passes we can merge

[vezenovm]

This looks good to me now