Rename `cfg_match!` to `cfg_select!` by tgross35 · Pull Request #137198 · rust-lang/rust

tgross35 · 2025-02-18T01:01:18Z

@Nemo157 pointed out that cfg_match! syntax does not actually align well with match syntax, which is a possible source of confusion. The comment points out that usage is instead more similar to ecosystem select! macros. Rename cfg_match! to cfg_select! to match this.

Tracking issue: #115585

rustbot · 2025-02-18T01:01:27Z

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2025-02-18T01:01:30Z

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

tgross35 · 2025-02-18T01:01:31Z

r? libs-api

joshtriplett · 2025-02-19T01:46:22Z

Nominating for discussion.

joshtriplett · 2025-02-19T01:46:41Z

Speaking for myself only: not in favor of this rename.

bors · 2025-02-23T15:06:57Z

☔ The latest upstream changes (presumably #137237) made this pull request unmergeable. Please resolve the merge conflicts.

tgross35 · 2025-02-26T05:47:54Z

From the meeting notes, TC mentioned cfg_cond as an alternative.

traviscross · 2025-02-26T15:35:30Z

That is what I always called the macro myself, in my versions. It's probably the most correct PL theory name for the construct.

cond is what you get in Rust if you write:

match () {
    _ if predicate1 => ..,
    _ if predicate2 => ..,
    _ if predicate3 => ..,
    _ => ..,
}

(That is, as if let .. = .. else if let .. is to match, if .. else if .. is to cond.)

So it's in that sense that I think cfg_match! is fine too, as this is a kind of match that's been stripped down that way. But... yes, cfg_cond! is probably more correct.

ChrisDenton · 2025-02-26T17:31:50Z

I don't have a strong opinion here only that having "match" in the name when it is notably different to match is less than ideal. On the other hand it's not the end of the world if I have to teach and explain that this match is a bit different to that match. It's just kinda awkward.

Amanieu · 2025-04-15T21:46:50Z

This was discussed in the @rust-lang/libs-api meeting last week. We decided to stick with the cfg_match name. Opinions were divided but in the end the syntax isn't any closer to select! than match.

Amanieu · 2025-05-06T17:11:05Z

As per the @rust-lang/libs-api decision in #115585 (comment), I'm re-opening this PR to rename cfg_match to cfg_select.

Amanieu · 2025-05-20T15:21:56Z

@rustbot author

rustbot · 2025-05-20T15:22:01Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

rustbot · 2025-05-20T21:15:20Z

The Miri subtree was changed

cc @rust-lang/miri

At [1] it was pointed out that `cfg_match!` syntax does not actually align well with match syntax, which is a possible source of confusion. The comment points out that usage is instead more similar to ecosystem `select!` macros. Rename `cfg_match!` to `cfg_select!` to match this. Tracking issue: rust-lang#115585 [1]: rust-lang#115585 (comment)

tgross35 · 2025-05-20T22:25:04Z

Rebased, it looks like no bootstrap config is needed anymore.

@rustbot ready

Amanieu · 2025-05-21T09:37:44Z

@bors r+

bors · 2025-05-21T09:37:47Z

📌 Commit 999967a has been approved by Amanieu

It is now in the queue for this repository.

bors · 2025-05-22T02:14:27Z

⌛ Testing commit 999967a with merge 6eef33b...

bors · 2025-05-22T05:25:57Z

☀️ Test successful - checks-actions
Approved by: Amanieu
Pushing 6eef33b to master...

github-actions · 2025-05-22T05:28:46Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 5df0f72 (parent) -> 6eef33b (this PR)

Test differences

Show 28 test diffs

Stage 0

macros::cfg_match_basic: pass -> [missing] (J0)
macros::cfg_match_debug_assertions: pass -> [missing] (J0)
macros::cfg_match_no_duplication_on_64: pass -> [missing] (J0)
macros::cfg_match_options: pass -> [missing] (J0)
macros::cfg_match_two_functions: pass -> [missing] (J0)
macros::cfg_select_basic: [missing] -> pass (J0)
macros::cfg_select_debug_assertions: [missing] -> pass (J0)
macros::cfg_select_no_duplication_on_64: [missing] -> pass (J0)
macros::cfg_select_options: [missing] -> pass (J0)
macros::cfg_select_two_functions: [missing] -> pass (J0)

Stage 1

macros::cfg_match_basic: pass -> [missing] (J1)
macros::cfg_match_debug_assertions: pass -> [missing] (J1)
macros::cfg_match_options: pass -> [missing] (J1)
macros::cfg_match_two_functions: pass -> [missing] (J1)
macros::cfg_select_basic: [missing] -> pass (J1)
macros::cfg_select_debug_assertions: [missing] -> pass (J1)
macros::cfg_select_options: [missing] -> pass (J1)
macros::cfg_select_two_functions: [missing] -> pass (J1)
macros::cfg_match_no_duplication_on_64: pass -> [missing] (J2)
macros::cfg_select_no_duplication_on_64: [missing] -> pass (J2)

Additionally, 8 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 6eef33bb399cabfab16aa4e0825895f5f32f4e26 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

x86_64-apple-2: 4888.6s -> 5807.5s (18.8%)
aarch64-apple: 5119.1s -> 4287.7s (-16.2%)
dist-apple-various: 6446.4s -> 7217.2s (12.0%)
dist-x86_64-msvc-alt: 7405.5s -> 8228.3s (11.1%)
dist-aarch64-apple: 5421.3s -> 5952.6s (9.8%)
x86_64-apple-1: 8252.9s -> 8782.1s (6.4%)
armhf-gnu: 4421.9s -> 4698.2s (6.2%)
dist-x86_64-musl: 7160.2s -> 7516.8s (5.0%)
dist-x86_64-apple: 8737.7s -> 9150.5s (4.7%)
x86_64-mingw-2: 7376.8s -> 7050.0s (-4.4%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2025-05-22T06:57:50Z

Finished benchmarking commit (6eef33b): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -1.7%, secondary -3.7%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.7%	[-1.7%, -1.7%]	1
Improvements ✅ (secondary)	-3.7%	[-3.7%, -3.7%]	1
All ❌✅ (primary)	-1.7%	[-1.7%, -1.7%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 776.959s -> 777.17s (0.03%)
Artifact size: 365.55 MiB -> 365.60 MiB (0.01%)

Rename `cfg_match!` to `cfg_select!` [`@Nemo157` pointed out](rust-lang#115585 (comment)) that `cfg_match!` syntax does not actually align well with match syntax, which is a possible source of confusion. The comment points out that usage is instead more similar to ecosystem `select!` macros. Rename `cfg_match!` to `cfg_select!` to match this. Tracking issue: rust-lang#115585 [1]: rust-lang#115585 (comment)

@traviscross

…=JonathanBrouwer stabilize `cfg_select!` *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/149783)* tracking issue: rust-lang#115585 closes rust-lang#115585 reference PR: - rust-lang/reference#2103 # Request for Stabilization ## Summary The `cfg_select!` macro picks the expansion corresponding to the first `cfg` condition that evaluates to `true`. It simplifies complex conditional expressions. ```rust cfg_select! { unix => { fn foo() { /* unix specific functionality */ } } target_pointer_width = "32" => { fn foo() { /* non-unix, 32-bit functionality */ } } _ => { fn foo() { /* fallback implementation */ } } } let is_unix_str = cfg_select! { unix => "unix", _ => "not unix", }; println!("{is_unix_str}"); ``` ## Semantics The expansion of a `cfg_select!` call is the right-hand side of the first `cfg` rule that evaluates to true. This can be roughly expressed using this macro: ```rust macro_rules! cfg_select { ({ $($tt:tt)* }) => {{ $crate::cfg_select! { $($tt)* } }}; (_ => { $($output:tt)* }) => { $($output)* }; ( $cfg:meta => $output:tt $($( $rest:tt )+)? ) => { #[cfg($cfg)] $crate::cfg_select! { _ => $output } $( #[cfg(not($cfg))] $crate::cfg_select! { $($rest)+ } )? } } ``` The actual implementation uses a builtin macro so that `cfg_select!` can be used both in item and expression position. ## Documentation reference PR: - rust-lang/reference#2103 ## Tests The `cfg_select!` macro is already used extensively in the rust compiler codebase. It has several dedicated tests: - [`tests/ui/check-cfg/cfg-select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/check-cfg/cfg-select.rs)tests that warnings are emitted when an unexpected `cfg` condition is used. - [`tests/ui/macros/cfg_select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/macros/cfg_select.rs) tests that `cfg_select!` has the expected expansion, and tests that the expected syntax is accepted. ## History - rust-lang#115416 - rust-lang#117162 - rust-lang#133720 - rust-lang#135625 - rust-lang#137198 - rust-lang#138993 - rust-lang#138996 - rust-lang#143461 - rust-lang#143941 - rust-lang#145233 - rust-lang#148712 - rust-lang#149380 - rust-lang#149925 # Resolved questions # Unresolved questions The style team has decided on how to format `cfg_select!`, but this formatting has not yet been implemented. See rust-lang#144323. r? @traviscross   > [!NOTE] > # Concerns (0 active) > > - ~~[allowing-comma-after-closing-brace](rust-lang#149783 (comment) resolved in [this comment](rust-lang#149783 (comment)) > > *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

@traviscross

…=JonathanBrouwer stabilize `cfg_select!` *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/149783)* tracking issue: rust-lang#115585 closes rust-lang#115585 reference PR: - rust-lang/reference#2103 # Request for Stabilization ## Summary The `cfg_select!` macro picks the expansion corresponding to the first `cfg` condition that evaluates to `true`. It simplifies complex conditional expressions. ```rust cfg_select! { unix => { fn foo() { /* unix specific functionality */ } } target_pointer_width = "32" => { fn foo() { /* non-unix, 32-bit functionality */ } } _ => { fn foo() { /* fallback implementation */ } } } let is_unix_str = cfg_select! { unix => "unix", _ => "not unix", }; println!("{is_unix_str}"); ``` ## Semantics The expansion of a `cfg_select!` call is the right-hand side of the first `cfg` rule that evaluates to true. This can be roughly expressed using this macro: ```rust macro_rules! cfg_select { ({ $($tt:tt)* }) => {{ $crate::cfg_select! { $($tt)* } }}; (_ => { $($output:tt)* }) => { $($output)* }; ( $cfg:meta => $output:tt $($( $rest:tt )+)? ) => { #[cfg($cfg)] $crate::cfg_select! { _ => $output } $( #[cfg(not($cfg))] $crate::cfg_select! { $($rest)+ } )? } } ``` The actual implementation uses a builtin macro so that `cfg_select!` can be used both in item and expression position. ## Documentation reference PR: - rust-lang/reference#2103 ## Tests The `cfg_select!` macro is already used extensively in the rust compiler codebase. It has several dedicated tests: - [`tests/ui/check-cfg/cfg-select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/check-cfg/cfg-select.rs)tests that warnings are emitted when an unexpected `cfg` condition is used. - [`tests/ui/macros/cfg_select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/macros/cfg_select.rs) tests that `cfg_select!` has the expected expansion, and tests that the expected syntax is accepted. ## History - rust-lang#115416 - rust-lang#117162 - rust-lang#133720 - rust-lang#135625 - rust-lang#137198 - rust-lang#138993 - rust-lang#138996 - rust-lang#143461 - rust-lang#143941 - rust-lang#145233 - rust-lang#148712 - rust-lang#149380 - rust-lang#149925 # Resolved questions # Unresolved questions The style team has decided on how to format `cfg_select!`, but this formatting has not yet been implemented. See rust-lang#144323. r? @traviscross   > [!NOTE] > # Concerns (0 active) > > - ~~[allowing-comma-after-closing-brace](rust-lang#149783 (comment) resolved in [this comment](rust-lang#149783 (comment)) > > *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

@traviscross

…=JonathanBrouwer stabilize `cfg_select!` *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/149783)* tracking issue: rust-lang#115585 closes rust-lang#115585 reference PR: - rust-lang/reference#2103 # Request for Stabilization ## Summary The `cfg_select!` macro picks the expansion corresponding to the first `cfg` condition that evaluates to `true`. It simplifies complex conditional expressions. ```rust cfg_select! { unix => { fn foo() { /* unix specific functionality */ } } target_pointer_width = "32" => { fn foo() { /* non-unix, 32-bit functionality */ } } _ => { fn foo() { /* fallback implementation */ } } } let is_unix_str = cfg_select! { unix => "unix", _ => "not unix", }; println!("{is_unix_str}"); ``` ## Semantics The expansion of a `cfg_select!` call is the right-hand side of the first `cfg` rule that evaluates to true. This can be roughly expressed using this macro: ```rust macro_rules! cfg_select { ({ $($tt:tt)* }) => {{ $crate::cfg_select! { $($tt)* } }}; (_ => { $($output:tt)* }) => { $($output)* }; ( $cfg:meta => $output:tt $($( $rest:tt )+)? ) => { #[cfg($cfg)] $crate::cfg_select! { _ => $output } $( #[cfg(not($cfg))] $crate::cfg_select! { $($rest)+ } )? } } ``` The actual implementation uses a builtin macro so that `cfg_select!` can be used both in item and expression position. ## Documentation reference PR: - rust-lang/reference#2103 ## Tests The `cfg_select!` macro is already used extensively in the rust compiler codebase. It has several dedicated tests: - [`tests/ui/check-cfg/cfg-select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/check-cfg/cfg-select.rs)tests that warnings are emitted when an unexpected `cfg` condition is used. - [`tests/ui/macros/cfg_select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/macros/cfg_select.rs) tests that `cfg_select!` has the expected expansion, and tests that the expected syntax is accepted. ## History - rust-lang#115416 - rust-lang#117162 - rust-lang#133720 - rust-lang#135625 - rust-lang#137198 - rust-lang#138993 - rust-lang#138996 - rust-lang#143461 - rust-lang#143941 - rust-lang#145233 - rust-lang#148712 - rust-lang#149380 - rust-lang#149925 # Resolved questions # Unresolved questions The style team has decided on how to format `cfg_select!`, but this formatting has not yet been implemented. See rust-lang#144323. r? @traviscross   > [!NOTE] > # Concerns (0 active) > > - ~~[allowing-comma-after-closing-brace](rust-lang#149783 (comment) resolved in [this comment](rust-lang#149783 (comment)) > > *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

@traviscross

…=JonathanBrouwer stabilize `cfg_select!` *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/149783)* tracking issue: rust-lang#115585 closes rust-lang#115585 reference PR: - rust-lang/reference#2103 # Request for Stabilization ## Summary The `cfg_select!` macro picks the expansion corresponding to the first `cfg` condition that evaluates to `true`. It simplifies complex conditional expressions. ```rust cfg_select! { unix => { fn foo() { /* unix specific functionality */ } } target_pointer_width = "32" => { fn foo() { /* non-unix, 32-bit functionality */ } } _ => { fn foo() { /* fallback implementation */ } } } let is_unix_str = cfg_select! { unix => "unix", _ => "not unix", }; println!("{is_unix_str}"); ``` ## Semantics The expansion of a `cfg_select!` call is the right-hand side of the first `cfg` rule that evaluates to true. This can be roughly expressed using this macro: ```rust macro_rules! cfg_select { ({ $($tt:tt)* }) => {{ $crate::cfg_select! { $($tt)* } }}; (_ => { $($output:tt)* }) => { $($output)* }; ( $cfg:meta => $output:tt $($( $rest:tt )+)? ) => { #[cfg($cfg)] $crate::cfg_select! { _ => $output } $( #[cfg(not($cfg))] $crate::cfg_select! { $($rest)+ } )? } } ``` The actual implementation uses a builtin macro so that `cfg_select!` can be used both in item and expression position. ## Documentation reference PR: - rust-lang/reference#2103 ## Tests The `cfg_select!` macro is already used extensively in the rust compiler codebase. It has several dedicated tests: - [`tests/ui/check-cfg/cfg-select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/check-cfg/cfg-select.rs)tests that warnings are emitted when an unexpected `cfg` condition is used. - [`tests/ui/macros/cfg_select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/macros/cfg_select.rs) tests that `cfg_select!` has the expected expansion, and tests that the expected syntax is accepted. ## History - rust-lang#115416 - rust-lang#117162 - rust-lang#133720 - rust-lang#135625 - rust-lang#137198 - rust-lang#138993 - rust-lang#138996 - rust-lang#143461 - rust-lang#143941 - rust-lang#145233 - rust-lang#148712 - rust-lang#149380 - rust-lang#149925 # Resolved questions # Unresolved questions The style team has decided on how to format `cfg_select!`, but this formatting has not yet been implemented. See rust-lang#144323. r? @traviscross   > [!NOTE] > # Concerns (0 active) > > - ~~[allowing-comma-after-closing-brace](rust-lang#149783 (comment) resolved in [this comment](rust-lang#149783 (comment)) > > *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

@traviscross

Rollup merge of #149783 - folkertdev:stabilize-cfg-select, r=JonathanBrouwer stabilize `cfg_select!` *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/149783)* tracking issue: #115585 closes #115585 reference PR: - rust-lang/reference#2103 # Request for Stabilization ## Summary The `cfg_select!` macro picks the expansion corresponding to the first `cfg` condition that evaluates to `true`. It simplifies complex conditional expressions. ```rust cfg_select! { unix => { fn foo() { /* unix specific functionality */ } } target_pointer_width = "32" => { fn foo() { /* non-unix, 32-bit functionality */ } } _ => { fn foo() { /* fallback implementation */ } } } let is_unix_str = cfg_select! { unix => "unix", _ => "not unix", }; println!("{is_unix_str}"); ``` ## Semantics The expansion of a `cfg_select!` call is the right-hand side of the first `cfg` rule that evaluates to true. This can be roughly expressed using this macro: ```rust macro_rules! cfg_select { ({ $($tt:tt)* }) => {{ $crate::cfg_select! { $($tt)* } }}; (_ => { $($output:tt)* }) => { $($output)* }; ( $cfg:meta => $output:tt $($( $rest:tt )+)? ) => { #[cfg($cfg)] $crate::cfg_select! { _ => $output } $( #[cfg(not($cfg))] $crate::cfg_select! { $($rest)+ } )? } } ``` The actual implementation uses a builtin macro so that `cfg_select!` can be used both in item and expression position. ## Documentation reference PR: - rust-lang/reference#2103 ## Tests The `cfg_select!` macro is already used extensively in the rust compiler codebase. It has several dedicated tests: - [`tests/ui/check-cfg/cfg-select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/check-cfg/cfg-select.rs)tests that warnings are emitted when an unexpected `cfg` condition is used. - [`tests/ui/macros/cfg_select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/macros/cfg_select.rs) tests that `cfg_select!` has the expected expansion, and tests that the expected syntax is accepted. ## History - #115416 - #117162 - #133720 - #135625 - #137198 - #138993 - #138996 - #143461 - #143941 - #145233 - #148712 - #149380 - #149925 # Resolved questions # Unresolved questions The style team has decided on how to format `cfg_select!`, but this formatting has not yet been implemented. See #144323. r? @traviscross   > [!NOTE] > # Concerns (0 active) > > - ~~[allowing-comma-after-closing-brace](#149783 (comment) resolved in [this comment](#149783 (comment)) > > *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

@traviscross

…Brouwer stabilize `cfg_select!` *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/149783)* tracking issue: rust-lang/rust#115585 closes rust-lang/rust#115585 reference PR: - rust-lang/reference#2103 # Request for Stabilization ## Summary The `cfg_select!` macro picks the expansion corresponding to the first `cfg` condition that evaluates to `true`. It simplifies complex conditional expressions. ```rust cfg_select! { unix => { fn foo() { /* unix specific functionality */ } } target_pointer_width = "32" => { fn foo() { /* non-unix, 32-bit functionality */ } } _ => { fn foo() { /* fallback implementation */ } } } let is_unix_str = cfg_select! { unix => "unix", _ => "not unix", }; println!("{is_unix_str}"); ``` ## Semantics The expansion of a `cfg_select!` call is the right-hand side of the first `cfg` rule that evaluates to true. This can be roughly expressed using this macro: ```rust macro_rules! cfg_select { ({ $($tt:tt)* }) => {{ $crate::cfg_select! { $($tt)* } }}; (_ => { $($output:tt)* }) => { $($output)* }; ( $cfg:meta => $output:tt $($( $rest:tt )+)? ) => { #[cfg($cfg)] $crate::cfg_select! { _ => $output } $( #[cfg(not($cfg))] $crate::cfg_select! { $($rest)+ } )? } } ``` The actual implementation uses a builtin macro so that `cfg_select!` can be used both in item and expression position. ## Documentation reference PR: - rust-lang/reference#2103 ## Tests The `cfg_select!` macro is already used extensively in the rust compiler codebase. It has several dedicated tests: - [`tests/ui/check-cfg/cfg-select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/check-cfg/cfg-select.rs)tests that warnings are emitted when an unexpected `cfg` condition is used. - [`tests/ui/macros/cfg_select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/macros/cfg_select.rs) tests that `cfg_select!` has the expected expansion, and tests that the expected syntax is accepted. ## History - rust-lang/rust#115416 - rust-lang/rust#117162 - rust-lang/rust#133720 - rust-lang/rust#135625 - rust-lang/rust#137198 - rust-lang/rust#138993 - rust-lang/rust#138996 - rust-lang/rust#143461 - rust-lang/rust#143941 - rust-lang/rust#145233 - rust-lang/rust#148712 - rust-lang/rust#149380 - rust-lang/rust#149925 # Resolved questions # Unresolved questions The style team has decided on how to format `cfg_select!`, but this formatting has not yet been implemented. See rust-lang/rust#144323. r? @traviscross   > [!NOTE] > # Concerns (0 active) > > - ~~[allowing-comma-after-closing-brace](rust-lang/rust#149783 (comment) resolved in [this comment](rust-lang/rust#149783 (comment)) > > *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

rustbot assigned Mark-Simulacrum Feb 18, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Feb 18, 2025

rustbot added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Feb 18, 2025

rustbot assigned m-ou-se and unassigned Mark-Simulacrum Feb 18, 2025

tgross35 mentioned this pull request Feb 18, 2025

Tracking issue for cfg_select (formerly cfg_match) #115585

Closed

5 tasks

joshtriplett added the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Feb 19, 2025

Amanieu removed the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Apr 15, 2025

Amanieu closed this Apr 15, 2025

Amanieu reopened this May 6, 2025

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 20, 2025

tgross35 force-pushed the cfg-match-rename branch from 3a231bf to 0e238c2 Compare May 20, 2025 21:15

tgross35 force-pushed the cfg-match-rename branch from 0e238c2 to 999967a Compare May 20, 2025 21:16

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 20, 2025

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 21, 2025

folkertdev mentioned this pull request May 21, 2025

use cfg_select! to select the right VaListImpl definition #141361

Merged

bors added the merged-by-bors This PR was explicitly merged by bors. label May 22, 2025

bors merged commit 6eef33b into rust-lang:master May 22, 2025
7 checks passed

rustbot added this to the 1.89.0 milestone May 22, 2025

tgross35 deleted the cfg-match-rename branch May 22, 2025 08:44

jieyouxu added the F-cfg_select `#![feature(cfg_select)]` label Aug 14, 2025

folkertdev mentioned this pull request Dec 8, 2025

stabilize cfg_select! #149783

Merged

Uh oh!

Conversation

tgross35 commented Feb 18, 2025

Uh oh!

rustbot commented Feb 18, 2025

Uh oh!

rustbot commented Feb 18, 2025

Uh oh!

tgross35 commented Feb 18, 2025

Uh oh!

joshtriplett commented Feb 19, 2025

Uh oh!

joshtriplett commented Feb 19, 2025

Uh oh!

bors commented Feb 23, 2025

Uh oh!

tgross35 commented Feb 26, 2025

Uh oh!

traviscross commented Feb 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ChrisDenton commented Feb 26, 2025

Uh oh!

Amanieu commented Apr 15, 2025

Uh oh!

Amanieu commented May 6, 2025

Uh oh!

Amanieu commented May 20, 2025

Uh oh!

rustbot commented May 20, 2025

Uh oh!

rustbot commented May 20, 2025

Uh oh!

tgross35 commented May 20, 2025

Uh oh!

Amanieu commented May 21, 2025

Uh oh!

bors commented May 21, 2025

Uh oh!

bors commented May 22, 2025

Uh oh!

bors commented May 22, 2025

Uh oh!

Uh oh!

github-actions bot commented May 22, 2025

Test differences

Stage 0

Stage 1

Job duration changes

Uh oh!

rust-timer commented May 22, 2025

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

11 participants

traviscross commented Feb 26, 2025 •

edited

Loading