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>
In theory discoverAvailableFiles() should wait for all possibly known
files to be discovered. But I think it is still possible to get the
set of known files changed, e.g. when are asking asynchronoiusly for
getIndex() and the user open a file that is not yet part of any driver.
Only the second hunk of the change (inside subtypes()) is required for fixing
the issue, the crucial change is toList() invocation. The switch from
_driver.knownFiles to _driver.fsState.knownFiles is done to avoid one extra
lookup for FileState.
The first hunk (inside declarations()) is done just for consistency.
Fixes https://github.com/dart-lang/sdk/issues/33412R=paulberry@google.com
Change-Id: I652ef7a156eba4bf0298c7e863dcef2b7c9f2b0e
Reviewed-on: https://dart-review.googlesource.com/60142
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: 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>
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>
We check all known files now, so we don't need looking up FileState(s)
by paths. It is expensive when we do it for thousand files in multiple
drivers.
Stopwatch is also not free, so now we check it every 100 files.
This makes _FilesReferencingNameTask about 4 times faster.
In total search of an element in a priority file is 2 times faster.
R=brianwilkerson@google.com
Change-Id: I2738df8035f84d20a8b7e1b6d3040d4461c2609d
Reviewed-on: https://dart-review.googlesource.com/58141
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This should be a non-breaking change since this is an internal
analyzer API. All clients that were making use of this internal API
have been updated to pass in the required argument.
Change-Id: Iec81454f6382c8de9ff6340d372338e678a3c73a
Reviewed-on: https://dart-review.googlesource.com/57920
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
* When iterating over folders with folderIterator we must check
elapsed time and decide to exit before we call moveNext. If we
do it in an oposite order we will skip the current element when we
come back - because we will call moveNext again.
* Only add driver.addedFiles *once* to the list of files. Previous
we were adding it everytime we called perform() leading to duplicates
in the list.
Change-Id: Idd1d2a272661fe204b24af0be4539c3a154c9652
Reviewed-on: https://dart-review.googlesource.com/57826
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Devon Carew