IntelliJ sends us the file and offset of the declaration of the element,
not the file and offset where the element is referenced (and where the
user actually requested search). It uses navigation information to do
this. Unfortunately this means that in the most case the unit that
defines the element is not a priority one, so we have to resolse it
from scratch. But we know that we are always given the name offset,
so we can look first into the element model and avoid performing
expensive unit resolution.
If the search is not successful, or the file is a priority one,
we use resolved unit anyway.
R=brianwilkerson@google.com
Change-Id: Ic6a32d3d8f9e61b245b1dd9f7fdf626c809f5fd5
Reviewed-on: https://dart-review.googlesource.com/58322
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@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>
The test times out, because we don't get any answer on our getNavigation().
Technically this happens because we dispose the corresponding instance
of AnalysisDriver, so it is removed from the AnalysisDriverScheduler,
and getResult() never completes.
Which, I think makes sense.
Once the analysis root is removed, the client cannot expect answers.
So, there is no need for the test.
R=brianwilkerson@google.com
Change-Id: I124ac3d6a4a903880c7b8f82cafe692b38c59017
Reviewed-on: https://dart-review.googlesource.com/57903
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
The abstract class TypeInferenceEngineImpl does not really serve any
purpose, so remove it. If nothing else, it makes it easier to
understand what is going on and change things.
Change-Id: I9aabcb041b3fbc7d5b7b63dfef9effeb73a6bab8
Reviewed-on: https://dart-review.googlesource.com/57822
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Kevin Millikin <kmillikin@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>
substitute4 was only used by the kernel resynthesizer, which is not
being maintained at the moment (and which I believe needs to be
reworked anyhow). With substitute4 gone, _explicitTypeParameters was
always null (except in the case of CircularFunctionTypeImpl, where it
had no effect), so we can just replace it with literal `null`.
Change-Id: I5248e0f93b9a39c55d3e4e8b62150536656608e8
Reviewed-on: https://dart-review.googlesource.com/57709
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Konstantin Shcheglov