Change:
<ins> // build-pass #![allow(incomplete_features)] #![feature(generic_const_exprs)] use std::marker::PhantomData; fn main() { let x = FooImpl::<BarImpl<1>> { phantom: PhantomData }; let _ = x.foo::<BarImpl<1>>(); } trait Foo<T> where T: Bar, { fn foo<U>(&self) where T: Operation<U>, <T as Operation<U>>::Output: Bar; } struct FooImpl<T> where T: Bar, { phantom: PhantomData<T>, } impl<T> Foo<T> for FooImpl<T> where T: Bar, { fn foo<U>(&self) where T: Operation<U>, <T as Operation<U>>::Output: Bar, { <<T as Operation<U>>::Output as Bar>::error_occurs_here(); } } trait Bar { fn error_occurs_here(); } struct BarImpl<const N: usize>; impl<const N: usize> Bar for BarImpl<N> { fn error_occurs_here() {} } trait Operation<Rhs> { type Output; } //// Part-A: This causes error. impl<const M: usize, const N: usize> Operation<BarImpl<M>> for BarImpl<N> where BarImpl<{ N + M }>: Sized, { type Output = BarImpl<{ N + M }>; } //// Part-B: This doesn't cause error. // impl<const M: usize, const N: usize> Operation<BarImpl<M>> for BarImpl<N> { //     type Output = BarImpl<M>; // } //// Part-C: This also doesn't cause error. // impl<const M: usize, const N: usize> Operation<BarImpl<M>> for BarImpl<N> { //     type Output = BarImpl<{ M }>; // } </ins>

Discussion:
You can also see a somewhat similar compilation error on Rust Playground . I tried this code: And I get this compilation error: It most recently worked on: rustc 1.53.0-nightly ( 2021-03-26) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bisected: searched nightlies: from nightly-2021-03-01 to nightly-2021-04-28 regressed nightly: nightly-2021-03-28 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI believe the cause is either or . cc
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium +requires-nightly -regression-from-stable-to-nightly
With removed: Note that removing the feature gate makes it compile and run without a problem.
looks like we aren't normalizing here. That shouldn't happen. is what introduced this but i would expect us to fix this by adding a call to normalize somewhere before creating symbols.
see , should still be fixed :laughing:

This code fails to link with :
Builds correctly with Fails with
appears to be nightly-2021-03-28, which I agree is the first regression. searched nightlies: from nightly-2021-03-26 to nightly-2021-04-07 regressed nightly: nightly-2021-03-28 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
The code I originally found this in does require and , but while minimizing it I arrived to this. The error also disappears when removing the braces in
feature enables lazy normalization. It seems that in one place a symbol name is constructed using an unevaluated const, while the other uses the evaluated one. This crates a mismatch in legacy symbol mangling scheme. The issue also disappears in which evaluates the const during mangling. Verbose:
I'm seeing a similar error: , with a very similar example! It seems that generic const parameters are making their way through monomorphization and into symbol mangling, which should definitely be fixed. Passing also fixes the linker error in my issue.
still an issue but the repro is slightly different ( some around and updated feature gate)
jup, should definitely be fixed

Const generics and release mode and Hc128Rng::seedfromu64 and rustc 1.45.0-nightly ( 2020-05-29) or later cause cc linking error. To avoid the error, do any of: use rustc 1.45.0-nightly ( 2020-05-14) or earlier remove the remove the line compile in debug mode I'm guessing that Hc128Rng::seedfrom_u64 is not the only thing that will trigger this, but I have not been able to find any other examples.
I reduced it. works, but does not work. In both release and debug, it yields approximate the same error as before on: But compiles successfully on:
This fails with , but not .
This appears to be working now. I'll add a test.
and I were unable to reproduce an error with the examples here, but they still fail on extended CI (though not with the original error here). The PR is We'll have to revisit this one.
Note that on latest nightly, I am still encountering this issue. (Any time I use the crate and with , I trigger this.) Error:
Sorry to keep bumping. I continue to encounter this issue when I attempt to use with on latest nightly. <details<summaryCode</summary</details<details<summaryError</summary</details<details<summaryrustc --version --verbose</summary</details
Reliably reproduces for me using latest code. modify labels: -E-needs-mcve +E-needs-test
I encountered a different trigger for what I am guessing is the same underlying bug. Error message is ~identical. To work around, do one of: Have return an array instead of a . Replace with . rustc --version --verbose:
Different trigger. Allocating with causes an ICE, but simple works.

Manifest for installing rust and build-essentials on ubuntu 20.04.03 rustup self uninstall apt-get update sudo add-apt-repository "deb $(lsb_release -sc) main universe" apt-get -u dist-upgrade apt install aptitude sudo aptitude install libc6=2.31-0ubuntu9 sudo aptitude install build-essential apt-get update curl --proto '=https' --tlsv1.2 -sSf | sh -s -- --default-toolchain none -y rustup toolchain install nightly --allow-downgrade --profile minimal --component clippy rustup default stable rustup update nightly rustup update stable rustup target add wasm32-unknown-unknown --toolchain nightly sudo apt install -y cmake pkg-config libssl-dev git gcc build-essential clang libclang-dev rustc --version source $ [][1] #ArmanRiazi.Blockchain [1]:
still causes a linker error but passes with symbol mangling: I assume we end up mangling an unevaluated constant somewhere with ?