cfg_select! macro
#2103
cfg_select! macro
#2103
Conversation
rustbot
added
S-waiting-on-review
folkertdev
force-pushed
the
cfg-select
branch
from
30ce14a to
a93da68
Compare
folkertdev
force-pushed
the
cfg-select
branch
from
a93da68 to
11dedff
Compare
folkertdev
force-pushed
the
cfg-select
branch
from
11dedff to
6cbeb12
Compare
| r[cfg.cfg_select] | ||
| ### The `cfg_select` macro | ||
|
|
||
| The built-in `cfg_select` macro expands to the right-hand side of the first configuration predicate that evaluates to `true`. | ||
|
|
||
| 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", | ||
| }; | ||
| ``` | ||
|
|
||
| A `_` can be used to write a configuration predicate that always evaluates to `true`. |
There was a problem hiding this comment.
Thanks for the Reference PR. It'd be worth filling in the details you provided in rust-lang/rust#149783 (comment), e.g. with the grammar, the removal of one level of braces, the compile error on fallthrough, etc.
There was a problem hiding this comment.
This can discuss as well how the bodies of each branch must be able to parse.
folkertdev
left a comment
folkertdev
left a comment
There was a problem hiding this comment.
I think all the raw information is here now, but it probably needs some editing/clarification.
Also should the lint on branches that come after a wildcard be mentioned?
| 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`. |
There was a problem hiding this comment.
is it clear enough from the grammer and the language here that the { /* ... */ } are dropped?
| 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 |
There was a problem hiding this comment.
I can't find the positions in which macro expansion is allowed in the reference, actually.
There was a problem hiding this comment.
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.
ehuss
left a comment
ehuss
left a comment
There was a problem hiding this comment.
Also should the lint on branches that come after a wildcard be mentioned?
As for lints, we normally don't document those. However, in this situation, it seems like it would be fine to have a > [!NOTE] block that mentions the lint (in whichever way rust-lang/rust#149960 ends up being).
| ```grammar,configuration | ||
| CfgSelect -> | ||
| cfg_select! `{` CfgSelectBranch* `}` | ||
| CfgSelectConfigurationPredicate -> | ||
| ConfigurationPredicate | `_` | ||
| CfgSelectBranch -> | ||
| CfgSelectConfigurationPredicate `=>` `{` TokenTree `}` | ||
| | CfgSelectConfigurationPredicate `=>` TokenTree `,` | ||
| ``` |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?)
|
What does this line do when checking for a closebrace? I would expect that:
That is, I would expect that |
4 participants
Stabilization report: rust-lang/rust#149783