The problem we're seeing is that mismatches between the element model and the AST are causing exceptions to be thrown that are not being handled by the normal exception handling in AnalysisTask. This causes the exception to be converted into an AnalysisException, which will cause the AST structure to be marked as being in ERROR, and it will be re-computed later after a change invalidates it.
This also causes the exception to be thrown more frequently to prevent mismatches from being ignored (and to report the mismatch earlier).
This only checks that every node in the AST has an element associated with it. The next step (in a future CL) is to ensure that the opposite problem doesn't exist (that is, that all elements are associated with a node).
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1669383002 .
Previously, we had a special class,
ConstantEvaluationTarget_Annotation, for this purpose. It held on to
a the AST node for the annotation. This was bad because it meant that
the presence of any ConstantEvaluationTarget_Annotation referring to a
given compilation unit would keep the entire compilation unit's AST in
memory.
Now we copy just the portions of the AST we need into
ElementAnnotation, just as we do for all other constant evaluation
targets. In addition to saving memory, this paves the way for
supporting annotations in summaries, by making it possible to compute
the constant value of an annotation without having to consult the full
AST.
Fixes#25285.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1665353002 .
This is a prerequisite to fixing #25285
(ConstantEvaluationTarget_Annotation consumes too much memory,
shouldn't exist). By creating the ElementAnnotation objects early, we
will be able to refer to them from the ConstantFinder; this will allow
us to use the ElementAnnotation objects as constant evaluation
targets.
Note: there is a small semantic change. Previously, Element.metadata
only contained ElementAnnotation objects for annotations that were
successfully resolved. Now, it contains ElementAnnotation objects for
all annotations.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1668483003 .
This reverts commit 3977c9f227.
The aforementioned commit broke co19 tests involving annotated `part of`
directives. It turns out that we can't create the ElementAnnotation
objects for annotated `part of` declarations in
BuildDirectiveElementsTask, because BuildDirectiveElementsTask is only
ever targeted at libraries, therefore it only creates ElementAnnotation
objects for annotated directives in defining compilation units.
I will follow up with a CL that builds all the ElementAnnotation objects
in BuildCompilationUnitElementTask, which runs on all compilation units.
TBR=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1665683002 .
Moving an element that's in the AnalysisCache causes
it to leak because operator== and hashCode are based
on its location.
To make sure we detect this, added a "frozen" flag to
Element. It's set when the element is used as a key
in the AnalysisCache.
Cleanup: in IncrementalResolver, make all fields
final that are never changed.
BUG=
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1650873002 .
This is a prerequisite to fixing #25285
(ConstantEvaluationTarget_Annotation consumes too much memory,
shouldn't exist). By creating the ElementAnnotation objects early, we
will be able to refer to them from the ConstantFinder; this will allow
us to use the ElementAnnotation objects as constant evaluation
targets.
Note: there is a small semantic change. Previously, Element.metadata
only contained ElementAnnotation objects for annotations that were
successfully resolved. Now, it contains ElementAnnotation objects for
all annotations.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1660713002 .
Previously, we would precompute the value of ClassElement.isValidMixin
and store it in the Modifier.MIXIN. But this didn't really save any
time, because (a) isValidMixin isn't used inside analyzer, and (b) it
is easily derivable from other information already present in the
element model.
Also, we were computing it incorrectly when the `--supermixin` flag
was present.
This CL replaces the precomputation logic with a direct implementation
in ClassElement.isValidMixin which is correct regardless of the
presence of the `--supermixin` flag. The tests are beefed up so that
(a) they validate correct behavior for both states of the flag, (b)
they validate correct behavior in the presence of factory
constructors, and (c) they validate that the behavior of
`isValidMixin` is consistent with the error messages produced by the
analyzer.
In addition to fixing bugs, the removal of Modifier.MIXIN means we
have one less piece of information to store in summaries.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1635063003 .
Brian Wilkerson