Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow local overrides of rustfmt configuration #4843

Open
RalfJung opened this issue May 18, 2021 · 4 comments
Open

Allow local overrides of rustfmt configuration #4843

RalfJung opened this issue May 18, 2021 · 4 comments

Comments

@RalfJung
Copy link
Member

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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants