Skip to content

Implement support for dynamic checks on parameters that are covariant-by-declaration due to inheritance #47072

New issue

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

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

Already on GitHub? # to your account

Closed
5 tasks done
eernstg opened this issue Sep 1, 2021 · 8 comments
Assignees
Labels
area-meta Cross-cutting, high-level issues (for tracking many other implementation issues, ...). implementation Track the implementation of a specific feature (use on area-meta issue, not issues for each tool) P2 A bug or feature request we're likely to work on

Comments

@eernstg
Copy link
Member

eernstg commented Sep 1, 2021

Cf. dart-lang/language#925, consider the following program:

class A {}
class B extends A {}

class C {
  // The parameter `b` is not covariant-by-declaration as seen from here.
  void f(B b) {}
}

abstract class I {
  // If `I` is a superinterface of any class,
  // the parameter of its `f` is covariant-by-declaration.
  void f(covariant A a);
}

class D extends C implements I {} // OK.

void main() {
  I i = D();
  i.f(A()); // Dynamic type error.
}

The class D will behave in such a way that the actual argument to its f method has its type checked dynamically. In other words, when C.f is inherited by D, it is changed such that it's parameter is covariant-by-declaration. (This may be achieved by implicitly inducing a forwarding stub into D that calls super.f(...), but it could also be done by other means.)

This issue is concerned with the implementation of this feature. The tests added in https://dart-review.googlesource.com/c/sdk/+/208504 can be used as a guide.

This is not tied to a language version or a flag, because it only allows programs with errors to become running programs.

Subtasks:

@nshahan
Copy link
Contributor

nshahan commented Sep 2, 2021

Can you comment on the priority of this issue? Are we expecting the implementation changes to be part of the next release?

@eernstg
Copy link
Member Author

eernstg commented Sep 2, 2021

I sent out email to @devoncarew and some team members in order to find a suitable milestone.

@eernstg
Copy link
Member Author

eernstg commented Oct 13, 2021

(Reopening, I think we should only close this when all subtasks are closed.)

@eernstg eernstg reopened this Oct 13, 2021
@johnniwinther
Copy link
Member

Yes. I accidentally used the wrong issue number in the fix for #47074

@devoncarew devoncarew added the P1 A high priority bug; for example, a single project is unusable or has many test failures label Oct 14, 2021
@devoncarew
Copy link
Member

@eernstg - we may be complete here?

@eernstg
Copy link
Member Author

eernstg commented Oct 18, 2021

Yep! Closing.

@eernstg eernstg closed this as completed Oct 18, 2021
@devoncarew devoncarew reopened this Oct 19, 2021
@devoncarew devoncarew added P2 A bug or feature request we're likely to work on and removed P1 A high priority bug; for example, a single project is unusable or has many test failures labels Oct 26, 2021
@devoncarew
Copy link
Member

FYI, we bumped the analyzer issue out of the current stable milestone (and moved this meta issue as well).

@devoncarew
Copy link
Member

I believe this is now complete.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
area-meta Cross-cutting, high-level issues (for tracking many other implementation issues, ...). implementation Track the implementation of a specific feature (use on area-meta issue, not issues for each tool) P2 A bug or feature request we're likely to work on
Projects
None yet
Development

No branches or pull requests

4 participants