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 .
This information will be necessary in order to determine whether a
summary needs to be re-linked, since a change to a part of library A may
affect any other library that depends on library A, even if the defining
compilation unit of library A is unaffected.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1574113002 .
The prelinker is capable of rebuilding the "Prelinked" summary
information based on the "Unlinked" information. We will need to do
this in order to make efficient use of summaries when some files are
changed but not others, or when a pub package is upgraded but another
package that depends on it is left alone.
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1576743002 .
These can be easily inferred at the time the summary is resynthesized
into an element model. This should make the summary size marginally
smaller, and make it easier to create summaries straight from the AST.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1565643002 .
In a future CL, this should allow the element model to be
resynthesized from a summary more efficiently, since it won't be
necessary to consult the referenced elements when resynthesizing a
FunctionTypeImpl.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1555233002 .
This will make it easier to re-link summaries when a file changes,
since all the information that is needed from imported libraries will
be in the "public namespace" section of the summary.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1543403002 .
Previously, we were generating code like:
if (_value != null || _value == <default>) {
<store _value in the summary>
}
which meant that (a) default values were being unnecessarily stored in
the summaries, and (b) passing null to a summary Builder setter would
have caused a crash.
This CL modifies the code generator to output code like this:
if (!(_value == null || _value == <default>)) {
<store _value in the summary>
}
which has the intended behavior of treating `null` like the default
value, and suppressing the default value from appearing in the summary.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1539953002 .
This is necessary in order to properly summarize the core type `Object`,
which lacks a supertype.
Note that there is no test for this functionality in
resynthesize_test.dart. It will be covered as soon as the test
`fail_core` is enabled.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1531913002 .
This makes the UnlinkedLibrary type go away, which means that we no
longer have any unlinked summary data which is spread across the
compilation units constituting a library. That in turn means that we
should be able to safely re-link summaries even in the (pathological)
case where a change to URI resolution affects the relationship between a
library and its parts.
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1528113002 .
Paul Berry