Change:
token.can_begin_expr() // This exception is here for backwards compatibility. && !token.is_keyword(kw::Let) <ins> // This exception is here for backwards compatibility. && !token.is_keyword(kw::Const) </ins> } NonterminalKind::Ty => token.can_begin_type(), NonterminalKind::Ident => get_macro_ident(token).is_some(),

Discussion:
Unclear on the extent to which these are the same problem: https://crater- https://crater- cc
The error looks like an old bug that was fixed by
only lists 0.1.0 so we should probably nag about a point release one more time :)
Whoops, looks like I half-fixed it. One of my dependencies is too strict. It does look like the same error so probably not a regression...
cc
and I both feel unclear about this: Is this a Rust regression or a regression in a library that was then picked up by Crater?
This is a regression in the Rust compiler.
The error seems to me like fallout from implementing . I'm guessing the issue is that it's expecting a block but immediately gets a literal. Not sure how this is supposed to behave though. Reposting the error here:
But I'm not quite sure; the span seems potentially wrong.
ping cleanup would be nice to get an MCVE
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Somewhat minimized (): On stable, it produces a bunch of semantic errors (which make sense since I removed a lot of type definitions), but on beta it produces:
Assigning as and removing .
Much more minimized: () Errors:
Here's the code again: I think the issue is that on beta the compiler thinks the in the macro invocation is starting an expression because of the new feature – thus it thinks it's using the first rule in the macro. But then when doing macro expansion, it realizes that it's actually not a valid expression because it's missing braces. On stable this is not an issue because the compiler never thinks that is starting an expression. I think the fix might be to not treat as the start of an expression if it is not immediately followed by braces. See the original PR: .

cc who has been implementing
My bisection is in line with my diagnosis: searched nightlies: from nightly-2020-10-15 to nightly-2020-10-19 regressed nightly: nightly-2020-10-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
I'm going to try working on this. If I get stuck I'll release my assignment since this is P-high!
So I'm trying to figure out which code is the culprit here. The PR is the one that introduced the regression, but looking at its changes I don't know if it's actual the underlying cause. I think the issue might be in the macro expansion code, but I'm not familiar with it at all. Since this issue is P-critical and potentially a release blocker, I'm going to release my assignment so that someone more experienced can take it over. Though I'm happy to help if there's some way to do that!
Actually, I just noticed that petrochenkov responded to my message asking for help finding the code
This should be fixed on the next nightly.
Reopening to track beta fix.
Should be backported to beta as part of
I think this can be closed as has been merged?