rustfmt: Rustfmt unable to format complex match statement with lots of fully qualified matches

Rustfmt is unable to format the following code:

fn foo() {
    match key {
        < :: icu_calendar :: provider :: JapaneseErasV1Marker as ResourceMarker > :: KEY => {
        AnyPayload :: from_static_ref :: << :: icu_calendar :: provider :: JapaneseErasV1Marker as DataMarker > :: Yokeable > (litemap_slice_get (calendar :: japanese_v1 :: DATA , key , req) ?)
        }
    }
}

We’re hitting that in https://github.com/unicode-org/icu4x/pull/2098, where we’ve generated a very large match statement containing a lot of those such arms (but we hit those bugs even for the one-arm match statement above). It woudl be nice if we could have our generated code be readable.

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 15 (14 by maintainers)

Most upvoted comments

Yeah, feels like if rustfmt cannot satisfy max_width it should still attempt to break it up as much as possible

I understand this desire but given some of the earliest structural decisions around rustfmt, it’s a bit like saying rustc should be able to compile successfully even when there are syntax errors or various files/mods/deps/etc. missing.

Every time you run rustfmt it is explicitly asked to ensure that no code lines run past max_width (whether you use the default max_width value or override it), and in cases like this it’s unequivocally impossible for rustfmt to meet that constraint and so defers to the “programmer” to refactor. I assume the motivation for this was largely because a width limit that’s ignored when exceeded would have been self-defeating, but that long predates my time with the project.

I appreciate that there are cases when users would prefer to treat the width limits as more of a soft limit or to “proceed anyway”, but that starts to get fuzzy quickly and is highly underspecified, as illustrated with cases like #3863.

I’m going to close because this is another case of exceptionally long, generated code and there’s no action to be taken, and because broader discussions about width behavior are probably best continued in existing issues.

calebcartwright on Jul 1, 2022