Repository navigation
[ICE]: bad span: ): ; cfg_select! invalid arm expr "successfully" formats but produces an ICE report #7087
Description
Activity
smaller:
cfg_select! { true => { fn foo {} } }
Huh, this one is a bit interesting. I think what's happening is that:
- The
cfg_select!formatting can only format well-formedcfg_select!arm exprs. - The
fn foo {}isn't valid syntax (missing()), so we are trying to panic somewhere in trying to format item (specifically a function item). We try to recover from such panics inrewrite_macroand fallback to emit the macro unmodified (i.e. "give up"). - The binary installs the rustc ICE hook which runs before unwinding.
- So we get this ICE report, except
rustfmtactually reports 0 (success), with thecfg_select!unmodified here, since we "successfully" gave up. - I was trying to add a test for this locally and noticed that the test harness cannot catch this ICE condition:
- For idempotency the macro is re-emitted unmodified
- For the has format failures on, it checks only non-macro formating failures
- The test harness does not install the ICE hook, so it won't have the ICE report
- The
1 remaining item
- changed the title
[-][ICE]: bad span: `)`: ``[/-][+][ICE]: `cfg_select!` invalid arm expr "successfully" formats but produces an ICE report[/+]on Sep 3, 2026 - changed the title
[-][ICE]: `cfg_select!` invalid arm expr "successfully" formats but produces an ICE report[/-][+][ICE]: bad span: `)`: ``; `cfg_select!` invalid arm expr "successfully" formats but produces an ICE report[/+]on Sep 3, 2026 - changed the title
[-][ICE]: bad span: `)`: ``; `cfg_select!` invalid arm expr "successfully" formats but produces an ICE report[/-][+][ICE]: bad span: `)`: ` `; `cfg_select!` invalid arm expr "successfully" formats but produces an ICE report[/+]on Sep 3, 2026 Yeah, I looked into this one too and it seems like
fn foo {}is getting parsed as a function declaration even though it's missing(). It's a little odd because I'd expect parsingfn foo {}to fail, but it seems to parse just fine when we callparse_expr.Once we've got what we think is a valid block expr we go through our regular formatting flow and when we reach
fn foo {}things fail because rustfmt (IMO rightfully) assumes that it will always be able to find an opening(and closing). I'm pretty sure we need to do that for comment recovery.Yeah, I looked into this one too and it seems like
fn foo {}is getting parsed as a function declaration even though it's missing(). It's a little odd because I'd expect parsingfn foo {}to fail, but it seems to parse just fine when we callparse_expr.D'oh I know why. It's because parser recovery. It's indeed invalid expr, but it's common enough that rustc's parser has a specific recovery for missing the arg list parentheses. In rustc we'd stash a diagnostics for the recovery that must be emitted or we ICE. Here in rustfmt, we cancel the stashed diagnostics but don't check error count.
EDIT: fix is #7171
Code
Meta
rustfmt --version:Error output
Backtrace