When a local function is generic, the front end gives us a type for it
that has fresh type parameters. We need to map those type parameters
to the type parameters at the local declaration site.
Change-Id: I3d44dcacb9d627cbe8fa41405581ef717ed1bd03
Reviewed-on: https://dart-review.googlesource.com/62665
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Currently a typedef is represented by two elements: an "outer" element
that points to the typedef and has type GenericTypeAliasElementImpl,
and an "inner" element that points to the RHS of the typedef and has
type GenericFunctionTypeElementImpl. GenericTypeAliasElementImpl.type
is never used and handles generic parameters incorrectly;
GenericFunctionTypeElementImpl.type should always be used instead.
I plan to clean all this up as part of #33641, but this CL is
sufficient to get tests passing.
Change-Id: Ib2d9af9294f4f9d94bfbbeff9aaae711f8cdad1d
Reviewed-on: https://dart-review.googlesource.com/62540
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
I broke this functionality when I refactored FunctionTypeImpl into
lazy and strict variants; this CL restores it and simplifies it.
This CL also adds a new method to the analyzer API:
FunctionTypeAliasElement.instantiate(), to allow a client to supply
type arguments to a typedef (as one would at a site where the typedef
is used), to produce a type. Putting the method in
FunctionTypeAliasElement helps move us toward an API that
distinguishes type "constructors" from types (a generic typedef
defines not just one type but a family of types; to obtain a type one
must instantiate the typedef by supplying type arguments).
Change-Id: I722db2befe2d54fd53d625ddba0dec856a555a7b
Reviewed-on: https://dart-review.googlesource.com/62282
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This fixes another crash in the fasta parser
and improves the way it recovers when parsing type parameters
before a map or list literal.
Change-Id: Ic02513b98a31e9ed3f59c8391c260a2a214983ae
Reviewed-on: https://dart-review.googlesource.com/62340
Commit-Queue: Dan Rubel <danrubel@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
There is a seeming parse error in typedefs, and an open question on the
issue (33343) about what to do when a generic function type is inferred.
Otherwise this seems ready to go.
Bug: 33343
Change-Id: I10d2ea9b6ca26ed2c6ff6b24ffe5008fc4797ef2
Reviewed-on: https://dart-review.googlesource.com/61109
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Does not handle the other half of #33343, rejecting generic function
types as type arguments.
This revealed a secondary minor issue which was easy enough to fix. Type
arguments were not resolved within bounds:
class C<T extends S Function<S>(S)> {}
this would report 'undefined class S' for the return and parameter types
`S`. I almost split this into a separate CL, but, these two CLs are tied
together inherently by the tests case. Easy to solve at once.
Bug: 33343
Change-Id: Ib34a04d90be08d8d6c6f21a9d485a452017585ba
Reviewed-on: https://dart-review.googlesource.com/61103
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
As of this CL, events for type variable declarations occur
in the following order:
* beginTypeVariables
* beginTypeVariable for each type variable in the declaration
* handleTypeVariablesDefined
* endTypeVariable for eah type variable in the declaration
* endTypeVariables
Revising the order of events facilitate removing the hack
in BodyBuilder.beginTypeVariables in a future CL.
This is another slice of https://dart-review.googlesource.com/c/sdk/+/57661
so that it can be landed in a more incremental fashion.
Change-Id: Ief0ad766c12f1ca9d53a8ec8d3c08b41166b2897
Reviewed-on: https://dart-review.googlesource.com/61940
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
This will allow us later switch from applying resolution to parsed
AST to directly generating resolved AST, when we get to this.
New failing tests are because of absence of annotations, constant
values (initializers, default values), and constructor initializers
in outlines.
We also don't get errors for constant value computing, hence some
tests are now passing, but not by the reason we intended to test.
R=brianwilkerson@google.com, paulberry@google.com
Change-Id: I5b45da592563af02c45e8cda160ccd24487c3591
Reviewed-on: https://dart-review.googlesource.com/61743
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
We are pivoting our implementation of FE/Analyzer integration a little
bit, and so the BodyBuilder will not be parameterized in exactly the
same way. Remove the existing parameterization from it and all the
supporting classes. This requires specializing the BodyBuilder to the
front end's instantiation of it and deleting the corresponding code in
the Analyzer.
Fixes https://github.com/dart-lang/sdk/issues/33503
Change-Id: I3ddcd2c5f5ebd8f2ff95f2ec8d4c7b98b70a0b0a
Reviewed-on: https://dart-review.googlesource.com/61502
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
This gets the tests running again. I'll follow this up with CLs that
reshape the ResolutionStorer API to match the Factory API we're
building, and then after that we can transition the code over to
calling the Factory API directly.
Fixes#33504Fixes#32258
Change-Id: I105841ed5b2ed1198ec5e3e7387f694c61d36ca7
Reviewed-on: https://dart-review.googlesource.com/61101
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This addresses one of the root causes of #33304. Note that when a
constant list or map is recorded in a summary, we don't encode enough
information in the summary to resynthesize its inferred type
correctly, so this only fixes cases where the constant is used in the
same build unit as its declaration.
Change-Id: Id0034f481cb82f18c77bbe2ee8ebec7e8b244caa
Reviewed-on: https://dart-review.googlesource.com/60203
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The static type of invocations of methods from class Object on
receivers with static type dynamic has changed. Clean up a pair of
analyzer tests that expected the previous behavior and were expected
to fail because the analyzer already implemented the intended
behavior.
Change-Id: I7a65fa4e46a0da51bcf1c183a7c30f0976baaef5
Reviewed-on: https://dart-review.googlesource.com/58205
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
danrubel