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>
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>
This will make it possible to delete CovariancePropagator without
regressing covariance instrumentation too badly.
Note that there are some small regressions due to the fact that
InferenceResolver doesn't yet correctly propagate covariance
annotations from a base class field to a subclass field/setter. These
regressions can't be fixed until after InferenceResolver is integrated
with top level type inference.
Change-Id: I29352484e9f13bbfa9b34d463c6b27eab7f9698f
Reviewed-on: https://dart-review.googlesource.com/10200
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@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>
Refactored the parseClass method in preparation for
adding recovery, updating error messages, and analyzer integration.
* Added several new parser events
- handleClassExtends
- handleClassImplements
- handleClassHeader
* Revised the endClassDeclaration event
Change-Id: Ib58893097650eefb45051b462e9df7260b7776b2
Reviewed-on: https://dart-review.googlesource.com/9580
Commit-Queue: Dan Rubel <danrubel@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This should fix the issue 30917 flakiness.
The reason why the tests were failing is that the code in the tests
was not quite correct Dart code, so Fasta generated a synthetic
`#errors` top-level variable with fileUri == null. We should skip
this field because it is not a part of any unit, because its fileUri
is not the fileUri of any unit.
But we lose fileUri for a Node if Program.uriToSource does not
include this URI. So, if we clear uriToSource in KernelDriver, we
lose all the file URIs. So, now we keep sources for the cycle files.
The reason for flakiness is because of the same race condition
between analyzing AnalysisDriver.addFile() and getResult(). If
we process getResult() before, we don't have to read the library
kernel file, we just create in first time, and fileUri(s) are
valid.
R=ahe@google.com, paulberry@google.com, sigmund@google.com
Bug: https://github.com/dart-lang/sdk/issues/30917
Change-Id: Ie559cf2a8a778ebf4a9e297f5cb13d30a98b5a3c
Reviewed-on: https://dart-review.googlesource.com/9744
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
* `as` clause and `deferred as` clause processing pushed
into a new processImportPrefixOpt method.
* New handleImportPrefix event for communicating
`as` clause and `deferred as` clause to the listeners.
* Several new more detailed error messages for out of order
clauses and keywords in the import directive.
Change-Id: I133842c7225403fa000ca1cf0e49af9f8a011386
Reviewed-on: https://dart-review.googlesource.com/8580
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
generator.
The script takes an input program Uri, and a file describing edits, and it mocks
applying the edits in multiple iterations.
incremental_perf_test illustrates how this can be used to do incremental
compiles of the dart2js source code.
Change-Id: I3518996a0faac34de8c6cef2f63468f4788b3c06
Reviewed-on: https://dart-review.googlesource.com/6026
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@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>
- New handleRecoverImport event
for clauses in import directive that are out of order
- New error codes for
Duplicate prefix
Prefix after combinator
Change-Id: I0fea7ad4b4014a0b8578d3982e0515fe85044854
Reviewed-on: https://dart-review.googlesource.com/7980
Commit-Queue: Dan Rubel <danrubel@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This should make it possible to run compile_platform_test.dart inside
google3, where package layout conventions are more strictly enforced
(files in test/ cannot import files in tool/).
Change-Id: I2299e0340b0edfc1a684a635de8cf87ecb9f241f
Reviewed-on: https://dart-review.googlesource.com/8701
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This method figures out which method a given forwarding node resolves
to, accounting properly for the fact that when there is multiple
inheritance, the inherited method is the one with the most specific
type.
Change-Id: Ia412e2d195dd697e35c1c08480b51f2a6bd1cac5
Reviewed-on: https://dart-review.googlesource.com/8360
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
One of the roles of InterfaceResolver will be to determine when
ClassHierarchy's technique for finding an inherited member would
produce the wrong result, and adding a forwarding stub when that
happens. Since ClassHierarchy's technique for finding an inherited
member is to just pick the first member it finds, we need to make sure
InterfaceResolver visits superclasses in the same order, so it will
know which member ClassHierarchy would pick.
This CL adds tests to make sure both classes visit members in the same
order, by testing that:
- methods in mixins take precedence over those from superclasses.
- methods in superclasses take precedence over those from interfaces.
- methods in interfaces are considered in the order in which the
interfaces are named.
Also, I discovered that it was unnecessary for InterfaceResolver to
visit mixins, since ClassHierarchy has already merged methods from
mixins into the list of members it considers to be "declared in" the
class.
Change-Id: If0ca03824887c87e0ae2090532c75cf6c5ad3161
Reviewed-on: https://dart-review.googlesource.com/8322
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL adds the ability to create a list of "forwarding nodes" for a
source class. A forwarding node is a data structure that will later
be resolved to either an explicitly declared member in the class or a
superclass, or to a forwarding stub. The idea is that we will create
the forwarding nodes at the time of outline building, and later,
during type inference, we will resolve each forwarding node as it is
encountered.
The reason we need to defer resolution of the forwarding nodes until
inference is because we may need to use the results of type inference
to determine which member a given forwarding node resolves to. For
example:
num f() => 1;
class A {
final x = 1; // Inferred type: int
}
class B {
final x = f(); // Inferred type: num
}
abstract class C implements A, B {}
We cannot determine at the time of building the outline for C whether
it inherits its x from A or B, because we need the results of type
inference to determine which of the two x's has a more specific type.
Note that some refactoring of ClassHierarchy was necessary in order to
allow the front end to maintain member lists in the same order used
internally by ClassHierarchy. This will let us avoid unnecessary
redundant sorting of methods.
Change-Id: Iee754957e0ad3b16c4b60608e17a4a7b0006dfb4
Reviewed-on: https://dart-review.googlesource.com/7851
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This will be needed once we start adding the creation of forwarding
stubs to inference, since we'll need to create the forwarding stubs
for base classes before creating the forwarding stubs for derived
classes.
Also, change the nomenclature "prepareInitializerInference" to
"prepareTopLevelInference" since this inference stage already infers
more things than just initializers, and will soon start doing even
more.
This required creating a "ShadowClass" class to allow easy access to
the SourceClassBuilder from the Class object. In future CLs I will
store other information related to inference and forwarding stubs in
ShadowClass.
Change-Id: Ie322c6c2230de2ffd2c042a707289992b1967f4f
Reviewed-on: https://dart-review.googlesource.com/7852
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
* Finish updating the fasta parser to handle native clauses
* Remove outdated native clause processing from listeners
Change-Id: I2797145d6aff07da2ee4e008d5e1f233f30813a2
Reviewed-on: https://dart-review.googlesource.com/7900
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Sigmund Cherem