This CL makes the following changes:
- Renames _FbInt32List to _FbGenericList, and makes it able to
represent lists of entities whose size isn't 4.
- Adds Uint32ListReader and _FbUint32List classes, which are
specialized to handle lists of 32-bit unsigned ints.
- Moves common elements of all _Fb*List classes to the _FbList base
class.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1685263003 .
Even while these libraries are not descibed directly in the
libraries.dart file of Dart SDK, they still can be imported using URIs
like 'dart:html_common/metadata.dart'. So, we need to serialize them
too. Unfortunately I don't see any direct way to know all the SDK
libraries.
R=brianwilkerson@google.com, paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/1681853002 .
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 .
UnlinkedConstOperation.length is used not only if we can prove that
the target is a StringLiteral (and actually we cannot encode it as a
reference).
The new ReferenceKind.length was added - it is used to encode reference
to the the only instance property we support - 'length'.
R=paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/1642483002 .
Previously, implicit types were serialized in the summary as
references to `dynamic`. Now, we simply omit the types from the
summary and the dynamic type is inferred at resynthesis time.
This should reduce the summary size and simplify the implementation of
inferred types.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1622673002 .
Previously we used a null EntityRef as a special case to mean "void".
This saved a tiny amount of space in the summary file, but it's not
worth it because (a) it will complicate some error handling scenarios,
and (b) it would be more worthwhile to use a null EntityRef to
represent implicit types. Both (a) and (b) will be addressed in
future CLs.
This CL changes "void" so that it's serialized as though it were
defined in the defining compilation unit of each library.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1625543002 .
Previously we used reference 0 as a special case to mean "dynamic".
This saved a tiny amount of space in the summary file, but it's not
worth it because it will complicate some error handling scenarios
(which will be addressed in future CLs).
This CL changes "dynamic" so that it's serialized as though it were
defined in the defining compilation unit of each library.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1621763002 .
This should allow more flexibility in the code that creates summaries,
since it will be possible to things like:
FooBuilder foo = new FooBuilder(bar: new BarBuilder);
foo.bar.baz = ...;
(Previously this would have been disallowed because foo.bar would have
returned a `Foo` rather than a `FooBuilder`, and the `Foo` class doesn't
have a setter for `baz`).
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1606283003 .
Note: the prelinker doesn't support type propagation, since type
propagation may require looking at files beyond direct imports and the
transitive closure of exports. However, to pave the way for a future
implementation of a full linker, we still maintain the distinction
between linked and unlinked data. The unlinked data for a propagated
type is simply a unique "slot id" for each type in the compilation
unit which may be propagated. The linked data is the propagated type
to fill into each slot, if any.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1610043002 .
Following a discussion on Tuesday, we've decided to only deal with the
distinction between linked and unlinked information in the summary
definition for now. This should allow fully-linked information (such as
constant evaluation, propagated types, and inferred types) to be added
to summaries without much trouble.
The distinction is preserved in the prelinker (which can't currently
handle fully-linked information), and to some degree it will be
preserved in unit tests (to minimize future churn).
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1584313005 .
Paul Berry