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>
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>
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>
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>
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>
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>
Add `ClassBody.members` and `EnumBody.constants`/`members` so callers
can access class and enum contents through the common body interfaces
instead of pattern matching on `BlockClassBody` and `BlockEnumBody`.
Implement empty node lists for empty class and enum bodies, update the
public API, and migrate analyzer, analysis_server, analyzer_plugin, and
linter code to use the new accessors directly. This removes the ad hoc
`members2` helper extensions and a large amount of repeated `tryCast`
and `switch` logic, making body traversal more uniform.
Change-Id: I51d75f2253c7e6f75efecae84bf0443ff5eb6788
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/488263
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This CL adds support for anonymous block bodies (as in `e.{...}`) by
generalizing the flow analysis to handle begin/end of anonymous block
bodies and treating them similarly to labeled statements (and treating
`return` statements using `handleBreak`). It generalizes `handleBreak`
and the internal make `_StatementToContext` to handle `Node` keys rather
than just `Statement` keys, such that an anonymous block body can be the
context. It adds a `bodyContext` instance variable to
`AnonymousBodyImpl` to be used during flow analysis of anonymous block
bodies. `BodyInferenceContext` gets a new factory constructor in order
to allow an anonymous block body to be the context. Finally,
`ErrorVerifier` is generalized to handle the case where a return
statement is returning from an anonymous block body.
Change-Id: I04bc3c852611dbefb885afce655dc00054709fb7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482786
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
DottedName previously exposed only a list of identifier components, so
the resulting string had to be reconstructed (e.g. by inserting periods)
and could lose the original token stream produced by the parser and
recovery.
Introduce an opt-in, token-based representation:
- Add `DottedName.tokens` containing the full token sequence (including '.').
- Add `useDottedNameInLibraryDirective` to let clients opt into the new shape.
- When the flag is enabled, route `library` / `part of` names through
`DottedName` (`name2` / `libraryName2`) instead of `LibraryIdentifier`.
- Update unlinked/summary serialization and builders to derive names from the
token stream when opted in, keeping offsets and lengths consistent.
- Extend the AST generator to support flag-guarded properties so the migration
can be staged without breaking existing clients.
Fixes: dart-lang/sdk#62819
Bug: https://github.com/dart-lang/sdk/issues/62819
Change-Id: Ibd9eab8919313765b321f464726ffd4c84dd6cb3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/485360
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Adds the modifiers `abstract`, `base`, `final`, and `interface` to the
API summary output.
This information is an important part of the public API of a package,
because it determines whether a client can:
- Construct an instance of the class,
- Extend the class, or
- Implement the class.
Change-Id: I6a6a6964ba07db1714bc2fcb549cc15230e87058
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482362
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fixes two minor bugs with the sorting of members in the API summary
tool:
- The technique for placing getters next to their corresponding
setters was to sort them lexicographically based on
`Element.apiName`, which in the case of setters appends `=`. This
mostly worked, but due to the fact that `=` is between `9` and `A`
in ASCII, it was wrong in a few corner cases. For example, it would
sort `x`, `x=`, `x1`, and `x1=` in the order `x`, `x1`, `x1=`,
`x=`. Fixing this didn't affect any `api.txt` files in practice.
- The technique for sorting constructors also used `Element.apiName`,
which in the case of an unnamed constructor is `new`. This meant
that if a class had both named and unnamed constructors, the unnamed
constructor would not always be sorted before the other
constructors.
The fix for both bugs is to sort by `Element.name` (which does not add
`=` for setters and is the empty string for unnamed constructors), and
then to break ties by explicitly checking whether the element is a
setter.
Change-Id: I6a6a69648fb5915266a9111c5d884531bba4405d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482361
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL adds some elements of the implementation of anonymous methods:
- _fe.../messages.yaml: Add error message about wrong parameter list.
- analysis_server/.../error_fix_status.yaml: Add status of above error.
- analyzer/.../src/.../ast.dart: Add new AST classes AnonymousArrowBody
AnonymousBlockBody, AnonymousMethodBody, AnonymousMethodInvocation.
- analyzer/.../to_source_visitor.dart: Add new `visit` methods.
- analyzer/.../ast_builder.dart: add `endAnonymousMethodInvocation`.
- analyzer/.../resolver.dart: add new `visit` methods.
Change-Id: Ifa562c653f608884319ad9a1d87e169d9fac4b75
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/475043
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Previously, the AST builder enforced strict constraints on extension
type primary constructors during parsing, often discarding or
transforming invalid parameters (e.g., multiple, optional, or named
parameters) to force a valid representation field structure. This
limited recovery and resulted in inaccurate element models for invalid
code.
This change updates the AST builder to parse and build elements for the
primary constructor's formal parameters exactly as written. The
validation logic ensuring a single, positional representation field has
been moved to `ErrorVerifier`.
To maintain the invariant that an extension type has a representation, a
synthetic "recovery" representation field is now added to the element
model if the parsed parameters do not provide a valid one.
Bug: https://github.com/dart-lang/sdk/issues/61701
Change-Id: I37b7eaf2c085db6317b2c2b0bf35ff31423f9738
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465180
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Deprecates `DiagnosticCode.name` and
`diagnosticCode.uniqueName`. Clients should use
`DiagnosticCode.lowerCaseName` and
`DiagnosticCode.lowerCaseUniqueName` instead. This will ensure that
clients will compare diagnostic codes in case-insensitive fashion, as
the analyzer itself does.
In a future breaking change release of the analyzer, I will remove the
deprecated getters.
Change-Id: I6a6a69642f2d386546406d4af734808afec13e5e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468080
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This will allow diagnostic reporting code in the analyzer to be more
easily converted to the new literate diagnostic reporting API, because
it will make it possible to use `SourceRange` as the common
denominator for situations where the location where a diagnostic needs
to be reported might come from either a `SyntacticEntity` or a
`SourceRange`.
Change-Id: I6a6a6964f3ec2ea33e8900d93b5abe714c9e1dcc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467682
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Adds the getters `lowerCaseName` and `lowerCaseUniqueName` to the
`DiagnosticCode` class. These getters behave the same as the `name`
and `uniqueName` getters, except that they convert the string to lower
case before returning. These getters should help make it easier for
the analyzer and related packages (as well as analyzer clients) to
treat diagnostic codes in a case-insensitive fashion.
In follow-up CLs, I plan to switch the analyzer and related packages
over to using the new getters, and then I'll deprecate and eventually
remove `name` and `uniqueName` from the analyzer public API.
Change-Id: I6a6a6964e8891fc6f74a9777eae375f1a553c2f3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/466182
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Konstantin Shcheglov