"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.

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