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 .
BSD systems don't place bash in /bin and a lot of the dart tools
hardcode a #!/bin/bash shebang that fails the 'all' target build
(not able to execute dart2js since the interpreter is not found).
Solve the issue by using #!/usr/bin/env as the shebang. For scripts
that need to pass arguments to bash modify the script to use the set
command as the first executed line of shell.
BUG=
R=whesse@google.com
Review URL: https://codereview.chromium.org/1552313002 .
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 .
In addition to simplifying some serialization/deserialization code, this
paves the way for merging the references table with the prefixes table
by allowing the zeroth entry in both tables to act as a sentinel value.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1528083002 .
This is a follow up to commit
f85684604b, which reorganized the
declarations by compilation unit to pave the way for allowing
summaries to be "re-linked" if the relationship between part files
changes. Organizing references by compilation unit is another
necessary step to make that possible.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1523093003 .
In the initial implementation of summaries, all declarations for a
given library were thrown together into a single bucket, regardless of
the compilation unit in which they appeared. This was done on the
grounds that semantically, the compilation unit in which a declaration
appears is irrelevant.
However, it turns out that this conflicts with one of the design goals
of summaries, which is to allow summaries to be quickly "re-linked"
when URI resolution changes. Since "part" declarations use URIs to
refer to part files, this means that URI resolution may affect the
relationship among compilation units within a library; thus, the
declarations for each compilation unit need to be in their own data
structure.
A side benefit of this reorganization is to make the structure of the
summary more similar to the structure of the element model; this
should in turn make it simpler (and possibly more performant) to
convert between element models and summaries.
This CL reorganizes the declarations themselves; future CLs will
reorganize the dependency and resolution information to match.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1530503002 .
- Regenerate tasks.dot
- Mark a test as passing that previously failed
(fail_finalPropertyInducingVariable_classMember_instance_unprefixed)
Note that there are three other tests that I would have expected to
start passing as well (see
fail_finalPropertyInducingVariable_classMember_instance_*), but they
still fail.
TBR=scheglov@google.com
Review URL: https://codereview.chromium.org/1469093002 .
In order to avoid having to reconstitute the entire element model when
deserializing a library summary, we'll need to be able to create element
handles for any elements referenced by the library. Since element
handles operate using a "location", and the "location" records
information about the compilation unit containing the element, this
means that the library summary needs to track which unit each referenced
element lives in (even though this information would otherwise not be
semantically relevant).
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1468583002 .
Instead of passing around opaque Objects which are the result of
calling the Builder.finish() methods, we pass around the Builder
objects themselves, and we call finish() from within the generated
code. This pushes the lack of type safety into the generated code,
leaving the handwritten code type safe.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1452363002 .
Paul Berry