feat: test error spans and messages

[asterite]

Description

Problem

Resolves #7455

Summary

Introduces a check_errors helper so we can to be used in frontend tests. Here's an example:

let src = "
fn main() -> pub i32 {
                 ^^^ expected i32 because of return type
    true        
    ~~~~ bool returned here
}
";
check_errors(src);

The idea is that "^^^" lines mark primary errors and "~~~" mark secondary errors.

Pros:

1. (in my opinion) It becomes easier to write these tests as we no longer need a long sequence of code to test thngs
2. The tests also become easier to understand as they include the error messages and their locations
3. We get to test error locations and make sure that's where we want them to be
4. New tests can be written, and be compiled, before the expected error is implemented
5. Multiple errors can be tested at once
6. The tests become more resilient to code refactors: if we change the structure of errors it would just affect the check_errors function
7. Tests are shorter (check the diff: +864, -2010)

Cons:

1. We no longer check the underlying type of the error, which might have been desired (not sure!)
2. We can no longer copy the test source code to a file and compile that without first removing the error squiggles (though this wasn't always possible before this PR, for example if a trait Default was introduced in a test it would conflict with the existing Default trait, etc.)

Additional Context

I decided to translate all tests here because after I started working on this I wanted to see it through, but also because I believe it would make things easier from now on, and we can also move faster.

As I translated tests I put some "TODO"s about small things to improve. Once this PR merges I'll create a follow-up issue to tackle those TODOs (here I decided not to change the compiler's code except in a couple of places where testing like this was impossible because of small bugs or unpredictability of the error messages).

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.

[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: 0857654	Previous: f0c1c7b	Ratio
AztecProtocol_aztec-packages_noir-projects_noir-protocol-circuits_crates_types	73 s	56 s	1.30

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

CC: @TomAFrench

[asterite]

(re-requested a review because previously it was a draft, now it's ready)

[jfecher]

Seeing this I can't help but wonder if we should have just started with golden tests all along

[asterite]

Ah, yes, using golden tests would also work. I guess we'd need to put frontend tests in a way similar to the ones in test_programs, right? Then, it wouldn't be as easy to write a test before introducing a new error, but it's not a big deal.

Another thing is that in these tests one can easily see the code and the errors at once. With golden tests I guess the code will be in one file and the error output will be in another one... which isn't a big deal either, though.

[jfecher]

LGTM.
This is moving us closer to a golden-tests style testing which is definitely more ergonomic to write tests for.

[jfecher]

Ah, yes, using golden tests would also work. I guess we'd need to put frontend tests in a way similar to the ones in test_programs, right? Then, it wouldn't be as easy to write a test before introducing a new error, but it's not a big deal.

Yeah, they'd probably need to be in a different folder to be more discoverable. You should still be able to write the test before the fix though. The program would just error in a different way (presumably) similar to running the frontend test today before the feature is implemented.

Another thing is that in these tests one can easily see the code and the errors at once. With golden tests I guess the code will be in one file and the error output will be in another one... which isn't a big deal either, though.

No, the code and output would be in the same file (see the examples of that repository I linked)

[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: 8cb8e0d	Previous: 3869fe9	Ratio
private-kernel-tail	1.218 s	0.988 s	1.23

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

CC: @TomAFrench

[TomAFrench]

We no longer check the underlying type of the error, which might have been desired (not sure!)

We can go some part of the way towards this with #7461 (but granted, we still lose full pattern matching)

[TomAFrench]

LGTM

[asterite]

We can go some part of the way towards this with #7461 (but granted, we still lose full pattern matching)

I guess once we add error codes we can include them like "^^^ [E1234] some message" and parse that (another big refactor, but a much simpler one)

[TomAFrench]

Yep, exactly