There are generally speaking no breaking changes. Upgrading the toolchain practically never requires any changes to code.
if you work on safety/security critical systems upgrading the toolchain is considered like changing the tires on a moving vehicle. We have introduced and many weeks later discovered critical (and hard to trace) bugs simply by changing -O2 to -O3 in gcc that ended in sporadic crashes when cross-compiling for 1 specific platform. (which is a change much less severe than upgrading gcc itself) And I'd be surprised if upgrading the toolchain wouldn't potentially introduce similar hard to trace issues in rust.
My point is that just because the first 2 months after upgrade look like there were no required changes in code doesn't mean there are none. I see rust being used in very large companies for internal projects, test harnesses, and other glue/plumbing. And the places I know are really reluctant to go all the way in and substitute their ~30 years of experience with C/C++ with something that remains a constantly moving target. To be fair there are other reasons such as culture, and distribution of skills across the team that drive these decisions but my main point still holds (i think).
I mean, even with C, there is a very circumscribed subset that you use for "safety critical" applications.
2) People are banging on about Rust not being stable but the Rust Embedded guys DO lag for stability--so you can have stability if you choose. And Rust is by far the best language I have seen about being able to stay on old compiler versions and still use newer libraries.
3) I find crappy libraries to be the biggest threat to Rust's sustainability. There was a big "Gold Rush" mentality and a whole lot of unqualified people built a whole lot of crap libraries with no good way for someone to come along later and to flag "That's a crap library, please remove it from crates.io permanently".
Sure, this happens regularly in C and C++ because large programs inevitably depend on undefined behaviour, and changing compiler versions, optimization levels and target platforms is allowed to change that behaviour.
For the last five years I've been writing 99% safe Rust code, which is designed to have no undefined behavior, and I think it's not a coincidence that I can't remember ever having a compiler update break code at runtime. Once in a long while a compiler update will fail to compile some existing code, but that's not a safety issue.
The idea that C and C++ compilers are somehow more stable across releases is a mirage. https://lwn.net/Articles/845691/ https://lwn.net/Articles/845775/
This sounds more like undefined behavior in your codebase than a compiler error. I don't know Rust but I'm pretty sure the whole selling point is that you won't run into problems like this.
As an aside, the clang bug would also affect Rust if they used that type of optimization (assuming strict aliasing rules).
[0] https://lists.isocpp.org/std-discussion/2020/10/0882.php
No, this bug cannot affect rust, because rust wouldn't allow to pass into a function three mutable references pointing to the same object. It wouldn't even allow two, nor one mutable and one immutable. Either it pass one mutable reference, or any number of immutable.
It doesn’t happen often, but it does happen.
Anyway, Rust has found plenty of noalias bugs in clang, which is why it still doesn't compile with noalias optimizations turned on.
It absolutely happens, but less often than you would think.
Rust has a tool named "crater" which compiles and executing tests for every package uploaded to crates.io (and some which are just on github).
It's not perfect but supposedly it catches quite a lot of bugs.