Change:
<ins> // compile-flags: -O // run-pass struct Foo { x: i32, } pub fn main() { let mut foo = Foo { x: 42 }; let x = &mut foo.x; *x = 13; let y = foo; assert_eq!(y.x, 13); // used to print 42 due to mir-opt bug } </ins>

Discussion:
The following MVE prints with ,source:'struct+Foo+%7B%0A++++x:+i32,%0A%7D%0A%0Afn+main()+%7B%0A++++let+mut+foo+%3D+Foo+%7B+x:+42+%7D%3B%0A++++let+x+%3D+%26mut+foo.x%3B%0A++++x+%3D+13%3B%0A++++let+y+%3D+foo%3B%0A++++println!!(%22%7B%7D%22,+y.x)%3B+//+-%3E+42%3B+expected+result:+13%0A%7D'),l:'5',n:'0',o:'Rust+source+%231',t:'0')),k:33.,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:r1450,filters:(b:'0',binary:'0',commentOnly:'0',demangle:'0',directives:'0',execute:'0',intel:'0',libraryCode:'1',trim:'1'),fontScale:14,j:1,lang:rust,libs:!(),options:'',selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'rustc+1.45.0+(Editor+%231,+Compiler+%231)+Rust',t:'0')),k:33.,l:'4',n:'0',o:'',s:0,t:'0'),(g:!

((h:output,i:(compiler:1,editor:1,fontScale:14,wrap:'1'),l:'5',n:'0',o:'%231+with+rustc+1.45.0',t:'0')),k:33.,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4) but with ,source:'struct+Foo+%7B%0A++++x:+i32,%0A%7D%0A%0Afn+main()+%7B%0A++++let+mut+foo+%3D+Foo+%7B+x:+42+%7D%3B%0A++++let+x+%3D+%26mut+foo.x%3B%0A++++x+%3D+13%3B%0A++++let+y+%3D+foo%3B%0A++++println!!(%22%7B%7D%22,+y.x)%3B+//+-%3E+42%3B+expected+result:+13%0A%7D'),l:'5',n:'0',o:'Rust+source+%231',t:'0')),k:33.,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:r1440,filters:(b:'0',binary:'0',commentOnly:'0',demangle:'0',directives:'0',execute:'0',intel:'0',libraryCode:'1',trim:'1'),fontScale:14,j:1,lang:rust,libs:!(),options:'',selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'rustc+1.44.0+(Editor+%231,+Compiler+%231)+Rust',t:'0')),k:33.,l:'4',n:'0',o:'',s:0,t:'0'),(g:!

((h:output,i:(compiler:1,editor:1,fontScale:14,wrap:'1'),l:'5',n:'0',o:'%231+with+rustc+1.44.0',t:'0')),k:33.,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4) Initially reported on .
With beta or nightly this again prints as expected.
If there is any benefit, it works as expected with this code.
This is a duplicate of the already fixed It seems like this bug somehow slipped into beta :/
Should there be a 1.45.1 with
Can 1.45.0 be yanked?
Yanking a release is not a thing. Presumably it wouldn't do anything once the stable channel is updated anyways.
It would do something for anyone who typed .
I'm confused. Based on the examples this bug appears to be very impactful, i.e. it should break a lot of code. Yet it made it to stable which, I assume, involves a crater run and independent testing on beta. Is there a subtle condition to this bug that isn't met in most productive code?
The bug is almost impossible to trigger on real world code. You need all values that are going into the bug to be constant values and there can't be any control flow or function calls in between.
As far as I know, has no support for yanking releases. Doing so would probably have to be done manually by the infra team and it could cause more harm than good. For example, are current or old versions of going to gracefully handle the case where a user has an installed release that doesn't exist anymore? We've had other point releases for major issues in the past and users are generally quick to upgrade. There is already a release scheduled for later this week with other backports and this fix will almost certainly be included.
Could try to print a massive warning (anytime it is invoked) telling the user that the patch is critical and is strongly recommended and that the previous release is deprecated?
Assigning .
I am happy to include in 1.45.1. -- there's some merge conflicts when cherry-picking onto stable, could you provide a commit/PR against stable with the merge conflicts fixed?

FWIW, I find the notion of putting warnings or saying "don't use this release" to be something we probably don't want to do right now. We'd basically have to do so for all non-latest Rust versions; they're all "unsupported" and may contain this (or other) problems. We ourselves do not patch more than the latest stable release if CVEs are detected, generally speaking. I would also ask that further discussion about yanking releases and such be directed to an internals thread and not this issue to avoid creating noise while we resolve this bug.
Nevermind, is already on it :heart:
Why this silly mistakeThe production environment is going to break
What said. It could be done with rustup check that will check and warn the user that new release introduce critical bug fixes or even security fixes.
I don't think this is the place to discuss policy changes. This issue is specifically for fixing the regression, not how regression fixes are communicated in general.
This thread has served its purpose, so locking it.
: by the way, this issue was not, technically, a duplicate of . Or at least, the issue described in only surfaces under conditions witnessed after commit (PR , merged on June 21st) <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailswhile this issue surfaces under conditions witnessed after commit (PR , merged on May 11th) <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsIt does seem like the same patch (PR ) fixes both issues; i.e., it seems likely that there is indeed one bug underlying both distinct issues. But the fact that they are distinct issues helps explain why we did not backport the fix to beta way back when.