Confusing error message with associated type bounds doesn't hint to possible typo

[asquared31415]

Given the following code:
playground

trait Foo {
    type Assoc;
}

impl Foo for () {
    type Assoc = ();
}

// trait w/ same name as the associated type in scope
trait Assoc {
    
}

// likely meant to use T::Assoc to get the associated type, not just one `:`
fn foo<T: Foo>(_x: T) -> Option<T:Assoc> {
    todo!()
}

The current output is:

   Compiling playground v0.0.1 (/playground)
error[E0658]: associated type bounds are unstable
  --> src/lib.rs:15:33
   |
15 | fn foo<T: Foo>(_x: T) -> Option<T:Assoc> {
   |                                 ^^^^^^^
   |
   = note: see issue #52662 <https://github.com/rust-lang/rust/issues/52662> for more information

error[E0107]: this enum takes 1 generic argument but 0 generic arguments were supplied
   --> src/lib.rs:15:26
    |
15  | fn foo<T: Foo>(_x: T) -> Option<T:Assoc> {
    |                          ^^^^^^ expected 1 generic argument
    |
note: enum defined here, with 1 generic parameter: `T`
help: add missing generic argument
    |
15  | fn foo<T: Foo>(_x: T) -> Option<T, T:Assoc> {
    |                                 ++

error[E0229]: associated type bindings are not allowed here
  --> src/lib.rs:15:33
   |
15 | fn foo<T: Foo>(_x: T) -> Option<T:Assoc> {
   |                                 ^^^^^^^ associated type not allowed here

Some errors have detailed explanations: E0107, E0229, E0658.
For more information about an error, try `rustc --explain E0107`.
error: could not compile `playground` due to 3 previous errors

Ideally the first error should have a hint that Assoc is also the name of an associated type on T and point to the single colon : with a suggestion to change it to a double colon to access the associated type.

Output is identical across stable 1.56.1, 1.57.0-beta.7, and 1.58 nightly 2021-11-24

[compiler-errors]

I'd love to work on this if nobody else is interested in it. @estebank, you're the expert on diagnostics, so you might know the best advice to do this fix cleanly.

edit: (re the previous thoughts I had typed up, I was wrong haha) I'll try to see where I need to add in the check that currently denies bindings in generics for types.

[estebank]

@compiler-errors you'll end up having to touch at least two different places (maybe three) to handle this correctly.

You might want to silence the first error that happens on visit_assoc_ty_constraint, simply because it's early enough that you don't have enough info to recover. E0107 I don't know how easy it will be to silence, depending on how we go about this. The last error is the one that you'll have the best chance of turning into a great error, by looking where prohibit_assoc_ty_binding is called, and rely on resolve to see if the thing on the right is a path that could be found as an assoc type on the thing on the left.

It also looks like we are forbidding assoc types in two places (ast and typeck). If the overlap is 100% for both, then we could have only one (and turn the other into a delay_as_err to make it panic if no other error happens).

[compiler-errors]

Thanks for the advice. I'll take a look at it when I get back to my rustc-building computer in a few days :)

@rustbot claim

[compiler-errors]

So I've hit some complications here.

1. Am I able to resolve a path in rustc_typeck? We have constraints of the form T : A::B::C and in order to suggest replacing : with ::, we need to be able to verify that T::A::B::C is a valid path. I don't know if we have that kind of information in check_generic_arg_count or the rest of astconv.
2. Some lowering shenanigans are going on somewhere above this stage, because I think by the time (e.g.) -> Option<T:Assoc> reaches rustc_typeck, it gets desugared into -> Option<T = impl Assoc>. This makes it significantly harder to suggest a correct fixup here, since I only want to match bounds that look like the former.

Maybe it's worthwhile to do this at the ast level instead or during hir where we have path resolution + a more faithful representation of the input code. But I don't know if we currently disambiguate positions where assoc constraints are (dis)allowed at those levels.

Not sure if you have any thoughts @estebank. Otherwise I might let this issue go so I'm not holding onto something somebody else wants to take a stab at.

[estebank]

1. I don't know if you can call resolve in typeck. I think that might not be possible. In some cases where we encounter these kind of problems, like for suggestions during parsing, we make a "best effort" suggestion by trying to be very targeted and mark the suggestion as MaybeIncorrect.
2. Yes, that desugaring makes sense.

And option would be to modify the AST to carry extra information, and for that desugaring I think you might be able to carry information in the ObligationCauseCode to get the original HirId to try and reconstruct things that way.

[JustusFluegel]

This could probably be marked as closed by #92788 ?

[estebank]

@JustusFluegel the current output is the following, so I wouldn't consider this fixed:

error[E0658]: associated type bounds are unstable
  --> src/lib.rs:15:33
   |
15 | fn foo<T: Foo>(_x: T) -> Option<T:Assoc> {
   |                                 ^^^^^^^
   |
   = note: see issue #52662 <https://github.com/rust-lang/rust/issues/52662> for more information
   = help: add `#![feature(associated_type_bounds)]` to the crate attributes to enable
   = note: this compiler was built on 2024-02-25; consider upgrading it if it is out of date

error[E0107]: enum takes 1 generic argument but 0 generic arguments were supplied
   --> src/lib.rs:15:26
    |
15  | fn foo<T: Foo>(_x: T) -> Option<T:Assoc> {
    |                          ^^^^^^ expected 1 generic argument
    |
note: enum defined here, with 1 generic parameter: `T`
   --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:572:10
    |
572 | pub enum Option<T> {
    |          ^^^^^^ -
help: add missing generic argument
    |
15  | fn foo<T: Foo>(_x: T) -> Option<T, T:Assoc> {
    |                                 ++

error[E0229]: associated type bindings are not allowed here
  --> src/lib.rs:15:33
   |
15 | fn foo<T: Foo>(_x: T) -> Option<T:Assoc> {
   |                                 ^^^^^^^ associated type not allowed here

[JustusFluegel]

Ok my bad 👍