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>
There doesn't appear to be any implementation work needed, so this just
adds some regression tests. If you can think of other test cases that
ought to be included, please let me know.
Change-Id: Icc9494cd0da32a748888bc7fc4261ca8f7d1282c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467400
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Updates the `messages.yaml` files to use `camelCase` naming
conventions for message keys, `sharedName` fields, and `analyzerCode`
fields. This eliminates a significant inconsistency between the
diagnostic code formats in the analyzer and the front end.
This CL was created automatically by running the script
`pkg/analyzer_utilities/tool/messages/switch_to_camel_case.dart`.
Change-Id: I6a6a6964cc9e5b2ff9d09875d49f0f3d3f404121
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467060
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@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>
Adds the getters `lowerCaseName` and `lowerCaseUniqueName` to the
`DiagnosticCode` class. These getters behave the same as the `name`
and `uniqueName` getters, except that they convert the string to lower
case before returning. These getters should help make it easier for
the analyzer and related packages (as well as analyzer clients) to
treat diagnostic codes in a case-insensitive fashion.
In follow-up CLs, I plan to switch the analyzer and related packages
over to using the new getters, and then I'll deprecate and eventually
remove `name` and `uniqueName` from the analyzer public API.
Change-Id: I6a6a6964e8891fc6f74a9777eae375f1a553c2f3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/466182
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@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>
In a follow-up CL, I will change the code generator for diagnostic
messages so that all code-generated instances of `DiagnosticCode` have
`name` and `uniqueName` fields in all lower case letters. This will
help pave the way toward resolving conflicts between the diagnostic
code naming conventions between the analyzer and CFE.
To prepare for this change, the following pieces of code need to first
be modified to be case insensitive:
- The `_ignoreNullSafetyWarnings` check in
`RemoveDeadCodeSoundFlowAnalysisTest`.
- The `_diagnosticCodes` fields in `_CannotIgnoreOptionValidator` and
`_ErrorFilterOptionValidator`.
- The `computeErrorData` methods in `ConstantsDataComputer` and
`_InheritanceDataComputer`.
- The `_writeDiagnostic` methods in `DriverEventsPrinter` and
`ResolvedUnitResultPrinter`.
- The `_validateMessages` and `_validateSnippet` methods in
`DocumentationValidator`.
- The `run` method in `TextualOutline`.
In most cases, the code was changed to be case insensitive by having
it call `.toLowerCase()` or `.toUpperCase()` on the diagnostic code
name before operating on it. In one case I was able to re-use the
`AnalyzerCode.lowerSnakeCaseName` getter.
Change-Id: I6a6a6964f3cc4c71f2e82478855d64d5ef91d26b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465804
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
FMorschel