Re: [PATCH 0/2] rust: kernel: add cfg_select! and use it for config-based selection

[Nika Krasnova <nika@nikableh.moe>]

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