The CL is reverted because it didn't account for the case when a check
of a user-specified type argument against the bound depends on another
type that is only known after type inference is done.
Change-Id: I1fd140af95ed37b9191a5b161a281d4639e3453f
Reviewed-on: https://dart-review.googlesource.com/c/79048
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Change-Id: I60f72904f4a9ae3427b2a2633a22f70a6b6f8ea9
Reviewed-on: https://dart-review.googlesource.com/c/79020
Commit-Queue: Peter von der Ahé <ahe@google.com>
Auto-Submit: Peter von der Ahé <ahe@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
The test isn't normally run, and all 12 testcases caused a crash.
Change-Id: Ie1576e32b70f01aa775c3305bff2bc992eebf86f
Reviewed-on: https://dart-review.googlesource.com/c/78940
Auto-Submit: Peter von der Ahé <ahe@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
* Ensure that we have a .dill file and it has the correct version before
we start decoding it in dump.dart.
* Throw errors, not strings. Ensure that they have a useful
toString().
* Do not print usage except when the command is invoked
incorrectly (wrong number of arguments). Once we get into the
command it's less likely that it's been invoked incorrectly and more
likely that something else has gone wrong.
Because these utilities are invoked from other scripts (like the
fasta command), printing their usage for problems other than
invoking them correctly doesn't match the way that they were invoked
and it's confusing.
Change-Id: I7832383594d2b3719a0a7a7392ba4685717a79d2
Reviewed-on: https://dart-review.googlesource.com/c/78206
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Demangle all names in messages to avoid printing mangled names in
user-facing output.
Point messages about implicit mixin application classes at the subclass
name for consistency with named mixin application classes.
Change-Id: I90973986c422f271af99e18b3deb5847adf4d430
Reviewed-on: https://dart-review.googlesource.com/c/77380
Reviewed-by: Kevin Millikin <kmillikin@google.com>
The code in class_hierarchy.dart that looped over override pairs
included implementations inherited from its superclass as potential
overriders, presumably in a broken attempt to include some interface
checks into the mix.
With this problem fixed, the special case in kernel_class_builder.dart
that excluded overriders not declared in the current class (i.e.
declared in a mixin) could be removed without incurring false
positives.
These override checks performed on members from a mixin produce an
extra context message indicating the class where the two members meet,
giving rise to the override relation (similarly to interface checks).
Since the same member can now override more than one member (or even
the same member more than once), the diagnostics message duplication
check has been extended to also include the context in the comparison.
Fixes https://github.com/dart-lang/sdk/issues/34235
Fixes https://github.com/dart-lang/sdk/issues/34285
Change-Id: I990e5719ae1749fd1aad1ad478aaa6e173cb170b
Reviewed-on: https://dart-review.googlesource.com/c/76900
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
When a member in the interface of a non-abstract class is found to
have an implementation with the correct name which does not override
the representative declaration of the member in the interface (and thus
has not been checked against that member for override validity), call
the override check to check interface validity.
Override relations thus checked produce an extra context message
explaining that the override relation must hold because both members
are inherited by a non-abstract class.
Fixes https://github.com/dart-lang/sdk/issues/32014
Change-Id: I955f057e35fa30f33c19da37c9cea1262042431c
Reviewed-on: https://dart-review.googlesource.com/c/74642
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Change-Id: I9882c2be31366cc85a1623a2b324ce4ec200aa20
Reviewed-on: https://dart-review.googlesource.com/c/77804
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Peter von der Ahé <ahe@google.com>
Allow super calls to occur in mixin declarations if they target a
method from any of the superclass constraint interfaces.
Instead of compiling the Dart mixin declaration
mixin M on S0, S1 {...}
to Kernel:
abstract class _M&S0&S1 = S0 with S1;
abstract class M extends _M&S0&S1 { ... }
we compile it to Kernel:
abstract class _M&S0&S1 implements S0, S1 {}
abstract class M extends _M&S0&S1 { ... }
because the former is not symmetrical with respect to S0 and S1. It
will prefer a method from the 'mixin' S1 over one from S0 which can
give a compile-time error if the method from S0 is more general.
Modify mixin inference to support the new compilation of mixin
declarations. It still has to support old-style VM super mixins until
support for those is removed from the VM.
Change-Id: Ib945aa11cc19c457b07bc802beae10d1663ff6b7
Reviewed-on: https://dart-review.googlesource.com/76141
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Teach TFA that small integer literals, which fit into Smi on all
platforms have a concrete class _Smi.
Change-Id: I4aec5389fc0a83f36077c1f1c0c9a5e59ff4b260
Reviewed-on: https://dart-review.googlesource.com/76302
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Depending on a value of a string literal, it is possible to determine
concrete class at compile time (either _OneByteString or _TwoByteString).
Change-Id: Ied696b328021e9a61f1ad14d02b88681a9ed4fed
Reviewed-on: https://dart-review.googlesource.com/76260
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Add a flag to Kernel classes that indicates that they were Dart mixin
declarations. Also, add an API to Kernel Class that allows a list of
superclass constraints to be gotten from it.
Change-Id: Ie78e7e56b5421dfb9d340e4330135b8d6f4e94f1
Reviewed-on: https://dart-review.googlesource.com/75261
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
If there are circular references between type parameters and types in the bounds,
currently serialization leaves original type parameters unchanged, which results
in failures to serialize compiled expression procedure.
This CL makes sure to clone all type parameters first, then passes map
with old-to-new type parameters to CloneVisitor.
Bug: https://github.com/dart-lang/sdk/issues/34052
Change-Id: Idf3e6e6e9099f93cdd7e970ab3b21921cdb29178
Reviewed-on: https://dart-review.googlesource.com/75241
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Change-Id: Ib9426243ae851bdf529f11d0d9b47c75679972fa
Reviewed-on: https://dart-review.googlesource.com/74760
Commit-Queue: Peter von der Ahé <ahe@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This reverts commit eec96f9076.
Revert "[vm/kernel] In async transformation check if strongMode is on."
This reverts commit 348ed30efd.
Reason for revert: getStaticType is unreliable in Kernel
R=alexmarkov@google.com
Change-Id: I08b914f947a00923491bb610ed74d6348882554f
Reviewed-on: https://dart-review.googlesource.com/75220
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
It seems we are still using non-strong mode targets in few
places (e.g. when training front-end server we by accident
train it in legacy mode).
A separate bug is filed to clean that up https://github.com/dart-lang/sdk/issues/34468
For now to unbreak the build we simply check if we are in the
legacy mode and then avoid using getStaticType in async
transformation.
This is followup to eec96f9076.
Bug: https://github.com/dart-lang/sdk/issues/34463
Change-Id: Ib693fddfb9abbf89599ae646cb408d4a9c93f1b6
Reviewed-on: https://dart-review.googlesource.com/75061
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Async transformation uses dynamic variables in few places (e.g.
for temporaries and for incomming arguments) - which creates
not strongly typed AST with method invocations having dynamic
receivers and non-null interface targets at the same time.
To maintain strong typedness of the AST we insert unsafeCast
when accessing the temporaries.
Bug: https://github.com/dart-lang/sdk/issues/34463
Change-Id: I11e38c128645ebc8acb0c982a80fe4c5c4036673
Reviewed-on: https://dart-review.googlesource.com/75000
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
The canonicalization of symbols needs to take library privacy into
account. Since the Symbol class itself only has a [_name] field but does
not reference in which library the symbol came from, the [_name] must be
mangled.
Mangling is done by backends and so we make a new [SymbolConstant] which
the backends can desugar by doing appropriate mangling and construction
of a [Symbol] instance.
Fixes https://github.com/dart-lang/sdk/issues/34396
Change-Id: I2e13288483c35f875d39eefdb73677b2cc03527a
Reviewed-on: https://dart-review.googlesource.com/74360
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This reverts commit ef72098353 as it broke
buildbot on CQ.
Change-Id: If9d19a9393157078d0e0890b92a418ba5ced42c6
Reviewed-on: https://dart-review.googlesource.com/74281
Reviewed-by: Alexander Markov <alexmarkov@google.com>
The canonicalization of symbols needs to take library privacy into
account. Since the Symbol class itself only has a [_name] field but does
not reference in which library the symbol came from, the [_name] must be
mangled.
Mangling is done by backends and so we make a new [SymbolConstant] which
the backends can desugar by doing appropriate mangling and construction
of a [Symbol] instance.
Fixes https://github.com/dart-lang/sdk/issues/34396
Change-Id: I5ddb5331ce79a0b942807929d4b8f1050a9899e7
Reviewed-on: https://dart-review.googlesource.com/73883
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Change a pair of package tests that relied on the existence of the
VM's Dart 1 platform Kernel binary. Use the Dart 2 platform instead,
becuase the VM will stop supporting Dart 1 in the future.
Change-Id: Ic93488974d9ed53cd205dcc24e0455a26b5f71b2
Reviewed-on: https://dart-review.googlesource.com/71246
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
This CL introduces a new abstract getter 'isConst' for Member class in
the AST. This change ought to be non-breaking since every subclass of
Member implements a boolean getter 'isConst'.
The primary motivation for introducing this change is that it enables
us to simplify some of the code base by eliminating some tedious
branching and/or casts to dynamic when we need to determine whether a
member is constant, e.g.
bool isConst = false;
if (member is Procedure) isConst = member.isConst;
else if (member is Constructor) isConst = member.isConst;
else if ...
becomes
bool isConst = member.isConst;
and
if ( (member as dynamic).isConst ) { ... }
becomes
if (member.isConst) { ... }
Change-Id: Ifcc3229c7a19dd8f261266f58df5eef562167885
Reviewed-on: https://dart-review.googlesource.com/71403
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Before this CL, if initializing from a dill file containing a class,
say A, but it wasn't used, and then later using it as a type, say
'A a = new A()', the class hierarchy would complain about not knowing A.
This was caused by the class hierarchy initially being constructed using
the full component of the first compile (i.e. in the example above
without any usage of A and thus without including A), and subsequent
compiles telling the class hierarchy about new classes created in that
compile. The problem was, that if the class was loaded from a dill file
(in the example above 'A' was such a class) it would never be included
if not a part of the first full component.
This CL fixes it by changing the interface to the class hierarchys
`applyTreeChanges` function and letting the class hierarchy know about
libraries too: It will now basically just be given the full component
when asked to update, and just update with the libraries it doesn't
already know about. In the example above that would - once using 'A' -
include 'A'.
Change-Id: I895100b51659938636da0bca6c80516d87b57a24
Reviewed-on: https://dart-review.googlesource.com/69302
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Currently we only annotate those call-sites that would result
in generic covariant checks performed on the callee side.
Bug: https://github.com/dart-lang/sdk/issues/31798
Change-Id: Ifcf60032036575f615015d716276484a7c1236b3
Reviewed-on: https://dart-review.googlesource.com/69580
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Similar to how dart2js keeps its own target in package compiler.
This allows VmTarget to use package vm specific transformations and metadata.
Change-Id: I41dd2ae241b828224fb2c9a51e6ad5073b6fdea8
Reviewed-on: https://dart-review.googlesource.com/69160
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
They were supposed to be used as a part of the closure conversion pass,
which is now obsoleted.
Change-Id: Ie063f6c44487df7cd5d21895e8edc03251525d5f
Reviewed-on: https://dart-review.googlesource.com/68662
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Set position on yield in sync* functions; use yield position in VM.
Change-Id: I1c92fd47e3c8d4f747242e076007c122ea0d2186
Reviewed-on: https://dart-review.googlesource.com/68366
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This changes how we step out of async* functions slightly to match how
Dart1 behaves.
Bug: #29158
Change-Id: I8ee2df5eee8167fd1907a6e9f30c9dc7ab6939b1
Reviewed-on: https://dart-review.googlesource.com/63625
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This changes how we step into async* functions slightly to match how
Dart1 behaves.
Bug: #29158
Change-Id: I4969ca48f798bd51f9d2d5bc26dd224fa7eff627
Reviewed-on: https://dart-review.googlesource.com/63624
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
See: https://github.com/dart-lang/sdk/issues/33901
Change-Id: I0bb8bc029865f2b46b052f50e49a5d2d13c5c81e
Reviewed-on: https://dart-review.googlesource.com/65981
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
