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>
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>
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>
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>
In the new interactive forms, some of the enums can be combined (eg. `FileExistence.New | FileExisting.Existing`). This adds a flag that produces some helper functions for `hasFlag()` and `combine()`.
These helpers are not used outside of tests in this CL but will be used in a future CL (which I'm trying to avoid getting too big to simplify reviewing).
Change-Id: I1b5f06f05d96781c4bc6a246a0a9309a786c1987
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505320
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Codes specified on the command-line are force-enabled in all of the
analysis options for all of the files. This is done in a brute force
way, but it should be safe because the code is creating an analysis
context collection just for this one run, so the options objects
should be short lived.
Closes https://github.com/dart-lang/sdk/issues/63345
Change-Id: I8925da426d6cb5b9ce686725e3b95696b552cae0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505045
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
No functional changes, this just converts the tests from group/test to test_reflective_loader to match other tests.
Changing the group()/test() calls to methods results in the tests being re-sorted by member name.
To possibly simplify reviewing, I've pushed this to Gerrit as two patch sets:
- PS1: does the conversion but includes index numbers in each test to preserve the order
- PS2: removes the index numbers and re-orders the tests
Change-Id: I72ebe3d3066b181a77052bec5082e4bd34066939
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/504580
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Uses the pubspec util `computeVersionBumpEdit` that bumps the pubspec
file's `sdk:` one minor version up.
Very basic iteration through the given pubspec files to bump all of
them. We'll very likely have to refactor this as we get the pre/post
migrations involved, but I wanted to get there in small (reviewable)
steps.
Bug: https://github.com/dart-lang/sdk/issues/63268
Change-Id: I2a7abeacdc76b114dfef7888cd6db6bc8973d01a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/504381
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Danny Tuppeny