The lint will fire even when there is a comment in the body, such as
```dart
class C() {
this { /* comment */ }
}
```
I think this is the right behavior because I can't think of any useful
comment that wouldn't be better somewhere else, but let me know if you
disagree.
This doesn't yet have a fix, but it should.
Change-Id: Ia5ffa6b06c75a6a7400ec32a9d22209c08a9c73d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510401
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Work towards https://github.com/dart-lang/sdk/issues/63527
We will want to deprecate the `analyzer/language/strict-casts` setting,
but we first need to ship an SDK to Flutter that offers the lint rule,
before we deprecate the setting, which will cause CI to fail (like a
Dart->Flutter roll).
When the deprecation is enabled, we can also ship the automated fix.
Change-Id: I0e9651171b721577acbd416d254bca3d0324f3f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509521
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Work towards https://github.com/dart-lang/sdk/issues/63516
I have code here to deprecate the `analyzer/language/strict-raw-types`
setting. But I disabled it, as I realized we first need to ship an SDK
to Flutter that offers the lint rule, before we deprecate the setting,
which will cause CI to fail (like a Dart->Flutter roll).
When the deprecation is enabled, we can also ship the automated fix.
Change-Id: I17d1ea9aba96063059e37891c05d4a8bd3f02737
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509063
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
When we built the added the original interactive refactors support, we supported the client telling the server which field kinds it can prompt for, so that if there were questions the client didn't support that did not have default values, the refactor could be hidden.
However, we only implemented one such refactor (Move to File) and the only field (destination URI) has a default value, so the client capabilities never have any effect.
Since we're replacing this support with the new "Interactive Forms" and don't intend to create any new refactors using the old system, this code is all redundant and therefore can be deleted.
Change-Id: Ic940dc54e325ccab05b28f496dbedee76e17e0b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509460
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Similar to the previous CL for Add Import Prefix, this adds support for prompting for a name for "Add Constructor Name" if Interactive Forms are available.
Change-Id: I952695df03016a549345f329ac04961d7c279af1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509380
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
If the client supports Interactive Forms, this will allow prompting for a name for the import prefix instead of using "prefix" (or "prefix1", etc.).
Includes moving some boilerplate out of each refactor into `ParameterizedRefactoringProducer` and support for a custom validation function for form fields (to validate the import prefix name in this case).
Change-Id: I7150664a18944c723eeeac0a309341af2860201f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509340
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
1. The `filters` field is specified/implemented as just file extensions, not patterns
2. We need `type: FileType.Regular` to stop you selecting directories as the target for the move
Change-Id: I39397ff844c91bbbfbbd8c070bc29ce2db371d73
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508921
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This adds support for the `command/resolve` request to support the new Interactive Forms functionality, and updates the refactor processes to use it instead of the original protocol when the client indicates support.
Currently only the "Move to File" refactor uses this functionality (matching the previous version) and it requires the `dart.experimentalInteractiveForms` setting be enabled for it to be used (in case we find bugs while developing the front-end that require incompatible changes).
Fixes https://github.com/dart-lang/sdk/issues/63371
Change-Id: I414a41fa2958ca9dcefe097f35ba28f3fa2fe367
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508121
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
I ran across this bug while testing to see what work was already done.
I didn't take the time to create an issue.
The bug is that an assist was being offered for `class C ^{}` to
convert the class body into a block. The result, for an empty block,
was just to add an extra space before the block body. For a non-empty
block, the result was to delete everything inside the block.
Change-Id: I0342b681ef67b5e659a00126a998d63d593223fd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508702
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Separate the subtype search entry points by result shape and caller
intent. Use `directSubtypeReferences` for reference locations in subtype
clauses, and use `directSubtypesWithMembersOfType` /
`directSubtypesWithMembersOfSubtype` for indexed direct subtypes with
their declared instance members.
Rename `SubtypeResult` to `DirectSubtypeWithMembers` so the model
matches what the search result actually represents. Update the server
member-collection logic to start from direct subtypes of the target type
and then walk direct subtypes by subtype id.
Introduce `SubtypeIndexElementId` as the single representation of
subtype index ids. This keeps id construction consistent between index
building and search, preserves the declaration file for declarations in
parts, and still exposes the element name separately for file-state
prefiltering.
Also make the subtype index expectations text-based so the expected
supertype id, subtype name, and member list are easier to read and
update.
Change-Id: Ice71d9b116aca83372bf595f6e58a8ce4aa9e9d1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507780
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
The assist was originall written as a fix, but it's on the list of new
assists that we think users would find useful, so I made it also work
as an assist. The tests are just a copy of the tests for the fix.
The assist is available when the cursor is inside the name of a field
on the left side of a field initializer.
Unlike the lint, which only flags initializers if there is a reference
to a constructor parameter on the right side, the assist will move any
initialization expression. I think that's reasonable, but let me know
if you think we should limit it.
Change-Id: I4f6d90dbd510d5c93f0087933741d298939d4a49
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508680
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This fixes a bug where an interactive form where all fields have defaults would be considered complete immediately, so we'd never present the fields to the client.
It also includes some minor refactoring extracted from a future CL that implements command/resolve and supports Interactive Forms in refactors in an attempt to reduce the size of that change to aid reviewing.
Change-Id: I176fe25dbb0b610d69617fa04562b0d3ce571642
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508220
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This updates the interactive forms classes to reflect recent changes.
Previously, we would only send back the outstanding fields to the client, and it would only provide answers for the same.
Now, the server will always send all fields to the client, and the client will always provide all answers. Answers are looked up IDs (a new field on `FormField`, and `FormAnswer` which wraps the answer) rather than rely on indexes.
Fields can also now be required.
Change-Id: If4aa1f9a18fa873e83cb0ea1fd74c2e42cd2fa1f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508103
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This add a fix to add a type annotation in place of the `var` keyword.
The assist to add a type annotation was already being offered, but it
didn't understand that it needed to also remove the keyword. The added
fix will do both, and, by being a fix, will appear higher in the list
of code actions that users see, along side the fix to remove the
keyword without adding a type annotation.
The fix to remove the keyword can be bulk applied, so I couldn't make
the new one also be bulk applicable. We might consider reversing the
status so that the default bulk fix behavior includes adding a type
annotation, but this CL doesn't do that.
Change-Id: I122221ef1e5119a76e1157a9a15cf1193135fc59
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507161
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Because of the reversed condition, the priority for primary constructor
bodies wasn't being added when the lint was disabled, causing it to not
be moved, resulting in seemingly inconsistent results.
Change-Id: I5110e39e066414e04bb69f61b3aa7189875469f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507460
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This addresses a comment on a previous CL by implementing the logic
required to handle the case where the declaring parameter has an old
style function type.
Change-Id: Ie65cc379571800b0d3d5acec82341d315e80ed4b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507162
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
(Part of https://github.com/dart-lang/sdk/issues/63288)
This change migrates the packages owned by the developer experience
team to use the new constructor declaration syntax, described in
https://github.com/dart-lang/language/blob/main/accepted/future-releases/primary-constructors/feature-specification.md#abbreviations-of-in-body-constructor-declarations.
This change was performed in an automated fashion, by (a) bumping the
packages' SDK constraints to `3.13.0-0`, (b) enabling the lints
`unnecessary_type_name_in_constructor` and
`unnecessary_const_in_enum_constructor`, (c) fixing the resulting lint
failures using `dart fix`, and then (d) reformatting the affected
files.
To ease code review, I've reverted unrelated formatting changes.
Since this change requires bumping SDK constaints to `3.13.0-0`, it
was only performed on packages that are *not* published on
pub. (Packages that *are* published on pub should remain on lower
language versions until at least after the stable version of 3.13 is
released, so that we don't block users on the stable channel from
receiving updates to those packages.)
Change-Id: Ibb4daebafd239da58251e838ea6a3f336a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505046
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
Server already supports the opposite, so this just makes it possible to
go both ways.
This doesn't support converting a declaring function typed parameter.
We could add that, but I'm hoping it's rare enough to not be worth doing.
Other than that, I think I've covered all the cases, but please pay
special attention to the test coverage.
Change-Id: I400204ca820d0e0f1cc44075dd54946db79b2115
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506740
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
It would incorrectly put the primary constructor parameter list before
the type's type parameter list, like:
```dart
// Before:
class C<T> {
C();
}
// After:
class C()<T> {
}
```
This fixes it to follow the type parameter list if there is one.
Change-Id: Ib49c7df7923e9feed11f87579fefc8300c56c4a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506760
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Work towards https://github.com/dart-lang/sdk/issues/62686
`dart analyze` uses an 'analysis.setAnalysisRoots' "command" to let
the analysis server know that the user requested, for example,
`dart analyze foo` or `dart analyze foo/bar.dart`. This was not conveyed
to analyzer plugins, so analyzer plugins will always analyze the entire
context collection.
(For some reason, only files in the "analysis roots" were reported in
stdout; maybe DAS or dartdev does its own filtering on diagnostics.)
This change forwards the `setAnalysisRoots` request to DAS plugins using
a new protocol message that mirrors the one for the server.
We should not change the behavior of `analysis.setContextRoots` for
legacy plugins, so we keep sending that request as per usual. Then
we send `analysis.setAnalysisRoots` at the same time.
If we receive an `analysis.setAnalysisRoots` message, dispose and
delete references to the existing context collection, and instantiate
a new one, with the specified `included` and `excluded` paths.
Change-Id: I53627da1c30351a22b5e5410a557bf486620a7aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505041
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
I recently introduced this deletion logic but was deleting the wrong
file; this was deleting the `plugin.dart` file that `plugin.aot` is
compiled from. Over the weekend I found this issue with manual testing.
I've also verified this fix with manual testing.
Change-Id: I3f570368068117e6bb952ada0707a09ee97b765c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506320
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Extension type augmentations do not have representation declarations, so
an `ExtensionTypeDeclaration` can no longer always expose its name
through a primary constructor. Add `ExtensionTypeDeclaration.namePart`
as the canonical API for the declared name and type parameters, and keep
`primaryConstructor` as a deprecated compatibility API for introductory
declarations.
Report `extensionTypeAugmentationHasRepresentation` when an augmentation
writes representation syntax. This keeps the parser recovery explicit:
the augmentation still gets a plain `namePart`, while the invalid
representation is diagnosed instead of being modeled as the
declaration's primary constructor.
Synthesize recovery representation and primary constructor fragments
only for the element model when an extension type has no introductory
declaration.
Migrate analyzer, analysis server, analyzer plugin, and linter clients
to read extension type names and type parameters from `namePart`.
Change-Id: I59dd957ac38f087c861b993caf246986dcdac713
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505067
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Add a syntactic diagnostic for extension type augmentations that declare
representation fields. Extension type augmentations may augment the
declaration, but they must not redeclare the representation.
Thread an explicit parser option through primary constructor parsing so
extension type augmentations can omit a representation without producing
the usual missing-primary-constructor diagnostics, while still reporting
an error when a representation is present.
Register the new diagnostic in the shared and analyzer generated
diagnostic tables and add it to fix status tracking.
Change-Id: I84815bb0669a76126564e590760e93096a3af046
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505860
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
The element matcher threw a null check exception when getting a matcher
in the argument list of a constructor redirect in a secondary
constructor declaration with no explicit type name. This fixes it so
that no exception will be thrown.
That said, it isn't clear to me that this code could ever be reached
outside of the tests. There might be a lot of unreachable code in
ElementMatcher. I just can't prove that this particular bug would never
have occurred.
Change-Id: I5adf9ab5d4f79686110099054902a28535483f4d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505921
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This CL is to resolve a TODO. I couldn't find a way to trigger any bugs
in the code, but I did add a test. I believe that the reason I couldn't
trigger a bug is because any constructor that has a null `typeName`
will not have a simple identifier in a place that would allow
`_isConstructorDeclarationReturnType` to be invoked.
I realized, while looking at the code, that the type check is
unnecessary. If the type name is null, then the test will somply return
`false`, which is what we'd expect it to do. Given that it isn't needed,
I decided to remove it.
Change-Id: Ib36aaf16475db0db5817e65a8b8bfbb8aa834dbd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505501
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This adds some classes for processing interactive forms (I'm splitting this from the CL that updates refactorings to simplify reviewing).
The `InteractiveForm` class managers a whole form (all fields), and processes a set of fields/answers that come back from the client (which may be the full set, or a subset). It produces a list of the outstanding fields (which need to be go back to the client) as well as maintaining the full set of answers for the master field list (to use as arguments for a command, for example).
I've also commented out enums/lists from the protocol code for now, because I made the field kinds `sealed` so we get exhaustiveness checking in the validation, but want to delay fully implementing those for now.
See https://github.com/dart-lang/sdk/issues/63371
Change-Id: Icc4dcea8c9eab20ffbdd19ebbc69e1285464f7ec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505683
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
(Part of https://github.com/dart-lang/sdk/issues/63288)
Updates the `CodeGenerator` mixin so that it outputs `ignore_for_file`
comments to ignore the following lints:
- unnecessary_type_name_in_constructor
- unnecessary_ignore
- duplicate_ignore
This mixin is used by the code generators that produce the Dart
wrappers for the analysis server and analyzer plugin wire protocols.
This is a first step towards migrating the packages `analysis_server`,
`analysis_server_client`, and `analyzer_plugin` packages to use the
new constructor declaration syntax, since it will allow the
`unnecessary_type_name_in_constructor` lint to be enabled without
breaking generated code.
Once all the packages have had their SDK constraints bumped to a
language version that supports the new syntax, I'll update the code
generator to use the new syntax, and remove the ignores.
For more information about the new constructor declaration syntax, see
https://github.com/dart-lang/language/blob/main/accepted/future-releases/primary-constructors/feature-specification.md#abbreviations-of-in-body-constructor-declarations.
Change-Id: Ied17e3ea772546675aad48efc324f6f16a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505521
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This fixes an exeception when code completing before the `new` or
`factory` keyword in a constructor and the type name is not explicitly
used. The exception prevents any suggestions from being returned, so
it's fairly serious.
Change-Id: I2f5028812ee1945ac9635f55953fb800b19a48c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505620
Auto-Submit: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Danny Tuppeny