* Enable --limit-ints-to-64-bits for CFE when it is used to generate
kernel for VM as CFE relies on int.parse being able to parse correct
literals and reject incorrect.
* Pass --limit-ints-to-64-bits to gen_kernel via environment
variable to support batch mode compilation.
* Use current Dart SDK instead of checked-in Dart SDK to run CFE
in gen_kernel as checked-in Dart SDK is old and it doesn't have
int.parse fix yet.
Issue: https://github.com/dart-lang/sdk/issues/31339
Change-Id: Iaba2a7945a3faa9427f9aab1e9f2b907fa2246a3
Reviewed-on: https://dart-review.googlesource.com/29941
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The optimizer uses the "is more specific than" relation to eliminate type tests.
In strong mode, the "is more specific than" relation is supposed to be identical
to the "is subtype of" relation. However, it is not quite true, and this is the
cause of this bug. In non-strong mode (Dart 1), the "is more specific than"
relation uses covariance for both result type and parameter types of functions.
In strong mode, we need covariance of result type and contravariance of
parameter types.
Added regression test and updated status files.
Change-Id: I6315643890db75213af6720aa99d8da7b15f99d6
Bug:
Reviewed-on: https://dart-review.googlesource.com/29900
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Régis Crelier <regis@google.com>
Fixes#31586.
Note that none of the back-ends handle Instantiation nodes yet, so the
language_2 tests added in this CL
(instantiate_tearoff_after_contravariance_check_test,
instantiate_tearoff_of_call_test, and instantiate_tearoff_test) fail
pretty much across the board right now.
Includes two fixes to Instantiation.getStaticType and the kernel type checker:
- Previously, they attempted to perform substitution on the full
function type, which had no effect because the type parameters were
bound.
- The type checker was not checking that type parameter bounds were
satisfied.
Note that the front end doesn't yet check that type parameter bounds
are satisfied by the inferred type parameters. I will address that in
a follow-up CL.
Change-Id: Ib0ad7a5fc5f4a2fdc8c99abe1f2d3d15b21a4974
Reviewed-on: https://dart-review.googlesource.com/29744
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The analyzer used to emit a warning when a type parameter to a generic
method was used in an "is" check. This warning was there to help
users write code that worked correctly on both Dart 1.0 and 2.0. Now
that 2.0 generic methods are being more broadly supported and used,
this warning is blocking further library work, and is being removed.
Fixes https://github.com/dart-lang/sdk/issues/30530
Bug:
Change-Id: I70395305ad082aee3072b5beeb0b1b7f7883391b
Reviewed-on: https://dart-review.googlesource.com/29821
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
* CompileStaticInitializer() should check result of Compile()
and should not leave sticky error. If left, this sticky error
could be picked up by compilation of some unrelated static
initializer. Also, assertions are added to make sure that code
which explicitly or implicitly relies on sticky errors is not
getting an error on entry.
* CompileStaticInitializerIgnoreErrors() clears sticky errors to
ignore them.
* Added inline bailout reason for cyclic static fields.
This guards against inlining of code which uses a field into static
initializer. This code might not be called so it should not trigger
compilation error eagerly.
Change-Id: I52da6f4cd05556125fd1a628b665dcc11621a4f7
Reviewed-on: https://dart-review.googlesource.com/28523
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Without strong mode, a "good enough" implementation is to simply call
the generic method with "dynamic" for the type arguments, which is what
this does. That should be enough to unblock our internal users.
We also need to not report a compile error when
dart_internal/extract_type_arguments.dart imports the hidden
"dart:_internal" library.
This patch does both of those for the VM and dart2js (using its old
front end).
Note that the test still fails because the test is more particular than
most actual user code would be -- it validates that the instantiated
type arguments are *exactly* correct, and not that the returned object
is merely subtype compatible.
Bug:
Change-Id: I0343beace4991861b29712b3fd7067ec8dc8f8ba
Reviewed-on: https://dart-review.googlesource.com/28020
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
The named import makes it into the kernel class name (meaning it has a
dot in it). That is currently not cleaned up when creating js code,
but it is catched as a non-legal js identifier.
```
Unhandled exception:
Invalid argument (name): not a valid identifier: "_Object$collection.ListMixin"
#0 new Identifier (package:dev_compiler/src/js_ast/nodes.dart:1148)
#1 ProgramCompiler._emitClassStatement (package:dev_compiler/src/kernel/compiler.dart:573)
#2 ProgramCompiler._defineClass (package:dev_compiler/src/kernel/compiler.dart:679)
#3 ProgramCompiler._emitClassDeclaration (package:dev_compiler/src/kernel/compiler.dart:501)
#4 ProgramCompiler._emitClass (package:dev_compiler/src/kernel/compiler.dart:450)
#5 List.forEach (dart:core-patch/dart:core/growable_array.dart:274)
#6 ProgramCompiler._emitLibrary (package:dev_compiler/src/kernel/compiler.dart:393)
#7 Iterable.forEach (dart:core/iterable.dart:226)
#8 ProgramCompiler.emitProgram (package:dev_compiler/src/kernel/compiler.dart:282)
#9 compileToJSModule (package:dev_compiler/src/kernel/command.dart:166)
#10 _compile (package:dev_compiler/src/kernel/command.dart:145)
```
Bug:
Change-Id: Ibb5a1c908c2ddba63600446f6062ced1b5dd34c2
Reviewed-on: https://dart-review.googlesource.com/28662
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
DDK, when visiting a let, wants to add a temporary into a list that has
not always been initialized.
```
Unhandled exception:
NoSuchMethodError: The method 'add' was called on null.
Receiver: null
Tried calling: add(Instance of 'TemporaryId')
#0 Object.noSuchMethod (dart:core-patch/dart:core/object_patch.dart:46)
#1 ProgramCompiler.visitLet (package:dev_compiler/src/kernel/compiler.dart:4762:21)
#2 Let.accept (package:kernel/ast.dart:3425:36)
#3 ProgramCompiler._visitAndMarkExpression (package:dev_compiler/src/kernel/compiler.dart:2996:31)
#4 ProgramCompiler._visitInitializer (package:dev_compiler/src/kernel/compiler.dart:1481:11)
#5 ProgramCompiler._emitLazyFields (package:dev_compiler/src/kernel/compiler.dart:2058:19)
#6 ProgramCompiler._emitLibrary (package:dev_compiler/src/kernel/compiler.dart:402:47)
#7 Iterable.forEach (dart:core/iterable.dart:226)
#8 ProgramCompiler.emitProgram (package:dev_compiler/src/kernel/compiler.dart:282:15)
#9 compileToJSModule (package:dev_compiler/src/kernel/command.dart:169:19)
#10 _compile (package:dev_compiler/src/kernel/command.dart:148:18)
```
Bug:
Change-Id: I337e05a7494e87e3e6ae047ceae8ca8f954b6226
Reviewed-on: https://dart-review.googlesource.com/28660
Reviewed-by: Karl Klose <karlklose@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Currently I get this when trying to compile with DDK:
```
Unhandled exception:
Concurrent modification during iteration: Instance(length:2) of '_GrowableList'.
<asynchronous suspension>
<asynchronous suspension>
<asynchronous suspension>
```
Bug:
Change-Id: I4d0cc88aeab4c9cab54a0d1f67ec5302110b2fe7
Reviewed-on: https://dart-review.googlesource.com/28580
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Preliminary testing shows, this increases performance by around 20%. The
main benefit is by re-using a warmed-up VM and not start one from
scratch for every compilation.
Going forward we can do more optimizations, e.g. reading the platform
dill file only once into memory (instead of repeatedly) ...
=> This requires us using the new state-full IKG compiler.
Issue https://github.com/dart-lang/sdk/issues/31585
Change-Id: I2d3448783fc118611baf4671187a897227a65a6c
Reviewed-on: https://dart-review.googlesource.com/28400
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
If a .dill file is specified on the VM command line (dart/dart_bootstrap),
and --kernel-binaries is not specified, then this dill file is used as
the source of platform libraries.
It supports the case of AOT-compiling a self-contained .dill file.
Change-Id: I42956a20b98958b9a2440f156fbbef17bfc359f8
Reviewed-on: https://dart-review.googlesource.com/24341
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
There is no actual implementation here yet (that's your job :) ), but there is:
- An external method in dart:_internal, extractTypeArguments().
- Empty patch methods for that for the VM, dart2js, and DDC. These need to have implementations
filled in.
- A "dart_internal" package to expose a subset of the API. It gives you:
extractListTypeArgument()
extractMapTypeArguments()
We'll bring this into Google, but not publish it externally unless we find we really need to.
- A test for the behavior. It probably has bugs since I can't run it.
See: https://github.com/dart-lang/sdk/issues/31371
Change-Id: I7d9f9a3a36f8e8be106440375c80d584898c83cb
Reviewed-on: https://dart-review.googlesource.com/26467
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
This is needed such that the expected outcome correctly characterizes
the nature of the fault during spec_parser.py test runs.
Change-Id: Iec0d9dd613f8d05793aac019ab9fc06261609a6b
Reviewed-on: https://dart-review.googlesource.com/27163
Reviewed-by: Erik Ernst <eernst@google.com>
Régis Crelier