Skip to content

Fixes to rust-toolchain.toml handling #1225

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

Merged
merged 3 commits into from
May 7, 2025

Conversation

joshtriplett
Copy link
Contributor

@joshtriplett joshtriplett commented May 7, 2025

This fixes a few aspects of the rust-toolchain.toml handling, to make it easier to make future changes such as limiting the use of rust-toolchain.toml to the tools that use rustc internals.

Fix a few obsolete references to rust-toolchain rather than rust-toolchain.toml, since c2rust doesn't use the former.

Use the rustfmt component rather than rustfmt-preview, since the latter is obsolete (rustfmt has not been a "preview" for a long time).

Finally, make c2rust-transpile use a separate file for the generated rust-toolchain.toml. When c2rust-transpile translates C variadics, it generates code using the (currently) nightly-only feature c_variadics, so it emits a rust-toolchain.toml file to use nightly. Rather than copy this file
from the rust-toolchain.toml used to build c2rust itself, use a separate file.

This also means the generated rust-toolchain.toml can stop requiring toolchain components that the generated code doesn't need, such as rustc-dev. (It still requires rustfmt, as c2rust may run cargo fmt on the generated code if invoking c2rust-refactor.)

Two .gitignore files and a GitHub workflow referenced `rust-toolchain`
without a `.toml` extension, but all the files in the repo and the
generated files are `rust-toolchain.toml`.

In addition, have the GitHub workflow's hashing take
`*rust-toolchain.toml` into account, to allow for a future split between
the toolchain for compiling c2rust and the toolchain for compiling
c2rust-generated code that needs nightly.
…in.toml`

When c2rust-transpile translates C variadics, it generates code using
the (currently) nightly-only feature `c_variadics`, so it emits a
`rust-toolchain.toml` file to use nightly. Rather than copy this file
from the `rust-toolchain.toml` used to build c2rust itself, use a
separate file.

This also means the generated `rust-toolchain.toml` can stop requiring
toolchain components that the generated code doesn't need, such as
rustc-dev. (It still requires `rustfmt`, as c2rust may run `cargo fmt`
on the generated code if invoking `c2rust-refactor`.)
Copy link
Contributor

@kkysen kkysen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@kkysen kkysen changed the title Fixes to rust-toolchain.toml handling Fixes to rust-toolchain.toml handling May 7, 2025
@kkysen kkysen merged commit 7a0bb7c into immunant:master May 7, 2025
8 of 9 checks passed
@kkysen
Copy link
Contributor

kkysen commented May 7, 2025

future changes such as limiting the use of rust-toolchain.toml to the tools that use rustc internals.

What do you mean by this?

@kkysen
Copy link
Contributor

kkysen commented May 8, 2025

Oh by the way, there are still a few uses of rustfmt-preview left. In scripts/provision_rust.sh and docs/README-developers.md.

@joshtriplett joshtriplett deleted the fix-toolchain-handling branch May 8, 2025 10:37
@joshtriplett
Copy link
Contributor Author

future changes such as limiting the use of rust-toolchain.toml to the tools that use rustc internals.

What do you mean by this?

I mean the implementation of #1220 : attempting to build only the tools needing rustc internals with the nightly toolchain, and the rest with the stable toolchain.

@kkysen
Copy link
Contributor

kkysen commented May 9, 2025

I mean the implementation of #1220 : attempting to build only the tools needing rustc internals with the nightly toolchain, and the rest with the stable toolchain.

Ahh. I thought you were referring to some future rustc/rustup change, lol. #1220/#1227 is totally good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants