Also, you need to be careful about what you implement yourself and what you import from crates. Otherwise it will be qt5 all over again.
Also, you need to be careful about what you implement yourself and what you import from crates. Otherwise it will be qt5 all over again.
I haven't really seen that happen with post-1.0 Rust, which is everything onwards of early 2015. I believe they've since tightened a couple of edge cases due to soundness issues, but nothing worse than that.
Would be interesting to hear about your contrary experiences.
See: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
You can reproduce this yourself with:
git clone https://github.com/cortex/ripasso.git
cd ripasso
git checkout release-0.5.1
cargo build --locked
On my arch system this fails to build with the same errors as the bug report i got, and my rustc version is: $ rustc --version --verbose
rustc 1.57.0 (f1edd0429 2021-11-29)
binary: rustc
commit-hash: f1edd0429582dd29cccacaf50fd134b05593bd9c
commit-date: 2021-11-29
host: x86_64-unknown-linux-gnu
release: 1.57.0
LLVM version: 13.0.0A related issue is that for many companies "stable" means the version shipped with Ubuntu LTS.
I think it was something as fundamental as Error being changed or moved around.
Then, you may have configured warnings to result in compilation errors in your build/project, however, I would argue this situation is not what most people would understand as "code not compiling due to a compiler update".
I don't remember and it doesn't really matter other than we had build issues and it was unexpected.
Are you talking about breaking changes in the compiler after Rust 1.0? That should be very rare, and generally easy to fix (e.g. by adding a few type annotations).
Or did you use unstable features? (Not sure if embedded is usable without unstable nowadays)