-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overflow evaluating requirement in latest nightly (1.85) #135143
Comments
My attempt at "simplifying" the reproducer code (requires an unstable feature): #![feature(trusted_len)]
pub struct Vec2;
pub trait Point {
type S;
}
impl Point for Vec2 {
type S = f32;
}
pub trait Point2: Point<S = Self::S2> {
type S2;
}
impl Point2 for Vec2 {
type S2 = Self::S;
}
////////////////////
pub struct RepeatWith<F>(F);
impl<A, F: FnMut() -> A> Iterator for RepeatWith<F> {
type Item = A;
fn next(&mut self) -> Option<A> {
None
}
}
unsafe impl<A, F: FnMut() -> A> std::iter::TrustedLen for RepeatWith<F> {}
////////////////////
trait MyFrom<T> {
fn my_from();
}
impl<P: Point2> MyFrom<P::S> for P {
fn my_from() {
_ = RepeatWith(|| unimplemented!()).collect::<Vec<P::S>>();
}
}
pub fn do_thing() {
<Vec2 as MyFrom<_>>::my_from();
} Note that removing the Replacing @rustbot labels +regression-from-stable-to-nightly +A-trait-system +A-specialization |
This seems to have regressed in #134081. |
Anyways I have a fix but I'll need to minimize this futher. I don't believe this relies on specialization. @rustbot claim |
Overflows on nightly with no specialization:
|
Use a post-monomorphization typing env when mangling components that come from impls When mangling associated methods of impls, we were previously using the wrong param-env. Instead of using a fully monomorphized param-env like we usually do in codegen, we were taking the post-analysis param-env, and treating it as an early binder to *re-substitute* the impl args. I've pointed out the problematic old code in an inline comment. This would give us param-envs with possibly trivial predicates that would prevent normalization via param-env shadowing. In the example test linked below, `tests/ui/symbol-names/normalize-in-param-env.rs`, this happens when we mangle the impl `impl<P: Point2> MyFrom<P::S> for P` with the substitution `P = Vec2`. Because the where clause of the impl is `P: Point2`, which elaborates to `[P: Point2, P: Point, <P as Point>::S projects-to <P as Point2>::S2]` and the fact that `impl Point2 for Vec2` normalizes `Vec2::S2` to `Vec2::S`, this causes a cycle. The proper fix here is to use a fully monomorphized param-env for the case where the impl is properly substituted. Fixes rust-lang#135143 While rust-lang#134081 uncovered this bug for legacy symbol mangling, it was preexisting for v0 symbol mangling. This PR fixes both. The test requires a "hack" because we strip the args of the instance we're printing for legacy symbol mangling except for drop glue, so we box a closure to ensure we generate drop glue. r? oli-obk
Rollup merge of rust-lang#135149 - compiler-errors:mangle, r=oli-obk Use a post-monomorphization typing env when mangling components that come from impls When mangling associated methods of impls, we were previously using the wrong param-env. Instead of using a fully monomorphized param-env like we usually do in codegen, we were taking the post-analysis param-env, and treating it as an early binder to *re-substitute* the impl args. I've pointed out the problematic old code in an inline comment. This would give us param-envs with possibly trivial predicates that would prevent normalization via param-env shadowing. In the example test linked below, `tests/ui/symbol-names/normalize-in-param-env.rs`, this happens when we mangle the impl `impl<P: Point2> MyFrom<P::S> for P` with the substitution `P = Vec2`. Because the where clause of the impl is `P: Point2`, which elaborates to `[P: Point2, P: Point, <P as Point>::S projects-to <P as Point2>::S2]` and the fact that `impl Point2 for Vec2` normalizes `Vec2::S2` to `Vec2::S`, this causes a cycle. The proper fix here is to use a fully monomorphized param-env for the case where the impl is properly substituted. Fixes rust-lang#135143 While rust-lang#134081 uncovered this bug for legacy symbol mangling, it was preexisting for v0 symbol mangling. This PR fixes both. The test requires a "hack" because we strip the args of the instance we're printing for legacy symbol mangling except for drop glue, so we box a closure to ensure we generate drop glue. r? oli-obk
This code fails to compile on the latest nightly (1.85):
Playground link: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=c912d455ab2679f04d8b3e8dedf694dc
I expected to see this happen: It compiles without any errors
Instead, this happened: On nightly, it fails to compile with
On stable (1.83.0) and beta (1.84.0-beta.6), it compiles just fine.
I encountered this bug while compiling this library, and then reduced the code until I got the example above: https://github.com/MetabuildDev/selo
Meta
rustc --version --verbose
:The text was updated successfully, but these errors were encountered: