Do you remember more specifics? I've seen four cases:
- a project with no Cargo.lock, where there have been breaking changes in a dependency that wasn't specific enough in Cargo.toml; fixing this requires some finessing of dependencies but is possible to get the project building without any code changes
- a project with proper dependency tree specified, but where a std change cause inference to break specific older versions of a crate in your tree (time 0.35 comes to mind); this requires similar changes to the above
- a project relies on UB on stable code that should always have been disallowed and since fixed; this is tricky, on a dependency, an updated version will likely exist, on your own project you'd have to either change your code or use the older toolchain, knowing that the code might not be doing what you want it to do (this happened a handful of times pre 1.20)
- an older project, with the proper dependency versions specified, being built on a newer platform; I saw this with someone trying to build a project untouched since 2018 on an ARM Mac: the toolchain for it didn't exist back then, and the macOS specific lib they were using didn't have any knowledge either. Newer versions of the library do, of course, but that required updating a set of libs that would be compatible too.
All of these cases are quite rare. You could encounter all of them at the same time, and that would be annoying, enough to have someone doing it for fun say "fuck it" and drop it. You can also get hit by a lightning.
But between Cargo.lock which should allow your project to build on newer toolchains, and access to all prior toolchains, your project should continue to build forever on the same platform.
I'd add pinning a rust toolchain version (using rust-toolchain.toml or similar) in addition to Cargo.lock
Rustc does have fairly frequent (every ~18 months of so) minor breaking changes between versions. These are often related to type inference, usually only affect a very small number of crates, and are usually mitigated by publishing patch versions of those crates that don't run into the issue. But if you have the patch version locked with a lockfile then that won't help you, and there is increased likelihood of the build failing, so it's best to lock down the rustc version too.
Luckily pinning the rustc version is very easy to do.
---
On regular projects this kind of issue can usually also be fixed by upgrading to the latest rustc and running `cargo update`. But conservative embedded projects may have legitimate reasons for not wanting to upgrade rustc to the latest version, and parts of ecosystem's disregard for MSRVs means that running `cargo update` on an older rustc has a high chance of causing build breakage due to MSRV issues.