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 .
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 .
Paul Berry