It's not the main problem we observe during pkg/analysis_server/test/operation/operation_test, but I still saw it.
The actual fix is removing "unary-".
The other change is just for performance.
It is much cheaper to compare int(s) than to compute (for methods) 'displayName'.
Maybe we should go as far as removing the name check altogether and use just element kind.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org//1149083007
Modifier.TYPEDEF was redundant with Modifier.MIXIN_APPLICATION and
ClassElement.isTypedef was redundant with
ClassElement.isMixinApplication.
Since Modifier.TYPEDEF was private to analyzer, it has been
eliminated. Since ClassElement.isTypedef is part of the public API to
analyzer, it is retained, but with a "@deprecated" annotation.
R=scheglov@google.com
Review URL: https://codereview.chromium.org//1158193008
This is a re-fix of dartbug.com/21912, which I previously fixed
incorrectly. Previously, our approach to avoiding infinite loops when
comparing types was to maintain a set of typedefs being expanded on
the stack, and prune the comparison whenever an attempt was made to
expand a typedef that was already being expanded. However, this was
too strict, since there are legal (non-circular) types which invole
expanding a given typedef in reentrant fashion; we can't prune these
types without producing incorrect semantics. An example (from the bug
report) is the type of f in the code below:
typedef T Function2<S, T>(S z);
Function2<Function2<A, B>, Function2<B, A>> f;
The solution is to maintain the list of typedefs being expanded inside
each FunctionTypeImpl object (and InterfaceTypeImpl object) rather
than on the stack during the comparison; this allows us to distinguish
the situations where we need to prune (those having to do exclusively
with expansion of a typedef) from the situations where we shouldn't
prune (those having to do with substitution of a type parameter).
A beneficial side effect of this change is that code that interacts
with types no longer needs to worry about typedef circularities, since
the circularities will automatically be pruned while exploring the
type definitions. This simplifies the implementation of
isAssignableTo, isSubtypeOf, operator==, and hashCode. (Note,
however, that code still needs to cope with circularities in the
inheritance hierarchy).
BUG=dartbug.com/21912
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1143003007
It is on the couple critical paths:
1. getErrors()
2. SearchEngine.
The SearchEngine is used in both search itself and by completion.
Without this change search has n^2 complexity, where `n` is the number of targets.
Statistics for search shows more than 10x performance improvement.
Before: 70 ms (analyzer), 230 ms (analyzer + dart2js).
After: 6 ms (analyzer), 17 ms (analyzer + dart2js).
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org//1152773002
This is not ideal, we might still want to start managing 'containingLibraries' at some point.
But it speeds up switching between file 10x - DartCompletionCache request of all top-level elements takes now about 170 ms, vs. 1800 ms before.
Also, we need "sources" in many places of AnalysisContext.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org//1149893004
We need to be more careful about this in the new task model, since the
new task model is more aggressive about chasing dependencies, and we
don't want constant evaluation to try to visit a non-const
constructor.
R=scheglov@google.com
Review URL: https://codereview.chromium.org//1145913002
Tasks may now override the getter "handlesDependencyCycles" to return
true to indicate that they can deal with circular dependencies. Most
tasks will not have to do this, since outside of constant evaluation
circular dependencies among tasks should only be possible due to an
analyzer bug.
Any task that handles dependency cycles can detect that a cycle has
occurred by consulting AnalysisTask.dependencyCycle inside its
internalPerform() method. The ComputeConstantValueTask uses this to
determine which constants are involved in the cycle.
This required modifying the TaskInputBuilder classes so that if the
current input can't be evaluated due to a circularity, they can
continue on to evaluate other inputs. This allows the circularity to
be reported on the whole strongly connected component, rather than
just the firs cycle that was noticed (which would be
nondeterministic).
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org//1147853002
With the current constant evaluator, the bug is benign because we only
do dependency analysis within a library cycle, and the library cycle
containing dart:core (which is the only library cycle with const
external factories) contains no invocations of those const external
factories.
But in the new task model we do full dependency analysis across
library cycles, so the dependency analysis needs to be correct in
order for the const external factory to be safely invoked.
R=scheglov@google.com
Review URL: https://codereview.chromium.org//1134343003
It works in general, bug currently it is buggy and slow.
Notes:
1. Implicit dependencies backfire.
If the cache size is not big enough and we end up flushing some CU, then recreating it, it looses its LibraryElement.
We need an explicit dependency on it.
2. If the cache size is not big enough, this still may cause an infinite analysis cycle.
3. We need to implement activating / deactivating cache partitions to change cache size.
4. Probably we need to set LineInfo into ChangeNotice always.
5. There are bugs in type hierarchy.
6. Semantic highlighting takes too long to display.
7. Overlay changes are not used.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org//1125303008
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@45811 260f80e4-7a28-3924-810f-c04153c831b5
Konstantin Shcheglov