Allow super calls to occur in mixin declarations if they target a
method from any of the superclass constraint interfaces.
Instead of compiling the Dart mixin declaration
mixin M on S0, S1 {...}
to Kernel:
abstract class _M&S0&S1 = S0 with S1;
abstract class M extends _M&S0&S1 { ... }
we compile it to Kernel:
abstract class _M&S0&S1 implements S0, S1 {}
abstract class M extends _M&S0&S1 { ... }
because the former is not symmetrical with respect to S0 and S1. It
will prefer a method from the 'mixin' S1 over one from S0 which can
give a compile-time error if the method from S0 is more general.
Modify mixin inference to support the new compilation of mixin
declarations. It still has to support old-style VM super mixins until
support for those is removed from the VM.
Change-Id: Ib945aa11cc19c457b07bc802beae10d1663ff6b7
Reviewed-on: https://dart-review.googlesource.com/76141
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
This normalizes all accesses of Object properties on dynamic receivers
to target the corresponding Object members.
CFE already set the interface target on for instance `a == b` where `a`
has static type `dynamic` but didn't for the implicit call to `==` in
for instance `a?.b`.
Change-Id: I4f714766ac33a431f5ef645df7ee1bbb254c06ce
Reviewed-on: https://dart-review.googlesource.com/76123
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
- including the first benefit: Removing Class/Member definitions from the K-world.
Change-Id: I440dce2e37758dd276a417851f67a1403f6535a0
Reviewed-on: https://dart-review.googlesource.com/76641
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This is a redo of "[dart2js] Simplify noInline / tryInline annotations"
but keeping compatibility between different versions of dart2js and package:meta
Change-Id: I30e48f374aeef13d99f41af81eb0b8f339ab8bb8
Reviewed-on: https://dart-review.googlesource.com/76581
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
This speeds up the computation of static type by avoiding repeated
visits of subtrees. The change also paves the way for improving
static type computation beyond what is specified. For instance by
handling negative type promotions.
Change-Id: Ifa3ea0f9760251f43cbbcc97b684004741a97b11
Reviewed-on: https://dart-review.googlesource.com/76020
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
We don't need to mark generic methods (not local functions) as needing
rti if subtypes of Functions need support for .runtimeType.
Unlike local functions, generic methods only have function type when
they are torn off. The tear-off itself doesn't add the need for type
arguments: either the function is instantiated, in which case the
instantiation carries the type arguments, or it is uninstantiated, in
which case the function type is still generic.
Change-Id: I5fc849aad443f49c4b0b26b18d6eccc409e43fb9
Reviewed-on: https://dart-review.googlesource.com/76000
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
The default Object.hashCode is different on every run, so avoid using it for MemberEntity.hashCode.
Using a consistent (if arbitrary) hashCode appears to fix issue 34527
and also makes the *.js.map files consistent.
We also sort instructions in SsaCodeMotion to make order less sensitive to unrelated changes.
We might still want to impose a canonical ordering for map files, e.g. minified map file entries might be sorted by name.
Change-Id: I94ad6c1e18ac808b92e62e76b48558a7e2fbd7b7
Reviewed-on: https://dart-review.googlesource.com/75982
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This is no longer needed since we eagerly register all classes with the
ClassHierarchyBuilder
Change-Id: Ifaa27017bac6a7b0a659de83af415f2bd25ea005
Reviewed-on: https://dart-review.googlesource.com/75260
Reviewed-by: Stephen Adams <sra@google.com>
Since dart2js is now strong-mode-only and ignores the --strong flag, I don't see the point in having 'strong' in the platform name.
Removed:
dart2js_platform
dart2js_server_platform
renamed:
dart2js_platform_strong --> dart2js_platform
dart2js_server_platform_strong --> dart2js_server_platform
Change-Id: If74ef31a17acc15a23a5338e5f53e820fc66b0dd
Reviewed-on: https://dart-review.googlesource.com/71425
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Stephen Adams <sra@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>
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>
This ensures that entities only used in metadata is part of the K-world
and doesn't have to be created late in (only) the J-world.
Change-Id: If9a264c51fba99093a196538fb655b1d5fafd47a
Reviewed-on: https://dart-review.googlesource.com/73880
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
* The J model is in the /js_model/ folder and KernelToElementMapForBuilding is renamed
to JsToElementMap.
* The K model is in the /kernel/ folder and KernelToElementMapForImpact is renamed
to KernelToElementMap.
* Code shared between JsToElementMap and KernelToElementMap is in the /ir/ folder using
the interface IrToElementMap internally.
* KernelToElementMap and JsToElementMap do _not_ implement IrToElementMap so all code
that is not part of the implementation must explicitly use one or the other.
* Both KernelToElementMap and JsToElementMap extend KernelToElementMapBase
but this will be changed in a follow-up.
Change-Id: Id6b762984d25354477cb099dc2f8301b83a7ba07
Reviewed-on: https://dart-review.googlesource.com/73382
Reviewed-by: Stephen Adams <sra@google.com>
* Refactor ClassData, remove ensureCallType
* Make kernel/types.dart its own library
Change-Id: I280f7de0b78f9a14551f0ae0548452693a6d0d05
Reviewed-on: https://dart-review.googlesource.com/72761
Reviewed-by: Stephen Adams <sra@google.com>
This makes closed world computation take the static type of the receiver
into account and removes non-live members from the J-world.
Change-Id: I5547aaae4685c6417a94916df0bc4e621296ce8d
Reviewed-on: https://dart-review.googlesource.com/72643
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Previous implementation didn't include subtypes of the specified type.
For instance `JS('Rectangle', ...)` should have triggered the inclusion
of `_DomRect` but the use of this-type in the subtype test,
`_DomRect <: Rectangle<T>`, prohibited this.
This fix is to use the raw type instead of the this-type. The subtype test
will therefore be `_DomRect <: Rectangle<dynamic>` which correctly
includes `_DomRect`.
The change has the effect that `JS('List', ...)` now actually includes subtypes of
`List`. For this reason uses of `List` have been updated to use `JSArray` or
explicitly use `returns:...` to avoid unintended inclusion of native lists such
as the native typed arrays.
Change-Id: I06ab55d9bf694829596875d9c3a0a6c954d396b7
Reviewed-on: https://dart-review.googlesource.com/73903
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Johnni Winther