Accept m!{ .. }.method() and m!{ .. }? statements.

[m-ou-se]

This PR fixes something that I keep running into when using quote!{}.into() in a proc macro to convert the proc_macro2::TokenStream to a proc_macro::TokenStream:

Before:

error: expected expression, found `.`
 --> src/lib.rs:6:6
  |
4 |     quote! {
5 |         ...
6 |     }.into()
  |      ^ expected expression

After:

(No output, compiles fine.)

---

Context:

For expressions like { 1 } and if true { 1 } else { 2 }, we accept them as full statements without a trailing ;, which means the following is not accepted:

{ 1 } - 1 // error

since that is parsed as two statements: { 1 } and -1. Syntactically correct, but the type of { 1 } should be () as there is no ;.

However, for specifically . and ? after the }, we do continue parsing it as an expression:

{ "abc" }.len(); // ok

For braced macro invocations, we do not do this:

vec![1, 2, 3].len(); // ok
vec!{1, 2, 3}.len(); // error

(It parses vec!{1, 2, 3} as a full statement, and then complains about .len() not being a valid expression.)

This PR changes this to also look for a . and ? after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases, since no statement can start with a . or ?.

[rust-highfive]

r? @nagisa

(rust-highfive has picked a reviewer for you, use r? to override)

[m-ou-se]

@rust-lang/lang I suppose this requires an FCP?

[joshtriplett]

I think, before approving something like this, we'd want to know if this restriction is important for any particular reason (e.g. interactions with parsing and follow sets). I don't think it would be, given the examples you gave, but it'd be helpful to have some guidance from someone with clear knowledge of how macros interact with the parser.

For my part, assuming it wouldn't break anything, I think this seems reasonable.

[petrochenkov]

I think this is the right thing to do and don't see any reasons for braced macros m! { ... } to be different from blocks { ... } in this position.
This shouldn't break anything since we are only making previously illegal code legal, and I don't see issues with expansion either.

cc @Aaron1011 just in case

[nikomatsakis]

+1 from me, I agree that this seems more consistent.

[nagisa]

I'm okay with this change on the implementation side of things.

On the language design side of things I feel like with this adjustment we end up neither here nor there for this syntax element appears to be treated in a fairly inconsistent manner compared to the rest of Rust's syntactic constructs. That is it now acts kind of like an expression but only in very specific contexts. I think it would be a good idea to go all the way to making it act like all the other ExpressionWithBlocks.

[scottmcm]

+1 from me as well for making it consistent. Given that things like

let x = loop { break 7_u32 }.count_ones();

work, then those same things working after macro_rules with braces seems like the right choice.

[nagisa]

r=me with a negative test added. At this point a FCP seems redundant given that we already had +1 from 3/5 T-lang members.

[m-ou-se]

@bors r= nagisa

[bors]

📌 Commit 7d8d7a0 has been approved by ``

[bors]

📌 Commit 7d8d7a0 has been approved by nagisa