Smarter handling of "block" and "headline" formatting. (#1687)

* Start adding support for "shape" parent constraints.

Currently, a parent can only indicate whether a child can contain newlines or not when determining whether a solution is invalid. This
works fine for most pieces, but isn't sophisticated enough to allow fixing #1465 and #1466 where we want to say that the child can have newlines but only in certain styles.

This is a step towards supporting those more sophisticated constraints. It doesn't change the underlying semantics at all, but it replaces the basic boolean newlines yes/no, with a Set<Shape>.

* Make indentation semantic.

Instead of pushing a raw integer for how much indentation a piece adds, use an enum with different values for each kind of indentation.

Then, instead of a separate "canCollapse" parameter, have some logic that understands that certain pairs of semantic indentation can be merged. The hope is that this should then simplify some of the complex indentation handling in AssignPiece (and maybe elsewhere).

There's no behavioral change or deep refactoring in this commit. It just replaces the int indentation and "canCollapse" parameter with an enum.

Note that the old short style code also has a class named Indent which has static constants for various indentation levels. The tall code also used that same class. Now it uses its own Indent class which is an actual enum. That's why much of the change in this commit is just removing an import. The existing uses of Indent silently switch over to the new enum in code_writer.dart.

* Use indentation merging to handle flattened indentation in assignments.

It looks nice if we align binary operands when the first operand is on its own line, which is often the case after `=`, `:`, and `=>`:

```dart
variable =
    operand +
    another;
```

This is also true for adjacent strings and conditional expressions.

Previously, we had some somewhat hacky code that looked at the AST node surrounding an expression to determine if it should indent itself or not. This removes that in favor of using the new merging ability of Indent. We use a separate Indent type for assignment and infix operators and then merge those two together.

This simplifies a bunch of things and lends itself to more uniform formatting since every AST node that lowers to a piece using Indent.infix will get this behavior. In fact, this commit highlighted that `is` and `as` expressions currently *aren't* formatted the same way as other binary operators, which I think was just an oversight.

This commit still formats them differently, but I'll probably change that later. For now, it just leaves TODOs.

This commit does change the formatter behavior very slightly, but only in obscure edge cases.

* Add support for block shapes and use that for block formatting.

This is (hopefully) the big commit. It's largely a refactoring but also has some style changes. Most of the style changes in places where the prior formatting was unintentional or a compromise to the old architecture.

The changes in this commit are:

- Add a new "block" shape. Pieces that split into delimited lists (collection literals, blocks, argument lists) have block shape.

- Change AssignPiece, CasePiece, ChainPiece, and ForInPiece to use that for handling their block-formatted child pieces. Previous commits already let a piece constrain its children to a subset of the allowed shapes, and now we use that to let them say not just whether not a newline is allowed, but what resulting shape the child must have.

- Add some machinery to CodeWriter to control the shape of the resulting piece when a newline is written. Coming up with a nice API for that is pretty hard, but I think what I have here works OK. There is also some machinery to determine how a child piece's shape affects the resulting shape of the parent. It isn't used heavily yet but will probably be used more in future changes to tweak the style for more complex nested expressions.

This commit has two negative consequences:

- Perf is regressed roughly 15% across the board. That's not great, but it's not catastrophic. To avoid a new pathological corner case, I added a hack where nested `=>` expressions (which occur when someone really wants to write Haskell in Dart) always force the outer ones to split. Without that, curried code gets catastrophically slow. I have some ideas on how to get some performance back but I'll save that for later.

- Some "headline"-shaped output is no longer supported. It's always been a goal of the formatter to support output like:

  ```dart
  variable = target
      .method()
      .another();
  ```

  Prior to this commit, that *sort of* worked for most expressions, but really only incidentally and you could run into places where it should work but didn't. Moving to shape-based constraints makes it uniformly *not* work. In a future commit, I plan to add another "headline" shape that will get code like this working again, reliably.

On the plus side, the behavior of the formatter is overall more consistent with this change.

* Fix double indentation of const pattern.

* Get "headline"-style formatting working.

We now allow some non-block shaped pieces on the right side of an assignment without splitting if it those pieces are "headline"-shaped. That means they have a single first line that makes sense on the `=` line followed by other subordinate code. There are three kinds of expressions that support that:

```dart
// Conditionals:
variable = condition
    ? thenBranch
    : elseBranch;

// Split method chains:
variable = target
    .method()
    .another();

// (Also with unsplit properties):
variable = target.some.props
    .method()
    .another();

// Multi-line strings:
variable = '''
    A very long string
    that is multiple lines.''';
```

Author: munificent

CHANGELOG.md

@@ -2,6 +2,38 @@
 
 * Format null-aware elements.
 
+* Allow the target or property chain part of a split method chain on the RHS of
+  `=`, `:`, and `=>` (#1466).
+
+  ```dart
+  // Before:
+  variable =
+      target.property
+          .method()
+          .another();
+
+  // After:
+  variable = target.property
+      .method()
+      .another();
+  ```
+
+* Allow the condition part of a split conditional expression on the RHS of `=`,
+  `:`, and `=>` (#1465).
+
+  ```dart
+  // Before:
+  variable =
+      condition
+      ? longThenBranch
+      : longElseBranch;
+
+  // After:
+  variable = condition
+      ? longThenBranch
+      : longElseBranch;
+  ```
+
 * Don't indent conditional branches redundantly after `=`, `:`, and `=>`.
 
   ```dart

benchmark/case/interpolation.expect

@@ -1,5 +1,6 @@
 main() {
-  var a = '''
+  var a =
+      '''
       {
         selected:
           hovered: $hoverColor, otherwise: ${colorScheme?.primary.withOpacity(0.04)},

benchmark/case/interpolation_1516.expect

@@ -1,4 +1,5 @@
-var _ = '''
+var _ =
+    '''
 ${x(1).x(1).xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx}
 ${x(1).x(1).xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx}
 ${x(1).x(1).xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx}

benchmark/case/large.expect

@@ -754,14 +754,13 @@ class Traverser {
           }
 
           // Replace any overridden dependencies.
-          deps =
-              deps.map((dep) {
-                var override = _solver._overrides[dep.name];
-                if (override != null) return override;
+          deps = deps.map((dep) {
+            var override = _solver._overrides[dep.name];
+            if (override != null) return override;
 
-                // Not overridden.
-                return dep;
-              }).toSet();
+            // Not overridden.
+            return dep;
+          }).toSet();
 
           // Make sure the package doesn't have any bad dependencies.
           for (var dep in deps) {
@@ -974,8 +973,7 @@ class Traverser {
         // Use the same source and description as the dependency override if one
         // exists. This is mainly used by the pkgbuild tests, which use dependency
         // overrides for all repo packages.
-        var pubDep =
-            override == null
+        var pubDep = override == null
             ? new PackageDep(depName, "hosted", constraint, depName)
             : override.withConstraint(constraint);
         return _registerDependency(

lib/src/ast_extensions.dart

@@ -162,6 +162,26 @@ extension AstIterableExtensions on Iterable<AstNode> {
 }
 
 extension ExpressionExtensions on Expression {
+  /// Whether this expression is a list, set, or map literal whose elements
+  /// all have a homogeneous type.
+  ///
+  /// In that case, the elements are relatively loosely related to each other.
+  /// The collection has an unbounded number of them and the contents tend to
+  /// change frequently.
+  ///
+  /// This isn't true for record literal fields and function call arguments. In
+  /// those cases, each argument position is meaningful and it's easiest to
+  /// read them all together.
+  ///
+  /// Thus it makes sense for the formatter to be looser about splitting list,
+  /// map, and set literals, while trying to avoid splitting argument lists and
+  /// records.
+  bool get isHomogeneousCollectionBody =>
+      this is ListLiteral || this is SetOrMapLiteral;
+
+  // TODO(rnystrom): We're moving towards using child piece shape to determine
+  // how a parent is formatted and how it indents its children. Once all pieces
+  // are moved over to that, delete this.
   /// Whether this expression is a non-empty delimited container for inner
   /// expressions that allows "block-like" formatting in some contexts. For
   /// example, in an assignment, a split in the assigned value is usually
@@ -187,6 +207,9 @@ extension ExpressionExtensions on Expression {
   /// splitting inside them, so are not considered block-like.
   bool get canBlockSplit => blockFormatType != BlockFormat.none;
 
+  // TODO(rnystrom): We're moving towards using child piece shape to determine
+  // how a parent is formatted and how it indents its children. Once all pieces
+  // are moved over to that, delete this.
   /// When this expression is in an argument list, what kind of block formatting
   /// category it belongs to.
   BlockFormat get blockFormatType {
@@ -375,28 +398,27 @@ extension AdjacentStringsExtensions on AdjacentStrings {
   /// Whether subsequent strings should be indented relative to the first
   /// string.
   ///
-  /// We generally want to indent adjacent strings because it can be confusing
-  /// otherwise when they appear in a list of expressions, like:
+  /// We generally prefer to align the strings because it makes them easier to
+  /// read as a single paragraph of text (which they often are):
   ///
-  ///     [
-  ///       "one",
-  ///       "two"
-  ///       "three",
-  ///       "four"
-  ///     ]
+  ///     function(
+  ///       'This is a long string message '
+  ///       'split across multiple lines.',
+  ///     )
   ///
-  /// Especially when these strings are longer, it can be hard to tell that
-  /// "three" is a continuation of the previous element.
+  /// But this is hard to read if there are other string arguments:
   ///
-  /// However, the indentation is distracting in places that don't suffer from
-  /// this ambiguity:
+  ///     function(
+  ///       'This is a long string message '
+  ///       'split across multiple lines.',
+  ///       'This is a separate argument.',
+  ///     )
   ///
-  ///     var description =
-  ///         "A very long description..."
-  ///             "this extra indentation is unnecessary.");
+  /// Here, unless you carefully notice the commas, it's hard to tell how many
+  /// arguments there are.
   ///
-  /// To balance these, we omit the indentation when an adjacent string
-  /// expression is in a context where it's unlikely to be confusing.
+  /// To balance these, we omit the indentation in argument lists only if there
+  /// are no other string arguments.
   bool get indentStrings {
     bool hasOtherStringArgument(List<Expression> arguments) => arguments.any(
       (argument) => argument != this && argument is StringLiteral,
@@ -411,27 +433,15 @@ extension AdjacentStringsExtensions on AdjacentStrings {
         if (message != null) message,
       ]),
 
-      // Don't add extra indentation in a variable initializer or assignment:
-      //
-      //     var variable =
-      //         "no extra"
-      //         "indent";
-      VariableDeclaration() => false,
-      AssignmentExpression(:var rightHandSide) when rightHandSide == this =>
-        false,
-
-      // Don't indent when following `:`.
-      MapLiteralEntry(:var value) when value == this => false,
-      NamedExpression() => false,
-
-      // Don't indent when the body of a `=>` function.
-      ExpressionFunctionBody() => false,
       _ => true,
     };
   }
 }
 
 extension PatternExtensions on DartPattern {
+  // TODO(rnystrom): We're moving towards using child piece shape to determine
+  // how a parent is formatted and how it indents its children. Once all pieces
+  // are moved over to that, delete this.
   /// Whether this expression is a non-empty delimited container for inner
   /// expressions that allows "block-like" formatting in some contexts.
   ///