Handle the possibility that the class name is in its own Group#2159
Handle the possibility that the class name is in its own Group#2159alexcrichton merged 4 commits intowasm-bindgen:masterfrom
Conversation
|
I think the remaining
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 @dtolnay does the above sound at all correct / should I open an issue on |
|
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... |
|
If this parse error seems to originate from |
|
@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 It actually also still fails with the same error for me locally. |
|
Oh whoops; just noticed you pinned the nightly version. I'll open an issue on |
|
In any case this seems like a good change to land regardless, so I'm going to merge this. |
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-hackis here.