-
Notifications
You must be signed in to change notification settings - Fork 540
Description
According to this page, “The semicolon following a statement is not a part of the statement itself.” While this view may be true and relevant for using the stmt
parser in procedural macros, the grammar, in particular a nonterminal literally named Statement
, tells a different story. I believe this is confusing.
Apart from the above, there is a problem / inaccuracy in the nonterminal ExpressionStatement
. The respective page accurately conveys that an ExpressionWithoutBlock
must be followed by ;
and an ExpressionWithBlock
usually isn’t. However, an ExpressionWithBlock
most definitely can have a ;
following it. This might syntactically be well covered by the fact that ;
in by itself is a valid Statement
, and I wouldn’t complain if this kind of ;
was always redundant and like a no-op statement following the ExpressionWithoutBlock
-statement, but this isn’t the case by means of what is stated below the grammar of ExpressionStatement
, “The type of ExpressionWithBlock
expressions when used as statements must be the unit type.”
It goes on further around there and speaks of a “trailing semicolon” one “can omit” and clarifies that more precisely, only “When the trailing semicolon is omitted, the result must be type ()
.” All this means is: A semicolon does change things: it allows the return type to be non-(). If the semicolon is relevant for type-checking an ExpressionStatement
containing ExpressionWithBlock
, in my view this should imply that said semicolon must be part of the statement.
I‘m not 100% sure what the best solution to improve this is. I’d suggest that the rule becomes:
ExpressionStatement: ExpressionWithoutBlock ; | ExpressionWithBlock ;?
i.e.: allow an optional semicolon behind ExpressionWithBlock, being part of the ExpressionStatement. Maximum munch would mean that if any ;
exists it will then be considered part of the statement. But there’s also the issue #762 that seems related. Perhaps there is a different approach that solves both problems together.
Activity
match
. #774petrochenkov commentedon Mar 4, 2020
A related rust-lang/rust issue - rust-lang/rust#61733.
(The
stmt
matcher is also actively wrong in the token-based model that I'd like to have implemented.)ehuss commentedon Mar 4, 2020
I think it makes sense to add
;<sup>?</sup>
toExpressionWithBlock
since that seems to better match the semantics.I would also completely remove the note about
stmt
macro inblock-expr.md
. It is out of place and confusing. The rules of;
andstmt
are already explained inmacros-by-example.md
.Would that be sufficient to clarify things for you?
Fix expression and statement grammar.