These methods both are guaranteed to return Procedures, due to the
fact that we only store Procedures in the `candidates` lists.
Change-Id: Ia07f9383baede71960717f8ef905fdd042baf841
Reviewed-on: https://dart-review.googlesource.com/16300
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This required a couple small fixes where we had made assumptions in our system
about not having anything other than dart, package, and file URIs.
Change-Id: Ie0943f609ceeaacf3fb284ceba0df5c55c315b0b
Reviewed-on: https://dart-review.googlesource.com/11650
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Peter von der Ahé <ahe@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>
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>
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>
Two changes:
- ShadowClass.getClassInferenceInfo now accepts an ordinary class, and
returns `null`. This will allow us to ensure that if a ShadowClass
gets re-used later as an ordinary Class (which sometimes happens
during incremental analysis), it will behave the same as an ordinary
Class.
- We don't create ShadowClass._inferenceInfo at the time of
ShadowClass creation; we wait until a builder is stored. This will
allow ShadowClass objects with no inference info to be easily
created in unit tests.
Change-Id: I0dd2d65b0c477b069ec36872c13b19ba8ebbd021
Reviewed-on: https://dart-review.googlesource.com/12382
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This is necessary because the need for a forwarding stub may be
affected by the types of inherited accessors, and the types of
inherited accessors may need to be determined by type inference.
Change-Id: I160cf21186485d2572301f3cda8621ede517c47b
Reviewed-on: https://dart-review.googlesource.com/12400
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This will simplify integrating top level type inference with the
InterfaceResolver, since the instrumentation logic won't have to be
migrated.
Change-Id: I89a23888d92622549c493249fd3d98c6ee5af8da
Reviewed-on: https://dart-review.googlesource.com/12124
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This separates compiling platform.dill files from the patch_sdk.dart
script. The motivation for that is that I'm working on reading patch
files directly from Fasta, so we can completely remove the build step
for generating patched_sdk and dart2js_patched_sdk.
Short-term this should allow Paul to add a strong-mode version of
platform.dill without causing to many conflicts with my work on
patches.
Change-Id: I1150845b2986348d4fffe27092701d8a9b57ea54
Reviewed-on: https://dart-review.googlesource.com/11506
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Type inference of methods now occurs during
SourceLoader.prepareTopLevelInference. Since this method visits
classes in class hierarchy order, we no longer need special logic to
ensure that base classes are inferred before derived classes.
Change-Id: Idf9f67226005bee6986d026c255e83926b4253d6
Reviewed-on: https://dart-review.googlesource.com/11560
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
We only need to retain long-lived forwarding nodes for getters and
setters; methods and operators can be resolved immediately, since
their resolution can't depend on top level type inference of
initializers.
This should help speed up InterfaceResolver by reducing the number of
long-lived objects it leaves in the heap.
Change-Id: I05f8d5ed1c12968f4382d43ae23955171cdbfc05
Reviewed-on: https://dart-review.googlesource.com/11241
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL replaces outdated VmTarget and FlutterTarget with VmFastaTarget
and FlutterFastaTarget. 'Fasta' suffix is droped from target names.
The new FlutterTarget extends VmTarget, so they share more code.
Change-Id: Id79956698a889c9a49b8a67914f1f96a731407ab
Reviewed-on: https://dart-review.googlesource.com/9423
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
When creating a forwarding stub for a method like this:
class C<T> {
void foo<U>(T x, U y) {}
}
class D<V> extends C<V> {
// Forwarding stub needed here
}
Two substitutions need to be done:
- We need to substitute V in place of T.
- We need to substitute the generic parameter for the forwarding stub
in place of the generic parameter for the method being overridden.
So the generated method should look like this:
class D<V> extends C<V> {
void foo<W>(V x, W y) => super.foo<W>(x, y);
}
Change-Id: Id846611c499b9aad4f042380862cbad08a6f1c17
Reviewed-on: https://dart-review.googlesource.com/10581
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
For the moment there is some duplicate functionality: both
InterfaceResolver and CovariancePropagator will try to propagate
covariance annotations. This is ok for the short term, since
InterfaceResolver is still incomplete. Once InterfaceResolver is
complete, I'll remove CovariancePropagater.
Note that forwarding stubs are now created, but they are not yet added
to classes, so they don't appear in the compiled kernel output.
Change-Id: I0a1814bd2abc5b63dbf7ceb6fc45f3da81728ee9
Reviewed-on: https://dart-review.googlesource.com/9788
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is necessary for two reasons:
- Sometimes we need to create a forwading stub that is abstract.
- Sometimes a class has an existing abstract member that needs to be
given an implementation.
Change-Id: I1fdb91ff421c1cd1234141db9c9b2190870164fa
Reviewed-on: https://dart-review.googlesource.com/9121
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
We have to generate a forwarding stub whenever the inherited member
isn't the same as the one that ClassHierarchy would have chosen, and
ClassHierarchy favors inheriting the first member. So this will avoid
creation of unnecessary forwarding stubs.
Change-Id: If2411c6ed0474da66544735b196f8042f98c2591
Reviewed-on: https://dart-review.googlesource.com/9063
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Konstantin Shcheglov