fix(frontend): Error for when impl is stricter than trait

[vezenovm]

Description

Problem*

Resolves #5210

Summary*

For context it is good to start with the linked issue and the discussion.

In the linked issue discussion, a non-existent trait implementation would pass type checking and fail during monomorphization. It turns out the linked issue's error was not that the compiler should error with No impl found ... but rather that the impl has stricter requirements than the trait. When we move the where clause to the trait impl we get the expected no matching impl error as expected.

But now the following code from the issue will have this error:

We will also error if the object type in a trait constraint has different generics:

trait MyTrait { }

trait Bar<T> {
    fn bar<U>() where Option<T>: MyTrait;
}

impl<A> Bar<A> for () {
    fn bar<B>() where Option<B>: MyTrait {}
}

Will return the following error:

I have also attached a test showing how we get the expected no impl found error when the where clause is accurately placed on the trait impl rather than the trait impl method.

Additional Context

The way we attach trait impl where clauses onto methods did complicate things a little. We should consider maintaining a clearer separation for where clauses on impls and where clauses on functions.

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.

[TomAFrench]

Looking at the issue in more detail now but doesn't this just boil down to prohibiting any trait bounds on the impl? Would this not be simpler + clearer than allowing it in the situation where it matches up with the trait?

[jfecher]

@TomAFrench we'd still want to allow trait bounds on an impl's method if the corresponding trait method also requires that impl. It's not the most common feature but it does match Rust's behavior.

[jfecher]

We should catch the case where the generics (or object type) on these trait constraints differ as well.

[vezenovm]

Looks like this still does not catch the case where the generics differ:

Ah yes I missed accounting for the trait generics. This case now fails with the following:

I have added a test in the frontend tests as well.

[jfecher]

LGTM