ICE: feature(generic_const_exprs) enabled in one crate but not another

[jplatte]

Extracted out from #78139 (comment), as that issue was closed but my case still ICEs

Given this code:

src/lib.rs:

#![feature(const_generics, const_evaluatable_checked)]
#![allow(incomplete_features)]

pub struct Const<const U: u8>;

pub trait Trait {
    type AssocTy;
    fn assoc_fn() -> Self::AssocTy;
}

impl<const U: u8> Trait for Const<U>
where
    Const<{ my_const_fn(U) }>: ,
{
    type AssocTy = Const<{ my_const_fn(U) }>;
    fn assoc_fn() -> Self::AssocTy {
        Const
    }
}

const fn my_const_fn(val: u8) -> u8 {
    // body of this function doesn't matter
    val
}

examples/breakit.rs:

use my_crate::{Const, Trait};

fn main() {
    let _ = Const::<1>::assoc_fn();
}

I get the following error:

error: constant expression depends on a generic parameter
  |
  = note: this may fail depending on what value the parameter takes

error: internal compiler error: compiler/rustc_traits/src/normalize_erasing_regions.rs:37:32: could not fully normalize `<my_crate::Const<U> as my_crate::Trait>::AssocTy`

Backtrace

thread 'rustc' panicked at 'Box<Any>', compiler/rustc_errors/src/lib.rs:945:9
stack backtrace:
   0: std::panicking::begin_panic
   1: rustc_errors::HandlerInner::bug
   2: rustc_errors::Handler::bug
   3: rustc_middle::util::bug::opt_span_bug_fmt::{{closure}}
   4: rustc_middle::ty::context::tls::with_opt::{{closure}}
   5: rustc_middle::ty::context::tls::with_opt
   6: rustc_middle::util::bug::opt_span_bug_fmt
   7: rustc_middle::util::bug::bug_fmt
   8: rustc_infer::infer::InferCtxtBuilder::enter
   9: rustc_traits::normalize_erasing_regions::normalize_generic_arg_after_erasing_regions
  10: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  11: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  12: rustc_data_structures::stack::ensure_sufficient_stack
  13: rustc_query_system::query::plumbing::get_query_impl
  14: rustc_middle::ty::structural_impls::fold_list
  15: rustc_middle::ty::normalize_erasing_regions::<impl rustc_middle::ty::context::TyCtxt>::normalize_erasing_regions
  16: rustc_middle::ty::layout::<impl rustc_middle::ty::instance::Instance>::fn_sig_for_fn_abi
  17: <rustc_target::abi::call::FnAbi<&rustc_middle::ty::TyS> as rustc_middle::ty::layout::FnAbiExt<C>>::of_instance
  18: rustc_codegen_ssa::mir::block::<impl rustc_codegen_ssa::mir::FunctionCx<Bx>>::codegen_call_terminator
  19: rustc_codegen_ssa::mir::block::<impl rustc_codegen_ssa::mir::FunctionCx<Bx>>::codegen_block
  20: rustc_codegen_ssa::mir::codegen_mir
  21: rustc_codegen_ssa::base::codegen_instance
  22: <rustc_middle::mir::mono::MonoItem as rustc_codegen_ssa::mono_item::MonoItemExt>::define
  23: rustc_codegen_llvm::base::compile_codegen_unit::module_codegen
  24: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  25: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task
  26: rustc_codegen_llvm::base::compile_codegen_unit
  27: rustc_codegen_ssa::base::codegen_crate
  28: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
  29: rustc_session::utils::<impl rustc_session::session::Session>::time
  30: rustc_interface::queries::Queries::ongoing_codegen
  31: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  32: rustc_span::with_source_map
  33: scoped_tls::ScopedKey<T>::set
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

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

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.49.0-nightly (e3051d8c2 2020-10-16) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type bin

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

query stack during panic:
#0 [normalize_generic_arg_after_erasing_regions] normalizing `<my_crate::Const<U> as my_crate::Trait>::AssocTy`
end of query stack
error: aborting due to 2 previous errors

error: could not compile `my_crate`

It goes away when putting all of the code into one compilation unit.

[in42]

@lcnr Hi, I would like to work on this. Which files should I look at to get started?

[lcnr]

edit: looks like the below comment is incorrect, it is still something that needs to be done though 😅

Looking at the the relevant tracking issue(#76560) this bug is caused by

fix privacy checks (they are not complaining about private const fn in complex consts in function signatures)

We already have a FIXME(const_evaluatable_checked) in rustc_privacy which is relevant here.

Instead of just ignoring ConstEvaluatable predicates you want to instead walk their abstract consts and visit all contained constants. This will be quite similar to what we are doing here:

rust/compiler/rustc_trait_selection/src/traits/object_safety.rs

Lines 815 to 868 in 603ab5b

	fn visit_const(&mut self, ct: &ty::Const<'tcx>) -> ControlFlow<()> {
	// First check if the type of this constant references `Self`.
	self.visit_ty(ct.ty)?;
	// Constants can only influence object safety if they reference `Self`.
	// This is only possible for unevaluated constants, so we walk these here.
	//
	// If `AbstractConst::new` returned an error we already failed compilation
	// so we don't have to emit an additional error here.
	//
	// We currently recurse into abstract consts here but do not recurse in
	// `is_const_evaluatable`. This means that the object safety check is more
	// liberal than the const eval check.
	//
	// This shouldn't really matter though as we can't really use any
	// constants which are not considered const evaluatable.
	use rustc_middle::mir::abstract_const::Node;
	if let Ok(Some(ct)) = AbstractConst::from_const(self.tcx, ct) {
	const_evaluatable::walk_abstract_const(self.tcx, ct, |node| match node {
	Node::Leaf(leaf) => {
	let leaf = leaf.subst(self.tcx, ct.substs);
	self.visit_const(leaf)
	}
	Node::Binop(..) | Node::UnaryOp(..) | Node::FunctionCall(_, _) => {
	ControlFlow::CONTINUE
	}
	})
	} else {
	ControlFlow::CONTINUE
	}
	}
	fn visit_predicate(&mut self, pred: ty::Predicate<'tcx>) -> ControlFlow<()> {
	if let ty::PredicateAtom::ConstEvaluatable(def, substs) = pred.skip_binders() {
	// FIXME(const_evaluatable_checked): We should probably deduplicate the logic for
	// `AbstractConst`s here, it might make sense to change `ConstEvaluatable` to
	// take a `ty::Const` instead.
	use rustc_middle::mir::abstract_const::Node;
	if let Ok(Some(ct)) = AbstractConst::new(self.tcx, def, substs) {
	const_evaluatable::walk_abstract_const(self.tcx, ct, |node| match node {
	Node::Leaf(leaf) => {
	let leaf = leaf.subst(self.tcx, ct.substs);
	self.visit_const(leaf)
	}
	Node::Binop(..) | Node::UnaryOp(..) | Node::FunctionCall(_, _) => {
	ControlFlow::CONTINUE
	}
	})
	} else {
	ControlFlow::CONTINUE
	}
	} else {
	pred.super_visit_with(self)
	}

This might be a bit difficult for a first issue, I recommend you to open a topic on #t-compiler/wg-const-eval on zulip if you want to challenge yourself here. https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval

[jplatte]

@lcnr Are you sure this is related to privacy? Making my_const_fn public in doesn't fix the issue.

[lcnr]

it does not 😮 then it looks like something else is also incorrect here

let me quickly check, don't have too much time atm

[lcnr]

:/

closing this as somewhat intended.

const_evaluatable_checked has to be active in both the crate defining the generic const operation and in the crate which tries to use it.

I don't think there is much we can do here. This compiles if you change example/breakit.rs to the following

#![feature(const_evaluatable_checked)]

use what::{Const, Trait};

fn main() {
    let _ = Const::<1>::assoc_fn();
}

[jplatte]

Ohh, of course. But surely this could produce an error instead of an ICE, no?

[lcnr]

This could, I don't know how to do that though 🤔

so yeah, let's keep that open for now