I will soon start landing fixes to address some (but not necessarily
all) of the test cases in this test, and I want to make sure that my
fixes produce corresponding status file changes, to secure against
possible future regressions.
Change-Id: Iaec11b85a20d670c0702220cadbbdfc51c026d1f
Reviewed-on: https://dart-review.googlesource.com/75624
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
To avoid causing unrelated tests to start failing, the tests have been
modified to avoid running afoul of the analyzer toplevel inference
limitations. (Note that we still have adequate test coverage in
pkg/front_end/testcases that the front end isn't subject to these
limitations).
Change-Id: I7b8f84a358d0e8891025b24143117c39d1b7dd69
Reviewed-on: https://dart-review.googlesource.com/75389
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Also modify async_backwards_compatibility_1_test so that fixing these
bugs won't cause it to start failing.
Change-Id: I7bb3b9587a0aeea8662df1923034bcb409a29522
Reviewed-on: https://dart-review.googlesource.com/75280
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The bleeding edge console revealed that status files for
dartk-checked-linux-release-x64 configuration needed to be updated.
Change-Id: I7015427f55436947aebd019212765c5f3937f846
Reviewed-on: https://dart-review.googlesource.com/75440
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
There are several crashes on kernel-precomp bots related to the new
tests. As front-end does not issue a compile-time error,
AOT transformations such as constant evaluation are not skipped and
may crash on incorrect hierarchy.
Stack trace:
Change-Id: Ieaf789535eb4c59a3cc4f2f3437b2b41b9e506f4
Reviewed-on: https://dart-review.googlesource.com/75401
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Fixes#34167. This implements the Dart 2 mixin proposal
(https://goo.gl/KEKQyv) for DDC. When the mixin is applied, a class
is created for the application that extends the correct superclass
and has all of the instance members, so `super` works correctly.
This also fixes a few minor issues in Analyzer's (mostly complete)
implementation:
- InterfaceType.isObject now returns false for Dart 2 mixins.
- Least upper bound calculation recognizes mixins are not Object.
- Interface of the mixin now implements its superclass constraints.
- Mixin superclass constraints are checked against the superclass and
all previously applied mixins (if any); this keeps it working with
the subtype fix above, and also prevents a not-yet-applied mixin
from satisfying the constraint
The language_2/mixin_declaration tests were updated with a few minor
fixes now that we can run Analyzer/dartdevc to test them.
This change implements super mixins for DDC's Kernel backend (DDK)
too. This will be enabled once Kernel adds a flag to recognize which
Class nodes are mixins (vs normal classes).
Change-Id: Ib3c4fcb12de9988345e52d92931196828d8227c3
Reviewed-on: https://dart-review.googlesource.com/74965
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
This includes the unknown potential targets of access to js-interop
members. Since we don't know actual classes implementing the js-interop
classes we just assume it could be any of them.
Change-Id: I4d91ab673fa8221eb701b34e9c32fd16e5a1c381
Reviewed-on: https://dart-review.googlesource.com/74980
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
The point is that #32782 requests a fix such that
`typedef F1 = void Function(int)` and `typedef void F2(int)`
satisfy that `F1 == F2` evaluates to true. This is marked
'p3-low' for the common front end but 'p1-high' for DDC.
It seems likely to me that this could create the situation where
code is developed using DDC, is working, and then fails upon
deployment using the vm. Also, there is a single case where
`dart2js` fails in the associated `type_alias_equality_test.dart`,
so deployment on the web would also fail upon deployment, though
only in some of the cases.
However, with some input from Aske I concluded that the situation
might have arisen because there _is_ no work to do for this in the
common front end, because it will be handled by the backend (which
also explains why `dart2js` has it almost right).
This CL is just introducing a tiny change: It changes the issue
indicated for all VM related failures in said test to point to
#32783, which is presumably the right issue for backend work.
Apart from that, I've added you, the reviewers, in order to make
sure that the relevant people get this heads up. We may then decide
to land this CL, change the priority on #31359, do nothing, or
whatever turns out to be the right response. ;-)
Change-Id: I92672547d7fe795e877604c0da1e0e4579e4e04a
Reviewed-on: https://dart-review.googlesource.com/74403
Reviewed-by: Jenny Messerly <jmesserly@google.com>
This is a step towards making our own code use Dart 2 rather that
Dart 1 semantics.
For instance, the js-runtime libraries often use `dynamic` to avoid
extra type checking in Dart 1 checked mode, which has the consequence
that we have _more_ checking in Dart 2 (or just worse inference
baselines).
The VM is now optimizing for the typed paths and we should therefore
avoid unneeded dynamic accesses in dart2js code itself.
Change-Id: I793ef6c478c4c1b8caa1513990baafc598c462d8
Reviewed-on: https://dart-review.googlesource.com/74380
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Calls that return constants and calls that forward to calls of the
same or smaller size should be inlined in static initializers.
Change-Id: I55284b7455bc70e34607c0a218a5bf6ca31fc6b4
Reviewed-on: https://dart-review.googlesource.com/74020
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Paul Berry