This allows dartdevk to compile tests that import packages like expect.
There are a few pieces to this:
- Add support to build_pkgs.dart to build the kernel summaries for each
test package (in addition to the analyzer summaries it already
builds).
- Plumb that through the dartdevc_test target in the GN build as well.
- While we're at it, use GN to build the ddc_sdk.dill file and have
test.dart load that one instead of the manually built one from calling
./tool/kernel_sdk.dart.
- Add command-line arguments to dartdevk for passing in the path to the
SDK summary and the other summaries to compile against.
- Fix a little typo in processed_options.dart that was preventing it
from resolving "package:" URIs.
- In test.dart, when compiling a test, link in the summaries for all of
the test packages.
At runtime, it still uses the JS for those packages generated from the
old analyzer-based front end since the kernel-based compiler isn't
complete enough to compile any of those packages yet.
With all of this, if I change a test to:
import "package:expect/expect.dart";
main() {
Expect.equals("a", "b");
}
Then it compiles but fails at runtime. The compiler is completing, but
the generated code has some bugs. I don't know enough to fix them
myself, but here's what I've found out:
- In _libraryToModule(), the Library we get from kernel has a null
fileUri, so this returns an empty string. That in turn means the
generated JS tries to use "$" as the module name.
Using this works around it temporarily:
if (moduleName.isEmpty) moduleName = library.name;
- In _emitTopLevelNameNoInterop(), it doesn't handle the case where the
NamedNode is a static method on a class. It just generates the library
and method name, skipping the class, so "Expect.equals(1, 2)" gets
compiled to "expect.equals(1, 2)" instead of
"expect.Expect.equals(1, 2)".
Change-Id: I6bd9d98bc9706965160d8fb7cf70b20eeebab3a8
Reviewed-on: https://dart-review.googlesource.com/16687
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Vijay Menon <vsm@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>
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>
Before this CL vmservice_io.dill included the entire platform
(marked as external), and as thus the dill file was big (4MB+).
With this CL the external libraries are not serialized. While this
doesn't appear to change anything speed-wise it does make the
vmservice_io.dill go from 4MB+ to ~225KB.
Bug:
Change-Id: I6243677b5f4667318c6771132fc0326b7c62ecd0
Reviewed-on: https://dart-review.googlesource.com/8501
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Previously lazy loading was done in Procedure by lazy loading functionNode,
now lazy loading is done (only through Procedure) in the functionNode by
lazy loading the body.
Bug:
Change-Id: I25cc86d038123ed4992162b65aa95781ea2c56e8
Reviewed-on: https://dart-review.googlesource.com/15560
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
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 removes a number of properties, most notably fileUri and
charOffset from TypeBuilder.
Change-Id: I9508bfb754f725199a8677d10d7d4be9eb351821
Reviewed-on: https://dart-review.googlesource.com/15180
Commit-Queue: Peter von der Ahé <ahe@google.com>
Reviewed-by: Aske Simon Christensen <askesc@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 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>
Peter von der Ahé