using const variable in generic implement causes rustc panic

[wtu-sos]

using const variable in generic implement causes rustc panic, but using it in specialization like impl A<u64> and A<u32> without A<T> is fine;

I tried this code:

#[derive(Default)]
struct A<T> {
    t: T,
}

impl<T> A<T> {
    const LEN: usize = 4;

    fn p() {
        println!("{}", Self::LEN * 5); 
    }   
}
fn main() {
    A::<u64>::p();
    A::<u32>::p();
}

thread 'main' panicked at 'assertion failed: !impl_self_ty.has_infer_types()', librustc_mir/borrow_check/nll/type_check/mod.rs:1033:21 note: Run with `RUST_BACKTRACE=1` for a backtrace.

error: internal compiler error: unexpected panic

I expected to see this happen:
20
Instead, this happened:
panic

Meta

rustc --version --verbose:
rustc 1.31.0-nightly (f99911a4a 2018-10-23)
binary: rustc
commit-hash: f99911a4a0bead7dd1f9ef2f90442844434cc391
commit-date: 2018-10-23
host: x86_64-unknown-linux-gnu
release: 1.31.0-nightly
LLVM version: 8.0

Backtrace:

stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at libstd/sys_common/backtrace.rs:71
at libstd/sys_common/backtrace.rs:59
2: std::panicking::default_hook::{{closure}}
at libstd/panicking.rs:211
3: std::panicking::default_hook
at libstd/panicking.rs:227
4: rustc::util::common::panic_hook
5: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:480
6: std::panicking::begin_panic
7: rustc_mir::borrow_check::nll::type_check::TypeChecker::relate_type_and_user_type
8: <rustc_mir::borrow_check::nll::type_check::TypeVerifier<'a, 'b, 'gcx, 'tcx> as rustc::mir::visit::Visitor<'tcx>>::visit_constant
9: <rustc_mir::borrow_check::nll::type_check::TypeVerifier<'a, 'b, 'gcx, 'tcx> as rustc::mir::visit::Visitor<'tcx>>::visit_rvalue
10: <rustc_mir::borrow_check::nll::type_check::TypeVerifier<'a, 'b, 'gcx, 'tcx> as rustc::mir::visit::Visitor<'tcx>>::visit_mir
11: rustc_mir::borrow_check::nll::type_check::type_check
12: rustc_mir::borrow_check::nll::compute_regions
13: rustc_mir::borrow_check::do_mir_borrowck
14: rustc::ty::context::tls::with_related_context
15: rustc::infer::InferCtxtBuilder::enter
16: rustc_mir::borrow_check::mir_borrowck
17: rustc::ty::query::__query_compute::mir_borrowck
18: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::mir_borrowck<'tcx>>::compute
19: rustc::ty::context::tls::with_context
20: rustc::ty::context::tls::with_context
21: rustc::dep_graph::graph::DepGraph::with_task_impl
22: rustc::ty::context::tls::with_related_context
23: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
24: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
25: rustc::ty::query::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::mir_borrowck
26: rustc::ty::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::par_body_owners
27: rustc::util::common::time
28: rustc::ty::context::tls::enter_context
29: <std::thread::local::LocalKey>::with
30: rustc::ty::context::TyCtxt::create_and_enter
31: rustc_driver::driver::compile_input
32: rustc_driver::run_compiler_with_pool
33: rustc_driver::driver::spawn_thread_pool
34: rustc_driver::run_compiler
35: <scoped_tls::ScopedKey>::set
36: <std::panic::AssertUnwindSafe as core::ops::function::FnOnce<()>>::call_once
37: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:102
38: rustc_driver::run
39: rustc_driver::main
40: std::rt::lang_start::{{closure}}
41: std::panicking::try::do_call
at libstd/rt.rs:59
at libstd/panicking.rs:310
42: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:102
43: std::rt::lang_start_internal
at libstd/panicking.rs:289
at libstd/panic.rs:392
at libstd/rt.rs:58
44: main
45: __libc_start_main
46:
query stack during panic:
#0 [mir_borrowck] processing <A<T>>::p

end of query stack

[thenewwazoo]

I found this bug to appear starting in 2018-10-19 nightly.

[memoryruins]

Thanks for reporting! This should no longer trigger an ICE on the next nightly now that #55323 has been merged. Closing as duplicate of #55219