inlining produces broken MIR by changing whether types can be normalized #112332
Comments
ahcm
added
C-bug
|
I bisected on a download of This manages to immune the bisection to about 5 different mir-opt changes over the past 7 months. Regression in nightly-2022-10-27 I feel like this might be normalization-related? cc @compiler-errors |
pub trait InnerProj {
type Assoc;
}
pub trait AmbigProj {
type AlwaysU32;
}
struct InnerWrap<T: AmbigProj + ?Sized> {
metadata: T::AlwaysU32,
}
pub struct Wrapper<T>(InnerWrap<[T]>);
#[inline]
fn as_slice<T>(v: &InnerWrap<[T]>) {
let _a: <[T] as AmbigProj>::AlwaysU32 = v.metadata;
}
pub fn deserialize<T: InnerProj>(a: &Wrapper<T::Assoc>)
where
[T::Assoc]: AmbigProj,
{
as_slice(&a.0);
}
impl<T> AmbigProj for [T] {
type AlwaysU32 = u32;
} |
|
@saethlin its unlikely any of my PRs in that list. more likely #102340 perhaps -- https://github.com/rust-lang/rust/pull/102340/files#diff-deb9513f9d3c0f87f924c627700124bed199d659cb223b0796a6509198139cd0R148 touches MIR validation right? cc @JakobDegen |
|
with |
|
I have a suspicion about the issue here. pub fn deserialize<T: InnerProj>(a: &Wrapper<T::Assoc>)
where
[T::Assoc]: AmbigProj,
{
let _a: <[T] as AmbigProj>::AlwaysU32 = a.0.metadata;
as_slice(&a.0);
}It now errors during type checking. error[E0308]: mismatched types
--> uwu.rs:24:45
|
24 | let _a: <[T] as AmbigProj>::AlwaysU32 = a.0.metadata;
| ----------------------------- ^^^^^^^^^^^^ expected `u32`, found associated type
| |
| expected due to this
|
= note: expected type `u32`
found associated type `<[<T as InnerProj>::Assoc] as AmbigProj>::AlwaysU32`
= help: consider constraining the associated type `<[<T as InnerProj>::Assoc] as AmbigProj>::AlwaysU32` to `u32`We have a blanket impl that always sets the associated type to impl<T> AmbigProj for [T] {
type AlwaysU32 = u32;
}Except that isn't the only candidate for And that's what we do! Candidates from the where clauses are perferred over impls. So inside the inner function, we pick the impl candidate and normalize it just fine. But after inlining, we now pick the where clause candidate and cannot normalize it. I don't know how to best fix this. |
|
cc @cjgillot maybe you have some insight |
|
That analysis is correct. I don't think this is easy to fix in general, and not sure how hard it would be to implement additional inlineability checks to avoid doing inlining in cases like this (also it would be a shame if the inliner skips valid inlining candidates just because of the trait solver being dumb). This is fixed afaict in the new trait solver. I wonder if we should use the new solver in mir validation as one of the first targets -- #112122 already does some of the work of making this possible. |
|
@compiler-errors if we disable this check in Mir validation, would we see an ICE in codegen/fullfillment? Depending on how widespread this is, doing less validation is always an option |
|
No, this would probably not ICE in codegen. |
…-errors Substitute types before checking inlining compatibility. Addresses rust-lang#112332 and rust-lang#113781 I don't have a minimal test, but I this seems to remove the ICE locally. This whole pre-inlining validation mirrors the "real" MIR validation pass to verify that inlined MIR will still pass validation. The debuginfo loop is added because MIR validation check projections in debuginfo. Likewise, MIR validation only checks `is_subtype`, so there is no reason for a stronger check. The types were not being substituted in `check_equal`, so we were not bailing out of inlining if the substituted MIR callee body would not pass validation.
Substitute types before checking inlining compatibility. Addresses rust-lang/rust#112332 and rust-lang/rust#113781 I don't have a minimal test, but I this seems to remove the ICE locally. This whole pre-inlining validation mirrors the "real" MIR validation pass to verify that inlined MIR will still pass validation. The debuginfo loop is added because MIR validation check projections in debuginfo. Likewise, MIR validation only checks `is_subtype`, so there is no reason for a stronger check. The types were not being substituted in `check_equal`, so we were not bailing out of inlining if the substituted MIR callee body would not pass validation.
|
#113802 works around this, right? I guess we're keeping the issue open since it's not a proper fix, just disabling inlining? |
|
i am also having this issue as we are tring to build our project with |
|
That looks to me like a different error, please open a separate issue. |
RalfJung
changed the title
Meta
cargo +stable does not show this.
rustc --version --verbose:Error output
The text was updated successfully, but these errors were encountered: