unstable_features does absolutely nothing

[ickk]

rustfmt 1.4.37-stable (59eed8a2 2021-11-01)

Given a rustfmt.toml that looks like

unstable_features = <val>
imports_layout = "Vertical" # Some unstable feature

Files are formatted according to the following table

	+stable	+nightly
unstable_features = true	ignores unstable features	uses unstable features
unstable_features = false	ignores unstable features	uses unstable features

So the value of unstable_features does absolutely nothing except cause rustfmt to emit one of the following warnings when using a stable toochain

Warning: can't set `unstable_features = true`, unstable features are only available in nightly channel.
Warning: can't set `unstable_features = false`, unstable features are only available in nightly channel.

which is ridiculous.

Either this key should allow you to enable unstable formatting settings for stable toolchains, or it should allow you to disable unstable formatting settings for nightly toolchains. Preferably both. It currently has no effect at all.

There is a bug here.

[calebcartwright]

Thanks for reaching out, but I'd ask you to be mindful of tone and to make sure we keep the dialog constructive.

While I appreciate the desire to be able to use unstable features on stable, that's not a supported pattern, across the entire ecosystem. Folks should not assume that unstable_features allows the use of unstable opts on stable, and I feel like the existing documentation/description for that option is pretty explicit in calling that out, though certainly feel free to propose wording changes if you think of a way that could be made more clear.

Personally, I'd love it if we were able to let folks opt in to using unstable opts on stable, but that's something that's been asked and rejected many, many times already unfortunately, and not something I want to rehash yet again here.

At the same time, we also didn't think it really made sense to force people on nightly to have to use yet-another-option to be able to use unstable opts on nightly (i.e. shouldn't have to set unstable_features = true), and IIRC, that was dropped quite some time ago. I suspect that 4th vector (unstable_features = false being a functional noop on nightly) is just a longstanding, and largely unnoticed side effect of that relaxation on nightly.

As such I don't necessarily agree with the characterization of this as a "bug", though agree we should do something to clarify the current behavior on nightly. However, I don't want to make modifications that reintroduce restrictions on nightly, as that'd be a step backwards, but I don't want to drop the option either because I'm holding out hope one day I can convince some folks to give us the green light to make it available on stable.

[ickk]

Apologies if my tone reads poorly, I had no intention to cause any upset.

It's confusing because right at the top of the docs it says

Each configuration option is either stable or unstable. Stable options can be used directly, while unstable options are opt-in. To enable unstable options, set unstable_features = true in rustfmt.toml or pass --unstable-features to rustfmt.

Which makes it seems like you could enable these features on stable toolchains.

Like you say, it does list unstable_features itself as an unstable feature though

unstable_features

Enable unstable features on the unstable channel.

Default value: `false`
Possible values: `true`, `false`
Stable: No (tracking issue: #3387)

But this description both makes it sound like you could disable other unstable features by setting the value to false, and also that unstable features should be disabled by default ("Default value: false").

---

If the intention is to just leave things as they are, where this key doesn't do anything, perhaps mention of it should just be scrubbed from the documentation entirely (at least removing its very prominent position at the top of the docs), or changed to clarify its behaviour as an 'unstable noop' - so it doesn't generate frustration for users when they try to use it.

[calebcartwright]

Yup that sounds fair. Think this is a case where functionality has started moving towards a desired state which has caused the documentation to drift a bit, and those docs need to be caught up.

Thanks again for flagging this!