When we generate SDK summary using AST (just for testing) we find code
like this:
class _SimpleCallbackSink<T> extends ChunkedConversionSink<T> {
final _ChunkedConversionCallback<List<T>> _callback;
final List<T> _accumulated = <T>[];
_SimpleCallbackSink(this._callback);
void add(T chunk) { _accumulated.add(chunk); }
void close() { _callback(_accumulated); }
}
It is not a valid constant, but we don't know this on AST level.
We could probably detect this, but I guess we would need to serialize
a wider set of expressions for type propagatation / inference anyway,
so it is better to serialize than to fail in this case.
R=paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/1841603003 .
This CL makes the following fixes:
- Handles the case where a constant makes an explicit reference to a
type.
- Handles references to top level names defined in imported libraries.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1839663003 .
We now detect constant cycles involving:
- Named constructors.
- Generic classes. (Note: we don't track the type arguments of
generic classes yet, because that's unnecessary for detecting
constant constructor cycles).
- References to top level constant variables and constant fields.
- Final fields in constant classes.
- Implicit calls to "super".
Also, we properly handle constants that refer to fields of an enum
class.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1832393002 .
This CL fixes:
- Computation of the public namespace when there are enums (previously
we weren't including enum values in the public namespace).
- Prelinking of references to enum values from constants.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1841433002 .
This CL adds a summary "linker", which wil be capable of taking the
output of the prelinker and adding the information that potentially
requires traversing transitive dependencies (propagated and inferred
types, and constant constructor cycles). When this is finished we
should be able to generate summaries straight from ASTs without
building a full element model in the interim.
The basic technique is to build a miniature element model, on demand,
which is discarded when linking is finished. Since the miniature
element model is only for a single purpose, it can be much more
compact than the full element model. Since it is thrown away after
linking, it can avoid the expensive dependency tracking that would be
necessary in order to keep the data structure up to date when there
are code changes.
So far I've built the basic infrastructure and started implementing
constant constructor cycle detection. Areas that still need to be
filled out are indicated by TODO comments.
Since the linker only has access to the UnlinkedUnit objects (not the
ASTs), it will be necessary to add a small amount of information to to
the UnlinkedUnits to record the information needed by type inference.
I'm hoping that it will be possible to adapt the existing
UnlinkedConst data structure for this purpose.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1828543009 .
Instead of a very slow .inDeclarationContext() method which determines
whether a given identifier is in a use position or not, we just create
a different subclass at parse time that encodes that fact directly.
Also, remove an unnecessary _validateElement() method.
On my Mac laptop, this takes benchmark/errors_in_all_libraries.dart
From: 0:00:05.673849
To: 0:00:05.193563 (91.53%)
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1833573006 .
Paul Berry