Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[analyzer] Deriving a mixin from a class whose superclass isn't Object not detected #45195

Closed
eernstg opened this issue Mar 4, 2021 · 5 comments
Assignees
Labels
analyzer-spec Issues with the analyzer's implementation of the language spec area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. P1 A high priority bug; for example, a single project is unusable or has many test failures type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@eernstg
Copy link
Member

eernstg commented Mar 4, 2021

Cf. #45193, Mixed is used to derive a mixin, and Mixed has the superclass Object with N, so it should be flagged as an error.

@eernstg eernstg added area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) analyzer-spec Issues with the analyzer's implementation of the language spec labels Mar 4, 2021
@scheglov scheglov self-assigned this Mar 5, 2021
@scheglov
Copy link
Contributor

scheglov commented Mar 5, 2021

It looks reasonable to me that we should mark these Object with X classes when used as mixins.
But there are existing language tests that fail.
For example language/mixin/mixin7_test.dart and language/covariant/setter_test.

@scheglov scheglov added the P1 A high priority bug; for example, a single project is unusable or has many test failures label Mar 5, 2021
@scheglov
Copy link
Contributor

scheglov commented Mar 5, 2021

@eernstg
Copy link
Member Author

eernstg commented Mar 8, 2021

Looking at language/mixin/mixin7_test.dart, I see the following:

The superclass of M<T> is Object for any T, so it's OK to derive a mixin from M<...>, and a raw M would have its type argument inferred.

In class A<U, V> = Object with M implements I<V>;, the specification actually makes Object the superclass of A, not Object with M<...>. That makes this <mixinApplicationClass> slightly different from class A<U, V> extends Object with M implements I<V> {}, and it would in particular be OK to derive a mixin from A<...>.

Cf. https://github.com/dart-lang/language/blob/53f3e4606f7efe25679c37698e167734df7f934c/specification/dartLangSpec.tex#L5197 and https://github.com/dart-lang/language/blob/53f3e4606f7efe25679c37698e167734df7f934c/specification/dartLangSpec.tex#L5387.

In class B<T> = Object with A implements J<T>;, the superclass is again Object, so it's again OK to derive a mixin from B<...> and B.

So where does that test fail? Maybe it's because class A = S with M; is actually treated as class A extends S with M {} such that it gets the superclass S with M?

Looking at language/covariant/setter_test.dart, the situation seems to be the same.

@scheglov
Copy link
Contributor

scheglov commented Mar 8, 2021

Thank you. My CL was wrong. I will fix it.

@scheglov scheglov closed this as completed Mar 8, 2021
@scheglov
Copy link
Contributor

scheglov commented Mar 8, 2021

dart-bot pushed a commit that referenced this issue Mar 8, 2021
Bug: #45195
Change-Id: I4b1e60a672b49c3c9fda92b3eac59c256eea13da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/189300
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
analyzer-spec Issues with the analyzer's implementation of the language spec area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. P1 A high priority bug; for example, a single project is unusable or has many test failures type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

No branches or pull requests

2 participants