feat: Allow associated types to be ellided from trait constraints

[jfecher]

Description

Problem*

Resolves #6571 (but does not implement #6811)
Resolves #7039

Summary*

Allows users to elide associated types from trait constraints. E.g. given a trait Iterator with an associated type Elem, we now allow constraints of the form T: Iterator in addition to the previous T: Iterator<Elem = U>.

Additional Context

Implementing this usually means finding where to insert implicit type variables for the associated types, this location is different for each item (functions, trait impls, trait definitions).

Because of constraints like where T: Foo, <T as Foo>::Bar: Eq, we have to introduce these assumed trait impls to scope as we go, otherwise we'll get an error that there's no impl for T: Foo when resolving the type <T as Foo>::Bar. Since I've chosen to do this in order, constraints like this rely on their ordering so where <T as Foo>::Bar: Eq, T: Foo will give an error.

This PR does not implement this feature for trait definitions (see #7024). I had trouble getting this working and believe this to be the rarest use case (compared to constraints on functions & trait impls) so I'm opting to leave this for a later PR.

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]

Compilation Memory Report

Program	Peak Memory
keccak256	78.13M
workspace	123.92M
regression_4709	424.09M
ram_blowup_regression	1.58G
rollup-base-public	4.85G
rollup-base-private	1.26G
private-kernel-tail	207.18M
private-kernel-reset	669.26M
private-kernel-inner	294.40M

[github-actions]

Execution Memory Report

Program	Peak Memory
keccak256	74.67M
workspace	123.84M
regression_4709	316.00M
ram_blowup_regression	512.61M
rollup-base-public	478.87M
rollup-base-private	325.48M
private-kernel-tail	180.47M
private-kernel-reset	245.16M
private-kernel-inner	208.55M

[github-actions]

Execution Report

Program	Execution Time	%
sha256_regression	0.052s	0%
regression_4709	0.001s	0%
ram_blowup_regression	0.602s	-1%
rollup-root	0.105s	0%
rollup-merge	0.007s	16%
rollup-block-merge	0.104s	-1%
rollup-base-public	1.222s	-1%
rollup-base-private	0.449s	-1%
private-kernel-tail	0.019s	0%
private-kernel-reset	0.313s	0%
private-kernel-inner	0.068s	-2%

[github-actions]

Compilation Report

Program	Compilation Time	%
sha256_regression	1.272s	1%
regression_4709	0.793s	1%
ram_blowup_regression	18.200s	1%
rollup-root	3.596s	7%
rollup-merge	1.960s	5%
rollup-block-merge	3.430s	-3%
rollup-base-public	40.340s	-7%
rollup-base-private	12.300s	-1%
private-kernel-tail	0.944s	-6%
private-kernel-reset	6.352s	-2%
private-kernel-inner	1.986s	-5%

[github-actions]

🚀 Deployed on https://67857d13afe7a20808934318--noir-docs.netlify.app

[jfecher]

The unit tests found a regression that I'm fixing atm. We apparently:

• Don't error anymore if the user forgets to specify an associated type in a trait impl (not a constraint, the actual impl)
• Error twice instead of once if an impl's constraint is to a trait that doesn't exist

[michaeljklein]

Don't error anymore if the user forgets to specify an associated type in a trait impl (not a constraint, the actual impl)

I think that might be this line? https://github.com/noir-lang/noir/pull/7026/files#diff-ac857943134bba360eee936142f9043704ff127f0a9a188e6feba623ae68d93aL386

Was wondering when I saw it how we could be sure that the error is thrown elsewhere and it sounds similar.

[jfecher]

@michaeljklein it was, yeah. The short of it was that in most cases we do allow associated types to be elided but in trait impls we also use that method for checking the trait being implemented has all its generics and associated types, so in that case we want to disallow them.

With that fixed, there's still one more test to fix which is that we issue the "no trait Foo in scope" error twice now in one case.

[jfecher]

@michaeljklein ready for re-review

[jfecher]

Currently blocked by #7039

Thanks @asterite for unblocking this

[github-actions]

FYI @noir-lang/developerrelations on Noir doc changes.

[michaeljklein]

LGTM