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
When using a leading | in the matches! macro, this leads to some weird formatting looking like closure syntax:
enumBla{A,B,}implBla{// before processing by `rustfmt`pubfnweird_unformatted(self) -> bool{matches!(self, | Self::A | Self::B)}// output of `rustfmt` --- looks like closure syntax!pubfnweird_formatted(self) -> bool{matches!(self, |Self::A| Self::B)}// what if we use just plain `match`?pubfnmatch_unformatted(self) -> bool{matchself{
| Self::A | Self::B => true,}}// that looks better!pubfnmatch_formatted(self) -> bool{matchself{Self::A | Self::B => true,}}}
The text was updated successfully, but these errors were encountered:
Thanks for reaching out, but closing as a duplicate of #4462
Formatting of macro calls is still a bit limited and rudimentary as rustfmt is a formatter of known/valid rust syntax, and args to calls aren't always such. As such, rustfmt will attempt to format calls that use paren or bracket delims, but not calls with brace delims. For paren/bracket delimited calls, rustfmt will only format if each arg can be parsed as a valid syntactical construct, with the first attempt being to parse as an expression. Using a leading pipe does result in that second arg getting parsed as a closure, so it's formatted according to the corresponding closure rules instead.
I'm sure at some point we'll get around to special case handling of matches! calls, but in the interim, would encourage skipping the leading pipe or using brace delims (though that'll require you to format the call contents entirely by hand)
When using a leading
|
in thematches!
macro, this leads to some weird formatting looking like closure syntax:The text was updated successfully, but these errors were encountered: