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>
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>
The canonicalization of symbols needs to take library privacy into
account. Since the Symbol class itself only has a [_name] field but does
not reference in which library the symbol came from, the [_name] must be
mangled.
Mangling is done by backends and so we make a new [SymbolConstant] which
the backends can desugar by doing appropriate mangling and construction
of a [Symbol] instance.
Fixes https://github.com/dart-lang/sdk/issues/34396
Change-Id: I2e13288483c35f875d39eefdb73677b2cc03527a
Reviewed-on: https://dart-review.googlesource.com/74360
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
In Fasta's outline builder, parse mixin declarations as if they were
the corresponding class declaration:
mixin M<T0,...,Ti> on S0,S1,...,Sj implement I0,...,Ik {...}
is parsed as if it were:
class M<T0,...,Ti> extends S0 with S1,...,Sj implements I0,...,Ik {
...
}
This supports the syntax and should automatically provide an
implementation of the runtime semantics on the VM. Not all of the
required static checks are implemented in the front end.
Change-Id: Ice65e93446222484272f8f7db0de2d18c352f56b
Reviewed-on: https://dart-review.googlesource.com/73760
Reviewed-by: Dan Rubel <danrubel@google.com>
The canonicalization of symbols needs to take library privacy into
account. Since the Symbol class itself only has a [_name] field but does
not reference in which library the symbol came from, the [_name] must be
mangled.
Mangling is done by backends and so we make a new [SymbolConstant] which
the backends can desugar by doing appropriate mangling and construction
of a [Symbol] instance.
Fixes https://github.com/dart-lang/sdk/issues/34396
Change-Id: I5ddb5331ce79a0b942807929d4b8f1050a9899e7
Reviewed-on: https://dart-review.googlesource.com/73883
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Jenny Messerly