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 .
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 .
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 .
1.13 stable builds of the SDK contain a version of server that fails catastrophically when analyzing source that imports packages that define embedded libraries. Since we can't pragmatically require more recent SDKs for flutter development we have been prevented from landing embedded libs in the flutter engine. By renaming the key we use to identify contributed libraries, this change avoids the issue. Old versions of server will simply ignore the new key and new ones will process it properly. Win-win!
BUG=
R=danrubel@google.com
Review URL: https://codereview.chromium.org/1643023002 .
Paul Berry