fix!: disallow casting numeric to bool

[asterite]

Description

Problem

Resolves #8157

Summary

This seems to be a big breaking change but I think we should still disallow it. Casting using as for numeric values means truncating or extending a value. When casting a u32 to u1 we only keep the least significant byte, so casting 1 to u1 gives 0, but casting 2 to u1 gives 0. But when casting u32 to bool it's not clear what should happen: is the rule that 0 is false and 1 is true, or is the least significant byte what's used (similar to u1). Or maybe 0 is false, 1 is true and everything else is...? That's my guess of why Rust disallows this and asks to compare with zero, because like that there's no room for confusion.

The other way around, that is, casting from bool to a numeric value, is allowed in Rust and is still allowed in Noir. Here we get 0 for false and 1 for true, but I think that's expected (you wouldn't expect any other values here).

Additional Context

Documentation

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.

[asterite]

Oh, no! It seems that before this PR casting a numeric value to bool actually truncates the number to one bit, then that bit is the one used for the bool. That means that casting 2 to bool gives false 😨 This is why AztecProtocol/aztec-packages#14593 is likely failing.

What I mean is that this program:

fn main(x: Field) -> pub bool {
    x as bool
}

is generating this SSA:

acir(inline) pure fn main f0 {
  b0(v0: Field):
    v1 = truncate v0 to 1 bits, max_bit_size: 254
    v2 = cast v1 as u1
    return v2
}

[vezenovm]

It seems that before this PR casting a numeric value to bool actually truncates the number to one bit, then that bit is the one used for the bool. That means that casting 2 to bool gives false 😨 This is why AztecProtocol/aztec-packages#14593 is likely failing.

Ahhh! 😨

Your intuition about the failure makes sense. This just reiterates to me that we should disallow casting to bool. as bool makes me think "anything but zero is true", which is more semantically correct by doing != 0. For 2 as u1 I do expect zero as the result.

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Compilation Time'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: cac462c	Previous: af2e5c9	Ratio
private-kernel-reset	8.588 s	6.96 s	1.23

This comment was automatically generated by workflow using github-action-benchmark.

CC: @TomAFrench

[asterite]

The only thing remaining now is releasing a new version of noir-bignum (0.7.3), then using that in Aztec-Packages , noir_bigcurve and noir_rsa.

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Test Suite Duration'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: 2ae02a2	Previous: d6e4ce9	Ratio
test_report_AztecProtocol_aztec-packages_noir-projects_noir-protocol-circuits_crates_rollup-lib	246 s	190 s	1.29

This comment was automatically generated by workflow using github-action-benchmark.

CC: @TomAFrench

[github-actions]

Changes to circuit sizes

Generated at commit: 86d1d598c0f82aa8166d4f71d4700f12a10da706, compared to commit: ce2fc37fd6286094df139308b90177df4a95c608

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
brillig_not	-16 ✅	-61.54%	-2,799 ✅	-99.22%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
brillig_not	10 (-16)	-61.54%	22 (-2,799)	-99.22%

[github-actions]

Changes to Brillig bytecode sizes

Generated at commit: 86d1d598c0f82aa8166d4f71d4700f12a10da706, compared to commit: ce2fc37fd6286094df139308b90177df4a95c608

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
brillig_not_inliner_max	-4 ✅	-10.81%
brillig_not_inliner_min	-4 ✅	-10.81%
brillig_not_inliner_zero	-4 ✅	-10.81%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
brillig_not_inliner_max	33 (-4)	-10.81%
brillig_not_inliner_min	33 (-4)	-10.81%
brillig_not_inliner_zero	33 (-4)	-10.81%

[github-actions]

Changes to number of Brillig opcodes executed

Generated at commit: 86d1d598c0f82aa8166d4f71d4700f12a10da706, compared to commit: ce2fc37fd6286094df139308b90177df4a95c608

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
brillig_not_inliner_max	-4 ✅	-12.90%
brillig_not_inliner_min	-4 ✅	-12.90%
brillig_not_inliner_zero	-4 ✅	-12.90%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
brillig_not_inliner_max	27 (-4)	-12.90%
brillig_not_inliner_min	27 (-4)	-12.90%
brillig_not_inliner_zero	27 (-4)	-12.90%

[asterite]

The "performance improvements" are just because I had to remove some code from test programs that checked that casting numbers to bools worked well.

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Execution Time'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: 8262724	Previous: ce2fc37	Ratio
rollup-merge	0.004 s	0.003 s	1.33

This comment was automatically generated by workflow using github-action-benchmark.

CC: @TomAFrench