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>
* 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>
Before: ownership of some or all of the libraries from one Kernel
program (P1) would be transferred to another program (P2). All the
canonical names in P1 would be unbound from their references and the
canonical names would eventually be recreated for the libraries that
were transferred.
After: when ownership of a library is transferred, the ownership of
the canonical name subtree rooted at the library's name is also
transferred. This allows the 1:1 relationship between Canonicalname
and Reference to be maintained which will enable lazy deserialization
of procedure bodies (because the mapping from CanonicalNames to
References in the corresponding link table will be persistent).
Change-Id: I98f975d6ba5804f975c30528a484756b39f09d2a
Reviewed-on: https://dart-review.googlesource.com/7549
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
- We now favor Platform.packageConfig (if non-null) for finding the
.packages file.
- We allow .dart files to be symbolic links.
These changes allow the test to work inside google3.
Change-Id: I58939a1c89ee326d98fb9ab5ab56c5d9881c6823
Reviewed-on: https://dart-review.googlesource.com/7584
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Several tests need to access source files in the 'pkg' directory, and
they use various mechanisms for finding it. This CL changes
everything to use the same mechanism.
Change-Id: I146a6d72ec05a20cf07451a83eada9fb8e71a966
Reviewed-on: https://dart-review.googlesource.com/5484
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This is a first cut at a new test for messages.yaml.
The long term goal is for this test to:
- Assert each error code maps to analyzer error code.
- Assert each error code has at least one example.
- Analyze each associated example
to assert that the error code is generated.
Carried forward from https://codereview.chromium.org/3010843002/
Change-Id: I24dea5556896011287ac81036641b547d1107a5a
Reviewed-on: https://dart-review.googlesource.com/5285
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Rather than track precisely which types can be passed to each method
parameter through all of the interfaces it implements, and mark them
as semiSafe when they don't match the declared parameter type, it is
simpler to simply make semiSafe an "inherited" version of semiTyped.
The simpler analysis is slightly conservative--it will unnecessarily
mark parameters as semiSafe in a few circumstances, but those
circumstances seem like they will be rare enough that they don't
justify doing extra work.
This allows us to get rid of the extra field additionalIncomingTypes
(which we would otherwise have had to store in the kernel
representation).
In the process, reworked the logic for deciding whether to mark a
parameter as semiSafe or semiTyped so that it uses a type visitor
rather than by substituting and then doing a subtype check; this
should be significantly faster.
Note that in order for semiSafe to be "inherited" in all the right
circumstances, we need to mark it on abstract methods as well as
concrete ones; this is a departure from analyzer behavior, so I've
added a hack to front_end_runtime_check_test to ensure that it
generates the expected annotations.
Change-Id: I53d3718d8fb1979ac8551fe02734ddaf3d6708b8
Reviewed-on: https://dart-review.googlesource.com/5044
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Supermixin support is not currently planned for the initial release of
Dart 2.0, so it seems unwise for front end and kernel to enable it.
Kernel didn't actually contain any usages of supermixin support; front
end contained one usage in a test.
Change-Id: I2b225f8d6c5f0ea32cb60d7636e043c89439548c
Reviewed-on: https://dart-review.googlesource.com/3020
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
1. Instead of using a single lib/lib.dart, use a couple of small shared
libraries, and special libraries for each case we want to test.
2. Give tests meaningful structured names, with "source_*" tests
testing that we take into account referenced *from* somewhere.
And "target_*" tests for testing that we include referenced entities.
And "transitive_*" tests for including complete transitive closure
of referenced entities.
We don't yet include full transitive closure, this CL is just for
tests and results produced at the moment. Implementation and test
fixes will follow.
We also don't yet take exports into account.
R=ahe@google.com, paulberry@google.com, sigmund@google.com
BUG=
Review-Url: https://codereview.chromium.org/3011663002 .
Paul Berry