"possibly missing a comma here" conflicts with rustfmt

[nirvdrum]

I'm currently encountering a lint error for "possibly missing a comma" from code that rustfmt produced. This is similar to the issue described in #3244, but since that issue got into discussion about specifics about how the code sample in the issue was formatted, I thought I'd open a new issue with a very different code sample.

The code in question is a precedence climber for the pest parsing library:

fn create_precedence_climber() -> PrecClimber<Rule> {
    PrecClimber::new(vec![
        Operator::new(Rule::or, Assoc::Left),
        Operator::new(Rule::and, Assoc::Left),
        Operator::new(Rule::equal, Assoc::Right)
            | Operator::new(Rule::not_equal, Assoc::Right)
            | Operator::new(Rule::less_than_equal, Assoc::Right)
            | Operator::new(Rule::less_than, Assoc::Right)
            | Operator::new(Rule::greater_than_equal, Assoc::Right)
            | Operator::new(Rule::greater_than, Assoc::Right),
        Operator::new(Rule::add, Assoc::Left) | Operator::new(Rule::subtract, Assoc::Left),
        Operator::new(Rule::multiply, Assoc::Left) | Operator::new(Rule::divide, Assoc::Left),
    ])
}

The error is:

error: possibly missing a comma here                                                                                                                                                                                                                                                      
  --> src/parser.rs:51:68                                                                                                                                                                                                                                                                 
   |                                                                                                                                                                                                                                                                                      
51 |             | Operator::new(Rule::greater_than_equal, Assoc::Right)                                                                                                                                                                                                                  
   |                                                                    ^      

I can make the error go away by moving the pipe to the of the line, like so:

fn create_precedence_climber() -> PrecClimber<Rule> {
    PrecClimber::new(vec![
        Operator::new(Rule::or, Assoc::Left),
        Operator::new(Rule::and, Assoc::Left),
        Operator::new(Rule::equal, Assoc::Right) |
            Operator::new(Rule::not_equal, Assoc::Right) |
            Operator::new(Rule::less_than_equal, Assoc::Right) |
            Operator::new(Rule::less_than, Assoc::Right) |
            Operator::new(Rule::greater_than_equal, Assoc::Right) |
            Operator::new(Rule::greater_than, Assoc::Right),
        Operator::new(Rule::add, Assoc::Left) | Operator::new(Rule::subtract, Assoc::Left),
        Operator::new(Rule::multiply, Assoc::Left) | Operator::new(Rule::divide, Assoc::Left),
    ])
}

I personally think the code produced by rustfmt looks nice, but I can see the appeal of using a trailing operator to indicate a multiline expression. In either case, clippy and rustfmt need to come to an agreement over which is correct.

[ghost]

Maybe we shouldn't lint if the second line has extra indentation.
So trigger on

vec![
1
- 2,
]

but not on

vec![
1
    - 2,
]

The spacing between the operator and the second operand might also be clue. Unary operators usually don't have spaces before the operand.

[basil-cow]

Fixed by this pr, can be closed @flip1995