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>
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>
The implementation strategy is to replace int literals with double
literals during type inference, provided they occur in a double
context and can be represented exactly as a double. This requires us
to keep integer literals larger than the 64-bit range until after type
inference and to keep the source text of 64-bit integers until after
type inference for error reporting.
We postpone the check for web int literals as well because the
expression generator that was performing it isn't otherwise needed.
Fixes https://github.com/dart-lang/sdk/issues/34357.
Change-Id: Ia78c031565cad83961675fc4fb1cc871eaed01d3
Reviewed-on: https://dart-review.googlesource.com/c/78122
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Peter von der Ahé <ahe@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>
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>
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>
When I first began working on the feature I mistakenly thought that
these two test cases would be free from compile-time errors, so it
seemed like it would be worth adding a test case to make sure others
don't have the same misunderstanding.
Change-Id: I322991c818f9d136180de443090fa4e15f6f0e27
Reviewed-on: https://dart-review.googlesource.com/76680
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
This change expands typedefs into their underlying function type in the
compiler. Typedefs no longer exist at runtime in DDC, so they now have
similar equality and identity behavior as other function types.
The compiler used to preserve typedefs so they could have a better
toString. But over time that support has been almost entirely lost;
the caching for function/interface types eliminates typedefs, and
DDC+Kernel does not appear to get any TypedefTypes from the common
front end. So in practice typedef types were almost never present at
runtime. Because of this, we can remove the remaining support with very
little user visible effect. This also brings DDC's canonicalization
roughly in line with dart2js for compile-time typedefs, so frameworks
like Angular will be able to continue their use of `identical` for fast
type comparisons.
This CL also fixes DDC's type caching for generic function types
(typeHashCode was incorrect for them), and has some refactoring to
improve names/comments and make the SDK runtime code more clear.
Change-Id: I4e34c0c8f737a8535ba474a4683967ff41bcd3c8
Reviewed-on: https://dart-review.googlesource.com/74664
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Alan Knight <alanknight@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>
Test mixin class definition syntax, and test that inference is not
performed in the on clause of a mixin. Bug fixes.
Change-Id: I01679c4eb556d9c7bd9227b5d3a79293a027706c
Reviewed-on: https://dart-review.googlesource.com/75622
Reviewed-by: Paul Berry <paulberry@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>
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>
Paul Berry