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 .
Due to the tight coupling between analyzer and front_end, they need to
be published atomically. The last published version of kernel is old
enough that it needs to be published too.
I've bumped the versions to the following, and changed the
dependencies so that this set of versions is mutually compatible:
- analyzer: 0.30.0-alpha.3
- front_end: 0.1.0-alpha.2
- kernel: 0.2.0
(Note that kernel's version didn't need bumping since the most
recently published version of it is 0.1.0)
R=asgerf@google.com
Review-Url: https://codereview.chromium.org/2828273003 .
This is the result of:
- taking the diff of the branch closure_conversion to master in the kernel
repository
- updating the file paths
- applying the diff to the Dart SDK
- fixing conflicts between the changes to pkg/kernel in the Dart SDK and the master branch in the kernel repository
R=asgerf@google.com
Review-Url: https://codereview.chromium.org/2561723003 .
The analyzer keeps a separate AnalysisContext for the SDK, and the
options we set on our own context did not match those on the SDK,
mainly causing issues for strong mode.
Also, the BatchModeState is now used to share the Dart SDK, instead of
using a single instance held in a static variable.
BUG=
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/504827013 .
Instance members are now cloned for every class that inherits it.
The constraint system now explicitly requires all values to be
created using `newValue()`.
There is now a notion of "unions" for representing sets of values.
For class values, unions correspond to types. For function values,
unions are based on overriding and method names.
The solver's internal map of type (Value,Field) -> Value denoting
the value of a given field has been removed.
The builder must instead register store and load locations for
every valid (Value,Field) pair. Dynamic stores assign into the
store location, and dynamic loads take the value from the load
location.
Final fields have no store location, so they cannot be polluted
by dynamic stores.
R=vegorov@google.com
Review URL: https://chromereviews.googleplex.com/455987013 .
Kevin Moore