This should help make sure that the front end is inserting all of the
necessary implicit downcasts.
The type checker is run after comparing to golden files, and before
running the test in the VM. So if a test case fails to match its
golden file, the test's status will be "Fail" regardless of whether it
type checks. If the test case matches its golden file but fails to
type chek, the test's status will be "TypeCheckError". Rationale: the
type checker is still under development; if it has bugs leading to
false failures, we don't want that to get in the way of comparing
against golden files.
Change-Id: I6764aa5c7f2aab92a10edfa41afcdb056946530b
Reviewed-on: https://dart-review.googlesource.com/17522
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
This change brings down core snapshot size by ~750KB, and brings
down app-jit snapshot size of simple "Hello, World" dart script by
~650KB. The bot cycle times will also come down by around ~20%.
Change-Id: I2a01c98bedc7ebfa2a653983995486a71504daf3
Reviewed-on: https://dart-review.googlesource.com/16323
Commit-Queue: Siva Chandra <sivachandra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Notes on test changes:
- This revealed runtime failures in some tests in
pkg/front_end/testcases/inference. Since these tests were never
meant to exercise runtime behavior in the first place, I just
changed them so that main() does nothing.
- This revealed runtime failures in some tests in tests/language_2.
These tests began failing because they used "var" for a fields and
then later assigned a value to the field that was incompatible with
the inferred type. It looks like the intent was for these fields to
have type "dynamic", so I changed the tests accordingly.
Change-Id: I0ddb2063427b52b5e4be1884fa333e25be4bf4f3
Reviewed-on: https://dart-review.googlesource.com/16881
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Dart2JS and the VM prefer for Enum names to be stored inline in the Enum
object to avoid having the static array of all Enum values. A base class
for Enums is provided to avoid repeating the common fields and accessors
between Enum definitions.
Bug:
Change-Id: I783f863015b45f13317fda06e627d14844fe2ddf
Reviewed-on: https://dart-review.googlesource.com/16526
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Otherwise we might match up a getter to a setter and crash.
The test cases indirectly verify that mixin resolution does the right
thing by checking the semantics of the generated code. These tests do
not pass yet, because covariance checks are not yet implemented in the
VM.
Change-Id: Ibe6d8b7479f86151c515c45c20ed7c880bf2ad43
Reviewed-on: https://dart-review.googlesource.com/16686
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Karl Klose <karlklose@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The behavior was fixed some time ago, but I failed to notice that I
should have re-enabled the test because its expectations were wrong.
Fixes#30547.
Change-Id: I8b740a8b7f478cc9223cd5d91d2bc0e7e5cf2855
Reviewed-on: https://dart-review.googlesource.com/16700
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
When the interface inherited for a method is different from the super
method (due to the inherited interface method having a more specific
type than the super method), we determine the set of covariance fixes
that need to be made by looking at the inherited interface method
(since that's the method that the forwarding stub will be created
from). However, in order to decide whether the forwarding stub needs
to be concrete, we need to compare the checks needed against the
checks that are made by the super method.
A few unit tests of this functionality didn't have the correct
expectations (or contained other errors); they have been fixed.
Change-Id: I70cff371be3bf8f3680c756feb6047794b650a9d
Reviewed-on: https://dart-review.googlesource.com/16680
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
For compound assignments, we need to look up the "combiner" operation
in the type of the getter (not the setter), since the receiver of the
combiner operation is the value that was read. This is necessary for
soundness.
Change-Id: I02e0e93310b6b6b94d4a6253d4cf2fc1d3c69cd5
Reviewed-on: https://dart-review.googlesource.com/16607
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
These tests check that forwarding stubs are properly generated when
the type of the forwarding stub comes from a different class than the
superclass.
Two of the tests currently fail--I will follow up with a CL that fixes
them.
Change-Id: Id3db38bdc869e91d74fc279f39696f108d174a0d
Reviewed-on: https://dart-review.googlesource.com/16334
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Before: mixin application classes could not have methods of their
own.
After: type inference will sometimes insert forwarding stubs in mixin
application classes. In the mixin elimination transformation, these
forwarding stubs are replaced with the methods of the mixin class if
they have the same name, but the parameter flags from the forwarding
stub are retained. The other forwarding stubs are left as methods of
the class.
Change-Id: I5ee89d6b1fc83194df82009c2800b54ce856e8c5
Reviewed-on: https://dart-review.googlesource.com/15887
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
This has no effect on the generated kernel output; it just affects tests.
Also fix an incorrect type in field_forwarding_stub_explicit_covariant.dart.
Change-Id: Ic89d59a52648dc37a43cb12c4289611daaf422c6
Reviewed-on: https://dart-review.googlesource.com/15647
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Change abefb7b432 introduced a typing issue
instead of fixing it: _SyncIterator<T>._current was actually used to return
either a value of type T (for yield) or value of type Iterable<T> (for yield*)
from the move callback.
This change refactors implementation of _SyncIterator in such a way that
_current is only used to return value for yield and a separate field
_yieldEachIterable is used to return Iterable<T> for yield*.
Change-Id: I3e3c832bbc8986d6976ddbb0856a1b5a127d845b
Reviewed-on: https://dart-review.googlesource.com/15542
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Also add a test to verify that contravariance is properly handled for
method calls using "if-null" syntax (since this is handled by a
slightly different code path in the front end).
Change-Id: I93ee8b38ff39d78e25cac23ff048fcf69f15b5db
Reviewed-on: https://dart-review.googlesource.com/15000
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
BodyBuilder converts an expression in a for loop initializer to the
initialization of a dummy variable. It needed to create this dummy
variable using ShadowVariableDeclaration to ensure that type inference
would be applied to the dummy variable.
Fixes#31133
Change-Id: Ibe5ed95f20429af633cbe8d49b06aabaa9df41fd
Reviewed-on: https://dart-review.googlesource.com/15001
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The first phase, called `resolve`, happens during top level type
inference; it determines which inherited method a forwarding node
resolves to, and ensures that dependencies are type inferred. The
second phase, called `finalize`, happens at the end of top level type
inference; it creates forwarding stubs if necessary and propagates
covariance annotations.
The reason we need two phases is illustrated by the new test
pkg/front_end/testcases/inference/inheritance_does_not_imply_circularity.dart.
There should be a type inference dependency from I1::x to y, and from
y to C::x. But there shouldn't be a type inference dependency from
C::x to I1::x, since C::x's type is fully specified.
Splitting into two phases makes this work: during type inference, we
can resolve C::x without needing to consult the type of I1::x. Once
type inference is over, and the type of I1::x has been determined, we
can finalize C::x and determine whether any covariance annotations
need to be propagated.
Change-Id: If96e7b23e16723c421f91b3e37fe2a4485919c5c
Reviewed-on: https://dart-review.googlesource.com/13600
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This reverts commit 4bb83e9311
This reverts commit f1b07b2789.
Reason for revert on analyzer bots:
Analyzing pkg/analyzer...
error • Undefined name 'source' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:625:9 • undefined_identifier
error • Undefined name 'CompileTimeErrorCode' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:625:18 • undefined_identifier
error • Undefined name 'source' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:626:13 • undefined_identifier
error • Undefined name 'source' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:635:9 • undefined_identifier
error • Undefined name 'CompileTimeErrorCode' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:635:18 • undefined_identifier
error • Undefined name 'source' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:636:13 • undefined_identifier
error • Undefined name 'source' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:645:9 • undefined_identifier
error • Undefined name 'CompileTimeErrorCode' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:645:18 • undefined_identifier
error • Undefined name 'source' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:646:13 • undefined_identifier
error • Undefined name 'source' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:655:9 • undefined_identifier
error • Undefined name 'CompileTimeErrorCode' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:655:18 • undefined_identifier
error • Undefined name 'source' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:656:13 • undefined_identifier
12 errors found.
Change-Id: Ie2035bf40e50c48f85b514c7a3786141cd0f2453
Reviewed-on: https://dart-review.googlesource.com/14061
Reviewed-by: Martin Kustermann <kustermann@google.com>
The outer loops are now through the arguments of the method to be
fixed, and the inner loops are through the inherited methods. This
allows us to handle the situation where a forwarding stub is needed
because isGenericCovariantInterface changes from true to false, but
the forwarding stub doesn't need to be concrete, since
isGenericCovariantImpl is inherited from the base class. (Previously
that situation didn't work because by the time we processed the
inheritance of isGenericCovariantImpl, we had already created a
concrete forwarding stub).
Additional fixes in this CL (necessary to get tests to pass in
meaningful ways):
- Updated InstrumentationValueForForwardingStub to print covariance
annotations on type parameters.
- Updated _createForwardingStub to copy covariance annotations from
the target procedure to the procedure being created.
- Moved call_through_this.dart from runtime_checks/ to
runtime_checks_new/ because the analyzer implementation doesn't
handle this case correctly.
Change-Id: I984a46826a3a4d8ad1a1ce840269498df049fef0
Reviewed-on: https://dart-review.googlesource.com/13963
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Peter von der Ahé