Upon a `textDocument/semanticTokens/full` request the analysis server
sorts the "tokens" via `sort` on List giving it a compare method.
The method, though, created a map literal for each comparison.
This CL "inlines" the map (it only had one entry anyway) and adds a
benchmark, where I note these changes:
```
1000:
Difference at 95.0% confidence
-0.0274151 +/- 0.0135978
-33.1981% +/- 16.4662%
(Student's t, pooled s = 0.0181832)
2000:
Difference at 95.0% confidence
-0.027344 +/- 0.0096196
-20.9529% +/- 7.3712%
(Student's t, pooled s = 0.0128635)
4000:
Difference at 95.0% confidence
-0.108847 +/- 0.0196627
-35.3172% +/- 6.37987%
(Student's t, pooled s = 0.0262932)
8000:
Difference at 95.0% confidence
-0.20647 +/- 0.0272577
-34.4932% +/- 4.55371%
(Student's t, pooled s = 0.0364494)
16000:
Difference at 95.0% confidence
-0.384931 +/- 0.0401393
-31.4809% +/- 3.28272%
(Student's t, pooled s = 0.0536748)
```
Change-Id: Ibacce056cd3f154afc9377805bbccfd8c5ca9ea9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/456341
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
We rename constant names to use lowerCamelCase, and append
"AttributeName" in most cases, as most constants refer to a (as it is
documented) "JSON attribute."
Additionally the `toJson` methods can be simplified by returning
Map literals, instead of setting key/value pairs in individual
statements.
Change-Id: I5f0adabfa3c4d274407ae8a5b5684dce22f9b5fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/455880
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Removes the diagnostic codes
`HintCode.deprecatedMemberUseFromSamePackage` and
`HintCode.deprecatedMemberUseFromSamePackageWithMessage`, and the
logic for reporting them. These hint codes have been replaced with
lints.
Removing these diagnostic codes avoids an ambiguity between
`HintCode.deprecatedMemberUseFromSamePackageWithMessage` and
`LinterLintCode.deprecatedMemberUseFromSamePackageWithMessage`.
Avoiding ambiguities like these is important, because in many cases
the user only sees the diagnostic name; they don't see the class it's
in. For example, `ignore:` comments just give the diagnostic name, and
the web page https://dart.dev/tools/diagnostics only shows diagnostic
names.
In the future I intend to add an error check to the analyzer
diagnostic code generator, to ensure that there are no ambiguities
like these. This CL is a prerequisite for adding the error check.
To avoid this change causing `ignore:` comments to become unnecessary
(which would break bots), I've enabled the lint
`deprecated_member_use_from_same_package` in `pkg/analysis_server`,
`pkg/analyzer`, `pkg/compiler`, and `pkg/linter`. After this change
lands, I will work with the owners of those packages to determine
whether it's better to keep the lint enabled or to remove the
`ignore:` comments.
Change-Id: I6a6a6964aa7f69a41b9b815e0f50fc638898f104
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/455541
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Renames the diagnostic code
`CompileTimeErrorCode.recordLiteralOnePositionalNoTrailingComma` to
`CompileTimeErrorCode.recordLiteralOnePositionalNoTrailingCommaByType`. This
avoids an ambiguity between this message and
`ParserErrorCode.recordLiteralOnePositionalNoTrailingComma`.
The two messages need to stay distinct, because one is reported during
parsing, and the other is reported during type analysis. Only
`ParserErrorCode.recordLiteralOnePositionalNoTrailingComma` should
prevent the formatter from running.
Avoiding ambiguities like these is important, because in many cases
the user only sees the diagnostic name; they don't see the class it's
in. For example, `ignore:` comments just give the diagnostic name, and
the web page https://dart.dev/tools/diagnostics only shows diagnostic
names.
In the future I intend to add an error check to the analyzer
diagnostic code generator, to ensure that there are no ambiguities
like these. This CL is a prerequisite for adding the error check.
Note that the `sharedName` of the renamed diagnostic remains
`RECORD_LITERAL_ONE_POSITIONAL_NO_TRAILING_COMMA`, so there will be no
change in how the error is presented to the user.
Change-Id: I6a6a6964c1d4e28c6db71072252abf95fbc13206
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/455562
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Removes the analyzer error code `ScannerErrorCode.expectedToken` and
replaces usages of it with `ParserErrorCode.expectedToken`. This
avoids an ambiguity between the two messages.
Avoiding ambiguities like these is important, because in many cases
the user only sees the diagnostic name; they don't see the class it's
in. For example, `ignore:` comments just give the diagnostic name, and
the web page https://dart.dev/tools/diagnostics only shows diagnostic
names.
In the future I intend to add an error check to the analyzer
diagnostic code generator, to ensure that there are no ambiguities
like these. This CL is a prerequisite for adding the error check.
Change-Id: I6a6a696491a41a9d220a4502bfa9b96410580a19
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/455561
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Removes the analyzer error code `ScannerErrorCode.missingIdentifier`
and replaces usages of it with
`ParserErrorCode.missingIdentifier`. This avoids an ambiguity between
the two messages.
Avoiding ambiguities like these is important, because in many cases
the user only sees the diagnostic name; they don't see the class it's
in. For example, `ignore:` comments just give the diagnostic name, and
the web page https://dart.dev/tools/diagnostics only shows diagnostic
names.
In the future I intend to add an error check to the analyzer
diagnostic code generator, to ensure that there are no ambiguities
like these. This CL is a prerequisite for adding the error check.
Change-Id: I6a6a696467b91740c152278f538b9fed763e258f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/455540
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Renames `TransformSetErrorCode.unexpectedToken` to
`TransformSetErrorCode.unexpectedTransformSetToken`. This avoids an
ambiguity between this message and `ParserErrorCode.unexpectedToken`.
Avoiding ambiguities like these is important, because in many cases
the user only sees the diagnostic name; they don't see the class it's
in. For example, `ignore:` comments just give the diagnostic name, and
the web page https://dart.dev/tools/diagnostics only shows diagnostic
names.
In the future I intend to add an error check to the analyzer
diagnostic code generator, to ensure that there are no ambiguities
like these. This CL is a prerequisite for adding the error check.
Change-Id: I6a6a69644ac250b0add9a5f70ec1fd4839ebdef3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/455468
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes the shared error code `FieldInitializerOutsideConstructor` so
that it generates
`CompileTimeErrorCode.fieldInitializerOutsideConstructor` rather than
`ParserErrorCode.fieldInitializerOutsideConstructor`, replacing the
old analyzer-only
`CompileTimeErrorCode.fieldInitializerOutsideConstructor`. This
eliminates unnecessary code duplication between
`pkg/analyzer/messages.yaml` and
`pkg/_fe_analyzer_shared/messages.yaml`.
Removes logic from `pkg/analyzer/lib/src/fasta/ast_builder.dart` that
previously reported
`ParserErrorCode.fieldInitializerOutsideConstructor`. This logic was
unreliable (it only triggered for method parameters and local function
declarations) and unnecessary (because it duplicated logic in the
`ErrorVerifier`). This improves the user experience by eliminating
duplicate errors.
Change-Id: I6a6a69648a9958db531bb0c84bc604358dd0af6f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/455466
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Modifies the analyzer diagnostic message code generator so that when
generating `withArguments` methods, it uses a fully qualified
reference to the diagnostic constant rather than a bare identifier.
Previously, if one of the named parameters of the `withArguments`
method had the same name as the (camelCase) diagnostic constant, the
parameter would shadow the diagnostic constant, so this would cause a
compile-time error in the genrated code.
Note that although this increases the size of the generated code, it
should still compile to the same machine instructions, so there should
be no performance impact.
Thanks to Brian for discovering this issue!
Change-Id: I6a6a6964c0bd33f06a47a12387a2956b018a8fea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/455467
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
No functional change, this just skips some work when opening/closing files if we have explicit analysis roots (`onlyAnalyzeProjectsWithOpenFiles=false`, which is the default). In this case, opening and closing files never changes the analysis roots so we don't need to do any of this work.
Change-Id: I052cca6a9b8cbb4d8f936787e83d453f302159c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/455500
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
While renaming SCREAMING_SNAKE constants, I noticed this local variable
which is computed from a static constant, so I decided it could also
be a static field. A static field is lazily computed. (It could even
be static constant, but PostfixTemplateDescriptor is not constant; it
could be, but I don't think our code-generation code has a facility
for making constant constructors.
Also make things camelCase.
Change-Id: I6f5da4e5cecee347b44bb3ad3d8fdcde7632986c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/454420
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
The primary change here is to rename constants from SCREAMING_SNAKE
case. Also:
* Make the fields private, as a best practice, which also highlights
that the `endOfLine` field is unused.
* In `sortUnitMembers`, use a switch since `CompilationUnitMember` is
a sealed class. This highlights, via the necessary `default` case,
that the switch is non-exhaustive.
Change-Id: I41a9ebdec651402e3e894321a9d6e72b1cbbb66a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/454421
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This code made assumptions about the list of (method) parameters and arguments being the same (length and order). This caused a RangeError if there were optional parameters that weren't provided, and the wrong argument names if the order was different.
We now look up the arguments based on the corresponding parameter names instead, don't try to write them if there isn't an argument, and write optional parameters into the new constructor if the original method parameters with optional.
Fixes https://github.com/dart-lang/sdk/issues/61382
Change-Id: Id000c122535f85daed0437d3bc271db9d6e818ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/453704
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
One can see that we have bare HTML in these signature-in-comments,
like:
"contextMessages": optional List<DiagnosticMessage>
These are flagged by the unintended_html_in_doc_comment lint rule.
This CL solves this by indenting these signatures 4 spaces, making
them Markdown indented code blocks. Alternatively we could use
backticks. Backticks would make the comments taller; indenting makes
them wider. I would prioritize whichever style is less intrusive when
reading them in plain text, which I think would be to use
indentation.
Change-Id: I019d9073e994a505325194ceeac3c6e0635d947e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/453642
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
* Rename `PluginSession.interestingFiles` to `.interestingFileGlobs`.
This confused me for a bit, though the doc comment is accurate.
* `PluginManager.broadcastWatchEvent` was needlessly async and
needlessly returned a Future. It can just return the List of Futures.
* In addition, the implementation of this method is made simpler; the
previous very long if-condition is broken into a series of
`if (foo) continue` statements, which allows for nice promotion and
allows the large comment to sit next to the condition to which it is
referring.
Change-Id: I77e8f7476b38d21f4c1a991045333d1e19a54143
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/452200
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
I noticed, when running `dart analyze`, that when `pub upgrade` could
not be run in a plugin directory, we would get the "An error occurred
while setting up ..." message (good), but then the plugin would still
be executed! And this message would get printed:
> An unexpected error was encountered by the Analysis Server.
> Please file an issue at https://github.com/dart-lang/sdk/issues/new/choose with the following details:
>
> Internal error: Issue stopping a plugin
> Bad state: Cannot stop a plugin that is not running.
The reason is that a PluginException was _only_ thrown, on line 560,
if the package config file was still _missing_. But in my case, the
plugin directory was pre-existing, from an earlier, successful run,
and so the package config file existed! So no exception was thrown,
and the server still attempted to run the plugin.
So this CL makes that whole situation much simpler, and in particular
removes the erroneous "An unexpected error was encountered by the
Analysis Server" message that we do not want to show to users, and an
extra stack trace.
Change-Id: I9be39d10b687e055392f9b81285c99cca4c57534
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/453140
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Adds a translation of the scanner error code `Encoding` to the
`translateErrorToken` function. Previously, this error was unhandled,
so if the scanner encountered invalid unicode, the analyzer would
crash.
Change-Id: I6a6a696433016dddd2cbc0660922ea5248d54419
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/452901
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In my tests with fine-grained dependencies the on-disk cache size
after analyzer/ + friends, and Flutter repository is at or a litlle
over the upper about 1 GB + 12%, which causes cache evictions, so when
I switch between these two sets, I saw analysis without changes.
Change-Id: Ief3344746177388b9e8a83df1474cc6f9aa821d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/452481
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
With fine-grained dependencies aggressively unloading deserialized
objects from memory, and probing cache for previous blobs, it becomes
necessary to have access to these blobs without hitting the file system.
This new size is enough to keep the Flutter repository fast.
Change-Id: Ief507cddc6da3493896db3fedd9f0938c7ccd030
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/452225
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Modifies the `analyzer_public_api` lint so that it reports
`analyzer_public_api_experimental_inconsistency` if an element in the
analyzer public API that is _not_ marked experimental has a type that
refers to an element in the analyzer public API that _is_ marked
experimental.
Such references are problematic because they can cause a client of the
analyzer public API to make use of an experimental type without
receiving a warning.
Change-Id: I6a6a6964fd5f1d37e163dc27a1cb4e605efd2d76
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/451550
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Keerti Parthasarathy