transpile: update generated nightly to nightly-2023-04-15 (1.70.0) for syn v2.0.107 and cargo's sparse registry
#1422
Conversation
…for `syn v2.0.107` and `cargo`'s sparse registry `c2rust-bitfields-derive` depends on `syn v2.0`. Without a `Cargo.lock`, like in transpiled projects (as opposed to `c2rust` itself), this will resolve to `syn v2.0.107`, which requires Rust 1.68, but the generated `rust-toolchain.toml` uses Rust 1.65 (the same as our own nightly). This is currently breaking CI for the `c2rust-instrument` tests, and will also break CI for `c2rust-testsuite` once #1418 lands (a bug fix). Furthermore, the old git-based registry fetching is extremely slow in CI, so when #1227 lands and switches to stable, we also want Rust 1.70 for `cargo`'s sparse registry. Due to stable crates now building on stable but testing their output on nightly, it is very difficult to correctly cache. Updating the nightly of their output to the earliest to have the sparse registry should fix this. The combination of this, #1418, #1419, #1420, and #1421 has been tested to work on `libxml2`: ```sh cargo build --release (cd ../c2rust-testsuite/tests/libxml2/repo/ && $OLDPWD/target/release/c2rust-refactor --cargo --rewrite-mode inplace --lib reorganize_definitions ) ```
kkysen
force-pushed
the
kkysen/update-generated-rust-version
branch
from
34a4213 to
ad39c04
Compare
ahomescu
left a comment
ahomescu
left a comment
There was a problem hiding this comment.
Maybe we should hold off on this until we get c2rust-refactor in CI?
kkysen
left a comment
kkysen
left a comment
There was a problem hiding this comment.
Maybe we should hold off on this until we get c2rust-refactor in CI?
It's running in CI already as of immunant/c2rust-testsuite#20.
|
If I understand it correctly, it means that the transpiled code will target the newer nightly, but the c2rust code itself still requires the older one to build? |
Yes. Well, |
…3-04-15`, matching `c2rust` now In immunant/c2rust#1422, `c2rust` updated its generated `rust-toolchain.toml` to a newer version than Hayroll was using, so it's easier to standardize on the newer one that's also tested upstream in Rust. This also means we don't have to have multiple separate toolchains when running both `c2rust transpile` and `hayroll`.
c2rust-bitfields-derivedepends onsyn v2.0. Without aCargo.lock, like in transpiled projects (as opposed toc2rustitself), this will resolve tosyn v2.0.107, which requires Rust 1.68, but the generatedrust-toolchain.tomluses Rust 1.65 (the same as our own nightly). This is currently breaking CI for thec2rust-instrumenttests, and will also break CI forc2rust-testsuiteonce #1418 lands (a bug fix).Furthermore, the old git-based registry fetching is extremely slow in CI, so when #1227 lands and switches to stable, we also want Rust 1.70 for
cargo's sparse registry. Due to stable crates now building on stable but testing their output on nightly, it is very difficult to correctly cache.Updating the nightly of their output to the earliest to have the sparse registry should fix this.
The combination of this, #1418, #1419, #1420, and #1421 has been tested to work on
libxml2: