- Adds support for normalizing package dependency roots using the
package config
- Updates the project generator so it can handle multiple project roots
and analysis contexts, as well as package configs.
- Handle sending watcher messages to the analyzer.
Removes the basic "initialization" scenario that didn't have any real
value other than being an example github project scenario.
Change-Id: I5b49effe524d325360a754296f4cc3578ad49527
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471360
Commit-Queue: Jake Macdonald <jakemac@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
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>
Previously, the AST builder enforced strict constraints on extension
type primary constructors during parsing, often discarding or
transforming invalid parameters (e.g., multiple, optional, or named
parameters) to force a valid representation field structure. This
limited recovery and resulted in inaccurate element models for invalid
code.
This change updates the AST builder to parse and build elements for the
primary constructor's formal parameters exactly as written. The
validation logic ensuring a single, positional representation field has
been moved to `ErrorVerifier`.
To maintain the invariant that an extension type has a representation, a
synthetic "recovery" representation field is now added to the element
model if the parsed parameters do not provide a valid one.
Bug: https://github.com/dart-lang/sdk/issues/61701
Change-Id: I37b7eaf2c085db6317b2c2b0bf35ff31423f9738
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465180
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@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>
Runs either `dart pub get` or `gclient sync`, based on project type.
For the SDK, copies the .gclient and .gclient_entries files as well
into the parent dir.
Also adds a `--timeout` argument, controls how long to wait for analyzer messages.
Change-Id: Id2c28e6d0251e94914bb0650be104c1f90a66651
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468620
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Auto-Submit: Jake Macdonald <jakemac@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>
This will allow diagnostic reporting code in the analyzer to be more
easily converted to the new literate diagnostic reporting API, because
it will make it possible to use `SourceRange` as the common
denominator for situations where the location where a diagnostic needs
to be reported might come from either a `SyntacticEntity` or a
`SourceRange`.
Change-Id: I6a6a6964f3ec2ea33e8900d93b5abe714c9e1dcc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467682
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Robert Nystrom