Syntax extensions (and macros) that start a line want to be a whole statement

[paulstansifer]

{ stringify!(bees).to_owned() }

 foo.rs:5:27: 5:28 error: unexpected token: `.`
 foo.rs:5          { stringify!(bees).to_owned() }
                                     ^

However, if you wrap the macro invocation in parens...

 { (stringify!(bees)).to_owned() }

...it works.

The tricky thing about this problem is that, when the parser sees stringify!, it doesn't know whether it'll be a statement macro or an expression macro; currently, it commits to the former, which breaks if the invocation has to be an expression.

[pnkfelix]

�@paulstansifer How hard is this to fix? How important is it to fix?

One can see similar paren-wrapping work-arounds elsewhere in such cases where disambiguation is necessary (e.g. to distinguish a method call a.foo() from a field-deref+function invocation (a.foo)()).

So, would it possibly suffice in this case to improve the parser's error message?

[paulstansifer]

I think that this is different from that because, in that case, we need parentheses to distinguish between two different legitimate parses, whereas, in this case, there's a legitimate interpretation that's not accessible (and surprises the user who isn't thinking about statements at all).

On the other hand, determining whether stringify!( is going to be a statement is not possible in LL(k). The workaround is to parse a node that could be a statement or an expression, depending on what comes next.

Summary: I think it's important, but I could be persuaded that using parens is the proper Rustic solution.

[huonw]

Triage: still an issue; personally I think that parsing it as a statement always is ok if we detected when we've hit a parse error due to this choice (detecting it heuristically or otherwise), i.e. something like:

fn main() { stringify!(1).to_owned(); }

currently errors out with

5941.rs:1:25: 1:26 error: unexpected token: `.`
5941.rs:1 fn main() { stringify!(1).to_owned(); }
                                   ^

but could error with

error: unexpected token: `.` (a macro starting a line is parsed as a statement, wrap in parentheses to parse as an expression)

or something like that.

[huonw]

I think changing this would be backwards incompatible (although it's not clear that we actually want to change it), e.g.

foo!()
(x + 1).bar()

currently parses as two statements foo!() and (x+1).bar(), but if it were to be parsed as an expression, I think it would come out as ((foo!())(x+1)).bar() i.e. a function call with a method call on its result.

(Similar things happen with a prefix unary - becoming binary subtraction and [...] literals becoming an indexing expression; there may be others.)

Nominating.

[pcwalton]

How important is it that we have macros that can expand to statements? Couldn't such macros instead expand to the expression { STATEMENT }? (Maybe we could just do that expansion "under the hood"?)

[jbclements]

Actually, I think there's some of that there, already; if you look at the default implementation of make_stmt in ext/tt/base.rs, you'll see that it does exactly that. I'm not looking at the larger conversation, though. There may be good reasons that this would break things.

Ooh, okay, how about this one; a let is a statement, right? So putting it in braces would kill its scope.

[huonw]

I have found use in an RAII macro like

macro_rules! guard {
    ($thing: expr) => { let _guard = Guarder::new($thing); }
}

which means

{
    guard!(foo);
    // ... all inside the guard above, due to the scoping of the `let`
}

works as you might expect; this was mainly to avoid problems where someone might write { Guarder::new(foo); ... } and thus not be inside the RAII-section for the .... However, we now have the #[must_use] attribute which makes this usecase less relevant.

[huonw]

(It would also kill macros like this.)