Bump rustfmt version

[Mark-Simulacrum]

No description provided.

[rust-highfive]

r? @ecstatic-morse

(rust-highfive has picked a reviewer for you, use r? to override)

[petrochenkov]

@calebcartwright
This looks like a regression, | patterns outside of matches! are not formatted with an indent like this.

[calebcartwright]

This one requires a much more thorough response. The short answer is that no it's not a regression, though you're not the first person to raise the question and I can certainly understand why.

For the longer answer, there's two core parts.

First, there was an issue in rustfmt where in cases with multi pats and at least one _ rustfmt was entirely unable to process the arg and thus wasn't applying any formatting at all against the mac call expr and just leaving the original formatting in place; rustfmt was just keeping whatever was here before as-is, not successfully applying the formatting rules.

An easy way to see this in practice is by running the older versions (I guess x.py fmt from master will work) with a wildly misformatted version of this, and you'll see that wild formatting remains untouched:

        matches!(self.annotation_type,AnnotationType::Multiline(_)
| AnnotationType::MultilineStart(_)                      | AnnotationType::MultilineLine(_)
              | AnnotationType::MultilineEnd(_)
        )

On the rustfmt side we've been particularly benefiting from the recent parser/tokens/etc. work that folks like yourself and Aaron have been working on, and now that we've pulled those rustc changes into rustfmt it's finally able to actually format these matches! calls producing the formatting seen here.

The second part relates to how we have to attempt to format macro call args in rustfmt. Obviously we're working with the calls in the AST pre-expansion, so when we encounter a maccall expression, we'll use the token streams to instantiate a parser and attempt to parse the args individually so that we can then apply the corresponding formatting rules when possible (e.g. an expr or type).

In the case of matches!, the tokens for that second arg actually ends up getting successfully parsed as a standard binop expression, and so rustfmt applies the corresponding formatting rules for binops which is why it gets indented this way.

Eventually I'd like to introduce some new special case process for matches! mac calls since we'll know definitively that second arg isn't actually a binop expr, and then be able to apply more pattern-like formatting rules instead.

Unfortunately though, for the foreseeable future rustfmt is going to continue to be formatting matches like any other mac call even though the emitted formatting is less than desireable

[petrochenkov]

@calebcartwright
Is this change intended? Looks like a regression.

AFAIK, the situation like

    HEADER BRACKET_OPEN
BRACKET_CLOSE

(with BRACKET_CLOSE being less indented than HEADER) is not supposed to happen in general.

[calebcartwright]

Thanks for the ping! This is definitely a bug that was introduced in v1.4.28, I'm guessing rust-lang/rustfmt#4474 but will dig into it

[calebcartwright]

this has been fixed in source, should available within the next couple days

[Mark-Simulacrum]

r? @petrochenkov

I've rebased with the latest rustfmt.

[petrochenkov]

@bors r+

[bors]

📌 Commit 063b427 has been approved by petrochenkov

[bors]

⌛ Testing commit 063b427 with merge 1f598ec78c7bee462b86200c62366c5ede08051c...

[bors]

💔 Test failed - checks-actions

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[petrochenkov]

Needs a rebase due to formatting changes in rustc_mir_build.

[Mark-Simulacrum]

@bors r=petrochenkov p=1 (likely prone to bitrot)

[bors]

📌 Commit d5b760b has been approved by petrochenkov

[bors]

⌛ Testing commit d5b760b with merge b81f581...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing b81f581 to master...