Repository navigation
Closed
Labels
A-const-genericsArea: const generics (parameters and arguments)Area: const generics (parameters and arguments)C-bugCategory: This is a bug.Category: This is a bug.F-const_generics`#![feature(const_generics)]``#![feature(const_generics)]`I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.glacierICE tracked in rust-lang/glacier.ICE tracked in rust-lang/glacier.requires-nightlyThis issue requires a nightly compiler in some way. When possible, use a F-* label instead.This issue requires a nightly compiler in some way. When possible, use a F-* label instead.
Description
This is a very slight modification of an example in #60813, but filing as a separate bug, since the error message is very different.
The following code
#![feature(const_generics)]
pub fn function_with_str<'a, const STRING: &'a str>() {
}
pub fn use_it() {
function_with_str::<"Hello, world!">()
}results in the following ICE:
Compiling playground v0.0.1 (/playground)
warning: the feature `const_generics` is incomplete and may cause the compiler to crash
--> src/lib.rs:1:12
|
1 | #![feature(const_generics)]
| ^^^^^^^^^^^^^^
error: internal compiler error: src/librustc/ty/subst.rs:489: Region parameter out of range when substituting in region 'a (root type=Some(&'a str)) (index=0)
thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:572:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
1: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:71
2: std::panicking::default_hook::{{closure}}
at src/libstd/sys_common/backtrace.rs:59
at src/libstd/panicking.rs:197
3: std::panicking::default_hook
at src/libstd/panicking.rs:211
4: rustc::util::common::panic_hook
5: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:478
6: std::panicking::begin_panic
7: rustc_errors::Handler::span_bug
8: rustc::util::bug::opt_span_bug_fmt::{{closure}}
9: rustc::ty::context::tls::with_opt::{{closure}}
10: rustc::ty::context::tls::with_context_opt
11: rustc::ty::context::tls::with_opt
12: rustc::util::bug::opt_span_bug_fmt
13: rustc::util::bug::span_bug_fmt
14: <rustc::ty::subst::SubstFolder as rustc::ty::fold::TypeFolder>::fold_region
15: rustc::ty::structural_impls::<impl rustc::ty::fold::TypeFoldable for &rustc::ty::TyS>::super_fold_with
16: <rustc::ty::subst::SubstFolder as rustc::ty::fold::TypeFolder>::fold_ty
17: rustc::ty::instance::Instance::resolve
18: <rustc::traits::project::AssociatedTypeNormalizer as rustc::ty::fold::TypeFolder>::fold_const
19: <smallvec::SmallVec<A> as core::iter::traits::collect::FromIterator<<A as smallvec::Array>::Item>>::from_iter
20: rustc::ty::fold::TypeFoldable::fold_with
21: rustc::ty::structural_impls::<impl rustc::ty::fold::TypeFoldable for &rustc::ty::TyS>::super_fold_with
22: <rustc::traits::project::AssociatedTypeNormalizer as rustc::ty::fold::TypeFolder>::fold_ty
23: rustc::traits::project::normalize
24: rustc_typeck::check::FnCtxt::instantiate_value_path
25: rustc_typeck::check::FnCtxt::check_expr_kind
26: rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs
27: rustc_typeck::check::callee::<impl rustc_typeck::check::FnCtxt>::check_call
28: rustc_typeck::check::FnCtxt::check_expr_kind
29: rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs
30: rustc_typeck::check::FnCtxt::check_block_with_expected
31: rustc_typeck::check::FnCtxt::check_expr_kind
32: rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs
33: rustc_typeck::check::FnCtxt::check_return_expr
34: rustc_typeck::check::check_fn
35: rustc::ty::context::GlobalCtxt::enter_local
36: rustc_typeck::check::typeck_tables_of
37: rustc::ty::query::__query_compute::typeck_tables_of
38: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::typeck_tables_of>::compute
39: rustc::dep_graph::graph::DepGraph::with_task_impl
40: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
41: rustc::ty::<impl rustc::ty::context::TyCtxt>::par_body_owners
42: rustc_typeck::check::typeck_item_bodies
43: rustc::ty::query::__query_compute::typeck_item_bodies
44: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::typeck_item_bodies>::compute
45: rustc::dep_graph::graph::DepGraph::with_task_impl
46: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
47: rustc::util::common::time
48: rustc_typeck::check_crate
49: rustc_interface::passes::analysis
50: rustc::ty::query::__query_compute::analysis
51: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::analysis>::compute
52: rustc::dep_graph::graph::DepGraph::with_task_impl
53: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
54: rustc::ty::context::tls::enter_global
55: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
56: rustc_interface::passes::create_global_ctxt::{{closure}}
57: rustc_interface::interface::run_compiler_in_existing_thread_pool
58: std::thread::local::LocalKey<T>::with
59: scoped_tls::ScopedKey<T>::set
60: syntax::with_globals
query stack during panic:
#0 [typeck_tables_of] processing `use_it`
#1 [typeck_item_bodies] type-checking all item bodies
#2 [analysis] running analysis passes on this crate
end of query stack
error: aborting due to previous error
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.36.0-nightly (a9ec99f42 2019-05-13) running on x86_64-unknown-linux-gnu
note: compiler flags: -C codegen-units=1 -C debuginfo=2 --crate-type lib
note: some of the compiler flags provided by cargo are hidden
error: Could not compile `playground`.
To learn more, run the command again with --verbose.
cc @Serentty
Reacted by Felipe S. S. Schneider
Metadata
Metadata
Assignees
Labels
A-const-genericsArea: const generics (parameters and arguments)Area: const generics (parameters and arguments)C-bugCategory: This is a bug.Category: This is a bug.F-const_generics`#![feature(const_generics)]``#![feature(const_generics)]`I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.glacierICE tracked in rust-lang/glacier.ICE tracked in rust-lang/glacier.requires-nightlyThis issue requires a nightly compiler in some way. When possible, use a F-* label instead.This issue requires a nightly compiler in some way. When possible, use a F-* label instead.
Activity
hellow554 commentedon May 14, 2019
@rustbot modify labels: I-ICE C-Bug T-compiler A-const-generics
varkor commentedon May 14, 2019
Ah, this is interesting. I don't think we intend to allow consts to be parameterised over other generic parameters just yet. Currently, you cannot parameterise a const by a type parameter, but we also should exclude lifetime parameters (for now).Edit: it seems like the implementation of
fold_constforAssociatedTypeNormalizermight be wrong.BenLewis-Seequent commentedon Sep 28, 2019
The current ICE is:
error: internal compiler error: src/librustc_mir/borrow_check/nll/universal_regions.rs:741: cannot convert
ReEarlyBound(0, 'a)to a region vidDetails
varkor commentedon Jun 14, 2020
The nomenclature is a bit confusing, but
constvariables don't act the same way thatconstgeneric parameters do. It doesn't make sense to have aconstvariable with a non-static lifetime, because consts should really be thought of as global declarations. However, const parameters are local, and may well refer to non-static lifetimes.varkor commentedon Jun 15, 2020
The difference is just due to the word "const" being reused for different things. Const variables are essentially just inlined, whereas const parameters are values that are are guaranteed to be constant, and known at compile time. In theory, I don't see why consts couldn't have non-static lifetimes in general. I don't know of a realistic example for non-static lifetimes in const generics either, but there's no technical reason they shouldn't work, so we should fix it :)
disallow non-static lifetimes in const generics
Rollup merge of rust-lang#74051 - yodaldevoid:issue_60814, r=nikomats…
varkor commentedon Jul 22, 2020
Fixed by #74051.