-
Notifications
You must be signed in to change notification settings - Fork 13.3k
ICE: Broken MIR equate_normalized_input_or_output: failed with NoSolution
#90638
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Probably related to #88382 |
I've looked into this: The problem here is that we try to equate the normalized The normalized input ty in this example corresponds to a closure with substs: and the unnormalized input ty from the mir is a closure with substs:
We can make this compile by normalizing @Manishearth Can you give me an example including a main function that uses upcast? I had problems fulfilling the |
Wait I'm a bit confused...does the hack that I added literally right there not work? |
Yes, that fails to normalize it. |
Ah, I see, it's |
@jackh726 trying to write the upcast displays the related bug that I was trying to reduce in the first place: impl<'a> Yokeable<'a> for Box<dyn IsCovariant<'static> + 'static> {
type Output = Box<dyn IsCovariant<'a> + 'a>;
}
// this impl is mostly an example and unnecessary for the pure repro
use std::borrow::*;
impl<'a, T: ToOwned + ?Sized> Yokeable<'a> for Cow<'static, T> {
type Output = Cow<'a, T>;
}
impl<'a, T: ToOwned + ?Sized> IsCovariant<'a> for Cow<'a, T> {}
fn upcast_yoke(y: Yoke<Cow<'static, str>>) -> Yoke<Box<dyn IsCovariant<'static> + 'static>> {
upcast(y)
} which throws
As mentioned before, this is along the same vein as #89196 and #85636 : The trait bound is satisfied by the type, rustc just can't figure it out. |
@jackh726 No 'b' is unnormalized, the problem seems to be that an empty |
Ah I see; I was reading it as the first arg. So,
In
We should be able to, yes. |
@jackh726 You're right about the second projection, but the normalization of |
Oh are we only able to normalize "all or nothing"? I'm not worried about that because it also appears in |
yeah its not important for the eq relation here, but |
…e_inputs_output, r=jackh726 Normalize both arguments of `equate_normalized_input_or_output` Fixes rust-lang#90638 Fixes rust-lang#90612 Temporary fix for a more complex underlying problem stemming from an inability to normalize closure substs during typecheck. r? `@jackh726`
…e_inputs_output, r=jackh726 Normalize both arguments of `equate_normalized_input_or_output` Fixes rust-lang#90638 Fixes rust-lang#90612 Temporary fix for a more complex underlying problem stemming from an inability to normalize closure substs during typecheck. r? ``@jackh726``
…e_inputs_output, r=jackh726 Normalize both arguments of `equate_normalized_input_or_output` Fixes rust-lang#90638 Fixes rust-lang#90612 Temporary fix for a more complex underlying problem stemming from an inability to normalize closure substs during typecheck. r? ```@jackh726```
…e_inputs_output, r=jackh726 Normalize both arguments of `equate_normalized_input_or_output` Fixes rust-lang#90638 Fixes rust-lang#90612 Temporary fix for a more complex underlying problem stemming from an inability to normalize closure substs during typecheck. r? ````@jackh726````
…e_inputs_output, r=jackh726 Normalize both arguments of `equate_normalized_input_or_output` Fixes rust-lang#90638 Fixes rust-lang#90612 Temporary fix for a more complex underlying problem stemming from an inability to normalize closure substs during typecheck. r? `@jackh726`
…e_inputs_output, r=jackh726 Normalize both arguments of `equate_normalized_input_or_output` Fixes rust-lang#90638 Fixes rust-lang#90612 Temporary fix for a more complex underlying problem stemming from an inability to normalize closure substs during typecheck. r? ``@jackh726``
…e_inputs_output, r=jackh726 Normalize both arguments of `equate_normalized_input_or_output` Fixes rust-lang#90638 Fixes rust-lang#90612 Temporary fix for a more complex underlying problem stemming from an inability to normalize closure substs during typecheck. r? ```@jackh726```
The ICE is now fixed, but the underlying bug I was trying to reduce still exists, going to file another issue. |
This is related to #89196 and #85636 ; but is not the same issue: #85636 is already resolved and #89196 is dealing with a more complex case where inference is lacking.
Also perhaps related to #56556
I'm filing an ICE because that's what I'm hitting as I try to reduce it, however I have a related bug where the workaround from #85636 doesn't actually work. I wonder if fixing the ICE will make this code compile or if it will hit code that needs to be worked around (My unreduced code is at https://github.com/Manishearth/icu4x/tree/rm-rcstruct ,
cd provider/core && cargo check --all-features
)Code
Code
Meta
rustc --version --verbose
:playpen
Error output
Backtrace
cc @jackh726 @eddyb
The text was updated successfully, but these errors were encountered: