I need these tests in order to be sure that I understand expectations
of the ClassHierarchy interface, and to be able to test a lazy
implementation I'm going to create for incremental kernel generator.
I moved lub_test tests into this wider test suite.
Tests for forEachOverridePair() are not complete yet, just one path
is tested.
If there are any additional cases that you think should be covered,
please let me know.
R=ahe@google.com, kmillikin@google.com, paulberry@google.com, sigmund@google.com
BUG=
Review-Url: https://codereview.chromium.org/2912173002 .
This allows for example to add SDK into a Program, then load the
"incomplete" Program A that has only the library A, and name sequences
that references SDK classes. Because we look into the nameRoot which
aleady has SDK CanonicalName(s), we can find these names while filling
the link table and use references which point to the existing SDK
AST nodes. Then we can load another set of library cycles, etc.
At the end we have a set of self-consistent libraries that we can
feed into DillTarget/DillLoader and resolve anothersource target
against it.
This CL is based on https://codereview.chromium.org/2872903005/
which has not been reviewed yet.
R=kmillikin@google.com, paulberry@google.com, sigmund@google.com
BUG=
Review-Url: https://codereview.chromium.org/2874723002 .
"bin" is part of the public API of a package, private tools can go under the
`tool` folder. This allows us to use a dev_dependency on analyzer without
exposing a broken import publicly.
I've only moved `dartk` so far (which I expect will be removed once we have a
better API for front_end.
R=asgerf@google.com, kmillikin@google.com
Review-Url: https://codereview.chromium.org/2842643002 .
from front_end/lib/src/fasta/analyzer/
to analyzer/lib/src/fasta/
analyzer_compile and compile_platform_dartk moved
from front_end/lib/src/fasta/analyzer/
to front_end/tool/_fasta/
front_end/src/fasta/testing/* continues to have some shared testing logic,
- logic to compute the patched sdk is moved up one level
- TestContext, Run, and suite.dart (which depend on analyzer) moved to pkg/front_end/test/fasta/testing/
- only a copy of TestContext is duplicated under pkg/kernel/test/closure/.
R=ahe@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2828583003 .
This CL introduces Fasta's first type inference rule, and hooks it up
to all the necessary testing infrastructure. The rule is that a local
variable whose initializer is an integer literal should have an
inferred type of int.
Only variables occurring at top level within a method are inferred (we
don't yet recurse inside sub-blocks).
Additional type inference rules will be added in follow-up CLs.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2828693003 .
There are four operations that work on Vectors: Vector creation, looking
up an item in a Vector, assigning a value to an item in a Vector, and
copying a Vector. The first three operations are allowed to only use
integer literals as number operands (length for Vector creation, index
for item lookup and assignment). Corresponding AST nodes are created for
these operations.
Vectors are used to represent contexts in Closure Conversion. The parent
context is stored as item 0 in its children contexts. The "golden" tests
for this transformation are adjusted accordingly.
The support for Vectors is added to ast-to-text, ast-to-binary, and
binary-to-ast transformations.
R=asgerf@google.com, kmillikin@google.com
Review-Url: https://codereview.chromium.org/2767773004 .
This CL moves many of the files from
pkg/front_end/lib/src/fasta/analyzer/ to pkg/analyzer/lib/src/fasta/.
It also moves two files from pkg/kernel/lib/analyzer/ to
pkg/analyzer/lib/src/kernel/.
This reduces the amount of circularity between analyzer and
front_end/kernel so that there are no files in front_end or kernel
which are both dependend upon by analyzer and depend upon analyzer. I
will clean up the remaining circularities in future CLs.
There should be no functional change.
R=ahe@google.com, asgerf@google.com, kmillikin@google.com, scheglov@google.com, sigmund@google.com
Review-Url: https://codereview.chromium.org/2756593004 .
All generic methods are equipped with one extra named parameter for
passing type arguments as a list of type values.
Additinally, this change forces strong mode usage for 'dartk' in
'reified_dart'. Strong mode is required for loader to not strip away
type arguments from generic methods. In future, a command line argument
may be implemented for that (e.g. --generic-methods), if generic method
support will land before the strong mode.
R=karlklose@google.com
Review-Url: https://codereview.chromium.org/2713163002 .
Konstantin Shcheglov