| commit | 0a785297b6c89e39848cf9e576acda6d761a16ad | [log] [tgz] |
|---|---|---|
| author | Bob Nystrom <rnystrom@google.com> | Mon May 20 15:22:19 2024 -0700 |
| committer | GitHub <noreply@github.com> | Mon May 20 15:22:19 2024 -0700 |
| tree | 6f019afedead453f7d04c868ab2d93d8f002ce84 | |
| parent | d2b88fc1bbf06e27eb379d47b7d1f90062e307d7 [diff] |
Use all unsolved pieces on the offending line as expand pieces. (#1494) The solver works by incrementally building a up a solution by binding pieces to states one at a time. To avoid wasting time exploring solutions that are pointless, it only looks at unbound pieces in play when the first line containing overflow characters or an invalid newline as written. Before this PR, it only looked at the *first* unbound piece on that line. Often, the first piece on the line is not the one that actually needs to split. For example, in: ```dart // | variable = function(argument); ``` Here, the first piece on the overflowing line is the AssignPiece for the `=`, but the piece we actually want to split at is the ListPiece for the argument list. To handle that, the solver currently tries binding the first piece to all values, including State.unsplit, even though that's effectively the value the current solution used, since unbound pieces behave like they have State.unsplit. The only reason it makes a new solution and binds the piece to State.unsplit is that if that piece turns out to *not* be the one that needs to split, we can now find the *next* piece on that same line. Now that the first piece is *bound* to State.unsplit, the second piece will be the first *unbound* one. But the end result is that we end up generating a lot of more or less redundant solutions that just bind a bunch of pieces to State.unsplit and then produce the exact same formatted result. Instead, this PR collects *all* of the unbound pieces on the first overflowing line. When it expands, it expands them all, but *doesn't* bind any of them to State.unsplit. The old formatter works the same way, but it wasn't clear to me that doing so was important for perf. It is! ``` Benchmark (tall) fastest median slowest average baseline ----------------------------- -------- ------- ------- ------- -------- block 0.065 0.067 0.131 0.070 96.3% chain 1.515 1.540 1.629 1.547 172.2% collection 0.169 0.173 0.189 0.175 98.6% collection_large 0.896 0.926 0.959 0.925 96.5% conditional 0.088 0.089 0.104 0.091 179.9% curry 1.651 1.667 1.689 1.668 147.9% flutter_popup_menu_test 0.409 0.422 0.448 0.423 116.8% flutter_scrollbar_test 0.154 0.159 0.176 0.159 94.2% function_call 1.428 1.457 1.625 1.463 98.1% infix_large 0.680 0.702 0.776 0.708 144.4% infix_small 0.163 0.167 0.193 0.169 97.5% interpolation 0.090 0.093 0.120 0.094 107.0% large 4.552 4.631 4.987 4.650 90.6% top_level 0.180 0.183 0.214 0.185 135.0% ``` My goal is to get the new formatter as fast as the old one on a real-world corpus. Here's the results for formatting the Flutter repo: ``` Current formatter 15.890 ======================================== Optimized 14.309 ==================================== Old formatter 7.131 ================= The current formatter is 55.12% slower than the old formatter. The optimized is 11.05% faster than the current formatter. The optimized is 50.16% slower than the old formatter. The optimization gets the formatter 18.05% of the way to the old one. ``` So not a huge improvement, but a big step in the right direction.
The dart_style package defines an automatic, opinionated formatter for Dart code. It replaces the whitespace in your program with what it deems to be the best formatting for it. Resulting code should follow the Dart style guide but, moreso, should look nice to most human readers, most of the time.
The formatter handles indentation, inline whitespace, and (by far the most difficult) intelligent line wrapping. It has no problems with nested collections, function expressions, long argument lists, or otherwise tricky code.
The formatter turns code like this:
// BEFORE formatting if (tag=='style'||tag=='script'&&(type==null||type == TYPE_JS ||type==TYPE_DART)|| tag=='link'&&(rel=='stylesheet'||rel=='import')) {}
into:
// AFTER formatting if (tag == 'style' || tag == 'script' && (type == null || type == TYPE_JS || type == TYPE_DART) || tag == 'link' && (rel == 'stylesheet' || rel == 'import')) {}
The formatter will never break your code—you can safely invoke it automatically from build and presubmit scripts.
The formatter can also apply non-whitespace changes to make your code consistently idiomatic. You must opt into these by passing either --fix which applies all style fixes, or any of the --fix--prefixed flags to apply specific fixes.
For example, running with --fix-named-default-separator changes this:
greet(String name, {String title: "Captain"}) { print("Greetings, $title $name!"); }
into:
greet(String name, {String title = "Captain"}) { print("Greetings, $title $name!"); }
The formatter is part of the unified dart developer tool included in the Dart SDK, so most users get it directly from there. That has the latest version of the formatter that was available when the SDK was released.
IDEs and editors that support Dart usually provide easy ways to run the formatter. For example, in WebStorm you can right-click a .dart file and then choose Reformat with Dart Style.
Here's a simple example of using the formatter on the command line:
$ dart format test.dart
This command formats the test.dart file and writes the result to the file.
dart format takes a list of paths, which can point to directories or files. If the path is a directory, it processes every .dart file in that directory or any of its subdirectories.
By default, it formats each file and write the formatting changes to the files. If you pass --output show, it prints the formatted code to stdout.
You may pass a -l option to control the width of the page that it wraps lines to fit within, but you're strongly encouraged to keep the default line length of 80 columns.
If you want to use the formatter in something like a presubmit script or commit hook, you can pass flags to omit writing formatting changes to disk and to update the exit code to indicate success/failure:
$ dart format --output=none --set-exit-if-changed .
If you need to run a different version of the formatter, you can globally activate the package from the dart_style package on pub.dev:
$ pub global activate dart_style $ pub global run dart_style:format ...
The package also exposes a single dart_style library containing a programmatic API for formatting code. Simple usage looks like this:
import 'package:dart_style/dart_style.dart'; main() { final formatter = DartFormatter(); try { print(formatter.format(""" library an_entire_compilation_unit; class SomeClass {} """)); print(formatter.formatStatement("aSingle(statement);")); } on FormatterException catch (ex) { print(ex); } }
Before sending an email, see if you are asking a frequently asked question.
Before filing a bug, or if you want to understand how work on the formatter is managed, see how we track issues.