On 2026-06-29 11:38:22 +0200, Miguel Ojeda wrote:
For instance, instead of waiting for the MSRV bump, could we already
use the upstream one since Rust 1.91.0? That means that we are already
sure we are using the upstream one as-is.
Or is there a reason to avoid that?
There is one, yes. First the toolchain picture (tested with
RUSTC_BOOTSTRAP=1):
- 1.85.0 (current MSRV): core::cfg_select does not exist -- only the
older
core::cfg_match (old `cfg(...)` arm syntax).
- 1.94.1: core::cfg_select present behind #![feature(cfg_select)], with
the final builtin behavior (single-brace expression position works).
- 1.95.0: core::cfg_select stable.
A gate (upstream when available, fallback when not) is possible, but
unlike
the cold_path case the fallback isn't a drop-in replacement. In item and
statement position the two are identical (single braces), but in pure
expression-operand position they are mutually exclusive: the builtin
takes
single braces, while the macro_rules needs an extra pair
(cfg_select! {{ ... }}), since it cannot put #[cfg] on a bare expression
without stmt_expr_attributes. No single spelling compiles on both.
That means a gate would force prohibiting expression-operand position
entirely (no portable spelling), which I would rather not do. I would
prefer to keep the macro_rules everywhere -- one consistent macro on
every
toolchain, expression position included -- and switch wholesale to
core::cfg_select once the MSRV reaches a version that has it. The switch
is
cheap: item/statement call sites are unchanged, and the only edit is
dropping the extra braces at any expression-position sites (there are
none
in the tree today).
I will still move it into std_vendor.rs and align the docs with
upstream's,
keeping the expression-position note since that is the one real
difference.
Does that work for you, or would you rather take the gate and drop
expression-operand support?
--
Nika Krasnova
