Populates the `kind` on the Document Highlights we return. This allows colouring reads and writes differently (which it turns out VS Code does by default).
The options are a bit limited (Read/Write/Text) and using Read/Write for things like type names feels slightly odd, but the spec does seem to encourage this and it's what TypeScript is doing.
Fixes https://github.com/dart-lang/sdk/issues/62929
Change-Id: I6a53450038cde31b399b5b1aca5f964083106763
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503060
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
This is another step toward being able to maximally convert a body of
code to using the primary_constructors features.
This CL does two things:
- Changes `convert_to_declaring_parameter` to also be a fix and applies
that fix to the `use_declaring_parameters` lint.
- Updated the `use_declaring_parameters` lint to also flag field formal
parameters.
Change-Id: I8b584186658abc73c025b166c145efbab95acd8b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/502740
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This CL adds a lint as part of the collection of lints used to automate
converting code to use the features under the primary constructors flag.
The lint flags initializers in a primary constructor body that
initialize a field in such a way that the initialization could be done
in the field declaration's initializer.
It only flags assignments to fields where the right-hand side of the
assignment includes a reference to one or more of the constructor's
parameters. Expressions that don't reference a parameter would have
been valid to move before primary constructors, so flagging them
wouldn't help find bugs in the impementation of the feature.
If we were going to ship this lint, then we might want to extend it to
find initializers that don't reference parameters, whether they are in
the primary constructor body's initializer list or in the initializer
list of a secondary constructor.
This doesn't include a fix. Once again, I wanted to make sure the lint
was covering all the important cases before implementing the lint.
Change-Id: Id4b1e02ec160af50af8f4fe7b8c675213e41abc7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/502202
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Add a compile-time diagnostic for augmentations that declare an explicit
return type different from the introductory declaration. Check top-level
functions, methods, and getters by comparing the augmentation annotation
against the introductory element return type using normal type equality.
Keep executable element return types initialized from the first fragment
only, so later augmentation fragments cannot overwrite the introductory
signature before validation. This also keeps synthetic getter/setter
variables based on the introductory declaration.
Change-Id: I08d55497e235ed2619a6915e0060bd5d8c8a45b6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/502200
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Use the collection-wide OwnedFiles map as the single source of truth for
deciding which analysis driver should process each file during search.
This replaces the per-query SearchEngineCache and SearchedFiles
ownership tracking with ownership recorded as files are discovered.
Store file paths, rather than URIs, in the analysis index so that
indexed element and subtype identifiers use the same File resources that
OwnedFiles tracks. Skip non-file sources when building or querying these
identifiers.
This lets search operations discover available files up front and then
search only files owned by the current driver. It avoids duplicate work
and duplicate results across drivers while keeping search ownership
consistent for references, subtypes, member declarations, top-level
declarations, and workspace symbols.
Bug: https://github.com/dart-lang/sdk/issues/63276
Bug: https://github.com/dart-lang/sdk/issues/63310
Change-Id: I27feed534cb84f52bffbd4da0c53e5c669910b1a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500300
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
The purpose of this lint is to be used with other lints to maximally
convert code to using the new features introduced by the primary
contructors feature. This one is targeted at finding container bodies
the could be replaced by a semicolon.
This CL does not include a fix. That will be added in a separate CL.
We will need to decide whether this lint is worth supporting beyond
the testing period.
Change-Id: I5d2d05117c9f1efc8c71279d5cde549eb48b480c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/502182
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
The use_primary_constructors lint is a temporary lint being used (along
with others) for testing the primary constructors feature. I don't
expect that it will ship to users in its current form, so these fixes
might be removed.
With that in mind, I updated the existing assist that can convert a
secondary constructor to a primary constructor so that it can be used
as a fix. (The assist will remain, even if the lint is removed.) I then
added a second fix to add a primary constructor when there are no
explicit constructors. I did this for two reasons:
1. I expect the fix to be removed before the feature is shipped because
it seems unlikely that users would want to have an explicit primary
constructor rather than the implicit default constructor.
2. Making it a separate lint allows it to have a better label on the
context menu in case users actually see it during the beta period
(or in the stable version if I'm wrong about #1.
The effect is that the lint can now be bulk fixed in order to maximally
convert a body of code.
Change-Id: I7c6dddd8735e67bbd1d398e4035ca578725d044f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/502180
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This is another lint intended primarily for testing. It is intended to
flag every non-declaring formal parameter in a primary constructor that
could be converted to be a declaring parameter.
There is an existing assist to convert a non-declaring parameter to a
declaring parameter, but I want to make sure that this lint is catching
all of the right conditions before enhancing it to be a fix.
Change-Id: I10f8a4980bbc77d35a920a221ef26957f96d22d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501580
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Move the analyzer-only Diagnostic, DiagnosticMessage, Severity, and
locatable diagnostic helper types out of _fe_analyzer_shared and into
package:analyzer.
I paln to make changes outlined in
https://github.com/dart-lang/sdk/issues/63311 and chat discussion.
Keeping these classes in the analyzer simplifies the migration and
avoids introducing a shared abstraction before there is a concrete need
for one.
If we decide later need to have a shared abstraction, we can always
extract one at that point. With coding agents internal code motion is
cheap.
Update analyzer, analysis server plugin, analyzer plugin, linter, and
scanner call sites to import the moved APIs from analyzer libraries, and
refresh API baselines to reflect the new public owner.
Change-Id: Ie0ef0f01c6e4be7ebaac25619ac3e3fe991a44d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501000
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
The purpose of this lint is to help automate testing of the primary
constructors feature. It is unlikely to be shipped in its current form.
The goal is to flag all cases where a secondary constructor could be
converted to a primary constructor. This includes classes with a default
constructor.
There is an assist that should convert most of these cases, but it has
not yet been enhanced to work as a fix. That will be done in a future
CL. I want to implement the lint first so that I know all of the
conditions that the fix needs to handle.
The most important part of this review is to ensure that the tests are
reasonably complete. If there are any missing cases where the lint
should flag a constructor for conversion, or any missing cases where a
conversion should not be requested, please let me know.
Change-Id: Ib8256677a0659479ab341974b87bd03c953ff644
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500583
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This changes the SessionLogFileSink from using `writeAsStringSync` and overwriting the whole file on each message. It does this by using `openWrite()` and keeping the `IOSink` instead.
This means:
- it uses `dart:io` (we don't have `openWrite`/sink support in the abstraction)
- we need to call `close()` to flush the file during shutdown (there was already a shutdown method on the session logger, but it wasn't used or called, so now it is)
This does mean the tests for this class write to the physical disk, but there are only two of them - most other tests use the in-memory sink (or are just testing the normalizer).
Fixes https://github.com/dart-lang/sdk/issues/63275
Change-Id: I7ef347fc46d8ce3daf30ed2f9965e8921c5c4856
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501640
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
The previous CL changes from just replacing paths, to handling URIs + filePaths separately.
This updates the committed scenario files so:
`file://{{workspaceFolder-0}}` becomes just `{{workspaceFolder-0}}` (since this token implies the file URI), and `{{workspaceFolder-0}}` (without the prefix) becomes `{{workspaceFolder-0:filePath}}` (to signify it was a file path).
Even with these changes, they fail for different reasons (invalid git hashes, mismatches in expected vs actual requests) so I there is still more work to do here.
Change-Id: Ic1543ab96ca002073540ef034adecb4c9ea57e58
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501521
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
For posix paths, replacing the file path during normalization and then swapping it back later works for both paths and URIs, because a file URI just contains the file path verbatim:
file:///foo/bar/baz
However that's not the case for Windows:
C:\foo\bar\baz
file:///c:/foo/bar/baz
So when normalizing, we need to know if we normalized a URI or a file path, so that we can reverse it later.
With this change, we'll use `{{workspaceFolder-0}}` for the URI, and `{{workspaceFolder-0:filePath}}` for the file path. Then when reversing, we can easily put the correct one back.
This also updates the log replace/scenarios to use the LogNormalizer to perform the denormalization so they don't have to have duplicated logic about what to restore.
I've also updated the existing committed scenarios (EDIT: moved this to a separate CL because Gerrit is falling over) - although even with those changes, they all fail for different reasons (invalid git hashes, mismatches in expected vs actual requests) so I think there is still more work to do here.
Fixes https://github.com/dart-lang/sdk/issues/63330
Change-Id: Ib4c4aabe2c7c0d089bd620bdf00de37acde25f52
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501600
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
It's possible that there are nested paths in LSP workspace folders, such as:
/foo
/fooBar
/bar/foo
We shouldn't just replace each path we were given, as it might replace the wrong parts of other parts. Instead, require the path to be surrounded by quotes, or prefixed by a quote and followed by the appropriate path separator.
I also tweaked the benchmark test a little to report the time for the first call separately from the others, since that one triggers the regex build.
On my machine, timings currently are:
```
Replacing 250 paths in payload of 2097152 bytes
Iteration #1, First: 43ms, Rest: 30ms
Iteration #2, First: 38ms, Rest: 30ms
Iteration #3, First: 33ms, Rest: 30ms
Iteration #4, First: 37ms, Rest: 30ms
Iteration #5, First: 31ms, Rest: 29ms
```
Change-Id: I75de1fb36a16636e0f50099cced1d5386318d589
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/491640
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Remove the `reportScannerErrors` option from `Scanner.tokenize`. The
parser handles scanner error tokens directly, so the scanner no longer
needs a mode that translates and reports them before parsing.
Update all callers to use the simplified `tokenize()` API. Adjust parser
recovery expectations where diagnostics are now reported at the
synthetic token location chosen by parser.
Change-Id: Ia2d479ba57b3156f1a4bab47c32444892c9d0aa4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500361
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Adds logic to the `RemoveTypeName` correction producer to ensure that
after the correction is applied, the spacing matches what `dart
format` would do. For example, `C()` is changed to `new()` rather than
`new ()`, and `factory C()` is changed to `factory()` rather than
`factory ()`.
This will make it easier for me to visually inspect intermediate
results when transitioning the SDK and google3 to language version
3.13. It also should provide a (marginally) nicer user experience.
Change-Id: I30babde38e58438ea39279ed0d5859ce6a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500880
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Replace the positional Scanner constructors with a single constructor
that takes the input text and error reporting callback as named required
arguments.
Remove the unused fasta forwarding constructor, reader offset handling,
and stored first token. The scanner now keeps only the input text and
returns the token stream directly from tokenize.
Update analyzer, analysis server, plugin, CLI, scrape, and scanner test
call sites to use the named constructor arguments.
Change-Id: Ieabb7b28570d4a963563fb2d1c5ef5ac0c89032a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500340
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This CL enables the primary constructors feature by default in Dart 3.13.
The primary constructors feature is a brevity feature. There are no new semantics, but it allows us to express declarations in a less verbose way.
This feature allows one constructor and a set of instance variables to be specified in the header of a declaration.
Currently a declaration with a constructor and some fields is written as:
```dart
// Current syntax.
class Point {
int x;
int y;
Point(this.x, this.y);
}
```
With a primary constructor, we would write the above as:
```
class Point(var int x, var int y);
```
If a primary constructor needs an initializer list or a body, they can be
specified inside the class using the `this` body syntax:
```dart
class Point(var int x, var int y) {
this : assert(x >= 0) {
print('Point created at $x, $y');
}
}
```
As part of this feature, you can also use the `new` and `factory` keywords to
declare constructors in the class body without repeating the class name:
```dart
class Point {
int x, y;
// Equivalent to Point(this.x, this.y)
new(this.x, this.y);
// Equivalent to Point.origin()
new origin() : x = 0, y = 0;
// Equivalent to factory Point.clone(Point other)
factory clone(Point other) => Point(other.x, other.y);
}
```
To learn more about the feature, check out the feature specification located here: https://github.com/dart-lang/language/blob/main/accepted/future-releases/primary-constructors/feature-specification.md
Tested: Has existing language, CFE, analyzer, analysis server tests.
Bug: https://github.com/dart-lang/sdk/issues/61524
Change-Id: I296f2fcd918b87bf2a1dd00256340759866c2423
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489241
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Michael Thomsen <mit@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
This some basic scaffolding for the migrate tool. We'll add a protocol to the analysis server with the following parameters and result:
Parameters
- `uris`: Workspaces/packages to be migrated
Result
- `summary`: Information about fixes that could not be applied automatically. (e.g. if there was a conflict) or information about what fixes were applied and what SDK version the pubspec has been changed to.
- `edit`: A list of edits to be applied.
There are no interesting tests yet, but I hope to have a suite of tests for the next change.
Fixes: https://github.com/dart-lang/sdk/issues/63247
Change-Id: I77508720acb17af5ec86675fd3f3045e2a610bf2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496801
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Deprecate FormalParameterElement.isInitializingFormal and
FormalParameterElement.isSuperFormal in favor of checking whether the
element implements FieldFormalParameterElement or
SuperFormalParameterElement.
Update analyzer and linter callers to use the subtype checks directly.
This makes the declaration form explicit in the element model and avoids
duplicating information that is already encoded by the parameter element
subtype.
Record the formal parameter declaration form in fine-grained manifests
as a single enum value instead of two independent booleans. This
preserves the distinction between regular, field formal, and super
formal parameters while making the manifest representation impossible to
encode as conflicting forms.
Update summary serialization, manifest printing, API text, and changelog
entries for the deprecated API.
Change-Id: Icb620afb90f31dc6d8510e1a9f49f0d9a6785754
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499681
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This adds error recovery for mixin and extension declarations with primary constructors. This avoids cascading errors when primary constructors are used with these declarations which do not support primary constructors.
Closes#63157
Change-Id: I17bfab4a7eabac1c75e7cfb580295dcf619c991d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499180
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
In WorkspaceFlutterWidgetPreviewsHandler.handle() and FlutterWidgetPreviewsHandler.handle(), an explicit cast of the server instance to LspAnalysisServer was used. When the analysis server is running in legacy mode, the server is a LegacyAnalysisServer, which caused a TypeError. This change removes the unnecessary cast and uses the base server instead.
Fixes https://github.com/flutter/flutter/issues/185657
Change-Id: If331de5ff2b7e987c07e49dd3a9cd8a03fc75853
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499720
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
This changes the "refactor.perform" command to prompt the user with an option to "Refactor anyway" if the refactor has non-fatal errors or warnings (matching existing Rename functionality).
This change is currently only for the non-self-describing refactors (inline/extract method/variable etc.). The self-describing refactors currently don't report errors in a way that can be ignored/continued and will need some additional changes, and may be better doing later if there will be protocol changes (I've filed https://github.com/dart-lang/sdk/issues/63294).
Fixes https://github.com/dart-lang/sdk/issues/53458
Change-Id: I0674f7b67c86fe1cf9f6bd57b2d6cee08b4066b3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499600
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Avoid constructing file URIs and paths directly from the host platform
when analyzer code is operating on an injected ResourceProvider. Those
direct conversions use the process path context, which is wrong when the
provider is using a Windows path context on another host platform.
Route file URI conversions through ResourceProvider, FileSource, File,
and PathContext APIs instead. This keeps file names, document links,
analysis options includes, navigation targets, and relative paths
aligned with the active provider.
Update affected tests and shared test utilities to use provider-backed
URIs and paths, so they exercise the same path semantics as production
code.
Change-Id: Iaf7751d028273a5fa72a04d8ca60e51aee700594
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499481
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This impacted the placement of the imports, but I think the new results
are better. If nothing else, it's more consistent.
I thought it might be easier to review as two separate changes.
- The first patchset includes the basic transformation.
- The second patchset removes the old code to add the imports.
Change-Id: Ia0a3745152a14ce32fb757e797d0848b9f8d47cb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499320
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This updates the `showUserPrompt` method to accept a cancellation token so that if requests are cancelled (by the client, or something like a second refactor cancelling the first), the prompt is also cancelled (and when the response arrives, it can be ignored).
Note: Unfortunately the protocol (and VS Code) don't actually allow for the prompt to be cancelled/hidden from the user, this is mainly to avoid us keeping the request "alive" on the server if the user ignores a prompt and we know the parent request was cancelled anyway.
Fixes https://github.com/dart-lang/sdk/issues/63285
Change-Id: Ia77880a749b284a2ff31c8cf560307ad908d2175
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499360
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Delay creation of formal parameter elements until after executable
fragment chains have been linked. This lets the element class be chosen
from the complete parameter fragment chain, rather than from whichever
fragment is first reached.
A regular parameter fragment can later be linked with a field-formal or
super-formal fragment from an augmentation. Build the element after that
linking step so the chain receives a field-formal or super-formal
element when any fragment in the chain requires it.
Apply the same model to parameters nested in function-typed parameters
and generic function types. Store and read their resolution separately
from the AST shape so deserialization can bind fragments first and then
restore parameter types.
Update callers that previously assumed a field-formal or super-formal
fragment always had a correspondingly typed element. During recovery,
extra unmatched parameters may still have plain formal parameter
elements, so these paths now check the element type before using
field-formal or super-formal specific state.
Bump the analyzer summary data version because the serialized parameter
resolution layout changed.
Change-Id: I9dfc79e3b1ccfcbaeea6bbe5cec00d7bf20f5bb3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498800
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Move PackageConfigFileBuilder into the analyzer_testing public API and
deprecate the copy exposed from package:analyzer. The builder is only
used by test infrastructure, so keeping it in analyzer_testing makes the
ownership clearer and avoids exposing test-only utilities from analyzer.
Update the builder API to accept a rootFolder instead of a rootPath.
This lets callers pass the resource-provider folder directly, so the
generated rootUri is derived from the same file-system abstraction that
created the test files. This avoids accidentally passing POSIX paths
where resource provider paths are required, such as on Windows.
Update existing test utilities and callers to import the new library and
pass Folder objects. Remove the production analysis server dependency on
the builder by emitting the temporary plugin package config JSON
directly.
Change-Id: I46b14710626e0d6d5884afcdc5a05b23077acfc9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499081
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Helin Shiah