Previously, we only stored a reference to the originating Typedef declaration
and is thus loosing the originating type arguments. We need these type arguments
in various places, including diagnostics and bounds checks.
Note: this CL maintains backwards compatibility wrt to the Dart API of
FunctionType. I'll update the API in a follow-up CL.
Change-Id: I896ce3c3b4522d542a82c5036f8a17ee098143dc
Reviewed-on: https://dart-review.googlesource.com/c/81367
Commit-Queue: Peter von der Ahé <ahe@google.com>
Auto-Submit: Peter von der Ahé <ahe@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This makes us report the following error
* in JIT:
Unhandled exception:
'test.dart': error: Type arguments must be instantiated in partial instantiation.
#0 main (...)
...
* in AOT:
test.dart:7:28: Error: The type '#lib1::C::T' is not a constant, only instantiated types are ...
const C({this.callback = _defaultCallback});
^
test.dart:7:17: Context: While analyzing:
const C({this.callback = _defaultCallback});
^
test.dart:5:37: Error: The type '#lib1::C::T' is not a constant, only instantiated types are ...
void foo([dynamic Function(T) f = _defaultCallback]) {}
^
test.dart:5:33: Context: While analyzing:
void foo([dynamic Function(T) f = _defaultCallback]) {}
^
test.dart:11:38: Error: The type '#lib1::bar::T' is not a constant, only instantiated types are ...
void bar<T>([dynamic Function(T) f = _defaultCallback]) {}
^
test.dart:11:34: Context: While analyzing:
void bar<T>([dynamic Function(T) f = _defaultCallback]) {}
Issue https://github.com/dart-lang/sdk/issues/32912
Change-Id: I05c7019119a50a9cc38939d9cb41aeaa06c853bc
Reviewed-on: https://dart-review.googlesource.com/c/81278
Auto-Submit: Martin Kustermann <kustermann@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
When a declared mixin is applied to a class, the class must implement
the superclass constraint interfaces named in the mixin declaration.
Change-Id: I6ace9fe244c1c87860b69c2c5e68f2c31ae73d7c
Reviewed-on: https://dart-review.googlesource.com/c/79206
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
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>
* 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>
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>
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>
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>
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>
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>
Dmitry Stefantsov