NNBD: Analyzer allows inherit two interfaces with incompatible type parameters: Object? vs FutureOr, Object? vs FutureOr<FutureOr> #40454
Description
Dart VM version: 2.8.0-edge.40f23c735f04433e4fc334fbd674474bd3de0f8b (Tue Jan 28 01:14:48 2020 +0000) on "linux_x64"
This issue is similar with #40453, but dart and analyzer behave in the different ways here.
The following source code declares classes X1 and X2 which inherit classes with incompatible type arguments:
import "dart:async";
class A<T>{}
class B implements A<Object?> {}
class C implements A<FutureOr> {}
class D implements A<FutureOr<FutureOr<FutureOr>>> {}
class X1 extends B implements C {}
class X2 extends B implements D {}
main() {}This code throws two compile errors with dart and passes with analyzer.
Seems like error should be thrown in both cases.
Sample output is:
$ dart --enable-experiment=non-nullable test.dart
test.dart:9:7: Error: 'X1' can't implement both 'A<Object?>' and 'A<FutureOr>'
- 'A' is from 'test.dart'.
- 'Object' is from 'dart:core'.
- 'FutureOr' is from 'dart:async'.
class X1 extends B implements C {}
^
test.dart:10:7: Error: 'X2' can't implement both 'A<Object?>' and 'A<FutureOr<FutureOr<FutureOr>>>'- 'A' is from 'test.dart'.
- 'Object' is from 'dart:core'.
- 'FutureOr' is from 'dart:async'.
class X2 extends B implements D {}
^
$ dartanalyzer --enable-experiment=non-nullable test.dart
Analyzing test.dart...
No issues found!
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
lrhn commentedon Feb 4, 2020
Reading the spec, I believe the analyzer is correct if the code is null-safe. (I'm not so sure if it's legacy code, though).
The check for having the same instantiation of an interface uses
NORMandNNBD_TOP_MERGE:The type
NORM(FutureOr)isdynamic, as isNORM(FutureOr<FutureOr<FutureOr>>).The
NNBD_TOP_MERGE(Object?, dynamic)isObject?, which means it's defined and there is no error.iarkh commentedon Feb 6, 2020
The same problem is reproducible for the
dynamicvsFutureOrcase.eernstg commentedon Feb 7, 2020
Agreeing that there is no error here, note that dart-lang/language#824 aims to make an adjustment to the definition of
NNBD_TOP_MERGE. This will not change the ability of an opted-it class to have superinterfaces that differ in the ways thatNNBD_TOP_MERGEeliminates, but it will make them implement a superinterface that has type argumentObject?ordynamicin some situations where the current rules would yieldvoid.chloestefantsova commentedon Feb 7, 2020
Proposed fix: https://dart-review.googlesource.com/c/sdk/+/134842