Change:
} } <del> // The value here is never passed to macros as tokens by itself (not as a part // of the whole attribute), so we don't collect tokens here. If this changes, // then token will need to be collected. One catch here is that we are using // a nonterminal for keeping the expression, but this nonterminal should not // be wrapped into a group when converting to token stream. let expr = self.parse_expr()?; </del> <ins> // Collect tokens because they are used during lowering to HIR. let expr = self.collect_tokens(|this| this.parse_expr())?; </ins> let span = expr.span; match &expr.kind {

Discussion:
Also tested on and , it errored without ICEing on 1.49 and ICEd on 1.50 so modify labels: +regression-from-stable-to-beta <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning as discussed as part of the and removing .
searched nightlies: from nightly-2020-12-01 to nightly-2021-01-21 regressed nightly: nightly-2020-12-11 searched commits: from ... regressed commit: It's cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
glacier ""
I spent some time looking at this. will not ICE in stable because the assert should be compiled away. What will happen is an incorrect span in the output duplicating a prior error. think this is caused by the double duty that s and have. We sometimes treat as indices into a byte buffer, but there's an additional piece of info in s that isn't carried over with , namely whether the byte position is the beginning or the end of a . This matters because when doing operations being or not being the end is the difference between having to do or not. I believe this is the underlying cause of these issues. if you're taking on this you might want to look at modifying to accept a new stating whether the is the start or end (and depending on that whether we should the assertion and likely other logic or not). are a bunch of small tweaks to these diagnostics that can be done as a separate PR by changing with and even provide a structured suggestion instead of the .
Why would the assert be compiled away in stable but not beta and nightly? I'm pretty sure the issue here is that the PR that causes this ICE was merged for 1.50 (which is the current beta version), not 1.49 (which is the current stable).
Am I wrong to understand that in controls whether ions get evaluated, which in turn is only enabled if ?

Regardless, a small patch to remove that assertion would get around the ICE without major negative impact (the label is shifted one char to the left and nothing else), if we don't cut a more comprehensive PR before the next release.
I'm not sure if that gets rid of calls (it may only get rid of calls). However, what I'm referring to is that you said it wouldn't ICE in stable, whereas my understanding is that if it ICEs in beta, it will ICE in the next stable.
taking over, I've figured out the problem.
Re-opening because this still affects beta and the PR needs to be backported.
The fix landed in 1.51.0, and I cherry-picked a fix for the 1.50.0 stable branch. If the cherry-pick is accepted by CI then we can close this issue!
CI passed on the test runner in the 1.50.0 promotion, but it timed out on an unrelated builder, so the fix worked! Closing this.