AstBinaryWriter does not yet support all node types, but a lot of them,
and can successfully write many large Dart files, including itself.
Whether it does it correctly, we cannot say yet, because AstBinaryReader
supports much smaller set of node types. I plan to add all nodes in
following CLs, and run over larger bodies of code.
R=brianwilkerson@google.com, paulberry@google.com
Change-Id: Iaa2a5c743bd1659ea30c93632028d3a475736bf5
Reviewed-on: https://dart-review.googlesource.com/c/94684
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
We already can store List<double>, but not `double` itself.
The LinkedConstantValue data structure I'm working on will have a
field of type `double`, so I need to support in in the generator.
R=paulberry@google.com
Change-Id: Ic5aa3a9a7266afabe6c64214fd68097fbebda4e8
Reviewed-on: https://dart-review.googlesource.com/c/93820
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Several tests need to access source files in the 'pkg' directory, and
they use various mechanisms for finding it. This CL changes
everything to use the same mechanism.
Change-Id: I146a6d72ec05a20cf07451a83eada9fb8e71a966
Reviewed-on: https://dart-review.googlesource.com/5484
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The API for pkg/front_end is still in flux so we want to avoid having
any packages depend directly on it (other than analyzer and
back-ends).
This CL re-exports some of the critical pieces of front_end needed by
analyzer clients so that those clients can access them via analyzer,
without having to directly depend on front_end. It also updates
pkg/analyzer_plugin to make use of those re-exports.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2993123002 .
This eliminates much of the duplication between the two token hierarchies
by merging much of the fasta.Token hierarchy into the analyzer.Token.
* merge token hierarchies
* cleanup fasta.Token.copy()
* set preceedingComments field via constructor
* replace isBuiltInIdentifier --> type.isBuiltIn
* change all fasta.Token references to analyzer.Token
* move fasta.Token.value() implementation into analyzer.SimpleToken
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2890523002 .
These utilities are needed for generating the code that supports
summaries; in order to move summary logic into front_end, we will need
these code generation tools in front_end as well.
Also make a minor change to summary code generation logic so that it
talks to the file system directly rather than depending on analyzer's
file system abstraction.
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2742333005 .
The end goal is to move summary logic to the front end, which means
that it won't be able to depend on analyzer. This removes a key
dependency on analyzer (the dependency of the code generator on the
analyzer parser).
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2748803003 .
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 .
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 .
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 .
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 .
This CL makes a small change to the format of the summary IDL file:
instead of containing classes with fields, it now contains classes
with getters. This allows the classes in the IDL file to be directly
used as interface classes, which makes code navigation much smoother.
Since the IDL file is now being used directly by the code, it has been
relocated to pkg/analyzer/lib/src/summary/idl.dart.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1667723002 .
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 .
danrubel