Path exclusions should ideally be defined inside a project's
`analysis_options.yaml` file, rather than being added programatically.
Plus, there's a bug with the constructor that causes this parameter to
be completely ignored anyways, so it's been obsolete and non-functional
for a while now. `getExcludedGlobs` in the `_ContextLocator` handles
parsing and adding excluded paths from the analysis server already, so
we should look into deprecating and removing this parameter.
Change-Id: I6c023041c7bb5fa4cb9dedc629afa4ea6ecb63d7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/511160
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
For clients outside the library the useful property in
`FormalParameterElement.type`, not *how* this type was specified
syntactically: `void f(int a<T>())` vs. `void f(int Function<T>() a)`.
This way, we have to think about these type parameters and formal
parameters only locally, like for example about local variables - they
exist, enclosed in a fragment, but don't leak outside into the element
model of a method.
I found this while working on the augmentations: that formal parameters
have to have the same types in the introductory declaration, and in
augmentations.
Change-Id: Ie4e92ebd0cd0204c4ba80200a9497e95859cc3e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509522
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Do not expose recovery type parameter and formal parameter elements
through the public element model. Recovery fragments are still needed
internally to link augmentation chains with mismatched shapes, but they
should not change the effective arity or callable signature of the
declaration being augmented.
Filter fragments marked as originating from another enclosing fragment
when computing executable formal parameters, executable type parameters,
and instance type parameters. This keeps function types, class arity,
and constructor or method signatures based on the real declaration
rather than on synthetic recovery elements introduced for invalid
augmentations.
Change-Id: I455a8a18bc07cdae30006754e069d687659aab1d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510182
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@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>
The analyzer makes a copy of `lineStarts` without the last element,
and copying it in to a `Uint16List` or an `Uint32List` depending on
what's needed (to avoid using more ram than necessary).
Because the (actual) scanner (`AbstractScanner`) does the same trick
with `Uint16List`/`Uint32List` the linestarts output from the scanner,
while a `List<int>`, is actually a `LineStarts` class, and copying that
into a `Uint16List` (or `Uint32List`) goes into
`_TypedIntListMixin._SlowSetRange` which as the name suggests is slower
than it has to be.
This CL puts the copying into the `LineStarts` class where it actually
has a `Uint16List`/`Uint32List` already, and doing the copy from that
instead avoids the slowdown.
Numbers from `perf stat`:
Before:
```
39,552,191,101 instructions:u
39,552,058,132 instructions:u
39,552,065,649 instructions:u
```
After:
```
39,419,426,977 instructions:u
39,419,429,914 instructions:u
39,419,441,613 instructions:u
```
Saving: about 132 million instructions.
Change-Id: Ibf6c7f6cc9324a54d2bd99c37058103af106164c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508580
Reviewed-by: Johnni Winther <johnniwinther@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>
Replace the local marker-based _AstTest helper in ast_test.dart with
ParserDiagnosticsTest parsing and the shared findNode utilities. This
keeps the tests aligned with the inline diagnostics style used by other
parser tests, and avoids a second way to locate AST nodes from marked
source snippets.
Update the affected tests to parse normal source text, then locate the
expected node through findNode single-node accessors. Add a
singleConstructorName accessor so constructor-name tests can use the
same shared lookup path.
Change-Id: Ib8c7c2e7c2c1b320c95810ce148b5a27e68dda43
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508421
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Report direct recursive interface inheritance diagnostics on the
inheritance clause that introduces the cycle, rather than on the class
or mixin name. This gives a more precise target for self-references in
extends, implements, on, and with clauses.
Track recursive inheritance reporting per interface element across
fragments so that augmentation clauses can produce the specific
diagnostic when they introduce the cycle. Defer the generic cycle
diagnostic while earlier fragments still have later augmentations to
inspect, and use the element target as the fallback location for
indirect cycles.
Update diagnostic expectations to match the new locations and cover
augmentation and part-file cases for recursive extends, implements, on,
and with clauses.
Change-Id: I480a56e4b766d704c290d67d9ca4f6a73a2f655b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507300
Reviewed-by: Paul Berry <paulberry@google.com>
Constructor parameters that were only referenced by a `super` parameter
in a primary constructor were being flagged as being unused because the
`super` parameter wasn't being visited. This CL causes all `super`
parameters to be visited.
Change-Id: Iad6eee87b3b74a387d86e783e3bb35300a801c12
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507262
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Auto-Submit: 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>
Move the remaining AstBuilderTest coverage out of the Fasta test
directory and into the corresponding parser test files under
test/src/dart/parser.
Place the migrated cases with the syntax they exercise, including class,
enum, mixin, extension, doc comment, record literal, record type
annotation, library directive, dot shorthand, and switch statement
coverage. Register the new parser test files in the parser test suite
and remove the deleted AstBuilderTest from the Fasta suite.
Add a find_node helper for locating a single RecordTypeAnnotation so the
migrated record type tests can use the same node lookup style as the
other parser tests.
Change-Id: I57370d161142ffa160c1a5e3972ffc25f3616d6d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505060
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Update generated AST node metadata and token ordering so child entities,
begin tokens, and reconstructed source follow the grammar order for
modifier tokens.
Place `augment` before declaration modifiers on class type aliases and
the affected top-level and class-level declarations. Order field
modifiers as `augment external static abstract covariant`, and order
named formal parameter modifiers as `required covariant`.
Also emit the missing modifier tokens in `ToSourceVisitor` so source
reconstruction preserves augmentation syntax and the canonical modifier
order.
Change-Id: I57b4aa05f856779526bc3c8d5e3319d8c260bc49
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/504682
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Report a dedicated diagnostic when an augmenting field or top-level
variable induces a getter whose return type differs from the getter
being augmented.
Previously, augmentation return type checking only covered executable
declarations with explicit return type annotations. Variable
augmentations that induced getters could therefore miss this mismatch,
or would not describe the induced getter case directly.
Add the new diagnostic code and use it for getter fragments induced by
variables. Keep the existing augmentation return type mismatch
diagnostic for methods and explicitly declared getters, and report the
induced getter diagnostic on the variable name so that mismatches in
multi-variable declarations are attributed to the specific variable.
Change-Id: Ifb421112d659815070110834702f68616e360a10
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/504181
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Add diagnostics for augmenting fields and top-level variables when the
augmentation induces an accessor that has no corresponding declaration
to augment.
Report these errors on each variable name rather than on the augment
keyword, so multi-variable declarations can report missing augmentation
targets independently. Include context pointing to the matching declared
or induced accessor when only one side of the getter/setter pair exists.
Register the getter- and setter-specific diagnostics in the generated
diagnostic tables and correction status metadata.
Change-Id: I78393a6e8bffe8748eb0fbc5182a0d01770771d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/504180
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Property-inducing augmentations were linked to the existing field or
top-level variable element before creating the getter and setter
fragments that the augmentation itself induces. This left augmentation
fragments without their corresponding accessor fragments.
Create induced getter and setter fragments for every field and top-level
variable fragment, including augmentations. When an accessor element
already exists, append the new fragment to it; otherwise, create the
accessor element independently so that augmenting getter-only and
setter-only properties works correctly.
Track the relationship at the fragment level in both directions, from
each property-inducing fragment to its induced accessors and from each
accessor fragment back to its inducing variable. Serialize these links
in summaries, expose them through the analyzer element API, and bump the
summary data version for the format change.
Change-Id: Iede43515564326182d8195bd872abf83345bbd72
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/504040
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
It is disabled when augmentations feature is enabled.
This is not a breaking change, because CFE did report this error.
The relevant reason is indirect, not a single sentence saying “on A
implements A is forbidden”.
Spec chain:
1. In dartLangSpec.tex:6019, a mixin declaration is modeled as:
`mixin N<T...> on T1, ..., Tn implements I1, ..., Ik { ... }`
2. In dartLangSpec.tex:6065, the mixin interface M_I is defined as if
by:
`abstract class N<T...> implements T1, ..., Tn, I1, ..., Ik { ... }`
and dartLangSpec.tex:6078 says it is a compile-time error for the mixin
if that synthetic class declaration would be a compile-time error.
3. In dartLangSpec.tex:5189, class superinterfaces say:
It is a compile-time error if two elements in the type list of the
IMPLEMENTS clause of a class C specifies the same type T.
So:
`mixin M on A implements A {}`
is checked like:
`abstract class M implements A, A {}`
which violates the duplicate implements type rule.
Change-Id: I29e5fa17c47d111346ef6a6e321ab5dbab985ad1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503501
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Konstantin Shcheglov