Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
69 changes: 67 additions & 2 deletions src/conditional-compilation.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ r[cfg.general]
*Conditionally compiled source code* is source code that is compiled only under certain conditions.

r[cfg.attributes-macro]
Source code can be made conditionally compiled using the [`cfg`] and [`cfg_attr`] [attributes] and the built-in [`cfg` macro].
Source code can be made conditionally compiled using the [`cfg`] and [`cfg_attr`] [attributes] and the built-in [`cfg!`] and [`cfg_select!`] [macros].

r[cfg.conditional]
Whether to compile can depend on the target architecture of the compiled crate, arbitrary values passed to the compiler, and other things further described below.
Expand Down Expand Up @@ -466,11 +466,75 @@ let machine_kind = if cfg!(unix) {
println!("I'm running on a {} machine!", machine_kind);
```

r[cfg.cfg_select]
### The `cfg_select` macro

r[cfg.cfg_select.syntax]
```grammar,configuration
CfgSelect ->
cfg_select! `{` CfgSelectBranch* `}`

CfgSelectConfigurationPredicate ->
ConfigurationPredicate | `_`

CfgSelectBranch ->
CfgSelectConfigurationPredicate `=>` `{` TokenTree `}`
| CfgSelectConfigurationPredicate `=>` TokenTree `,`
```
Comment on lines +473 to +483
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This grammar doesn't quite look correct to me.

Some comments:

  • We don't have a precedent for documenting macro inputs. I don't think we can express it like `cfg_select!` `{` … `}` because the braces can also be () or [] (also ! is a separate token), and the macro name can be renamed. I would suggest just documenting what the input to the macro is, and not the surrounding invocation syntax.
  • This doesn't handle the difference in behavior of the last branch.
  • This doesn't specify that the non-braced value needs to be an expression of a certain kind.
  • This doesn't handle the optional , behavior.

I'm thinking the grammar would be something closer to:

@root CfgSelect ->
    CfgSelectBranch*
    LastCfgSelectBranch?

CfgSelectBranch ->
    CfgSelectConfigurationPredicate `=>` `{` TokenTree `}`
  | CfgSelectConfigurationPredicate `=>` ExpressionWithBlockX `,`?
  | CfgSelectConfigurationPredicate `=>` ExpressionWithoutBlockX `,`

ExpressionWithBlockX ->
      BlockExpression
    | ConstBlockExpression
    | UnsafeBlockExpression
    | LoopExpression
    | IfExpression
    | MatchExpression

ExpressionWithoutBlockX ->
      LiteralExpression
    | PathExpression
    | OperatorExpression
    | GroupedExpression
    | ArrayExpression
    | AwaitExpression
    | IndexExpression
    | TupleExpression
    | TupleIndexingExpression
    | StructExpression
    | CallExpression
    | MethodCallExpression
    | FieldExpression
    | ClosureExpression
    | AsyncBlockExpression
    | ContinueExpression
    | BreakExpression
    | RangeExpression
    | ReturnExpression
    | UnderscoreExpression
    | MacroInvocation

LastCfgSelectBranch ->
    CfgSelectConfigurationPredicate => ExpressionX `,`?

ExpressionX -> ExpressionWithBlockX | ExpressionWithoutBlockX

CfgSelectConfigurationPredicate ->
    ConfigurationPredicate | `_`

Where the X expressions are from the Expression grammar, but without the outer attributes. If this is correct, we'll need to rework Expression to support that.

Does that make sense?

Copy link
Contributor

@ehuss ehuss Jan 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though looking again, my suggestion above won't work because we are moving towards a grammar that does not have infinite lookahead for disambiguation. So the LastCfgSelectBranch won't work. I offhand can't think of a way to actually express that...

(Maybe lookahead is required?)


r[cfg.cfg_select.general]
The built-in `cfg_select` macro expands to the `TokenTree` on the right-hand side of the first configuration predicate that evaluates to `true`.
Comment on lines +485 to +486
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it clear enough from the grammer and the language here that the { /* ... */ } are dropped?


For example:

```rust
cfg_select! {
unix => {
fn foo() { /* unix specific functionality */ }
}
target_pointer_width = "32" => {
fn foo() { /* non-unix, 32-bit functionality */ }
}
_ => {
fn foo() { /* fallback implementation */ }
}
}
```
The `cfg_select` macro can also be used in expression position:

```rust
let is_unix_str = cfg_select! {
unix => "unix",
_ => "not unix",
};
```

r[cfg.cfg_select.wildcard]
A `_` can be used to write a configuration predicate that always evaluates to `true`.

r[cfg.cfg_select.fallthrough]
If none of the predicates evaluates to `true`, a compiler error is emitted.

r[cfg.cfg_select.positions]
The `cfg_select!` macro is accepted in the following macro expansion positions

- items
- statements
- expression
- impl items
- trait impl items
- trait items
- foreign items
Comment on lines +518 to +527
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't find the positions in which macro expansion is allowed in the reference, actually.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The list of macro invocation sites is listed in https://doc.rust-lang.org/nightly/reference/macros.html#r-macro.invocation.intro. I don't think this needs to duplicate the list.

We haven't really gotten into documenting built-in attributes, so there isn't a well-trodden path here. I think it would be fine to say that it may specified in any position where macro invocations are allowed.


r[cfg.cfg_select.well-formed]
Each right-hand side must syntactically be valid expansion for the position that the macro is invoked in.

[Testing]: attributes/testing.md
[`--cfg`]: ../rustc/command-line-arguments.html#--cfg-configure-the-compilation-environment
[`--test`]: ../rustc/command-line-arguments.html#--test-build-a-test-harness
[`cfg`]: #the-cfg-attribute
[`cfg` macro]: #the-cfg-macro
[`cfg!`]: #the-cfg-macro
[`cfg_select!`]: #the-cfg_select-macro
[`cfg_attr`]: #the-cfg_attr-attribute
[`crate_name`]: crates-and-source-files.md#the-crate_name-attribute
[`crate_type`]: linkage.md
Expand All @@ -479,4 +543,5 @@ println!("I'm running on a {} machine!", machine_kind);
[attributes]: attributes.md
[cargo-feature]: ../cargo/reference/features.html
[crate type]: linkage.md
[macros]: macros.md
[static C runtime]: linkage.md#static-and-dynamic-c-runtimes
Loading