Skip to content
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

[unstable option] unstable_features #3387

Open
scampi opened this issue Feb 13, 2019 · 8 comments
Open

[unstable option] unstable_features #3387

scampi opened this issue Feb 13, 2019 · 8 comments
Labels
unstable option tracking issue of an unstable option

Comments

@scampi
Copy link
Contributor

scampi commented Feb 13, 2019

Tracking issue for unstable_features

@scampi scampi added the unstable option tracking issue of an unstable option label Feb 13, 2019
@Stargateur
Copy link

Stargateur commented Jul 17, 2019

So to use unstable_features that allow to opt in unstable feature, itself need to be in already unstable channel because it itself not stable.

There is something I miss

@thomaseizinger
Copy link
Contributor

According to this issue it behaves the way it is supposed to behave.

However, I'd still argue that it should behave differently.

Our usecase is to compile our code against stable Rust but we like to use unstable formatting features. Currently, this forces us install two versions of Rust in CI which

  • a) causes configuration complexity in our CI setup
  • b) extends the time our CI builds take by having to download two toolchains
  • c) causes complexity in our builds scripts because we have to call cargo fmt with a +nightly-XXXX option.

@topecongiro
Copy link
Contributor

On 2.0, we will remove this and enable all unstable features on the nightly channel by default. On the stable, every unstable feature will be disabled.

@thomaseizinger
Copy link
Contributor

thomaseizinger commented Jan 14, 2020

Just to clarify:
There is going to be no way of using unstable formatting features on the stable release channel? :(
So we always have to install two versions of Rust in CI, just to check formatting and then compile with stable?

I believe stable/nightly rust and stable/unstable formatting features are orthogonal to each other.

@karyon
Copy link
Contributor

karyon commented Nov 14, 2021

This will need to be re-decided for 1.x

@Veetaha
Copy link

Veetaha commented Dec 22, 2023

So we always have to install two versions of Rust in CI, just to check formatting and then compile with stable?

I totally agree on this one. It's really annoying, and it's the thing across entire rust toolchain. Why do we need to explicitly install the nightly version of the toolchain to use an unstable feature? Why is it not enough to pass --unstable-features flag to "sign a contract that I'm using unstable". This makes it annoying to use unstable features and provide feedback for them so much that one would rather give up on the idea and wait until the feature becomes stable.

With rustc though there is at least a workaround of using RUSTC_BOOTSTRAP, but with rustfmt you have to explicitly download and pin a specific nightly version because you don't want CI to break on occasion.

@Veetaha
Copy link

Veetaha commented Dec 22, 2023

For anyone else who lands here: YOU CAN USE UNSTABLE FEATURES ON STABLE TOOLCHAN, but you have to specify them via the CLI parameters like this:

cargo fmt -- --config unstable_features=true --config error_on_unformatted=true

For the reasoning why you can use them only via CLI and can't use them via a config file see #5511 (comment)

@joshka
Copy link
Contributor

joshka commented May 22, 2024

For anyone else who lands here: YOU CAN USE UNSTABLE FEATURES ON STABLE TOOLCHAN, but you have to specify them via the CLI parameters like this:

cargo fmt -- --config unstable_features=true --config error_on_unformatted=true

For the reasoning why you can use them only via CLI and can't use them via a config file see #5511 (comment)

I was confused about this and thought this meant that I could enable just the unstable_features via cli and that would cause the rustfmt.toml config file values to just work, but you have to enable every config option that you'd like to use. This seems like an unfortunate and non-intuitive way of making this work.

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

No branches or pull requests

7 participants