Incorrect Release Code Generation (Works in Debug)

[ghost]

I tried this code:

// Note: original reduced to a minimal reproducing sample
fn main() {
    let foos = 1;
    let mut iter = FooIter {foos: &foos, current: Some(Foo::A)};
    match iter.next() {
        None => println!("INCORRECT"), // Occurs in release mode
        Some(_) => println!("CORRECT") // Occurs in debug mode
    }
}

#[derive(Copy, Clone)]
pub enum Foo {
    A,
    B,
    C
}

pub struct FooIter<'a> {
    foos: &'a u32,
    current: Option<Foo>
}

impl<'a> Iterator for FooIter<'a> {
    type Item = Foo;
    
    fn next(&mut self) -> Option<Self::Item> {
        loop {
            let current = self.current?;
            self.current = None;
            
            if *self.foos == 1 {
                return Some(current)
            }
        }
    }
}

I expected to see this happen: In both debug and release builds, I expect to see "CORRECT" be printed.

Instead, this happened: The debug build correctly prints "CORRECT", but the release build incorrectly prints "INCORRECT". Minor perturbations cause the release build to print "CORRECT". Presumably the code is triggering an excessively-aggressive optimization.

Meta

• I reproduced this on version 1.56.0, target triple x86_64-pc-windows-msvc. As this was on a different system from the one on which I am filing the bug report, I cannot show rustc --version output.
• As a sanity check, I also reproduced this on the rust playground using 1.56.1 stable: [(https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=af0b28cf2eafd458e51a554e8e007332)]
• On rust playground using beta and nightly, the bug did NOT reproduce. As this does not necessarily mean it was fixed (as opposed to merely hidden), I opted to file the report anyway.

Thank you for your time and attention!

[ehuss]

Thanks for the report! This appears to have been fixed by #88765. I don't see which change in that update would be related to this, but maybe @rust-lang/wg-llvm can comment.

[ehuss]

https://bugs.llvm.org/show_bug.cgi?id=51125 looks suspiciously similar.

[apiraino]

@mattelkinsTC can you report if the LLVM upgrade mentioned in this comment helps (iiuc the above comment)? thanks

[ghost]

I never tracked it down to the specific code generation problem, so it is hard to say whether the LLVM upgrade was what fixed it. However, the issue does NOT reproduce in 1.57, so it seems likely.

[apiraino]

Discussed in the Zulip thread of the Prioritization Working Group.

I'm going to close this as fixed / not reproducible anymore, but please anyone feel free to reopen if I'm wrong here.

@rustbot label -I-prioritize