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.