Adds logic to the `RemoveTypeName` correction producer to ensure that
after the correction is applied, the spacing matches what `dart
format` would do. For example, `C()` is changed to `new()` rather than
`new ()`, and `factory C()` is changed to `factory()` rather than
`factory ()`.
This will make it easier for me to visually inspect intermediate
results when transitioning the SDK and google3 to language version
3.13. It also should provide a (marginally) nicer user experience.
Change-Id: I30babde38e58438ea39279ed0d5859ce6a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500880
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Replace the positional Scanner constructors with a single constructor
that takes the input text and error reporting callback as named required
arguments.
Remove the unused fasta forwarding constructor, reader offset handling,
and stored first token. The scanner now keeps only the input text and
returns the token stream directly from tokenize.
Update analyzer, analysis server, plugin, CLI, scrape, and scanner test
call sites to use the named constructor arguments.
Change-Id: Ieabb7b28570d4a963563fb2d1c5ef5ac0c89032a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500340
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This some basic scaffolding for the migrate tool. We'll add a protocol to the analysis server with the following parameters and result:
Parameters
- `uris`: Workspaces/packages to be migrated
Result
- `summary`: Information about fixes that could not be applied automatically. (e.g. if there was a conflict) or information about what fixes were applied and what SDK version the pubspec has been changed to.
- `edit`: A list of edits to be applied.
There are no interesting tests yet, but I hope to have a suite of tests for the next change.
Fixes: https://github.com/dart-lang/sdk/issues/63247
Change-Id: I77508720acb17af5ec86675fd3f3045e2a610bf2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496801
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Deprecate FormalParameterElement.isInitializingFormal and
FormalParameterElement.isSuperFormal in favor of checking whether the
element implements FieldFormalParameterElement or
SuperFormalParameterElement.
Update analyzer and linter callers to use the subtype checks directly.
This makes the declaration form explicit in the element model and avoids
duplicating information that is already encoded by the parameter element
subtype.
Record the formal parameter declaration form in fine-grained manifests
as a single enum value instead of two independent booleans. This
preserves the distinction between regular, field formal, and super
formal parameters while making the manifest representation impossible to
encode as conflicting forms.
Update summary serialization, manifest printing, API text, and changelog
entries for the deprecated API.
Change-Id: Icb620afb90f31dc6d8510e1a9f49f0d9a6785754
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499681
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This adds error recovery for mixin and extension declarations with primary constructors. This avoids cascading errors when primary constructors are used with these declarations which do not support primary constructors.
Closes#63157
Change-Id: I17bfab4a7eabac1c75e7cfb580295dcf619c991d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499180
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
In WorkspaceFlutterWidgetPreviewsHandler.handle() and FlutterWidgetPreviewsHandler.handle(), an explicit cast of the server instance to LspAnalysisServer was used. When the analysis server is running in legacy mode, the server is a LegacyAnalysisServer, which caused a TypeError. This change removes the unnecessary cast and uses the base server instead.
Fixes https://github.com/flutter/flutter/issues/185657
Change-Id: If331de5ff2b7e987c07e49dd3a9cd8a03fc75853
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499720
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
This changes the "refactor.perform" command to prompt the user with an option to "Refactor anyway" if the refactor has non-fatal errors or warnings (matching existing Rename functionality).
This change is currently only for the non-self-describing refactors (inline/extract method/variable etc.). The self-describing refactors currently don't report errors in a way that can be ignored/continued and will need some additional changes, and may be better doing later if there will be protocol changes (I've filed https://github.com/dart-lang/sdk/issues/63294).
Fixes https://github.com/dart-lang/sdk/issues/53458
Change-Id: I0674f7b67c86fe1cf9f6bd57b2d6cee08b4066b3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499600
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Avoid constructing file URIs and paths directly from the host platform
when analyzer code is operating on an injected ResourceProvider. Those
direct conversions use the process path context, which is wrong when the
provider is using a Windows path context on another host platform.
Route file URI conversions through ResourceProvider, FileSource, File,
and PathContext APIs instead. This keeps file names, document links,
analysis options includes, navigation targets, and relative paths
aligned with the active provider.
Update affected tests and shared test utilities to use provider-backed
URIs and paths, so they exercise the same path semantics as production
code.
Change-Id: Iaf7751d028273a5fa72a04d8ca60e51aee700594
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499481
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This impacted the placement of the imports, but I think the new results
are better. If nothing else, it's more consistent.
I thought it might be easier to review as two separate changes.
- The first patchset includes the basic transformation.
- The second patchset removes the old code to add the imports.
Change-Id: Ia0a3745152a14ce32fb757e797d0848b9f8d47cb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499320
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This updates the `showUserPrompt` method to accept a cancellation token so that if requests are cancelled (by the client, or something like a second refactor cancelling the first), the prompt is also cancelled (and when the response arrives, it can be ignored).
Note: Unfortunately the protocol (and VS Code) don't actually allow for the prompt to be cancelled/hidden from the user, this is mainly to avoid us keeping the request "alive" on the server if the user ignores a prompt and we know the parent request was cancelled anyway.
Fixes https://github.com/dart-lang/sdk/issues/63285
Change-Id: Ia77880a749b284a2ff31c8cf560307ad908d2175
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499360
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Delay creation of formal parameter elements until after executable
fragment chains have been linked. This lets the element class be chosen
from the complete parameter fragment chain, rather than from whichever
fragment is first reached.
A regular parameter fragment can later be linked with a field-formal or
super-formal fragment from an augmentation. Build the element after that
linking step so the chain receives a field-formal or super-formal
element when any fragment in the chain requires it.
Apply the same model to parameters nested in function-typed parameters
and generic function types. Store and read their resolution separately
from the AST shape so deserialization can bind fragments first and then
restore parameter types.
Update callers that previously assumed a field-formal or super-formal
fragment always had a correspondingly typed element. During recovery,
extra unmatched parameters may still have plain formal parameter
elements, so these paths now check the element type before using
field-formal or super-formal specific state.
Bump the analyzer summary data version because the serialized parameter
resolution layout changed.
Change-Id: I9dfc79e3b1ccfcbaeea6bbe5cec00d7bf20f5bb3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498800
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Move PackageConfigFileBuilder into the analyzer_testing public API and
deprecate the copy exposed from package:analyzer. The builder is only
used by test infrastructure, so keeping it in analyzer_testing makes the
ownership clearer and avoids exposing test-only utilities from analyzer.
Update the builder API to accept a rootFolder instead of a rootPath.
This lets callers pass the resource-provider folder directly, so the
generated rootUri is derived from the same file-system abstraction that
created the test files. This avoids accidentally passing POSIX paths
where resource provider paths are required, such as on Windows.
Update existing test utilities and callers to import the new library and
pass Folder objects. Remove the production analysis server dependency on
the builder by emitting the temporary plugin package config JSON
directly.
Change-Id: I46b14710626e0d6d5884afcdc5a05b23077acfc9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499081
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This continues the effort to move all of the legacy refactors over to
using the ChangeBuilder rather than creating legacy edit objects
directly. This should make it easier to atomically convert all of the
refactors to produce a protocol-agnostic representation as part of the
move to remove the legacy protocol.
Change-Id: I659c14966b543f21ecc94248a2c0dda5692473fb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499045
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Fixes https://github.com/dart-lang/sdk/issues/54927
Generally this warning reports these cases:
The function expression has an unassignable return type:
```
void f(Future<int> future) {
future.then((_) => 0, onError: (e, st) => 'c');
}
```
The function has an unassignable return type
```
void f(Future<int> future, String Function(dynamic, StackTrace) cb) {
future.then<int>((_) => 1, onError: cb);
}
```
The block function body has an unassignable return type or is missing a return type:
```
void f(Future<int> future) {
future.then((_) => 0, onError: (e, st) {
if (1 == 2) {
return;
} else {
return 0.5;
}
});
}
```
Change-Id: I5d67ae35109a874543af01936f13256ff457b35b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498240
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
I changed the parsing of const dot shorthands to parse the entire selector chain in `parsePrecedenceExpression` rather than parsing them in `parseConstExpression`. We were originally parsing the initial expression before the `.` and only flagging that as a dot shorthand which prevented any chaining on const constructors. Const expressions with chained methods/property accesses were not being flagged as a dot shorthand so we weren’t saving the context type properly which led to producing the “unknown context type” error.
Before:
```
class C {
const new someConstCtor();
C method() => this;
}
C c = const .someConstCtor.method();
// (const .someConstCtor) is parsed and handled as a const constructor
// (const .someConstCtor) is handled as a dot shorthand, context is
// saved on only this AST and not the outer chain.
// Then we parse the rest of the selector chain (.method())
//
// Error: No context type for (const .someConstCtor.method())
```
After:
```
class C {
const new someConstCtor();
C method() => this;
}
C c = const .someConstCtor.method();
// (const .someConstCtor) is parsed and handled as a const constructor.
// Then we parse the rest of the selector chain (.method())
// (const .someConstCtor.method()) is handled as a dot shorthand, context is saved for this outer node.
//
// OK. No error because we are able to retrieve the type for the
// entire dot shorthand chain.
```
Fixes: https://github.com/dart-lang/sdk/issues/63119
Change-Id: I3308d8eb7ce101466be257aba6b5448921bff136
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/495560
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
This adds a new lint that was requested in order to support the primary
constructors feature.
This also enables the existing fix to remove the keyword and adds some
tests for the new use of the fix.
Change-Id: Iae3c86ca87a2af6abb82488e218d839a06699778
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496741
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This CL is a bit different from many previous CLs in a couple of ways.
The smallest difference is that I realized that some of the logic could
be shared and that we have a utility method that just need to be
enhanced a bit to support primary constructors. At some point we should
go back to the previous implementations and update them to use the
utility method.
The larger difference is the use of a pair of wrapper classes to
encapsulate some of the differences between primary and secondary
constructors. I'm not sure how I feel about the two approaches. On the
one hand, the wrapper classes feel a bit heavy-handed, but on the other
hand they could make a lot of code more DRY.
Your thoughts would be appreciated.
Closes https://github.com/dart-lang/sdk/issues/63047
Change-Id: I93af6d2a529bbc0491cf64ff03f7a58e6b874d81
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/495461
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
There's one class left to convert, as far as I know, and I have it
mostly converted, but adding `awaits` to the code causes an inconsistent
analysis exception and I don't want to wait until I've solved that
problem to land the rest.
Change-Id: Ic5f159f0703fc708119f8bfa249270cb8a853678
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/495782
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Permit `abstract` on top-level variable declarations when the
augmentations feature is enabled. Previously the parser always reported
`abstract` as extraneous at the top level, which rejected valid syntax
and dropped the modifier before later stages could see it.
Thread the abstract token through top-level field parsing, record it on
`TopLevelVariableDeclaration`, and pass it through the front-end
builders. Reorder the field callback arguments so `augment` precedes
`abstract`, matching the augmentation grammar for incomplete top-level
variables and keeping the parser, listener, and outline plumbing
consistent.
Change-Id: I680414a746b707d483e485702685c95f28a9c9ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494564
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Add `InterfaceType.interfaceMembers` and
`InterfaceType.inheritedConcreteMembers`, and implement them by applying
the type's substitution to the underlying element members.
This moves member instantiation to the `InterfaceType` API instead of
requiring callers to read raw element maps and wrap the results
manually. With this change, code that works with an instantiated type
can ask the type itself for the corresponding instantiated members.
Update completion, inheritance, extension resolution, and summary
reading code to use the new API and `ExecutableElement.substitute()`
instead of `SubstitutedExecutableElementImpl.from()`. This removes the
old helper, simplifies callers, and makes substitution behavior more
uniform across the analyzer.
Change-Id: I2349546d65e9745c2cdeda19ca6ff9283a5fd001
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/495100
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Refactor `applicable_extensions.dart` so its public entry points accept
`DartType` and `ExtensionElement`, and perform implementation casts
internally at the analyzer boundary.
Remove the `strictCasts` parameter as well. Extension applicability
always ignores casts, so the parameter only added noise to the API and
to every call site.
Update completion and fix code in analysis_server to pass public types
directly and drop imports of internal analyzer type classes. Also
centralize the cast from `ExtensionElement` to `ExtensionElementImpl`
inside the helper instead of repeating it in multiple loops.
This makes the API cleaner, keeps the public/internal split in one
place, and reduces accidental coupling to analyzer implementation types.
Change-Id: I770ee5d8788f4c4a7004a0ad18a00cc52552e3b5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494802
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Report dedicated diagnostics for mixin classes that use a `with` clause
and for mixin application classes that use multiple mixins, instead of
folding both cases into `mixinClassDeclarationExtendsNotObject`.
This makes the reported error match the actual invalid construct. A
`mixin class` with a `with` clause does not have the same problem as a
`mixin class` that extends a non-`Object` superclass, and a mixin
application with multiple mixins is a separate restriction again.
Update the error verifier, diagnostic definitions, messages, and fix
status entries to use the new codes. Also guard `RemoveExtendsClause` so
it only offers a fix when an actual extends clause is present, avoiding
a bogus fix for diagnostics that are now reported on `with` clauses
instead.
Consolidate the diagnostic tests under a single mixin class declaration
test file and update expectations to use the more precise error codes.
The original impetus for this change was a crash in RemoveExtendsClause
quick fix.
Change-Id: I937276f37deb293ca1fecab3ff838ace45af2ec4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/493865
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Danny Tuppeny