Analyzer does not put mixin declarations in the `.types` getter, which
broke DDC's assumption that it contained all of the class/interface
types in the compilation unit. Kernel backend was not affected.
Change-Id: I219d814766fb97ef81920d0150cb1dfbbc6087f5
Reviewed-on: https://dart-review.googlesource.com/c/82022
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Alan Knight <alanknight@google.com>
Reviewed-by: Alan Knight <alanknight@google.com>
This fixes the instantiated type for type parameters of function types
(whose default types are otherwise not computed) when the bound is
explicitly specified as Object.
It also enables error reporting to detect if a bound on a type variable
was specified or not, so that when a generic function type is printed,
the bound can be printed if and only if it was originally specified.
Fixes https://github.com/dart-lang/sdk/issues/34920
Change-Id: I9ad3f1cacb1b36eaef139d50c8e73cc7a8cc915b
Reviewed-on: https://dart-review.googlesource.com/c/81405
Reviewed-by: Dmitry Stefantsov <dmitryas@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>
If we use `_InvocationMirror._withoutType`, the symbol for the member name is created dynamically and escapes obfuscation.
We need to create the member name symbol statically via a `const` constructor.
Change-Id: I11c0f745187f4ef1646be6d5348780f502393043
Reviewed-on: https://dart-review.googlesource.com/c/81264
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Rationale:
Rather than relying on a separate loop detector, rely
on the new loop framework, which avoids code duplication
and ensures any improvement in loop detection/handling
will benefit this phase too. Note, most of the time, the
same loops are discovered with a few exceptions (which
is okay, since this is "just" heuristic usage). This CL
also simplifies loop detection a bit.
https://github.com/dart-lang/sdk/issues/34473
Change-Id: I1a1b19b99a698c74822473d2a1fe370287c1ade4
Reviewed-on: https://dart-review.googlesource.com/c/80523
Commit-Queue: Aart Bik <ajcbik@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
When building outlines, resolve unresolved types from the class
header (including superclass, mixin, and interface types) before any
methods from the body are parsed. This ensures that they types from
the class header are not shadowed by names introduced in the body.
Change-Id: Ie842b9ab23d9b44d91609f9e1bf79c052cfce2d4
Reviewed-on: https://dart-review.googlesource.com/c/81008
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Commit-Queue: Peter von der Ahé <ahe@google.com>
Auto-Submit: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Similar to how we treat catch entry instructions, this cl adds new
function and osr entry instructions. The [FunctionEntry] and
[OsrEntry] - just like [CatchBlockEntry] - have now their own initial
definitions. The [GraphEntry] has only initial definitions for
constants.
Explicit phis are inserted for all parameter / special parameter
instructions if necessary.
Future work is:
a) Minimize parallel moves due to the phis on parameters
b) Cleanup frame setup: Move it entirely into FunctionEntry/CatchEntry
(instead of the split version we have now)
Fixes https://github.com/dart-lang/sdk/issues/34435
Fixes https://github.com/dart-lang/sdk/issues/34287
Change-Id: Iefa0280a709716f748d6fb0523b8d0f4d8de1fec
Reviewed-on: https://dart-review.googlesource.com/c/74782
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
The kernel representation of mixin classes was changed in
c9b05d3f1ff0ba22cc8cc2e66e2654d99609e087; this adapts to the change.
Also, status file entries are added to reflect the differences
currently found by the comparison tool.
Change-Id: I16d5cb495cb70b05bf03e6d000002a69304ab4b0
Reviewed-on: https://dart-review.googlesource.com/c/79643
Auto-Submit: Paul Berry <paulberry@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The added test in this CL causes code to be optimized with _Smi's and
eliminated field guards. Field guards were eliminated due to usage of Smi ops,
which get removed due to the WidenSmiToInt32 optimization.
A use of the code with _Mint's will then trigger a test failure.
The WidenSmiToInt32 optimization has been disabled for the time being.
Change-Id: I6f7dd003a875b0abd708b3b948cda44378c42198
Reviewed-on: https://dart-review.googlesource.com/c/79540
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Declared mixins are not classes and should not be able to be
extended. This was not allowed by the analyzer anyway and since the
mixin declaration feature is not launched, we are not breaking any
code by making this bug fix.
Change-Id: Ia49dd207213accb16ad8dd819a22844d65ccfcab
Reviewed-on: https://dart-review.googlesource.com/c/79524
Reviewed-by: Aske Simon Christensen <askesc@google.com>
class in a foreign library.
This CL changes the predicate which is used to decide whether to
generate noSuchMethod forwarders such that it returns true whenever
the class in question has a user defined no such method or the
enclosing library of the class is different from that of the member.
Closes https://github.com/dart-lang/sdk/issues/33727
Change-Id: I0ffcbb8c8bdd69e4261bcefce2251d31babc19cf
Reviewed-on: https://dart-review.googlesource.com/c/79209
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@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 parser now generates a ConstructorWithTypeArguments error and a new
handleInvalidTypeArguments event after a begin/endTypeArguments event pair
when those type arguments are in a syntatically invalid location.
For example: `new C.n<int>();` in
```
class C<T> { T f; C.n() {} }
main() { var x = new C.n<int>(); }
Most listeners handle this event by dropping the invalid type arguments,
but AstBuilder now preserves those invalid type arguments in the AST
to support better code quick-fixes/quick-assists/refactoring.
Change-Id: I5b22bd4903cd9ee3645936b9a108598b603cf9ca
Reviewed-on: https://dart-review.googlesource.com/c/79300
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
Dart for-in loops allow `var x = [1]; for (var x in x) {}`, which is not
allowed in JS. If this pattern is detected, a temporary variable is
introduced so the for-in initializer expression is evaluated outside of
the JS for-of loop.
(This issue seems to be unique to for-in loops. For loops and other
kinds of variable declarations of the form `var x = ...` are not
allowed to use `x` in the initializer, even if `x` is declared in an
outer scope.)
Also fixes an out-of-date comment in the DDC+Analyzer backend.
Change-Id: I35b272a5a311f7b6f104cc82a99cc83a6ed5c247
Reviewed-on: https://dart-review.googlesource.com/c/79142
Commit-Queue: Alan Knight <alanknight@google.com>
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Alan Knight <alanknight@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>
Jenny Messerly