Vertical sprawl

[kornelski]

Rustfmt has formatted this:

    assert_eq!(1, srv.state.metrics.unique.lock().unwrap().unique_request_urls.get());
    assert_eq!(1, srv.state.metrics.unique.lock().unwrap().unique_request_etags.get());

as

   assert_eq!(
        1,
        srv.state
            .metrics
            .unique
            .lock()
            .unwrap()
            .unique_request_urls
            .get()
    );
    assert_eq!(
        1,
        srv.state
            .metrics
            .unique
            .lock()
            .unwrap()
            .unique_request_etags
            .get()
    );

This
  vertical
  explosion
  is
  absurd.

This
  is
  not
  readable.

This
  is
  not
  a
  sensible
  formatting
  for
  such
  code.

There is no max line length setting that avoids this. If I set it to long lines, then rustfmt will unwrap well-formatted multi-line code into long spaghetti lines. If I set it to short, I get vertical sprawl like this. It's broken both ways.

Please, change rustfmt to behave like gofmt. Instead of being a canonicalizer designed for rewrapping worst-case machine-generated code, it should be a style-corrector designed to gently cooperate on human-written code.

The essential difference is that gofmt preserves line breaks inserted by the author. If a construct has been written in a single line, it will stay as a one-liner. If a construct has been written in multiple lines, it won't be unwrapped to a long line, regardless of max line setting. Without this behavior rustfmt's token-based heuristics are doomed to make absurd formatting mistakes like this.

[ytmimi]

@kornelski I understand that you might be frustrated, but please be mindful of your tone. The approach you've taken above is not constructive, and not conducive to a respectful discussion.

Have you considered setting chain_width=100? doing so would format your input as follows:

assert_eq!(
    1,
    srv.state.metrics.unique.lock().unwrap().unique_request_urls.get()
);
assert_eq!(
    1,
    srv.state.metrics.unique.lock().unwrap().unique_request_etags.get()
);

Going to close this as a duplicate of #4306