Make `cfg_match!` a semitransparent macro by CAD97 · Pull Request #138993 · rust-lang/rust

CAD97 · 2025-03-26T18:04:05Z

IIUC this is preferred when (potentially) stabilizing macro items, to avoid potentially utilizing def-site hygiene instead of mixed-site.

Tracking issue: #115585

rustbot · 2025-03-26T18:04:10Z

r? @workingjubilee

rustbot has assigned @workingjubilee.
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

workingjubilee · 2025-03-27T03:49:19Z

@CAD97 I'm confused, what's wrong with def-site hygiene?

CAD97 · 2025-03-27T03:56:28Z

Nothing wrong, per say, just that nothing has yet exposed "macros 2.0" hygiene existing to stable. Even pin!, which was originally formulated to rely on def-site access to a private inner field, has been changed to use semitransparent hygiene.

joshtriplett · 2025-04-08T15:56:40Z

We discussed this in today's libs-api meeting. The rationale of not exposing "macros 2.0" hygiene differences made sense, and if we understood correctly, this should be equivalent to if the macro was written using macro_rules! instead. We also expected that if it were exposed any differently, that'd need to be a lang decision to expose any "macros 2.0" functionality, and we didn't expect that there'd be any desire to do so. So, generally speaking 👍 from libs-api.

That said, several of us were interested in understanding this better. Could someone post an example of, in the absence of this PR, what would be possible using cfg_match! that would expose the "macros 2.0" hygiene difference?

CAD97 · 2025-04-08T18:59:04Z

I believe there's no functional difference in this case as cfg_match! is currently implemented, since the only names used in the expansion are cfg_match! and #[cfg]. The former is made fully hygienic via the $crate:: path, and #[cfg] can't be shadowed.

Thus, using the semitransparent macro_rules! hygiene is just being conservative in this case; the already stable usable hygiene is sufficient, so it's better to use it instead of the macros 2.0 hygiene.

dtolnay

Thanks!

dtolnay · 2025-04-08T19:14:13Z

@bors r+

bors · 2025-04-08T19:14:41Z

📌 Commit 2c70c8a has been approved by dtolnay

It is now in the queue for this repository.

…=dtolnay Make `cfg_match!` a semitransparent macro IIUC this is preferred when (potentially) stabilizing `macro` items, to avoid potentially utilizing def-site hygiene instead of mixed-site. Tracking issue: rust-lang#115585

…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#137412 (Ensure `swap_nonoverlapping` is really always untyped) - rust-lang#138869 (Try not to use verbatim paths in `Command::current_dir`) - rust-lang#138993 (Make `cfg_match!` a semitransparent macro) - rust-lang#139099 (Promise `array::from_fn` is generated in order of increasing indices) - rust-lang#139364 (Make the compiler suggest actual paths instead of visible paths if the visible paths are through any doc hidden path.) - rust-lang#139468 (Don't call `Span::with_parent` on the good path in `has_stashed_diagnostic`) - rust-lang#139481 (Add job summary links to post-merge report) r? `@ghost` `@rustbot` modify labels: rollup

…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#138869 (Try not to use verbatim paths in `Command::current_dir`) - rust-lang#138993 (Make `cfg_match!` a semitransparent macro) - rust-lang#139099 (Promise `array::from_fn` is generated in order of increasing indices) - rust-lang#139364 (Make the compiler suggest actual paths instead of visible paths if the visible paths are through any doc hidden path.) - rust-lang#139468 (Don't call `Span::with_parent` on the good path in `has_stashed_diagnostic`) - rust-lang#139481 (Add job summary links to post-merge report) - rust-lang#139573 (Miri subtree update) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#138993 - CAD97:cfg_match_semitransparent, r=dtolnay Make `cfg_match!` a semitransparent macro IIUC this is preferred when (potentially) stabilizing `macro` items, to avoid potentially utilizing def-site hygiene instead of mixed-site. Tracking issue: rust-lang#115585

…=dtolnay Make `cfg_match!` a semitransparent macro IIUC this is preferred when (potentially) stabilizing `macro` items, to avoid potentially utilizing def-site hygiene instead of mixed-site. Tracking issue: rust-lang#115585

@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.*

mark cfg_match! semitransparent

2c70c8a

rustbot assigned workingjubilee Mar 26, 2025

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

dtolnay approved these changes Apr 8, 2025

View reviewed changes

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 Apr 8, 2025

dtolnay assigned dtolnay and unassigned workingjubilee Apr 8, 2025

matthiaskrgr mentioned this pull request Apr 9, 2025

Rollup of 7 pull requests #139571

Closed

matthiaskrgr mentioned this pull request Apr 9, 2025

Rollup of 7 pull requests #139581

Merged

bors merged commit 19d4d9f into rust-lang:master Apr 9, 2025
6 checks passed

rustbot added this to the 1.88.0 milestone Apr 9, 2025

CAD97 deleted the cfg_match_semitransparent branch April 10, 2025 02:43

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

jieyouxu mentioned this pull request Aug 14, 2025

Tracking issue for cfg_select (formerly cfg_match) #115585

Closed

5 tasks

folkertdev mentioned this pull request Dec 8, 2025

stabilize cfg_select! #149783

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Make `cfg_match!` a semitransparent macro#138993

Make `cfg_match!` a semitransparent macro#138993
bors merged 1 commit intorust-lang:masterfrom
CAD97:cfg_match_semitransparent

CAD97 commented Mar 26, 2025 •

edited

Loading

Uh oh!

rustbot commented Mar 26, 2025

Uh oh!

workingjubilee commented Mar 27, 2025

Uh oh!

CAD97 commented Mar 27, 2025

Uh oh!

joshtriplett commented Apr 8, 2025

Uh oh!

CAD97 commented Apr 8, 2025

Uh oh!

dtolnay left a comment

Uh oh!

dtolnay commented Apr 8, 2025

Uh oh!

bors commented Apr 8, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Uh oh!

Conversation

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

Uh oh!

Uh oh!

rustbot commented Mar 26, 2025

Uh oh!

workingjubilee commented Mar 27, 2025

Uh oh!

CAD97 commented Mar 27, 2025

Uh oh!

joshtriplett commented Apr 8, 2025

Uh oh!

CAD97 commented Apr 8, 2025

Uh oh!

dtolnay left a comment

Choose a reason for hiding this comment

Uh oh!

dtolnay commented Apr 8, 2025

Uh oh!

bors commented Apr 8, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

CAD97 commented Mar 26, 2025 •

edited

Loading