prefer_void_to_null false positive in case of nullable generics

[maRci002]

Describe the issue

abstract class Data {}

abstract class DataHolder<T extends Data?> {
  const DataHolder({required this.data});

  final T? data;

  bool isNullable() => null is T;
}

class FooData extends Data {}

class FooHolder extends DataHolder<FooData> {
  FooHolder({required super.data});
}

// prefer_void_to_null: Don't use the Null type, unless you are positive that you don't want void.
class ExplicitNullHolder extends DataHolder<Null> {
  ExplicitNullHolder() : super(data: null);
}

class ImplicitNullHolder extends DataHolder {
  ImplicitNullHolder() : super(data: null);
}

void main() {
  print(FooHolder(data: FooData()).isNullable()); // false
  print(ExplicitNullHolder().isNullable()); // true
  print(ImplicitNullHolder().isNullable()); // true
}

Expected behavior
Using explicit Null shouldn't trigger prefer_void_to_null lint rule.

[bwilkerson]

There are two potential problems here:

• Null should be allowed when the bound is nullable, and
• void shouldn't be suggested when void isn't compatible with the bound.

The second condition might only apply when there's a bug in the code to start with (for example, making the bound for T be Data), but it's still a case where the lint shouldn't produce a diagnostic.

[maRci002]

Null should be allowed when the bound is nullable

It is allowed, the program compiles successfully.

[bwilkerson]

I meant: allowed by the lint (as in not flagged as being a problem).