You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm hoping one of the more experienced rustfmt contributors might point me in a good architectural direction (or discuss the feasibly, if likely difficult) for an implementation of an option that does the following.
Suppose an unformatted rust snippet:
match(dberr.schema.as_ref(), dberr.table.as_ref()){(Some(schema),None) =>
message.push_str(&format!(" with schema `{}`", schema)),(Some(schema),Some(table)) =>
message.push_str(&format!(" with table `{}.{}`", schema, table)),// this line is too long(None,Some(table)) =>
message.push_str(&format!(" with table `{}`", table)),
_ => returnErr(()),}
Rustfmt currently formats this as the following (a pretty ok format):
// NOTE: One line was too longmatch(dberr.schema.as_ref(), dberr.table.as_ref()){(Some(schema),None) => message.push_str(&format!(" with schema `{}`", schema)),(Some(schema),Some(table)) => {
message.push_str(&format!(" with table `{}.{}`", schema, table))}(None,Some(table)) => message.push_str(&format!(" with table `{}`", table)),
_ => returnErr(()),}
The option I'd like to add would be to force that match branches use either _ => $expr, or _ => $block consistently within a single match statement. As a (more difficult to implement?) but likely better extension, only match branches not separated by a blank line would be forced to be consistent; e.g.
Formatting with proposed option:
// NOTE: All of the expressions stay vertically alignedmatch(dberr.schema.as_ref(), dberr.table.as_ref()){(Some(schema),None) => {
message.push_str(&format!(" with schema `{}`", schema))}(Some(schema),Some(table)) => {
message.push_str(&format!(" with table `{}.{}`", schema, table))}(None,Some(table)) => {
message.push_str(&format!(" with table `{}`", table))}
_ => returnErr(()),}
Prefer vs Force (Added in edit)
Mostly a note to self?
This option could prefer consistency (rather than force it) by only forcing consistency
if all blocks contain exactly one expression (~ or overflow to at most 1 line?). I'll see if its also fairly simple to add both with an enum option rather than a boolean (probably Off, Prefer, and Force).
The text was updated successfully, but these errors were encountered:
This would be fairly easy to implement, but I don't think there is much hope of having a nice implementation.
Basically, when formatting each match arm you would need some extra mutable state in the context (which might mean needing more flexibility in the Rewrite trait) so you can set a flag if any arm is formatted using a block. Then if any arm sets that flag, you start over forcing every arm to use a block. You could try looking at the output of formatting an arm and force a block if any arm includes a newline, however, whether that would work depends on the precise behaviour you want around newlines in the pattern, comments, etc.
If you implemented this and it didn't have too much overhead, then I think it would be a fine option to support.
I'm hoping one of the more experienced rustfmt contributors might point me in a good architectural direction (or discuss the feasibly, if likely difficult) for an implementation of an option that does the following.
Suppose an unformatted rust snippet:
Rustfmt currently formats this as the following (a pretty ok format):
The option I'd like to add would be to force that match branches use either
_ => $expr,
or_ => $block
consistently within a single match statement. As a (more difficult to implement?) but likely better extension, only match branches not separated by a blank line would be forced to be consistent; e.g.Formatting with proposed option:
Prefer vs Force (Added in edit)
Mostly a note to self?
This option could
prefer
consistency (rather thanforce
it) by only forcing consistencyif all blocks contain exactly one expression (~ or overflow to at most 1 line?). I'll see if its also fairly simple to add both with an enum option rather than a boolean (probably
Off
,Prefer
, andForce
).The text was updated successfully, but these errors were encountered: