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 .
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 .
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 .
Brian Wilkerson