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

matches!(x, | A | B | ...) produces strange output #5176

Closed
01mf02 opened this issue Jan 19, 2022 · 2 comments
Closed

matches!(x, | A | B | ...) produces strange output #5176

01mf02 opened this issue Jan 19, 2022 · 2 comments

Comments

@01mf02
Copy link

01mf02 commented Jan 19, 2022

When using a leading | in the matches! macro, this leads to some weird formatting looking like closure syntax:

enum Bla {
    A,
    B,
}

impl Bla {
    // before processing by `rustfmt`
    pub fn weird_unformatted(self) -> bool {
        matches!(self, | Self::A | Self::B)
    }

    // output of `rustfmt` --- looks like closure syntax!
    pub fn weird_formatted(self) -> bool {
        matches!(self, |Self::A| Self::B)
    }

    // what if we use just plain `match`?
    pub fn match_unformatted(self) -> bool {
        match self {
            | Self::A | Self::B => true,
        }
    }

    // that looks better!
    pub fn match_formatted(self) -> bool {
        match self {
            Self::A | Self::B => true,
        }
    }
}
@calebcartwright
Copy link
Member

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)

@01mf02
Copy link
Author

01mf02 commented Jan 26, 2022

Ok, thanks for your detailed explanation!

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

2 participants