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>
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>
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>
With this CL, we stop creating the old AccessorNode objects and start
creating the inference nodes associated with the new ForwardingNode
infrastructure. This fully integrates top level type inference with
forwarding stub generation.
There is a small difference between the behavior of the old and new
type inference infrastructure: in the old infrastructure, when
inferring the type of a getter or setter, we would consider both
inherited getters and inherited setters. Now, we follow the spec.
This introduces some minor differences from analyzer functionality, so
the tests of this functionality are moved into the "inference_new"
directory.
Change-Id: Ie17df9abf1a3ab99e7d22683ffdf6d1b13ec86be
Reviewed-on: https://dart-review.googlesource.com/13180
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This required adding a few extra parser events to allow the type
propagator to update its state when the `?` and `:` are encountered
(similar to what was done for `if`).
Fixes#30620.
Change-Id: I0d3ede8056fd8bab01ead5b242d00803286c9373
Reviewed-on: https://dart-review.googlesource.com/13182
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This allows covariance information to propagate properly between
classes and avoids creation of unnecessary forwarding stubs.
Change-Id: Ib55c62adb74d16f94282e752e387634086001946
Reviewed-on: https://dart-review.googlesource.com/12600
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
When a variable declaration in a for initializer has an error,
an error-throwing expression statement is produced by the general
variable declaration parser code. The body builder was not prepared
for this, but was trivially extended to handle it.
Closes https://github.com/dart-lang/sdk/issues/29984
Change-Id: Iace9a095cc150e26e62ed17716823e62e5d2ece3
Reviewed-on: https://dart-review.googlesource.com/8801
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
The inferred types for const expressions shouldn't refer to type
variables that are in scope, because at runtime those type variables
may take on different values at different times (meaning the const
expression isn't actually const after all).
Test cases are in inference_new, since analyzer implements incorrect
behavior.
Fixes#30677.
Change-Id: I27b9a95a92557ad1ce1c2c0f28d9a760c372d52a
Reviewed-on: https://dart-review.googlesource.com/5298
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL addresses desugared assignments produced for assignments to
local and static variables.
Change-Id: I1e02745c65ef717a8f6484a0eed35c4ada3b89ac
Reviewed-on: https://dart-review.googlesource.com/4280
Reviewed-by: Peter von der Ahé <ahe@google.com>
Fixes#30582.
I'll address other kinds of assignments (assignment to a local
variable, static field/setter, or property) in follow up CLs.
Change-Id: I9055e951dc23a4aa1aa19489cf99a832319938c9
Reviewed-on: https://dart-review.googlesource.com/4184
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL implements type promotion logic for both `&&` and `||`;
however, the logic for `||` has no effect, since `_factsWhenFalse`
always returns the current facts. This is consistent with the current
Dart specification (which only specifies type promotion for `&&`).
Change-Id: I79f608aa33ea0501bb4bba303949330af2da4dda
Reviewed-on: https://dart-review.googlesource.com/3345
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Previous to this CL, inference of `??` matched the behavior specified
in the informal spec (https://github.com/dart-lang/sdk/pull/29371),
whereas inference of `?:` matched analyzer behavior.
In the long run, we want the behavior of both `??` and `?:` to match
the spec (note that the spec is still being debated, so this is a
moving target). But for now, to ease the transition to the new front
end, we want to match analyzer behavior.
With this CL, the inference for `??` is changed to match analyzer
behavior, and a boolean is introduced to make it easy for us to switch
to the behavior specified in the informal spec when it's appropriate
to do so.
Should address the inconsistency pointed out in #30624.
Change-Id: I33d95cd59e4c7e474f3ba27491be87c1bf66d85e
Reviewed-on: https://dart-review.googlesource.com/3421
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Paul Berry