Several final fields in SDK have not valid constant expression
initializers, which is OK because the enclosing classes don't have
constant constructors. However we were throwing exceptions and failing
building SDK summaries.
Alternatively we could just ignore final field initializers in classes
without a constant constructor. But it seems to me that we need to
catch exceptions anyway, just in case of invalid code.
R=paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/1674073002 .
There are two changes:
1. Modify `_isPeekGenericTypeParametersAndOpenParen` to call
`_skipTypeParameterList` instead of `_skipTypeArgumentList`. This
fixes parsing of generic function declarations like `f<@a T>() {}`,
which previously couldn't be parsed because `<@a T>` isn't a valid
type argument list.
2. Rename `_isLikelyParameterList` to `_isLikelyArgumentList` to
reflect how it is actually used (and what it actually does). This is
no user-visible effect.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1674043002 .
This was always the intention, but it didn't wind up getting
implemented as intended due to lack of testing. This CL adds testing
and fixes the implementation.
Note that there is no effect on resynthesis, since resynthesis only
consults LinkedReference.dependency for top level entities.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1670353002 .
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 .
I noticed it when I was in there for LUB, so I figured I'd do some
spring cleaning. Changes are:
- Consolidate duplicate code in namedParameterTypes,
normalParameterTypes, and optionalParameterTypes into a shared
_forEachParameterType() method.
- Consolidate duplicate code in isSubtypeOf() and isMoreSpecificThan()
into a shared _testTypeRelation() method that is parameterized over
the specific relation.
- Also some other small-scale changes in the relation code.
R=paulberry@google.com
Review URL: https://codereview.chromium.org/1662873002 .
This CL makes a small change to the format of the summary IDL file:
instead of containing classes with fields, it now contains classes
with getters. This allows the classes in the IDL file to be directly
used as interface classes, which makes code navigation much smoother.
Since the IDL file is now being used directly by the code, it has been
relocated to pkg/analyzer/lib/src/summary/idl.dart.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1667723002 .
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 .
Not all thrown objects in Dart derive from `Exception`; in particular,
errors such as NoSuchMethodError derive from `Error`, which is unrelated
to `Exception`. So in order for `JavaException` to work with both, its
`cause` field must have type `Object`.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1657413002 .
Now we can resynthesize a given library without having to consult any
summaries other than the linked summary for the library itself and the
unlinked summaries for all its compilation units. All other summaries
are consulted only on demand if the information in them is needed.
Tests are updated to validate this.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1653163003 .
Konstantin Shcheglov