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>
Work towards https://github.com/dart-lang/sdk/issues/59524
* avoid_private_typedef_functions - Doesn’t meet any sufficient
criteria? I think a private typedef can certainly make local code
more readable.
* one_member_abstracts - Low impact. This is maybe here for Java
developers? It encourages users to use top-level functions.
Change-Id: I829acda8af0bc2bb265553e1297cd1740761b4da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508681
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
Previously, in the `CheckSorted` presubmit check, if
`verify_sorted_test.dart` returned a nonzero exit code but none of its
output lines contained the string `Unsorted file`, then a presubmit
failure would be generated containing an empty string, resulting in
confusing output like this:
Running presubmit upload checks ...
18.4s to run CheckChangeOnUpload from /home/paulberry/dart1/sdk/pkg/_fe_analyzer_shared/PRESUBMIT.py.
** Presubmit ERRORS: 1 **
Presubmit checks took 21.4s to calculate.
There were presubmit errors.
This might happen, for example, if `verify_sorted_test.dart` contained
a compile-time error or threw an unhandled exception.
With this change, the message is `CheckSorted: could not parse output
of verify_sorted_test.dart`, followed by the full stdout and stderr
from the attempt.
This should make this sort of failure a lot easier to debug.
Note: I've made this same fix before to
`pkg/_fe_analyzer_shared/PRESUBMIT.py` (see
https://dart-review.googlesource.com/c/sdk/+/485601). I didn't realize
at the time that the code was duplicated.
Note: This should make it easier to debug
https://github.com/dart-lang/sdk/issues/63464.
Change-Id: I4892dcff7ad6969ca40564c1fd7e62e36a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506605
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@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>
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 file is no longer published and has no other value. Removing it
removes one step from the process of writing a new lint, which improves
our velocity.
Change-Id: Ie81b914bfa59aa8ec2c8fb2921eec2e9963bd601
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503620
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: 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>
Move the analyzer-only Diagnostic, DiagnosticMessage, Severity, and
locatable diagnostic helper types out of _fe_analyzer_shared and into
package:analyzer.
I paln to make changes outlined in
https://github.com/dart-lang/sdk/issues/63311 and chat discussion.
Keeping these classes in the analyzer simplifies the migration and
avoids introducing a shared abstraction before there is a concrete need
for one.
If we decide later need to have a shared abstraction, we can always
extract one at that point. With coding agents internal code motion is
cheap.
Update analyzer, analysis server plugin, analyzer plugin, linter, and
scanner call sites to import the moved APIs from analyzer libraries, and
refresh API baselines to reflect the new public owner.
Change-Id: Ie0ef0f01c6e4be7ebaac25619ac3e3fe991a44d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501000
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@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>
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>
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>
IIRC, we don't actually change the status of such lints until they can
no longer be used via a language override. Let me know if that's not
the case.
Also, if the feature doesn't ship in 3.14 then I'll need to update the
comments. Not sure whether I should commit now or wait until the flag
flip.
Change-Id: If73c6e121dfb3d6b8a72c52275dcaa9e1e994041
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498740
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Parker Lougheed