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>
Note, that we remove getResolvedUnitObject() and replace it with
normal getIndex(). I think it was done initially this way because we
initiate sending implemented notification when analysis is finished
in analysis server. So, to avoid analysis-fisnished, send-implemented,
do-analysis, analysis-finished, send-implemented infinite sequence.
But getIndex() does not mark AnalysisDriver as requiring analysis.
So, we don't get infinite sequence of events.
R=brianwilkerson@google.com
Change-Id: Ibaf5be5c7a33edb938bd1a4670811dc200dee522
Reviewed-on: https://dart-review.googlesource.com/59500
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Previously, all FunctionTypeImpl objects needed to be associated with
an element in the element model, and the set of free type variables in
those types had to correspond to types declared in enclosing scopes.
This created problems because there are several instances during type
inference where the analyzer needs to create a synthetic function
type, and it can't easily associate it with an existing element.
Also, when the analyzer is integrated with the common front end, we
will need the ability to represent function types that aren't
associated with elements, since that's how function types are
represented in the common front end.
The new kind of FunctionTypeImpl is implemented by
_FunctionTypeImplStrict; the old behavior is implemented by
_FunctionTypeImplLazy.
Fixes#33159.
Change-Id: I17e5fef1e59837728faf5265b8b722a7afadfbf4
Reviewed-on: https://dart-review.googlesource.com/59160
Reviewed-by: Jenny Messerly <jmesserly@google.com>
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>
Part of #30384. This was usually not a problem as most cases involve
additional visitors which rewrite this (for instance, inference).
However, in some cases (appears to be summaries only), that extra
resolution is not needed/skipped, so the non-instantiated constructors
remain.
That makes the constantValue of annotations vulnerable to this, and the
resulting DartObject types will have 'TypeParameterType's for there
typeArguments.
Instantiate the types to bounds, and get the ctor from the type rather
than the element, inside of AstRewriter in order to ensure these
constructors are instantiated.
Change-Id: I65f55feb751e139e68c774786bfbc53788d32995
Reviewed-on: https://dart-review.googlesource.com/58800
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Previously, FunctionTypeImpl.elementWithNameAndArgs was used for two
purposes: (1) when creating a FunctionTypeImpl for an executable
element, to initialize _typeArguments to the types of the type
parameters that are in scope, and (2) when creating a FunctionTypeImpl
for a typedef, to supply the type arguments necessary to instantiate
the typedef. (1) turns out to be unnecessary, since the
FunctionTypeImpl.typeArguments getter automatically gathers type
arguments from enclosing elements if necessary, and (2) makes more
sense to do as part of the .forTypedef constructor. So this CL
removes FunctionTypeImpl.elementWithNameAndArgs and updates its
callers to use the unnamed constructor or the .forTypedef constructor,
as appropriate.
Also, a check is added to make sure that the unnamed constructor is
never accidentally used for typedefs. So now FunctionTypeImpl has
just three public constructors, each with a clear use case, enforced
either by an assertion or by the type system:
- The unnamed constructor (for executable elements, not typedefs)
- The .forTypedef constructor (for typedefs only)
- The .fresh constructor (for creating one FunctionTypeImpl from
another by binding fresh type parameters)
Finally, the public constructors for FunctionTypeImpl are all changed
to factories so that client code can't inadvertently FunctionTypeImpl.
(It shouldn't anyway, since FunctionTypeImpl is defined inside src/,
but this gives an extra level of safety).
Change-Id: I5f7abc1ca114eb612cbf539c1d61fc0cace5a4dd
Reviewed-on: https://dart-review.googlesource.com/58043
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Correctly typed as far as old mockito is concerned because it does not
check types. With this fixed we'll be clear to upgrade mockito inside
the SDK to the one that does.
Change-Id: If68c0bb02c8652be6b891c189fabee135423f94c
Reviewed-on: https://dart-review.googlesource.com/57712
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
I am about to start embarking on bug fixes and refactors to
FunctionType, so I want a set of tests that I can use to make sure I
don't break any important behaviors. These tests use a mock element
model, so they don't rely on any behaviors outside of FunctionTypeImpl
itself.
Change-Id: I037f6a8cd2ee2a94fba13bb9b6be9e7090e254e8
Reviewed-on: https://dart-review.googlesource.com/57708
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Brian Wilkerson