Commits on Jul 24, 2021

1. Display an extra note for trailing semicolon lint with trailing macro …

   Currently, we parse macros at the end of a block
   (e.g. `fn foo() { my_macro!() }`) as expressions, rather than
   statements. This means that a macro invoked in this position
   cannot expand to items or semicolon-terminated expressions.
   
   In the future, we might want to start parsing these kinds of macros
   as statements. This would make expansion more 'token-based'
   (i.e. macro expansion behaves (almost) as if you just textually
   replaced the macro invocation with its output). However,
   this is a breaking change (see PR rust-lang#78991), so it will require
   further discussion.
   
   Since the current behavior will not be changing any time soon,
   we need to address the interaction with the
   `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lint. Since we are parsing
   the result of macro expansion as an expression, we will emit a lint
   if there's a trailing semicolon in the macro output. However, this
   results in a somewhat confusing message for users, since it visually
   looks like there should be no problem with having a semicolon
   at the end of a block
   (e.g. `fn foo() { my_macro!() }` => `fn foo() { produced_expr; }`)
   
   To help reduce confusion, this commit adds a note explaining
   that the macro is being interpreted as an expression. Additionally,
   we suggest adding a semicolon after the macro *invocation* - this
   will cause us to parse the macro call as a statement. We do *not*
   use a structured suggestion for this, since the user may actually
   want to remove the semicolon from the macro definition (allowing
   the block to evaluate to the expression produced by the macro).

   

   Aaron1011 committed Jul 24, 2021
   Configuration menu

   • View commit details
   • Copy full SHA for 0df5ac8
   • Browse repository at this point

   Copy the full SHA

   0df5ac8 View commit details

   Browse the repository at this point in the history