The general idea is to remove the need for the subclass,
`_SharedOptionsMap` and the entry class, `OptionsMapEntry`, by wrapping
a Map instead of a `List<OptionsMapEntry>`.
When we use a Map internally, the `getOptions` and `_allOptions`
implementations collapse into one. And we can set the `sharedOptions`
constructor parameter to be the `_defaultOptions` field. With these
changes, we do not need the `_SharedOptionsMap` class.
The `entries` field was previously a commonly used public API for the
AnalysisOptionsMap class, but we can replace it with a `folders` getter
and a `options` getter.
Instead of sorting the map of options on `add` (as was previously done),
we use a `SplayTreeMap` to keep the options sorted.
Change-Id: I9e51931731f4cb4382f2f61f272d53ee15529642
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471320
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
With these changes, primary constructor bodies will sort with
constructors (based on whether `sort_members_first` is enabled), but
will always be before other constructors.
Change-Id: If6719dedd5178c384712a5d08b4e74a38aaf54a1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471280
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
- Skip notifications from analyzer
- Hard code responses to certain startup logs if they are unexpected
- Use cli_util to show loading spinner and get sdk location
- Update normalize to substitute the sdk location
- Make id field optional on message (notifications don't have ids)
Change-Id: Ia5276eef554a3afefeae227fa7351f902d21131e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471060
Auto-Submit: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This data is collected on shutdown, the same as the legacy analytics data.
This is implementation for some of the analytics we want to collect,
specified at go/dart-analyzer-plugin-analytics.
* How many plugins are enabled for each context?
* How many lint rules are registered for each plugin?
* How many warning rules are registered for each plugin?
* How many fixes are registered for each plugin?
* How many assists are registered for each plugin?
Change-Id: I36c176737c194550e1947985576ed461fd8a1bf3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/452482
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This isn't the right implementation, but it no longer crashes when
experimenting with the primary_constructor feature.
While I don't expect this to impact users, it makes it easier for us to
play with the feature while developing the tooling for it.
Change-Id: I317eb03bfd4057adb39dd4352e43e41fdd28bd7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/469101
Auto-Submit: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
In the analyzer, remove our custom warning for `visibleForOverriding`,
`invalid_visible_for_overriding_annotation` (replaced by the existing
`invalid_annotation_target` warning). The tests for that warning are
mostly covered by the existing `invalid_annotation_target` tests, but
I added a few to fill some gaps.
Work towards https://github.com/dart-lang/sdk/issues/62253
Change-Id: Ie960db6ebe007afde787f68e4b6b9f20a1835639
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468702
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Work towards https://github.com/dart-lang/sdk/issues/62248
In this change, we exclude fields declared in a primary constructor
which is declared in an extension type. Since the representation field
is required, the corrective action is unclear. (I can't think of what
purpose an extension type would serve, if its representation field is
never referenced. But users are creative.)
Change-Id: I9556f5d28a16dc7114b30c77369281774bc7c2fd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467924
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This is mainly to exercise the performance test framework, for writing
a report for the test runs.
- adds a flag to specify a file
- logs context information and info from the message scheduler
Started with just these two as an example as I was not sure what performance data we do want to record.
Change-Id: I3e5ff4b77c62d36e47ba7bac8f656b19ba19c457
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468600
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
This stops completion from suggesting `final` outisde a primary
constructor's parameter list when the feature is enabled. When the
feature is not enabled, it won't be suggested anywhere. I did that
because in the same release this CL is for we'll produce a warning if
`final` is used, and it seems unhelpful to suggest adding code that will
have a diagnostic associated with it.
Change-Id: I2f8ad2d92ea0641e2212c89d01aa23921b39b3e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468401
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This adds completion support in the class header. Support for completion
in the body will be added in a separate CL.
Please look carefully at the tests to ensure that there aren't holes in
the coverage.
Change-Id: I189f25fbb90f43b4d8993622d5eb025d3160bef1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467920
Reviewed-by: Kallen Tu <kallentu@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Fixes https://github.com/dart-lang/sdk/issues/62214
Danny describes the problem at a high level in https://github.com/dart-lang/sdk/issues/62214.
At a lower level, the issue is that we add the new `PluginIsolate` to
the `_pluginMap` as soon as we instantiate it! Before we've even made
the request to start it up. The `_pluginMap` is how PluginManager sends
out various requests, like watch events, priority files, and update
content.
The fix is easy enough: we wait to add the PluginIsolate to the `_pluginMap` until after we've awaited `PluginIsolate.start`.
Change-Id: I05e6314fde10fbaf4cf25b38b526c5cf96bd65ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467923
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Changes the logic in `pkg/analysis_server` to use
`DiagnosticCode.lowerCaseName` instead of `DiagnosticCode.name`, and
`DiagnosticCode.lowerCaseUniqueName` instead of
`DiagnosticCode.uniqueName`. This ensures that diagnostic codes are
matched in a case-insensitive fashion.
This paves the way for deprecating (and eventually removing) the
`DiagnosticCode.name` and `DiagnosticCode.uniqueName` getters.
Change-Id: I6a6a69643ef19385ab43d7a04809e58305ca4f0a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/466185
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Align extension type primary constructor handling for classes.
Previously, extension types had a dedicated builder path that
synthesized their representation field and primary constructor from the
PrimaryConstructorDeclaration. This special-case handling meant:
- The constructor fragments for extension types were built differently
from class constructors.
- Representation fields carried name/offset metadata that did not match
how other declaring-parameter fields are modeled.
- Informative data encoded a separate representation block for extension
types, adding custom binary format and read/write logic.
This change reuses the standard primary-constructor builder for
extension types, so their constructors and fields are produced the same
way as for classes. The representation field is now derived from the
first formal parameter in the shared builder logic, instead of via a
separate extension-type-specific helper.
Key changes:
- Route ExtensionTypeDeclaration.primaryConstructor through the general
visitor path (`primaryConstructor.accept(this)`) and remove the
extension-type-specific `_buildExtensionTypePrimaryConstructor`.
- Initialize extension type constructor fragments and declaring
field fragments using the same flags as class primary constructors
(isAugmentation, isConst, isPrimary, isDeclaring, typeName, etc.).
- Treat the first formal parameter of an extension type primary
constructor as the representation parameter, even when it does not
have `final`/`var`, and model the corresponding field as non-synthetic
in that case.
- Drop the dedicated `_InfoExtensionTypeRepresentation` structure from
informative data; extension type fields and constructors now use the
standard field/constructor informative records.
- Adjust informative offsets so that representation fields use the
extension type’s offset instead of the parameter’s offset, and update
golden tests to expect `<null>` name/first-token offsets where the
representation field does not own a standalone name token.
- Update refactoring and diagnostics to be robust when certain fragments
do not have a name range or name offset by:
- Guarding `fragmentName` with a null check before creating edits.
- Using `originalFragment.offset` and `nonSynthetic.firstFragment.offset`
instead of nameOffset in diagnostic locations.
- Make `FieldElementImpl.nonSynthetic` delegate to the declaring formal
parameter when the field originates from a declaring parameter, so
clients consistently land on a non-synthetic element for navigation and
error reporting.
- Allow rename-class-member refactoring to consider extension type
constructors when renaming fields by removing the special-case
exclusion for `ExtensionTypeElement` implementors.
Together, these changes remove special-case representation handling for
extension types, make their primary constructors behave like class
primary constructors, and simplify both element and informative data
models while improving robustness of diagnostics and refactoring.
Change-Id: I50b069ebe8a3afc54e70184d9c395f06c2afa331
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/466441
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The primary constructors language feature changes the interpretation of
members of the form `factory() {}`. Before the feature that code defines
a method named `factory`, but with the feature enabled that now defines
a factory constructor.
This CL adds a warning that applies when the feature is not enabled that
tells users that methods named `factory`, when there is nothing before
the name of the method such as a return type, will no longer be
supported after the feature is enabled.
In addition, it associates a fix with the diagnostic in order to make it
easier for users to update their code in a way that will preserve the
semantics of the code after the feature is enabled.
I added the check in the `BestPracticesVerifier`, but that might not be
the best place for it. Please let me know if it should be moved.
Change-Id: Iff51d36975a914a4b1e3d9c2497cc23a1485c0b1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/466180
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This is not a slam dunk, and I can abandon this if it is not deemed
_more_ readable. Having a Map collection literal with a collection-if
and a spread map literal inside (`if (foo) ...{ ... }`) isn't the
most readable code.
I change a programmatic filling of Maps to be declarative, with Map
literals, collection elements like collection-if and collection-for.
In particular, I think the null-aware elements nicely indicate
nullable values, which might not be included in the Map. If something
doesn't appear in the Insights pages from these property maps, it is
more clear from the code that a value might be `null`, and might not
appear.
This simplifies the code all the way through `writeProperties` and
`writeProperty`, which previously considered `null` values, but now
only need to handle Objects.
Change-Id: I64ab32cebbb3ed0b69d3e4005b9ad2c843030636
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465988
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
We stopped referencing BuiltInServerIsolateChannel a while ago, so the
only concrete subclass of ServerIsolateChannel was
DiscoveredServerIsolateChannel. This change removes the former class
and collapses the latter class into the parent class.
We also make `pluginUri` and `sessionLogger` private.
Also, `packagesUri` was referencing the old `.packages` files, which
are replaced with package config files, so we rename that field to
`_packageConfigUri`.
Change-Id: I93e2f4f10e14d832d85ea63382188019716b5de0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465985
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This paves the way for a follow-up CL that will standardize all
diagnostic names to `lower_snake_case` conventions.
For now, the case differences between the entries in
`error_fix_status.yaml` and the actual diagnostic code names are
accounted for by adding some calls to `.toLowerCase()` to
`verify_error_fix_status.dart`.
Change-Id: I6a6a6964b0eacf50b11f302ab511fba149b1ac07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465981
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Fixes https://github.com/dart-lang/sdk/issues/61684
This caching is based largely on the `--depfile` feature offered by
`dart compile`, which is based on a Ninja depfile concept
(https://ninja-build.org/manual.html#_depfile), which spits out a file
(`depfile.txt` here) which lists all of the input files which were
required to build an AOT snapshot.
The process is essentially:
1. If an AOT snapshot is found, maybe use it as a cached snapshot!
a. If the `pubspec.yaml` modification timestamp is newer, re-compile!
b. If the `.dart_tool/package_config.json` modification timestamp is
newer, re-compile!
c. If the `bin/plugin.dart` modification timestamp is newer,
re-compile!
d. If the `bin/depfile.txt` file is missing or malformed, re-compile!
e. If any files mentioned in `bin/depfile.txt` have a newer
modification timestamp, or don't exist, or are an otherwise bad
path, re-compile!
f. Otherwise, save a dozen seconds and use the cached snapshot.
Change-Id: Icc747198f8af76d256ac915685473d6f529a3cef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464602
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Work towards https://github.com/dart-lang/sdk/issues/61684
PluginManager needs to be more testable before implementing the caching feature. This CL lays the groundwork.
We add ProcessManager.runSync, and a handler for that in MockProcessHandler. Then we can add tests which call `PluginManager.filesFor` with `isLegacy: false`, and `dart pub upgrade` will not be run on the real filesystem.
Change-Id: I7b8877d985296741e51543c10a7cb87c8a43c116
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465662
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
FMorschel