ICE with Const Generics cast of self in supertrait list

[JulianKnodt]

I was writing some generic code over vectors using the under-construction feature of const generics, and had a circular chain of super-traits that required me to cast the Self type to the trait as can be seen in the Div supertrait requirement. I believe that is causing the MIR error.
I think this may be related to #66906 but it is subtly different so I'm putting the issue up regardless.

Code

#![feature(const_generics)]
use std::ops::Div;
use num::Float;

/// Abstract vector over some finite field
pub trait Vector<const N: usize>: Div<<Self as Vector<N>>::Field, Output = Self> + Copy {
  type Field: Float;
  fn cons(vs: [Self::Field; N]) -> Self { todo!() }
}

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=3856486297085a463f98c2fc9f9a99c6

Meta

rustc --version --verbose:
I updated my rust version on nightly right before I ran this so hopefully it is up to date:

rustc 1.44.0-nightly (f509b26a7 2020-03-18)
binary: rustc
commit-hash: f509b26a7730d721ef87423a72b3fdf8724b4afa
commit-date: 2020-03-18
host: x86_64-apple-darwin
release: 1.44.0-nightly
LLVM version: 9.0

Error output

... Warnings Elided for convenience...

warning: Error finalizing incremental compilation session directory `/Users/julianknodt/Desktop/programming/projects/rustjects/gfx/target/debug/incremental/ray_weekend-1jydezk8mz1tf/s-flpmnsfnok-1ritjvd-working`: No such file or directory (os error 2)

error: internal compiler error: mir_const_qualif: MIR had errors
 --> src/vec.rs:8:55
  |
8 | pub trait Vector<const N: usize>: Div<<Self as Vector<N>>::Field, Output = Self> + Copy {
  |                                                       ^

error: internal compiler error: PromoteTemps: MIR had errors
 --> src/vec.rs:8:55
  |
8 | pub trait Vector<const N: usize>: Div<<Self as Vector<N>>::Field, Output = Self> + Copy {
  |                                                       ^

error: internal compiler error: broken MIR in DefId(0:2682 ~ ray_weekend[6635]::vec[0]::Vector[0]::{{constant}}[0]) ("return type"): bad type [type error]
 --> src/vec.rs:8:55
  |
8 | pub trait Vector<const N: usize>: Div<<Self as Vector<N>>::Field, Output = Self> + Copy {
  |                                                       ^

error: internal compiler error: broken MIR in DefId(0:2682 ~ ray_weekend[6635]::vec[0]::Vector[0]::{{constant}}[0]) (LocalDecl { mutability: Mut, local_info: Other, internal: false, is_block_tail: None, ty: [type error], user_ty: UserTypeProjections { contents: [] }, source_info: SourceInfo { span: src/vec.rs:8:55: 8:56, scope: scope[0] } }): bad type [type error]
 --> src/vec.rs:8:55
  |
8 | pub trait Vector<const N: usize>: Div<<Self as Vector<N>>::Field, Output = Self> + Copy {
  |                                                       ^

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:360:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.44.0-nightly (f509b26a7 2020-03-18) running on x86_64-apple-darwin

note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib

note: some of the compiler flags provided by cargo are hidden

error: could not compile `ray_weekend`.

To learn more, run the command again with --verbose.

Backtrace

...Warnings elided for clarity...

warning: Error finalizing incremental compilation session directory `/Users/julianknodt/Desktop/programming/projects/rustjects/gfx/target/debug/incremental/ray_weekend-1jydezk8mz1tf/s-flpmrtevdl-1q49gen-working`: No such file or directory (os error 2)

error: internal compiler error: mir_const_qualif: MIR had errors
 --> src/vec.rs:8:55
  |
8 | pub trait Vector<const N: usize>: Div<<Self as Vector<N>>::Field, Output = Self> + Copy {
  |                                                       ^

error: internal compiler error: PromoteTemps: MIR had errors
 --> src/vec.rs:8:55
  |
8 | pub trait Vector<const N: usize>: Div<<Self as Vector<N>>::Field, Output = Self> + Copy {
  |                                                       ^

error: internal compiler error: broken MIR in DefId(0:2682 ~ ray_weekend[6635]::vec[0]::Vector[0]::{{constant}}[0]) ("return type"): bad type [type error]
 --> src/vec.rs:8:55
  |
8 | pub trait Vector<const N: usize>: Div<<Self as Vector<N>>::Field, Output = Self> + Copy {
  |                                                       ^

error: internal compiler error: broken MIR in DefId(0:2682 ~ ray_weekend[6635]::vec[0]::Vector[0]::{{constant}}[0]) (LocalDecl { mutability: Mut, local_info: Other, internal: false, is_block_tail: None, ty: [type error], user_ty: UserTypeProjections { contents: [] }, source_info: SourceInfo { span: src/vec.rs:8:55: 8:56, scope: scope[0] } }): bad type [type error]
 --> src/vec.rs:8:55
  |
8 | pub trait Vector<const N: usize>: Div<<Self as Vector<N>>::Field, Output = Self> + Copy {
  |                                                       ^

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:360:17
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: <unknown>
  18: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.44.0-nightly (f509b26a7 2020-03-18) running on x86_64-apple-darwin

note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack
error: could not compile `ray_weekend`.

To learn more, run the command again with --verbose.

This issue has been assigned to @lcnr via this comment.

[lcnr]

minimized:

#![feature(const_generics)]

pub trait Trait<const N: usize>: From<<Self as Trait<N>>::Item> {
  type Item;
}

@rustbot claim

[eddyb]

Looks like maybe constants in trait paths don't get their type correctly?
cc @varkor @yodaldevoid

[eddyb]

Initially I thought this was about bounds but no, this also fails: (playground)

#![feature(const_generics)]

pub trait Trait<const N: usize> {
  type Item;
  const VAL: <Self as Trait<N>>::Item;
}

[eddyb]

I believe this code is responsible:

rust/src/librustc_typeck/collect/type_of.rs

Lines 285 to 287 in 5f13820

	// This is no generic parameter associated with the arg. This is
	// probably from an extra arg where one is not needed.
	.unwrap_or(tcx.types.err)

And the problem is that this doesn't handle associated types which need the same treatment:

rust/src/librustc_typeck/collect/type_of.rs

Lines 259 to 261 in 5f13820

	Res::Def(DefKind::Ctor(..), def_id) => {
	tcx.generics_of(tcx.parent(def_id).unwrap())
	}

[eddyb]

Alternatively, instead of using path.res to get the DefId, maybe we could use the Resolution from the segment we found the const parameter in?
I believe nowadays we have per-segment resolutions, which would avoid breaking GATs in the future.

Actually, I expect Struct::<N>::method::<M>() is also broken, let's try it... Yupp: (playground)

#![feature(const_generics)]

struct Struct<const N: usize>;

impl<const N: usize> Struct<N> {
    fn method<const M: usize>(&self) {}
}

fn test<const N: usize, const M: usize>(x: Struct<N>) {
    Struct::<N>::method::<M>(&x);
    x.method::<N>();
}

EDIT: took a second look and that M is in a QPath::TypeRelative, which has to be resolved by the body of test, which means it's as bad as the method call form (which I just added).

Maybe we should disallow passing explicit generic args to methods for now?
Since I have no idea how one would figure out the expected type.

[eddyb]

@varkor @yodaldevoid If you look at this later btw, my comment above (#70167 (comment)) still isn't addressed, but I haven't made an issue yet about it.