Handle the possibility that the class name is in its own Group

[rrbutani]

Closes #2158.

I'm not sure if this is the best way to go about fixing this or if there are other places where this kind of thing should be added.

If it's helpful, @dtolnay's fix for proc-macro-hack is here.

[rrbutani]

I think the remaining #[wasm_bindgen] invocation that fails under the latest nightly is breaking because of syn.

syn seems to assume that entire expressions will be a part of a single Group (trailer_expr in expr.rs) which leads to the bit that parses the body of functions (Block::parse_within in stmt.rs) checking if the fragment of the expression that was returned from parse_stmt (this calls stmt_expr which calls expr_early → unary_expr → trailer_expr) needs a semicolon (using requires_terminator in expr.rs). requires_terminator isn't Group aware but it doesn't matter; either way the function would correctly report that expressions do need to be followed by a semicolon when they're the last thing in a block. And so, we get an error.

I think the right thing to do here is to update the expr parse machinery to not stop on Groups (without just throwing away the Groups). Just ditching the check for Groups in trailer_expr seems to do the trick for me, but I'm not sure if this is the best way to do things/actually fixes the issue properly (I'm not at all familiar with syn's internals).

@dtolnay does the above sound at all correct / should I open an issue on syn's repo?

[alexcrichton]

Thanks for this! Poking around a bit I think it might be best to be a bit more general with these fixes rather than being so case-specific in these few locations. I'm a bit lost though in the final error and how we could work around and/or fix it...

[alexcrichton]

If this parse error seems to originate from syn though then it seems reasonable to file an issue upstream about that.

[rrbutani]

@alexcrichton I made the suggested changes.

That last error doesn't seem to happen anymore in CI, but I have no idea why. The fix that was pushed to syn doesn't seem like it fixes our case (we don't have a :: in the function name).

It actually also still fails with the same error for me locally.

[rrbutani]

Oh whoops; just noticed you pinned the nightly version.

I'll open an issue on syn.

[alexcrichton]

In any case this seems like a good change to land regardless, so I'm going to merge this.