On 2026-06-29 21:07:34 +0200, Miguel Ojeda wrote:
The tracking issue says the latest change was in Rust 1.91.0. Did it
not work there? Were there changes after that?

Checked 1.91.0 directly: core::cfg_select is there behind
#![feature(cfg_select)] and behaves the same as 1.94.1 -- single-brace
expression position included. So 1.91.0 is the cutoff (RUSTC_VERSION >=
109100), nothing changed between 1.91.0 and 1.94.1.

[...] If I understand you correctly, you are saying that even with
the conversion here, we wouldn't even need the expression case, no?

That is correct. Everything in this series is item or statement position;
nothing uses the expression-operand form.

[...] if we want to go with this one in all versions, then we should
make sure we only allow that subset that cleanly maps to the future.

Agreed. I'll restrict the fallback to exactly that subset
(item/statement, single braces) by dropping the expression-operand form.
Everyone hits the fallback until the MSRV bump, so a non-portable use
fails uniformly instead of compiling locally and breaking in linux-next.
The accepted subset is a strict subset of core::cfg_select, so the
eventual switch needs no call-site changes. (I'll also have the fallback
emit compile_error! on no-match, to match core.)

Now, to be honest, the easiest is to just wait a year and then start
using `core`'s directly... i.e. it is not like we are in a rush to
start using it anyway...

Fair, I'm fine with dropping it. The counterargument is that the fallback
is small and self-contained, and the conversion removes a chunk of
easy-to-desync pairs of #[cfg] now rather than in a year. Happy to send a
v2 if you want it.

--
Nika Krasnova

Reply via email to