Allow local overrides of rustfmt configuration

[RalfJung]

rustfmt configuration makes it wonderfully flexible, however, the configuration must be the same for the whole project. The are some settings that I would like to control on a per-file or even per-function basis. For example, match_arm_blocks -- most of the time I like it set to false, but some matches IMO look a lot better when it is set to true. (In fact they'd look even better if I could set match_arm_blocks to something like Force, where all arms in a match get braces.)

This is probably very non-trivial to implement, but I was imagining something like having an attribute to control rustfmt behavior locally:

#[rustfmt::configure(match_arm_blocks = true)]
fn foo() {
 ...
}

[calebcartwright]

This has been requested in one form or another a few times over the years, though primarily only implicitly or indirectly (which is why I'll leave it open). I understand why folks want this, and if I could fast forward to a day where support was fully implemented and bug free I'd be rather happy to have that on our feature list.

Unfortunately, however, I can't imagine this coming any time soon. For better or worse (depending on one's personal style preferences relative to the Style Guide) the rustfmt source and code flow is heavily geared towards supporting that philosophy of consistency across a codebase (and ideally the majority of Rust codebases), so it's not really amenable to formatting identical constructs differently within a codebase. Accordingly I have concerns about the feasibility of trying to do something like this, absent some major refactoring.

As an example, AFAIK when processing the formatting rules against a given AST node, rustfmt has no contextual knowledge of attributes applied to nodes higher in the hierarchy. Even if we were to make changes to support that tracking, we'd still have to deal with conflicting rules and potential idempotency issues when formatting single files vs. an entire project (e.g. format-on-save in an editor and then a subsequent cargo fmt).

It's not an unsolvable a problem, but it'd likely be a rather large undertaking and we've too many bugs and gaps around core functionality and primary formatting goals, and too few resources, for this feature request get any investment/attention for quite a long time.

[RalfJung]

Thanks for the explanation; I feared something like that might be the case. rustfmt::skip shows some amount of "context awareness" in some of the formatting logic, but I imagine that is done in a way that does not easily generalize.

[calebcartwright]

That's correct. Skip attributes are a different story and are mercifully simple by comparison. When processing a given node we don't really have to worry about skip attributes on ancestor nodes because if some higher level item/expr/etc. had a skip then we wouldn't have gotten to the current node in the first place.

[Lokathor]

If this was exclusively implemented at a per-file level (eg: for this file use "max_width = 500"), would that simplify the request?