`#[cfg(debug_assertions)]` on expression causing odd formatting

[Centri3]

This code:

#[feature(stmt_expr_attributes)]

fn a() {
    let aaaaa = 1;
    let bbbb = 2;

    #[cfg(debug_assertions)]
    aaaaa * bbbb;
}

Is formatted into this:

#[feature(stmt_expr_attributes)]

fn a() {
    let aaaaa = 1;
    let bbbb = 2;

    #[cfg(debug_assertions)]
    aaaaa
        * bbbb;
}

Any line shorter than that (17 characters) is formatted correctly. Not entirely sure what's happening here.
Maybe related: #5871, but not sure.

[ytmimi]

Thank you for another report!

[GambitingMan]

I think the issue originates with how the expression is parsed.
The code

#[cfg(debug_assertions)]
aaaaa * bbbb;

is parsed such that the attribute is only applied to aaaaa, not the entire expression. It is essentially parsed as:

Expression {
  Binary {
    Expression {
      Path (aaaaa)
      attrs [
        Attribute (cfg)
      ]
    }
    Expression {
      Path (bbbb)
    }
  }
}

If you wrap the expression in parentheses, it formats as expected:

#[cfg(debug_assertions)]
(aaaaa * bbbb);

and this is parsed as

Expression {
  Paren {
    Binary {
      Expression {
        Path (aaaaa)
      }
      Expression {
        Path (bbbb)
      }
    }
  }
  attrs [
    Attribute (cfg)
  ]
}

In the first code snippet, we end up at the following code because of the multiplication:
https://github.com/rust-lang/rustfmt/blob/b6367235ebb7e009faa7c5bfa017c99de11c6381/src/expr.rs#L100C9-L100C57
rewrite_all_pairs first tries to format with rewrite_pairs_one_line, but this fails because the first pair is
#[cfg(debug_assertions)]\n aaaaa in it's entirety. Since it contains a new line, rewrite_pairs_one_line returns None.

https://github.com/rust-lang/rustfmt/blob/b6367235ebb7e009faa7c5bfa017c99de11c6381/src/pairs.rs#L65C1-L65C72

I don't know if it is the intended behavior for the parser to only apply the attribute to the first part of the expression or if it's a bug.
I don't really know how to proceed from here - any thoughts?

[ytmimi]

@GambitingMan thank you for taking the time to look into this! If this is a parsing issue, then it'll be best to handle this upstream in the compiler.

[Centri3]

I'm a bit reluctant to consider it a parsing bug (in the sense that it applies it to the wrong node), there's ambiguity here (what is #[cfg(debug_assertions)] being applied to? lhs or the entire statement?). Looking at the tracking issue for stmt_expr_attributes, it seems like this is a longstanding issue with this feature. As such I don't think this can be fixed on the rustfmt side.