See: https://github.com/dart-lang/sdk/issues/33901
Change-Id: I0bb8bc029865f2b46b052f50e49a5d2d13c5c81e
Reviewed-on: https://dart-review.googlesource.com/65981
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
See: https://github.com/dart-lang/linter/issues/1040
Change-Id: Iedc7c4f0b3c4a9543292e07c2fd738329d39406d
Reviewed-on: https://dart-review.googlesource.com/62324
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Reference pkg:testing by path
Remove dependency on pkg:ansicolor - not used
Also removed outdated reference to fasta in .packages
Change-Id: Iaeaa4a868e376e6cfdd5dad35d87521a18b213f2
Reviewed-on: https://dart-review.googlesource.com/61908
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Commit-Queue: Kevin Moore <kevmoo@google.com>
After some discussion, we decided that it's not necessary to publish
alpha versions when making non-breaking changes. (The rationale for
publishing alpha versions is to minimize the number of breaking
changes, since breaking changes to a popular package can potentially
slow down pub's version solver, but this is not an issue for
non-breaking changes).
Change-Id: I3f4f975712af43b6b0475f2c68dc430c394454cb
Reviewed-on: https://dart-review.googlesource.com/57140
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL looks a little weird because a previous CL,
https://dart-review.googlesource.com/46126 partially updated
the yaml files but the packages were never published.
Bug: dartbug.com/32509
Change-Id: I2ab19b6165fcd9d748defb6eeeb5efff2925df6c
Reviewed-on: https://dart-review.googlesource.com/47904
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Janice Collins <jcollins@google.com>
I'm not sure -- I ticked analyzer to 0.32 from 0.31-alpha.
I think because of the new methods, this is the right call (though it
leaves us in the weird place where there was no stable publish of
0.31.2?)
Also not sure if I need to update any other downstream packages (args?
dart_style?). Seems like if so, those are all in other repos.
Change-Id: I512e6674549a99fdafe47f2138738463f4e66e37
Reviewed-on: https://dart-review.googlesource.com/46126
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Update changelog and versions prior to publish, primarily for the crash
in computeNode fixed by 3791ddb496 (diff-ff9cb85838db7a802ac5aa9c55f26d86).
Change-Id: If3bbe3238fb622d884cee5df87a06a90b401fe7e
Reviewed-on: https://dart-review.googlesource.com/41040
Commit-Queue: Janice Collins <jcollins@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Verified that the new analyzer at least smoke-tests on .21 still,
so did not update SDK constraints. Publish is to address
dart-lang/dartdoc#1603.
Change-Id: I39320e5557344f6c1c79df50b792246fc1c29840
Reviewed-on: https://dart-review.googlesource.com/40401
Commit-Queue: Janice Collins <jcollins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Devon Carew <devoncarew@google.com>
Change-Id: Ifea9db1f41e232136afe0c0eacdcc7c1a430e69d
Reviewed-on: https://dart-review.googlesource.com/24200
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Prepare to publish meta
Change-Id: I1bc564c68315fb2f27469deda76e75495e42c23b
Reviewed-on: https://dart-review.googlesource.com/9364
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Devon Carew <devoncarew@google.com>
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 .
