The API signature of a summary is an MD5 hash of the API of the code
being summarized. This will be used by analysis server to detect when
a summary needs to be relinked (because it was built with reference to
another summary whose API has since changed).
R=scheglov@google.com
Review URL: https://codereview.chromium.org/2216873003 .
Consider libraries `A`, `B`, and `C`, where `C` imports `B`, and `B`
exports `A`. [RESOLVED_UNIT4] of `C` depends on [LIBRARY_ELEMENT4] of
[IMPORTED_LIBRARIES], i.e. `B`. Even though [LIBRARY_ELEMENT4] of `B`
depends on [LIBRARY_ELEMENT3]s of its [EXPORT_SOURCE_CLOSURE] (i.e. `A`
and `B`), [RESOLVED_UNIT4] of `C` sees only [LIBRARY_ELEMENT4] of `B`.
When invalidate results of `B` (but keep results of `C`), we will
invalidate and remove [LIBRARY_ELEMENT4] of `B`, so we lose knowledge
that [RESOLVED_UNIT4] of `C` indirectly depends on `A`.
The solution is do depend on [EXPORT_SOURCE_CLOSURE] of all
[IMPORTED_LIBRARIES] in [RESOLVED_UNIT4] of `C`.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/2171673002 .
These assertions were helpful back when the client manually managed
offsets. Now that offsets are managed automatically by the toBuffer()
logic, they don't carry any benefit.
Removing these assertions will pave the way for allowing a summary to be
created, serialized, modified, and then serialized again, which we will
need to do to efficiently generate both "full" and "semantic" summaries.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2110693002 .
Options are largely unused but are in line with what is specified in CLI to support `build_mode` bringing us a step closer to a unified summary builder and in the short term to a provisional API that should work for Flutter SDK generation experiments in the next alpha release.
BUG=
R=brianwilkerson@google.com, paulberry@google.com
Review URL: https://codereview.chromium.org/2078033002 .
Steps towards generalizing summary creation bits (to allow for, among other things, flutter SDK summary creation). API is provisional (note still in `lib/src`).
Next up:
* move result writing out of `tool/` to allow for reuse
* `SummaryBuilder.forPackageMap(..)` factory (or similar) for use in the flutter SDK case
BUG=
R=brianwilkerson@google.com, paulberry@google.com
Review URL: https://codereview.chromium.org/2055543002 .
We now disambiguate all types by their full library
URI (e.g. "dart:core.Map" instead of "Map"). In addition, we now expand
function types based on local functions into their arguments and return
types (e.g. "() -> dynamic" rather than
"typeof(....localFunction[0].localFunction[0])".
This allows more accurate comparison of AST-based and element-based
summaries.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1997753002 .
This paves the way for further improvements to dump_inferred_types to
allow it to make use of linker data structures. That will in turn make
it easier to validate the linker code by exercising more of it.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1969313006 .
This makes it easier to compare the output of AST-based and
element-based summaries, since element-based summaries cannot
distinguish between implicit type arguments and explicitly-specified
type arguments that happen to match the default (usually `dynamic`).
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1957133002 .
In rare cases a summary package bundle may contain a LinkedLibrary
object but not its corresponding UnlinkedUnits. (This could happen, for
instance, if both a package and one of its dependencies contain
libraries that reference the same file as a "part"--in this case, the
UnlinkedUnit for the part might only be included in one of the package
bundles, because it is redundant in the other).
This CL modifies dump_inferred_types.dart so that it doesn't crash in
this rare corner case.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1930663003 .
It (in combination with --build-summary-only-diet) makes the
package:path summary is almost 3 times smaller, partially because of
skipping bodies, patially because of excluding documentation comments,
and partially because of making 'codeRange' fields informative.
We also remove MD5 hashes.
As I can see after changes in method bodies we generate the exactly
same file (or at least 'cmp -l' thinks so). Adding a new field results
in a file of different length.
R=paulberry@google.com, brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1828973002 .
Paul thinks that there is a bug in gyp or make, and we should generate
only one output. So, we generate the whole bundle with all summaries
and index information. And then we have separate actions that take
this bundle and extract one output each - spec.sum and strong.sum files.
R=paulberry@google.com, whesse@google.com
BUG=
Review URL: https://codereview.chromium.org/1775973003 .
If an attempt is made to read an unrecognized enum value, then rather
than crashing, we will read the default (first) value of the enum type.
This facilitates forwards compatibility by ensuring that if a new enum
value is added in the future, older code will still be able to read the
resulting summary files without crashing.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1747413002 .
If an IDL field is marked as `@deprecated`, no setter will be
generated for it, and the getter generated for it will throw an
UnimplementedError. This is similar to the behavior of standard
Flatbuffer tools (which generate neither setters nor getters for
deprecated fields) except that we have to generate a getter in order
to avoid warnings.
Once we have begun using summaries in the wild, we will need to make
use of this feature in order to avoid changing Id numbers and breaking
backwards compatibility.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1753883002 .
It turned out that for used names we don't need any flags because we
want to store only qualified unresolved (potential) class member
usages. So, no flags for used names at all, at least for now.
R=paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/1750163003 .
This file can be consumed by standard flatbuffer tools, allowing
summaries to be consumed from other languages. For example, a summary
file can now be converted to JSON using:
flatc -o $outputDirectory -t \
pkg/analyzer/lib/src/summary/format.fbs -- $inputFile
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1743713002 .
Konstantin Shcheglov