Formatting for cfg_select

[joshtriplett]

https://doc.rust-lang.org/nightly/std/macro.cfg_select.html

libs-api is discussing stabilization of this. We should talk about formatting of it.

Right now, rustfmt completely ignores it, including all the code inside it, and doesn't format any of it.

[traviscross]

We talked about this in the @rust-lang/style call today. We agreed as follows:

• The arms must be wrapped in braces, so rustfmt will have to ensure to not remove those.
• The LHS of each arm should be formatted according to the rules that we use to format the inside of a #[cfg(..)] today, in terms of where to break if the line gets too long.
  • Since we want to change the rule (over a style edition, or maybe as a bug fix) for match to always break => { together as one unit, we maybe could do that here now, following the rule that we prioritize inter-edition consistency over intra-edition consistency.
    • If we can achieve this by fixing match ahead of doing cfg_match!, that would be best.
    • If it would delay things too much or be too hard in the implementation to do this for cfg_match!, then it'd be OK to do the same (undesirable) thing that we do with match.
• The RHS, following the => is a Rust BlockExpression and should be formatted in the usual way for that.
• If it seems that it might be too difficult for rustfmt to implement this soon, which is a possibility, we'll need to consider whether to ship cfg_match! ahead of rustfmt support.

@rfcbot fcp merge

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @calebcartwright
• @joshtriplett
• @traviscross

Concerns:

• wrapping (Formatting for cfg_select #201 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

psst @traviscross, I wasn't able to add the final-comment-period label, please do so.

[calebcartwright]

The LHS of each arm should be formatted according to the rules that we use to format the inside of a #[cfg(..)] today, in terms of where to break if the line gets too long.

AFAIK we do not have any explicit prescriptions in the style guide for formatting cfg and it's the high level attribute formatting rules that rustfmt applies

With one of the operative instructions being:

For attributes with an equal sign, put a single space before and after the =, e.g., #[foo = 42].

The Style Guide does not specify if/how to handle breaking if that needs to be multilined, and as a result rustfmt does not currently break these, even if they extend past the max width limit

#[cfg(
    feature = "debug-with-rustfmt-long-long-long-long-loooooooonnnnnnnnnnnnnnnggggggffffffffffffffff"
)]
fn main() {
    println!("Hello, world!");
}

One formatting prescriptions for match expressions with long patterns and/or guards requiring breaking of the LHS is:

match x {
    a_very_long_pattern | another_pattern
        if expr =>
    {
        ...
    }
}

So if we proceed with existing cfg behavior and don't wrap, what's the current proposal?

cfg_match! {
    feature = "debug-with-rustfmt-long-long-long-long-loooooooonnnnnnnnnnnnnnnggggggffffffffffffffff" => {
        // abc
    }
    _ => {
        // abc
    }
}

Or if we're going to break the => and keep them together is the proposal to instead do:

cfg_match! {
    feature = "debug-with-rustfmt-long-long-long-long-loooooooonnnnnnnnnnnnnnnggggggffffffffffffffff"
    => {
        // abc
    }
    _ => {
        // abc
    }
}

Or should the => be intended off the "pattern"?

cfg_match! {
    feature = "debug-with-rustfmt-long-long-long-long-loooooooonnnnnnnnnnnnnnnggggggffffffffffffffff"
        => {
        // abc
    }
    _ => {
        // abc
    }
}

Or do we need to introduce nwe wrapping rules around the =, after which there's various options for what to do with the =>?

[calebcartwright]

@rfcbot concern wrapping