rustfmt librustc_resolve

[tshepang]

No description provided.

[rust-highfive]

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

[petrochenkov]

cc @jseyfried, most of this formatting is yours.
My opinion is that this is a good source of issues for rustfmt, but not ready to land because it makes formatting consistently worse.

[tshepang]

@petrochenkov what does "most of this formatting is yours" mean?

[petrochenkov]

@tshepang
"yours" == @jseyfried's (he maintains these parts of the compiler currently)

[tshepang]

@which parts of the diff do you not like?

[petrochenkov]

Struct expression fits into one line but splitted into several lines anyway (1).

[tshepang]

I find this more readable

[petrochenkov]

Ok, that's enough for now.
My personal approach to code formatters is to start with "change nothing" configuration and enable only transformations with near-zero false-positives (whitespaces before/after punctuation, indentation), line-wrapping heuristics, in particular, are almost never enabled with this approach.
This differs a lot from rustfmt general approach, that's why I avoid looking at rustfmt librustc_xxx PRs at all cost unless they touch my code :D

[jseyfried]

@petrochenkov You summed up my thoughts on these PRs exactly :)

Also, "visual indenting" of function calls with many arguments really bothers me:

let foo = some_long_function_name("a reasonable string literal",
another_argument,
a,
b,
c,
x,
y);

This often causes really bad rightward drift, really bad diffs, wasted vertical space, and general ugliness.

I'd much prefer

let foo = some_long_function_name("a relatively short string literal", another_argument, a, b, c, x, y,);

[bors]

☔ The latest upstream changes (presumably #34365) made this pull request unmergeable. Please resolve the merge conflicts.

[tshepang]

highly-opposed and too many merge conflicts