You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Add DelimitedListBuilder.addLeftBracket().
The existing leftBracket() method takes a couple of optional parameters
to build up a Piece in different ways. But an upcoming change also adds
yet another way that the left bracket Piece might need to be
constructed.
Instead of adding yet another optional parameter, I just made a separate
addLeftBracket() method that takes a complete Piece made any way you
want and then changed the existing callsites to use that unless they
only need a single token.
* Change the Piece structure for Object patterns.
This change is mainly to ensure that every outermost Piece for a pattern
that can be block-formatted is a ListPiece. That will be needed in a
later commit so that when a pattern appears to the left of an `=`, we
can constrain it to block split sometimes.
But this change also slightly changes the formatting of object patterns
in a way that I think looks better: if the type arguments in an object
pattern split, it forces the fields to split too.
* Turn createForLoopParts() into createFor().
The only two calls createForLoopParts() are in visitForStatement() and
visitForElement() and those two are very similar. In a future commit,
they will have more code to share, so reorganizing now to make it easier
to share it.
* Move the operator in AssignPiece to a separate child piece.
Prior to this change, the operator was directly attached to either the
LHS piece (for ` =`) or the RHS (for `in `). This pulls it out to its
own piece. The formatting is unchanged by this commit.
In a future commit, we'll use this to be able to constrain the LHS
child piece without the operator getting in the way.
* Rework AssignPiece formatting.
Formatting assignments is complex because LHS can be block split, or
expression split, or not split. Likewise with the RHS, and thus all nine
combinations. Even figuring out what the formatting should be is tricky.
The "in" clause of a for-in loop also uses the same formatting logic,
which adds more complexity because now it's nested inside a surrounding
statement-like form and parentheses.
It gets even weirder when you have metadata before the variable (which
isn't in this commit).
This change tweaks the formatting rules to, as best as I can tell, make
the edge cases look as nice as I can get. It also adds more tests for
corners that weren't covered. The main changes are:
- If the RHS of an `in` expression splits, then go ahead and split
before the `in` too. It's pretty rare for splits in `in` to occur in
the wild, but when they do, the Flutter tends to keep it tightly
packed with the rest the for loop variable. The initial style tried
to follow that. But it gets really weird if you happen to have
metadata in there. I also don't love how it looks. Usually, when a
split occurs in an operand or clause, we split at the preceding
operator or keyword too.
This commit does that. If an expression split occurs to the right of
`in`, it splits before the `in` too.
- Tweak the relative priority between block splitting on the LHS of an
assignment versus at the operator itself. The main way this is visible
is that `=>` function bodies (which also use AssignPiece) now prefer
to split after the `=>` instead of in the parameter list. I think
that looks better.
- If the LHS *can* block split but chooses not to, then don't allow the
RHS to expression split. This is the most important tweak. Before
this change, the formatter could produce:
for (var [i] in veryLongIterator +
longExpression) {
;
}
That was never intended. The `in` shouldn't get buried in the middle
of a line like that. This change fixes that by having the AssignPiece
explicitly constrain the LHS to split when it's a block and it's
going to allow the RHS to expression split.
* Format metadata on for loop variables.
This is the actual *new* syntax supported by this PR.
* Allow splitting between the type and name in a for loop variable.
This was an oversight. All other type annotated variables allow
splitting between the type and name (even though it's rare).
* Consistently call buildPiece() directly in the argument to
addLeftBracket().
The other callsites all do, so may as well do so here too.
0 commit comments