-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Implement constructor tearoffs support in the VM/AOT #46231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The tests
currently crash on
|
These tests also fail:
|
TEST=co19/LanguageFeatures/Constructor-tear-offs Issue: #46231 Change-Id: I177d0d77eac32b49d39949d696de8aa9a618cc6c Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208442 Commit-Queue: Alexander Markov <alexmarkov@google.com> Reviewed-by: Martin Kustermann <kustermann@google.com>
More tests have shown up as crashing on ia32, with the latest commit landed: co19/LanguageFeatures/Constructor-tear-offs/named_constructor_A01_t01 DART_CONFIGURATION=DebugIA32 out/DebugIA32/dart --sound-null-safety --enable-experiment=constructor-tearoffs --ignore-unrecognized-flags --packages=/b/s/w/ir/cache/builder/sdk/.packages /b/s/w/ir/cache/builder/sdk/tests/co19/src/LanguageFeatures/Constructor-tear-offs/named_constructor_A01_t02.dart exit code: stderr: |
…enerating constructor tear-off All handles passed to IL instructions should be ZoneHandles. Recently added code for generating constructor tear-offs has been passing Handle instead of ZoneHandle by mistake. This change fixes the bug and adds assertions to AllocateObjectInstr so it would check handle type earlier and on all platforms. TEST=co19/LanguageFeatures/Constructor-tear-offs in debug/ia32 mode Issue #46231 Change-Id: I99e6889e59bf40f4788a7f3c6d37dad89aa91ab0 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208686 Reviewed-by: Martin Kustermann <kustermann@google.com> Commit-Queue: Alexander Markov <alexmarkov@google.com>
Replace bogus body created for redirecting factories with a normal body which calls target factory or constructor and forwards all arguments. Such a body can be used by back-ends if they choose to treat redirecting factories as ordinary factories. TEST=ci Fixes #41915 Issue #46231 Change-Id: I62c83bcc9005995e85de049d3d929ca86a75297f Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208681 Commit-Queue: Alexander Markov <alexmarkov@google.com> Reviewed-by: Johnni Winther <johnniwinther@google.com>
After https://dart-review.googlesource.com/c/sdk/+/208681 it is now possible to use bodies of redirecting factories in the VM and treat redirecting factories like ordinary factories. TEST=vm/cc/DartAPI_New TEST=vm/dart/redirection_type_shuffling_test TEST=co19/LanguageFeatures/Constructor-tear-offs Fixes #33041 Fixes #29201 Issue #46231 Change-Id: If410d2913704a33035800144699fd6e8a2570a19 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208684 Reviewed-by: Martin Kustermann <kustermann@google.com> Reviewed-by: Johnni Winther <johnniwinther@google.com> Commit-Queue: Alexander Markov <alexmarkov@google.com>
There could be multiple instances of implicit static closures due to instantiations at run time: void foo<T>(T x) {} void bar<T>() { void Function(T) myfoo1 = foo; void Function(T) myfoo2 = foo; print(myfoo1 == myfoo2); } This change fixes equality to handle this case. TEST=language/generic_methods/explicit_instantiated_tearoff_test TEST=language/constructor/tear_off_test Issue #46231 Issue #46487 Change-Id: I485acc5444d19860ef4d8ebeec2e540fe57776d6 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208981 Reviewed-by: Ryan Macnak <rmacnak@google.com> Commit-Queue: Alexander Markov <alexmarkov@google.com>
TEST=language/typedef/aliased_constructor_tear_off_test Issue #46231 Change-Id: I10df62d4d170a4ae018a0e943ac6fc37d669d439 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208984 Reviewed-by: Johnni Winther <johnniwinther@google.com> Commit-Queue: Alexander Markov <alexmarkov@google.com>
…neric classes When copying types of parameters from a constructor to a signature of its tear-off, types should be instantiated to substitute class type parameters with function type parameters. For example, class A<T> { A(T x); } A.new // Should be 'A<S> Function<S>(S x)' Without instantiation the parameter type would still reference class type parameter: A<S> Function<S>(T x) As a result, Closure::GetInstantiatedSignature would replace class type parameters with dynamic (as tear-off doesn't have instantiated type arguments) which is not correct: A<S> Function<S>(dynamic x) TEST=co19/LanguageFeatures/Constructor-tear-offs/summary_A01_t01 (after dart-lang/co19#1141 is fixed) Issue #46231 Change-Id: I0517c400271e2a59ab0496a8cc39be51022768b4 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209851 Commit-Queue: Alexander Markov <alexmarkov@google.com> Reviewed-by: Tess Strickland <sstrickl@google.com>
Implementation is complete. Current status of tests:
|
In weak mode ( |
When taking a type of an instance with x.runtimeType we can map internal classes _List, _ImmutableList and _GrowableList to a user-visible List class. This is similar to what we do for implementation classes of int, String and Type. After that, result of x.runtimeType for built-in lists would be compatible with List<T> type literals. Also, both intrinsic and native implementations of _haveSameRuntimeType are updated to agree with new semantic of runtimeType. TEST=co19/LanguageFeatures/Constructor-tear-offs/type_literal_A01_t01 TEST=runtime/tests/vm/dart/have_same_runtime_type_test Fixes #46893 Issue #46231 Change-Id: Ie24a9f527f66a06118427b7a09e49c03dff93d8e Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210066 Commit-Queue: Alexander Markov <alexmarkov@google.com> Reviewed-by: Tess Strickland <sstrickl@google.com>
…as List" This reverts commit 824bec5. Reason for revert: b/196606044 Original change's description: > [vm] Hide internal implementation List types and expose them as List > > When taking a type of an instance with x.runtimeType we can map > internal classes _List, _ImmutableList and _GrowableList to a > user-visible List class. This is similar to what we do for > implementation classes of int, String and Type. > After that, result of x.runtimeType for built-in lists would be > compatible with List<T> type literals. > > Also, both intrinsic and native implementations of _haveSameRuntimeType > are updated to agree with new semantic of runtimeType. > > TEST=co19/LanguageFeatures/Constructor-tear-offs/type_literal_A01_t01 > TEST=runtime/tests/vm/dart/have_same_runtime_type_test > > Fixes #46893 > Issue #46231 > > Change-Id: Ie24a9f527f66a06118427b7a09e49c03dff93d8e > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210066 > Commit-Queue: Alexander Markov <alexmarkov@google.com> > Reviewed-by: Tess Strickland <sstrickl@google.com> TBR=rmacnak@google.com,alexmarkov@google.com,sstrickl@google.com Change-Id: I4c3dddbc358d6ad3b14081706f7aec110a2e0562 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210200 Reviewed-by: Alexander Markov <alexmarkov@google.com> Commit-Queue: Alexander Markov <alexmarkov@google.com>
…as List" This is a reland of 824bec5 Original change's description: > [vm] Hide internal implementation List types and expose them as List > > When taking a type of an instance with x.runtimeType we can map > internal classes _List, _ImmutableList and _GrowableList to a > user-visible List class. This is similar to what we do for > implementation classes of int, String and Type. > After that, result of x.runtimeType for built-in lists would be > compatible with List<T> type literals. > > Also, both intrinsic and native implementations of _haveSameRuntimeType > are updated to agree with new semantic of runtimeType. > > TEST=co19/LanguageFeatures/Constructor-tear-offs/type_literal_A01_t01 > TEST=runtime/tests/vm/dart/have_same_runtime_type_test > > Fixes #46893 > Issue #46231 > > Change-Id: Ie24a9f527f66a06118427b7a09e49c03dff93d8e > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210066 > Commit-Queue: Alexander Markov <alexmarkov@google.com> > Reviewed-by: Tess Strickland <sstrickl@google.com> TEST=co19/LanguageFeatures/Constructor-tear-offs/type_literal_A01_t01 TEST=runtime/tests/vm/dart/have_same_runtime_type_test TEST=lib/mirrors/regress_b196606044_test Fixes #46893 Issue #46231 Change-Id: I79b587540338808bd73a6554f00a5eed042f4c26 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210201 Commit-Queue: Alexander Markov <alexmarkov@google.com> Reviewed-by: Tess Strickland <sstrickl@google.com>
Status of co19 tests on the most recent version of tests from co19 repository (at https://github.com/dart-lang/co19/commits/6cb0670b42ddd2a74d65f7d69213af76ef5f8ac9): dartk-strong-linux-release-x64, dartk-weak-asserts-linux-release-x64: 185 tests passed, 7 failed (5 CompileTimeError, 2 MissingCompileTimeError). dartkp-strong-linux-release-x64, dartkp-weak-asserts-linux-release-x64: 184 tests passed, 8 failed (6 CompileTimeError, 2 MissingCompileTimeError). There are no outstanding VM bugs. |
Uh oh!
There was an error while loading. Please reload this page.
This issue tracks support of the constructor tearoffs feature. See the enclosing meta-issue for details.
The text was updated successfully, but these errors were encountered: