Skip to content

Generate a noSuchMethod thrower when a private method has an implementation with a wrong signature #61717

@eernstg

Description

@eernstg

Consider the following program:

// Library 'n122.dart'.

import 'n122lib.dart';

base class C extends B {}

void main() {
  try { C().public(); } catch (_) { print('C.public throws'); }
}
// Library 'n122lib.dart'.

base class A {
  void _m(int _) {}
  void public() => _m(0);
}

abstract base class B extends A {
  void _m(num _);
}

This program is accepted by the analyzer. The common front end, however, reports the following:

n122.dart:5:12: Error: The implementation of '_m' in the non-abstract class 'C' does not conform to its interface.
base class C extends B {}
           ^
n122lib.dart:4:15: Context: The parameter '_#wc0#formal' of the method 'A._m' has type 'int', which does not match the corresponding type, 'num', in the overridden method, 'B._m'.
Change to a supertype of 'num', or, for a covariant parameter, a subtype.
  void _m(int _) {}
              ^
n122lib.dart:9:8: Context: This is the overridden method ('_m').
  void _m(num _);
       ^

In the situation where a private method from a different library has no implementation (or it has one, but its signature is not a correct override of the signature in the interface), a synthetic method known as a noSuchMethod thrower should be generated, and no error should be reported.

(I'd love to be able to get a warning whenever a noSuchMethod thrower is generated, but that's a separate issue.)

Metadata

Metadata

Assignees

Labels

area-dart-modelFor issues related to conformance to the language spec in the parser, compilers or the CLI analyzer.cfe-dysfunctionalitiesIssues for the CFE not behaving as intendedtype-bugIncorrect behavior (everything from a crash to more subtle misbehavior)

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions