Change:
Reproducible at . <details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems to be introduced in :
Thanks for the report! A compiler panic is probably best reported in rust-lang/rust, even though it's being surfaced by a dev tool. I'll check with infra to see if it makes sense to move the issue We actually haven't made any changes to rustfmt in that window and the were highly minimal and certainly don't strike me as anything that would be the root cause. As such I suspect this is due to changes made elsewhere within the compiler mods, and would at least like for those folks to be aware (even if we need to make changes on the rustfmt side to address/work around) Would you be up for trying to boil it down to a more simple repro case?
Sure! Here is a MRE:
I have bisected to . cc I noticed that rustfmt is exiting with 0 even though it panicked. Is that normal?
I'll look into it today or tomorrow! claim
Outside a macro, no, (as was the case in the original full repro), but yes within the context of a macro as in the minimal rerpo. We have our calls to rustcparse internals wrapped in so the panic isn't really surfacing here, but rustfmt is still displaying the underlying error text prior to emitting formatting. This is done partly due to the fact that there are scenarios where those internals panic that we want to wrap to an error type, and partly due to there being some scenarios we want to ignore for the purposes of formatting due to how we attempt to deal with macros in the pre-expansion world where rustfmt lives. The latter being a result of limited macro support and leaving macros it can't handle alone, while carrying on formatting the rest of the file/crate/workspace
It looks like I'm still getting this error with (Coming from that was closed due to this one) Playground seems to produce it also:
I'll take another look then.
Yeah, this continues to ICE even in rustc. Fixed in another PR.

Discussion:
match x { Ok((_, _, false)) => { if self.eat(&token::Gt) { <del> let turbo_err = e.span_suggestion_verbose( </del> <ins> e.span_suggestion_verbose( </ins> binop.span.shrink_to_lo(), TURBOFISH_SUGGESTION_STR, "::".to_string(), Applicability::MaybeIncorrect, <del> ); if self.check(&TokenKind::Semi) { turbo_err.emit(); *expr = self.mk_expr_err(expr.span); return Ok(()); } else { match self.parse_expr() { Ok(_) => { turbo_err.emit(); *expr = self .mk_expr_err(expr.span.to(self.prev_token.span)); return Ok(()); } Err(mut err) => { turbo_err.cancel(); err.cancel(); } </del> <ins> ) .emit(); match self.parse_expr() { Ok(_) => { *expr = self.mk_expr_err(expr.span.to(self.prev_token.span)); return Ok(()); } Err(mut err) => { *expr = self.mk_expr_err(expr.span); err.cancel(); </ins> } } }

self.parse_block_expr(label, lo, BlockCheckMode::Default, attrs) } else if !ate_colon && (self.check(&TokenKind::Comma) || self.check(&TokenKind::Gt)) { // We're probably inside of a `Path<'a>` that needs a turbofish, so suppress the <del> // "must be followed by a colon" error. </del> <ins> // "must be followed by a colon" error, and the "expected one of" error. </ins> self.diagnostic().delay_span_bug(lo, "this label wasn't parsed correctly"); consume_colon = false; Ok(self.mk_expr_err(lo))

<ins> fn main() { f<'a,> //~^ ERROR expected } </ins>

<ins> error: expected one of `.`, `:`, `;`, `?`, `for`, `loop`, `while`, `{`, `}`, or an operator, found `,` --> $DIR/issue-93282.rs:2:9 | LL |     f<'a,> |         ^ expected one of 10 possible tokens | help: use `::<...>` instead of `<...>` to specify lifetime, type, or const arguments | LL |     f::<'a,> |      ++ error: aborting due to previous error </ins>