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>
(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>
This is a rediculously large CL, and if you want me to split it up I'm
willing to do so.
However, the changes were all made by running a script I wrote and then
running the formatter over the code, so hopefully a spot-check will be
sufficient.
Change-Id: Ifc59b2cc3bf9e4edf0229a130cd587dc73f95615
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505042
Reviewed-by: Samuel Rawlins <srawlins@google.com>
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Report new diagnostics when an introductory function, member, or factory
constructor is still incomplete after applying all augmentations.
Keep the existing missing-body diagnostics for declarations that have no
augmentations, but report augmentation-specific diagnostics when an
augmentation chain exists and none of the fragments provides a body or
factory redirection.
Move the checks into error verification so that extension and extension
type members can participate in augmentation completion before reporting
the existing abstract-member diagnostics. Also suppress the
corresponding shared parser diagnostic when it is reported by the
verifier.
Consolidate body-related tests by declaration shape instead of by
individual diagnostic. This keeps missing bodies, external bodies,
augmentation completion, and already-complete checks side by side,
making the interaction between these rules easier to review and extend.
Move the constructorAlreadyComplete coverage from its dedicated test
file into constructor_body_test.dart, and add the factory body
completeness cases there as well. Add executable_body_test.dart for
function and member body coverage, including top-level declarations,
static members, extension members, and extension type members.
Add diagnostic definitions and fix-status entries for the new
diagnostics.
Change-Id: I9ee803c1e767ff47a608c86413ef7ffc71518cfd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503540
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This is another step toward being able to maximally convert a body of
code to using the primary_constructors features.
This CL does two things:
- Changes `convert_to_declaring_parameter` to also be a fix and applies
that fix to the `use_declaring_parameters` lint.
- Updated the `use_declaring_parameters` lint to also flag field formal
parameters.
Change-Id: I8b584186658abc73c025b166c145efbab95acd8b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/502740
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This CL adds a lint as part of the collection of lints used to automate
converting code to use the features under the primary constructors flag.
The lint flags initializers in a primary constructor body that
initialize a field in such a way that the initialization could be done
in the field declaration's initializer.
It only flags assignments to fields where the right-hand side of the
assignment includes a reference to one or more of the constructor's
parameters. Expressions that don't reference a parameter would have
been valid to move before primary constructors, so flagging them
wouldn't help find bugs in the impementation of the feature.
If we were going to ship this lint, then we might want to extend it to
find initializers that don't reference parameters, whether they are in
the primary constructor body's initializer list or in the initializer
list of a secondary constructor.
This doesn't include a fix. Once again, I wanted to make sure the lint
was covering all the important cases before implementing the lint.
Change-Id: Id4b1e02ec160af50af8f4fe7b8c675213e41abc7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/502202
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Report augmentationModifierExtra and augmentationModifierMissing when an
augmenting class or mixin does not use the same modifiers as the
introductory declaration.
Check class augmentations for abstract, base, final, interface, sealed,
and mixin modifiers. Check mixin augmentations for the base modifier.
Keep the explicit syntactic abstract modifier on class fragments
separate from the semantic abstract state in the class. This lets sealed
declarations continue to produce abstract class elements without making
their fragments appear to have an explicit abstract modifier, so
augmentation modifier checks can distinguish sealed from abstract
sealed.
Change-Id: I169e16c7b7363802d91882759550264f1c96f026
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/502183
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
The purpose of this lint is to be used with other lints to maximally
convert code to using the new features introduced by the primary
contructors feature. This one is targeted at finding container bodies
the could be replaced by a semicolon.
This CL does not include a fix. That will be added in a separate CL.
We will need to decide whether this lint is worth supporting beyond
the testing period.
Change-Id: I5d2d05117c9f1efc8c71279d5cde549eb48b480c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/502182
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This is another lint intended primarily for testing. It is intended to
flag every non-declaring formal parameter in a primary constructor that
could be converted to be a declaring parameter.
There is an existing assist to convert a non-declaring parameter to a
declaring parameter, but I want to make sure that this lint is catching
all of the right conditions before enhancing it to be a fix.
Change-Id: I10f8a4980bbc77d35a920a221ef26957f96d22d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501580
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
The purpose of this lint is to help automate testing of the primary
constructors feature. It is unlikely to be shipped in its current form.
The goal is to flag all cases where a secondary constructor could be
converted to a primary constructor. This includes classes with a default
constructor.
There is an assist that should convert most of these cases, but it has
not yet been enhanced to work as a fix. That will be done in a future
CL. I want to implement the lint first so that I know all of the
conditions that the fix needs to handle.
The most important part of this review is to ensure that the tests are
reasonably complete. If there are any missing cases where the lint
should flag a constructor for conversion, or any missing cases where a
conversion should not be requested, please let me know.
Change-Id: Ib8256677a0659479ab341974b87bd03c953ff644
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500583
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This CL enables the primary constructors feature by default in Dart 3.13.
The primary constructors feature is a brevity feature. There are no new semantics, but it allows us to express declarations in a less verbose way.
This feature allows one constructor and a set of instance variables to be specified in the header of a declaration.
Currently a declaration with a constructor and some fields is written as:
```dart
// Current syntax.
class Point {
int x;
int y;
Point(this.x, this.y);
}
```
With a primary constructor, we would write the above as:
```
class Point(var int x, var int y);
```
If a primary constructor needs an initializer list or a body, they can be
specified inside the class using the `this` body syntax:
```dart
class Point(var int x, var int y) {
this : assert(x >= 0) {
print('Point created at $x, $y');
}
}
```
As part of this feature, you can also use the `new` and `factory` keywords to
declare constructors in the class body without repeating the class name:
```dart
class Point {
int x, y;
// Equivalent to Point(this.x, this.y)
new(this.x, this.y);
// Equivalent to Point.origin()
new origin() : x = 0, y = 0;
// Equivalent to factory Point.clone(Point other)
factory clone(Point other) => Point(other.x, other.y);
}
```
To learn more about the feature, check out the feature specification located here: https://github.com/dart-lang/language/blob/main/accepted/future-releases/primary-constructors/feature-specification.md
Tested: Has existing language, CFE, analyzer, analysis server tests.
Bug: https://github.com/dart-lang/sdk/issues/61524
Change-Id: I296f2fcd918b87bf2a1dd00256340759866c2423
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489241
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Michael Thomsen <mit@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Ben Konyi <bkonyi@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>
We used thisType in invalid_runtime_check_with_js_interop_types
to ignore nullability and generics when comparing two types for
checks and casts. This is erroneous when doing a subtype check
because the distinct instantiated type arguments in each type
will lead to the two types not being subtypes of each other.
When JSExportedDartFunction and JSFunction became generic, this
became an issue because now JSFunction<T> is not a supertype of
JSExportedDartFunction<T>.
So, instead, we should always initialize the params to their
bounds when comparing types if we want to ignore generics.
Change-Id: I8418d3b87123a658fbe8a0a9379f43cba738f063
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498241
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@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>
Konstantin Shcheglov