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>
Move another batch of analyzer tests away from offset-based
assertErrorsInCode() expectations. Put expected diagnostics and context
messages directly in the source snippets instead, including multi-file
cases that need context markers in supporting files.
This keeps each diagnostic expectation next to the code that produces
it, making the tests easier to read and less fragile when surrounding
code changes. It also removes now-unused diagnostic imports and helper
parameters that were only needed for explicit ExpectedDiagnostic lists.
Update the diagnostic expectation utilities so stripping generated
marker lines preserves the retained source lines correctly.
Change-Id: Ibe3890b9ff5e2b2e102e13e5ecc243bdf80c5f4b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509682
Reviewed-by: Johnni Winther <johnniwinther@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>
Replace ad hoc assertions over DartObjectImpl with
assertDartObjectText() in constant evaluation and resolution tests. This
makes the expected constant value shape explicit, including invalid
results, variables, constructor invocations, type arguments, and
superclass fields, instead of checking only selected fields.
Use raw multi-line strings for these expectations so expected text can
be copied and maintained consistently without escaping interpolation or
other Dart string syntax.
Remove the now-unused null assertion helper and analyzer implementation
imports that were only needed by the direct assertions.
Change-Id: Ib734c1d428dd69104403484534b60af918944d13
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508705
Reviewed-by: Paul Berry <paulberry@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>
Konstantin Shcheglov