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 .
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 .
Not yet used. This is mostly copied from experiments done earlier in
the year, and is therefore incomplete; I plan to refine this in the
process of fleshing out the implementation and tests.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1410383004 .
Paul Berry