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>
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 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>
I'm trying to fix an analyzer bug where typedef type parameters
weren't checked properly, and it appears that we have no language_2
test cases for it.
Change-Id: I216a337eeaae6ac2008c0c26139797e00099ffcb
Reviewed-on: https://dart-review.googlesource.com/76707
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This required adding an implementation of super-bounded types to the
analyzer.
We really could use some more tests to verify that we disallow
super-bounded types in all the appropriate locations, but allow it in
other cases (it seems that there are no language_2 tests to verify
this). To avoid churn, I'll wait until I have confirmation that my
reasoning is correct in #34583 before submitting test cases.
Fixes#34532.
Fixes#34560.
Change-Id: I3c5def60bcac0d31b56bead31cb1aab445f18e96
Reviewed-on: https://dart-review.googlesource.com/76280
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This reverts commit 836a1d7a88.
Revert "Don't use ClassElementImpl for now in override checking."
This reverts commit 58e44c1400.
Revert "large_class_declaration_test is slow now."
This reverts commit 56f6c52d58.
Revert "Add regression test for issue 34392."
This reverts commit ef7d144bc7.
Revert "Mixin declarations don't have supertype, fix isMoreSpecificThan()."
This reverts commit 95b8a19a20.
Change-Id: Icda9cf9091ef35acc8fd61ac5dc135b3717eba0a
Reviewed-on: https://dart-review.googlesource.com/76301
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
In a named mixin application, the superclass doesn't include the last
type appearing in the "with" clause, so that class isn't considered a
superclass constraint.
Fixes some test cases broken by 46e5954b0a.
Change-Id: I2e824d38017fe2c7eaa23e8f185cea07fe2222b7
Reviewed-on: https://dart-review.googlesource.com/75940
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Now that we have an explicit syntax for mixins that is available all
the time, we have to do mixin inference error checking all the time,
not just when the "--supermixin" flag is supplied.
This required fixing several minor bugs:
- ErrorVerifier._checkForMixinSuperInvokedMembers did not properly
handle a mixinElement argument that was a ClassElementHandle.
- ErrorVerifier._checkMixinInference wasn't using the actual
substituted mixin types, causing errors to be wrongly reported when
a class declaration had multiple inferred mixins (this was the root
cause of #34404).
- Type names in "with" clauses in the resolved AST weren't properly
reflecting the mixin type arguments that had been inferred.
Fixes#34404.
Change-Id: Ia773233c66f8d9ab778f207689c73922e9e3a880
Reviewed-on: https://dart-review.googlesource.com/75792
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
I will soon start landing fixes to address some (but not necessarily
all) of the test cases in this test, and I want to make sure that my
fixes produce corresponding status file changes, to secure against
possible future regressions.
Change-Id: Iaec11b85a20d670c0702220cadbbdfc51c026d1f
Reviewed-on: https://dart-review.googlesource.com/75624
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
To avoid causing unrelated tests to start failing, the tests have been
modified to avoid running afoul of the analyzer toplevel inference
limitations. (Note that we still have adequate test coverage in
pkg/front_end/testcases that the front end isn't subject to these
limitations).
Change-Id: I7b8f84a358d0e8891025b24143117c39d1b7dd69
Reviewed-on: https://dart-review.googlesource.com/75389
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Also modify async_backwards_compatibility_1_test so that fixing these
bugs won't cause it to start failing.
Change-Id: I7bb3b9587a0aeea8662df1923034bcb409a29522
Reviewed-on: https://dart-review.googlesource.com/75280
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fixes#34167. This implements the Dart 2 mixin proposal
(https://goo.gl/KEKQyv) for DDC. When the mixin is applied, a class
is created for the application that extends the correct superclass
and has all of the instance members, so `super` works correctly.
This also fixes a few minor issues in Analyzer's (mostly complete)
implementation:
- InterfaceType.isObject now returns false for Dart 2 mixins.
- Least upper bound calculation recognizes mixins are not Object.
- Interface of the mixin now implements its superclass constraints.
- Mixin superclass constraints are checked against the superclass and
all previously applied mixins (if any); this keeps it working with
the subtype fix above, and also prevents a not-yet-applied mixin
from satisfying the constraint
The language_2/mixin_declaration tests were updated with a few minor
fixes now that we can run Analyzer/dartdevc to test them.
This change implements super mixins for DDC's Kernel backend (DDK)
too. This will be enabled once Kernel adds a flag to recognize which
Class nodes are mixins (vs normal classes).
Change-Id: Ib3c4fcb12de9988345e52d92931196828d8227c3
Reviewed-on: https://dart-review.googlesource.com/74965
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Vijay Menon