To insert covariant checks, CFE was searching for covariance in
contravariant positions and _not_ for non-covariant
(=contravariant+invariant) positions of type parameters. This
let to the omission of needed checks when type parameteres were
used in invariant positions (in function type parameter bounds).
Closes#37476
Change-Id: Icb4a827e75aee1a679ef7175d36904bbfbf6aa0a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108815
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This change adds support for bytecode generation in incremental compiler in
kernel service. Bytecode generation is performed as a post-processing step,
after delta components are merged.
Bytecode generation requires CoreTypes and ClassHierarchy, which cannot be
constructed using delta component from incremental compilation (as it doesn't
contain platform or previously compiled libraries). The solution is to obtain
CoreTypes and ClassHierarchy directly from incremental compiler.
Now the following tests work:
vm/cc/IsolateReload_KernelIncrementalCompile
vm/cc/IsolateReload_KernelIncrementalCompileAppAndLib
Change-Id: I34c5870b01850c057ace71a63f8effa5b010cfcf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108682
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
The objective of this CL is to allow the incremental compiler to track
which dill input libraries it actually used (in order to - in a modular
context - be able to ignore changes to dependencies we didn't really
use).
This is done by:
* Making the dill library builder lazy (and mark if it has been used).
* Making kernels class hierarchy record which classes it has been
asked questions about.
* Add special handling to redirecting factory constructors as they
bypass the fasta-builders and directly use the kernel ast.
Please note that:
* This has to be enabled, but kernels class hierarchy always records
which classes it was asked about (even if disabled,
or not running though the incremental compiler).
There might potentially be some overhead to this (though setting
a bool to true is probably comparably cheap - we did just do a
map lookup).
* This was designed to be used together with modules
(e.g. setModulesToLoadOnNextComputeDelta) - as used via for instance
api_unstable/bazel_worker.dart. It might not function the way you'd
expect in other circumstances.
* The incremental compiler (potentially) gives you the full kernel tree
despite not having marked all of those libraries as 'used'. If a
client use such libraries it is the clients responsibility to take
that into account when answering any questions about this
libraries/dill files was used.
* This feature works on the library level. In practice it is most likely
needed at the dill-filename level. A translation from library to
dill-filename is up to the client.
* This is a new feature, and we cannot promise that 100% of actually
used libraries are marked. If you find used but un-marked libraries
please report a bug.
Change-Id: I01d7ff95b9baac9550b77d8e09ea772d43173641
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107280
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
- Pass empty environment defines into CompilerOptions - to ensure that
there are no unevaluated constants in the output. VM does not expect
those.
- Include constant table when comparing expectations
Change-Id: I276e8bf8ce1f4f39c63265e4ae2650953649e41f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108800
Auto-Submit: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Normally, TFA runs after constant evaluation and it expects @pragma
annotations in the evaluated form. In unit tests TFA runs after
front-end and it was expecting @pragma annotations in the expression
form. With constants-update-2018 front-end starts evaluating constants,
so TFA unit tests should switch from ExpressionPragmaAnnotationParser
to ConstantPragmaAnnotationParser.
This CL does not update test expectations as flag is not flipped yet.
Test expectations should be updated when flipping a flag using
tools/test.py -m release --vm-options -DupdateExpectations=true pkg/vm
Change-Id: I94ee2de9f70328ce3ed3ffd9902a92eeb26d3a29
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108840
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Samir Jindel <sjindel@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This:
(1) Uses dartdevc and kernel_worker directly to build ddk artifacts.
(2) Generates an outline file instead of a full dill file for ddc_sdk.dill.
(3) Fixes source maps in the shipped sdk so that urls from dart_sdk.js.map
have correct relative paths to dart files in the sdk. This won't work with
webdev/build as that copies and serves dart_sdk.js, but it will now be
able to build the sdk directly.
Change-Id: I7b9470fe18cac9b4343c7c520fe6ffd7bd9246b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104842
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vijay Menon <vsm@google.com>
This CL reworks the tests flow_analysis_test.dart and
type_promotion_test.dart to make use of the framework recently
introduced into pkg/front_end/lib/src/testing/id.dart. The long term
goal is to move these tests into a common location so that they can
exercise both the front end and the analyzer.
Change-Id: Iad95065e995b0fe3c6e4990d2ea015215895743a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108265
Reviewed-by: Johnni Winther <johnniwinther@google.com>
CFE failed to replace an invalid AwaitExpression in a non-async context
with an InvalidExpression. The lead to untransformed (and thus unexpected)
await expressions crashing the hot reload.
Closes#37108
Change-Id: I4457925b20749d231cbf9dac80203ee9b381a312
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107501
Reviewed-by: Dan Rubel <danrubel@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
For const constructors, we need to compile the initializer expressions
and write them into the outline so that we can perform modular
constant evaluation. As a first step, preserve the tokens for the
initializer expressions in const constructor builders when building
the outline.
Currently they are discarded later during outline building at the
point when we should compile them instead.
Change-Id: Ief8d94ceb752b2315982d720836496b7d597e55c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107509
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
If an abstract method overrides a concrete method, and the abstract one
is more specific, it's an error, unless there's a user-defined
noSuchMethod, effectively making the abstract method concrete.
Change-Id: I06ebe2de257ef6627529e6e97ca11b768c9647b9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/106084
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
The CL fixes how override-based inference works in the cases when the
type of a parameter in the overriding method is omitted, and the type
of this parameter in the overridden method contains a type parameter
of the class. Basically, the type should be substituted in this case.
Change-Id: I36d6c614d47e5cd68dc14eae1a2bbe4cd19d842b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104784
Reviewed-by: Aske Simon Christensen <askesc@google.com>
If both the getter and the setter are present in the superclass, the type should
be taken from the setter.
Change-Id: Ie0d84e45d15341151af4a688c508da0f1d7b522d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101988
Reviewed-by: Aske Simon Christensen <askesc@google.com>
In the upstream CL https://dart-review.googlesource.com/c/sdk/+/100580 the
'covariant' bit on parameters of class methods isn't propagated correctly in the
case of mixins. Effectively, if it's used in a member of the superclass of the
mixin application, it won't be propagated to the mixin application or its
subclasses. Consider the following:
```
class A {
void foo(covariant num x) {}
}
class B {
void foo(num x) {}
}
class C {
void foo(num x) {}
}
class D extends A with B implements C {
void foo(int x) {}
}
```
The program above doesn't have any errors, and overriding foo in D using int as
the type of the parameter is allowed, because D's superclass A declares the
parameter as 'covariant'. Without the changes from this CL, the code will
result in a compile-time error. With the change, the 'covariant' bit is
propagated correctly, and the program compiles.
An existing test already covers the described behavior: see class Mixed in
tests/language_2/covariant_override/tear_off_type_test.dart.
Change-Id: Ia508a224527c95f5ef04c1f1fb02614f8ff43714
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101284
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Previously we were just getting the default experiment flags (regardless of the arg),
which never matched any experiments passed in, so we always threw away the world.
I also added invalidation based on experiment flags for DDC.
This gives overall ~20% initial build time reduction for flutter gallery, and ~30% for angular_components_example.
Change-Id: I578d9611b89d3776e45ae8d309cfe8f70c7b7edd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107188
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
Also actually compare the SDK summary digest instead of assuming it doesn't change.
Most of this logic is mirroring logic in the bazel_worker.dart file that kernel uses, which eventually we should unify.
Change-Id: If33af0d8de0b0a6a17081dcd852dd036c4b34a82
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107184
Auto-Submit: Jake Macdonald <jakemac@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>