Resolution problem with associated types with defaults

[arielb1]

STR

#![feature(associated_consts)]

trait Foo {
    type Bar;
}

#[cfg(not(works))]
trait Baz {
    type Fv: Foo = u8;
    const C: <Self::Fv as Foo>::Bar = 6665;
}

#[cfg(works)]
trait Baz {
    type Fv: Foo = u8;
    const C: <Self::Fv as Foo>::Bar;
}

Results

<anon>:9:15: 9:23 error: failed to resolve. Use of undeclared type or module `Self`
<anon>:9     const C: <Self::Fv as Foo>::Bar = 6665;
                       ^~~~~~~~
<anon>:9:15: 9:23 error: use of `Self` outside of an impl or trait
<anon>:9     const C: <Self::Fv as Foo>::Bar = 6665;
                       ^~~~~~~~
error: aborting due to 2 previous errors

Removing the default (#[cfg(works)]) removes the error. cc @quantheory

[quantheory]

This is at least blocked on the generic const RFC, though I do intend to take a crack at implementing that, or at least the groundwork, in the coming weeks.

On top of that, handling this example probably requires some changes both to the code and to how we deal with casts/coercion in constant expressions. Right now, I think that unsuffixed literals always have a specific integer type inferred. But you want the type here to be inferred as <Self::Fv as Foo>::Bar, which is a projection, and not even required to be an integer type. To handle this, we would need some bound on Bar that means "an integer literal can be cast to this type at compile time".

[jonas-schievink]

Updated code:

#![feature(associated_type_defaults)]
#![feature(associated_consts)]

trait Foo {
    type Bar;
}

trait Baz {
    type Fv: Foo = u8;
    const C: <Self::Fv as Foo>::Bar = 6665;
}

Fails to compile with:

error[E0308]: mismatched types
  --> src/lib.rs:10:39
   |
10 |     const C: <Self::Fv as Foo>::Bar = 6665;
   |                                       ^^^^ expected associated type, found integer
   |
   = note: expected type `<<Self as Baz>::Fv as Foo>::Bar`
              found type `{integer}`

Removing the default value of the constant makes it build. According to RFC 2532, I believe this is working as expected: Trait items may not assume that assoc. type defaults hold.