-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Use stable Rust #512
RFC: Use stable Rust #512
Conversation
The semantics of int-to-pointer casts under strict provenance has changed. Ideally, we would update our `From<usize> for Register` implementation to use the `sptr` crate, but `sptr` does not currently have a suitable license. There is a [PR](Gankra/sptr#14) to change that, but it hasn't gotten a response in 7 months, so I don't think we can use it. Instead, this copies the implementation of `core::ptr::invalid`. This also bumps our `thiserror` dependency, which forces Cargo to pick a newer version of `proc-macro2` that is compatible with recently nightly toolchains.
Only use nightly for miri.
@@ -129,7 +117,7 @@ test: examples test-stable | |||
LIBTOCK_PLATFORM=hifive1 cargo clippy $(EXCLUDE_STD) \ | |||
--target=riscv32imac-unknown-none-elf --workspace | |||
MIRIFLAGS="-Zmiri-strict-provenance -Zmiri-symbolic-alignment-check" \ | |||
cargo miri test $(EXCLUDE_MIRI) --workspace | |||
cargo +nightly miri test $(EXCLUDE_MIRI) --workspace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to pin to a particular nightly release, otherwise this will break randomly as new nightly toolchains come out.
It won't. |
I did some digging and found the reasoning here: rust-lang/rustup#3355. It seems the underlying issue is that because user-defined toolchain names exist, |
I'm not arguing with you, but these people built an entire programming language, they could figure out how to handle host-side testing needing a different compiler than a binary for an embedded system (if they wanted to). |
Improved by #513 |
Opening this on top of #511 as an idea to switch to using stable rust. Since we don't have to chase specific nightly versions, it seems like a good idea to just use stable rust with a minimum version for specific features we want.
But, this toolchain selection seems very confusing because again rust seems like it doesn't really support cross-compiling. What we want are very separate ways to specify the toolchain for building for embedded targets from ways to specify the toolchain for running host-side tests. It remains perplexing to me that rust still doesn't really seem to take this seriously.
Specifically, I don't know how to tell cargo "use nightly, but use a nightly with miri available". Maybe it does this automatically since we are running a miri command? I don't know.