-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
broken MIR in Item (nightly) #99866
Comments
Can you post what your dependencies are? Or include the Or something that can just be stuck in a |
Of course, my bad for not providing this upfront. I've been able to repo it with this setup: deps/features:
lib.rs #[cfg(feature = "metal")]
use gfx_backend_metal as back;
pub use gfx_hal as hal;
#[cfg(feature = "vulkan")]
use gfx_backend_vulkan as back;
#[cfg(not(any(feature = "metal", feature = "vulkan")))]
use gfx_backend_empty as back;
pub type B = back::Backend;
pub struct Exacterator<I: Iterator<Item = T>, T> {
iter: I,
size: usize,
}
impl<I: Iterator<Item = T>, T> Exacterator<I, T> {
pub fn new(iter: I, size: usize) -> Self {
Self { iter, size }
}
}
impl<I: Iterator<Item = T>, T> Iterator for Exacterator<I, T> {
type Item = I::Item;
fn next(&mut self) -> Option<Self::Item> {
self.iter.next()
}
fn size_hint(&self) -> (usize, Option<usize>) {
(self.size, Some(self.size))
}
}
impl<I: Iterator<Item = T>, T> ExactSizeIterator for Exacterator<I, T> {}
pub trait Exact<T>: Iterator<Item = T> + Sized {
fn exact(self, size: usize) -> Exacterator<Self, T>;
}
impl<I: Iterator<Item = T>, T> Exact<T> for I {
fn exact(self, size: usize) -> Exacterator<Self, T> {
Exacterator::new(self, size)
}
}
#[derive(Debug)]
pub struct HalSetLayouts {
vertex_layout: <B as hal::Backend>::DescriptorSetLayout,
fragment_layout: <B as hal::Backend>::DescriptorSetLayout,
fragment_sampler_layout: <B as hal::Backend>::DescriptorSetLayout,
}
impl HalSetLayouts {
pub fn iter<DSL>(&self) -> impl ExactSizeIterator<Item = &DSL> + '_
where
// rust 1.37 fails to typecheck `iter` without this. This is fixed in nightly.
B: hal::Backend<DescriptorSetLayout = DSL>,
DSL: std::fmt::Debug + Send + Sync + 'static,
{
std::iter::once(&self.vertex_layout)
.chain(std::iter::once(&self.fragment_layout))
.chain(std::iter::once(&self.fragment_sampler_layout))
.exact(3)
}
} |
Ah yes, thank you very much. I can reproduce it (with the |
For reference, minimised it down to this: pub trait Backend {
type DescriptorSetLayout;
}
pub struct Back;
impl Backend for Back {
type DescriptorSetLayout = u32;
}
pub struct HalSetLayouts {
vertex_layout: <Back as Backend>::DescriptorSetLayout,
}
impl HalSetLayouts {
pub fn iter<DSL>(self) -> DSL
where
Back: Backend<DescriptorSetLayout = DSL>,
{
self.vertex_layout
}
} I also bisected this, and it turns out to be the same rollup as in #99852... So I suspect both these errors were introduced in the same commit. Interesting! Edit: Adjusted the code (edit2: twice!), check comment history for the original. |
Here is the MIR for the fn <impl at lol.rs:17:1: 17:19>::iter(_1: HalSetLayouts) -> DSL {
debug self => _1; // in scope 0 at lol.rs:18:22: 18:26
let mut _0: DSL; // return place in scope 0 at lol.rs:18:31: 18:34
bb0: {
_0 = move (_1.0: DSL); // scope 0 at lol.rs:22:9: 22:27
return; // scope 0 at lol.rs:23:6: 23:6
}
} |
After looking into this a bit, I got the following: The body is treating the generic type This is actually ok though, since in the where bounds To me, this looks like a bug in the MIR validator. |
This was probably regressed by #96856. cc @drmeepster |
Yes, manually reverting the PR fixed the issue for me locally. |
While it regressed in that PR, the PR only called validation that wasn't called before. The validation has been broken for longer. |
@rustbot claim |
Probably just needs a normalize call somewhere 🤔 |
Oooppsss... Sorry, this test still ICE. On the bright side, I was able to reduce the compiler arguments to |
… r=oli-obk Try normalizing types without RevealAll in ParamEnv in MIR validation Before, the MIR validator used RevealAll in its ParamEnv for type checking. This could cause false negatives in some cases due to RevealAll ParamEnvs not always use all predicates as expected here. Since some MIR passes like inlining use RevealAll as well, keep using it in the MIR validator too, but when it fails usign RevealAll, also try the check without it, to stop false negatives. Fixes rust-lang#99866 cc `@compiler-errors` who nicely helped me on zulip
… r=oli-obk Try normalizing types without RevealAll in ParamEnv in MIR validation Before, the MIR validator used RevealAll in its ParamEnv for type checking. This could cause false negatives in some cases due to RevealAll ParamEnvs not always use all predicates as expected here. Since some MIR passes like inlining use RevealAll as well, keep using it in the MIR validator too, but when it fails usign RevealAll, also try the check without it, to stop false negatives. Fixes rust-lang#99866 cc ``@compiler-errors`` who nicely helped me on zulip
… r=oli-obk Try normalizing types without RevealAll in ParamEnv in MIR validation Before, the MIR validator used RevealAll in its ParamEnv for type checking. This could cause false negatives in some cases due to RevealAll ParamEnvs not always use all predicates as expected here. Since some MIR passes like inlining use RevealAll as well, keep using it in the MIR validator too, but when it fails usign RevealAll, also try the check without it, to stop false negatives. Fixes rust-lang#99866 cc ```@compiler-errors``` who nicely helped me on zulip
… r=oli-obk Try normalizing types without RevealAll in ParamEnv in MIR validation Before, the MIR validator used RevealAll in its ParamEnv for type checking. This could cause false negatives in some cases due to RevealAll ParamEnvs not always use all predicates as expected here. Since some MIR passes like inlining use RevealAll as well, keep using it in the MIR validator too, but when it fails usign RevealAll, also try the check without it, to stop false negatives. Fixes rust-lang#99866 cc ````@compiler-errors```` who nicely helped me on zulip
… r=oli-obk Try normalizing types without RevealAll in ParamEnv in MIR validation Before, the MIR validator used RevealAll in its ParamEnv for type checking. This could cause false negatives in some cases due to RevealAll ParamEnvs not always use all predicates as expected here. Since some MIR passes like inlining use RevealAll as well, keep using it in the MIR validator too, but when it fails usign RevealAll, also try the check without it, to stop false negatives. Fixes rust-lang#99866 cc `````@compiler-errors````` who nicely helped me on zulip
… r=oli-obk Try normalizing types without RevealAll in ParamEnv in MIR validation Before, the MIR validator used RevealAll in its ParamEnv for type checking. This could cause false negatives in some cases due to RevealAll ParamEnvs not always use all predicates as expected here. Since some MIR passes like inlining use RevealAll as well, keep using it in the MIR validator too, but when it fails usign RevealAll, also try the check without it, to stop false negatives. Fixes rust-lang#99866 cc `@compiler-errors` who nicely helped me on zulip
… r=oli-obk Try normalizing types without RevealAll in ParamEnv in MIR validation Before, the MIR validator used RevealAll in its ParamEnv for type checking. This could cause false negatives in some cases due to RevealAll ParamEnvs not always use all predicates as expected here. Since some MIR passes like inlining use RevealAll as well, keep using it in the MIR validator too, but when it fails usign RevealAll, also try the check without it, to stop false negatives. Fixes rust-lang#99866 cc ``@compiler-errors`` who nicely helped me on zulip
… r=oli-obk Try normalizing types without RevealAll in ParamEnv in MIR validation Before, the MIR validator used RevealAll in its ParamEnv for type checking. This could cause false negatives in some cases due to RevealAll ParamEnvs not always use all predicates as expected here. Since some MIR passes like inlining use RevealAll as well, keep using it in the MIR validator too, but when it fails usign RevealAll, also try the check without it, to stop false negatives. Fixes rust-lang#99866 cc ```@compiler-errors``` who nicely helped me on zulip
… r=oli-obk Try normalizing types without RevealAll in ParamEnv in MIR validation Before, the MIR validator used RevealAll in its ParamEnv for type checking. This could cause false negatives in some cases due to RevealAll ParamEnvs not always use all predicates as expected here. Since some MIR passes like inlining use RevealAll as well, keep using it in the MIR validator too, but when it fails usign RevealAll, also try the check without it, to stop false negatives. Fixes rust-lang#99866 cc ````@compiler-errors```` who nicely helped me on zulip
… r=oli-obk Try normalizing types without RevealAll in ParamEnv in MIR validation Before, the MIR validator used RevealAll in its ParamEnv for type checking. This could cause false negatives in some cases due to RevealAll ParamEnvs not always use all predicates as expected here. Since some MIR passes like inlining use RevealAll as well, keep using it in the MIR validator too, but when it fails usign RevealAll, also try the check without it, to stop false negatives. Fixes rust-lang#99866 cc `````@compiler-errors````` who nicely helped me on zulip
… r=oli-obk Try normalizing types without RevealAll in ParamEnv in MIR validation Before, the MIR validator used RevealAll in its ParamEnv for type checking. This could cause false negatives in some cases due to RevealAll ParamEnvs not always use all predicates as expected here. Since some MIR passes like inlining use RevealAll as well, keep using it in the MIR validator too, but when it fails usign RevealAll, also try the check without it, to stop false negatives. Fixes rust-lang#99866 cc ``````@compiler-errors`````` who nicely helped me on zulip
… r=oli-obk Try normalizing types without RevealAll in ParamEnv in MIR validation Before, the MIR validator used RevealAll in its ParamEnv for type checking. This could cause false negatives in some cases due to RevealAll ParamEnvs not always use all predicates as expected here. Since some MIR passes like inlining use RevealAll as well, keep using it in the MIR validator too, but when it fails usign RevealAll, also try the check without it, to stop false negatives. Fixes rust-lang#99866 cc ```````@compiler-errors``````` who nicely helped me on zulip
Code
Meta
rustc --version --verbose
:Error output
Backtrace
This came from a workaround for what seems to be an old compiler bug. removing the workaround gets ride of the ICE:
The text was updated successfully, but these errors were encountered: