DartVM: abstract methods inheritance should be properly verified

[DartBot]

This issue was originally filed by ief...@unipro.ru

---

What steps will reproduce the problem?
consider the following test:
class A {
  abstract f(var x);
}

class C extends A {
  f(var x, var y) {}
}

main() {
  new A().f(2);
  new C().f(2, 2);
}

What is the expected output? What do you see instead?
Expected: compile-time error
Actual: successful compilation

What version of the product are you using? On what operating system?
DartVM r2810

Please provide any additional information below.
There are more various co19 tests:
LangSpecTest/07_Classes/1_Instance_Methods/1/Abstract/Methods/A03/t02
LangSpecTest/07_Classes/1_Instance_Methods/1/Abstract/Methods/A03/t03
LangSpecTest/07_Classes/1_Instance_Methods/1/Abstract/Methods/A03/t04
LangSpecTest/07_Classes/1_Instance_Methods/1/Abstract/Methods/A03/t05

LangSpecTest/07_Classes/1_Instance_Methods/1/Abstract/Methods/A04/t02
LangSpecTest/07_Classes/1_Instance_Methods/1/Abstract/Methods/A04/t03
LangSpecTest/07_Classes/1_Instance_Methods/1/Abstract/Methods/A04/t05
LangSpecTest/07_Classes/1_Instance_Methods/1/Abstract/Methods/A04/t06

[dgrove]

Added Area-VM, Triaged labels.

[iposva-google]

Marked this as being blocked by #1031.

[DartBot]

This comment was originally written by ief...@unipro.ru

---

Please note that the following tests were corrected and are not related to this issue anymore
LangSpecTest/07_Classes/1_Instance_Methods/1/Abstract/Methods/A04/t02
LangSpecTest/07_Classes/1_Instance_Methods/1/Abstract/Methods/A04/t03

[iposva-google]

Matthias, can you please work with Gilad to resolve whether these are still expected to be compile-time errors and whether they should be. See the blocking bug.

---

cc @gbracha.
Set owner to @mhausner.
Added Accepted label.

[gbracha]

Class C should cause a compile time error, because of the illegal override of f/1 by f/2 (I'm using the Erlang notation to distinguish methods with the same name and different arity). That rule is not expected to change.

[gbracha]

Note that Abstract/Methods/A04/t03 is not a compile-time error. The overriding method declares all named parameters declared by the overridden method, in the same order. It adds ana additional named parameter at the end, but that is ok. Same for Abstract/Methods/A04/t02

[DartBot]

This comment was originally written by rodion...@unipro.ru

---

the new relevant test names are:
Language/07_Classes/4_Abstract_Instance_Members_A03_t02
Language/07_Classes/4_Abstract_Instance_Members_A03_t03
Language/07_Classes/4_Abstract_Instance_Members_A03_t04
Language/07_Classes/4_Abstract_Instance_Members_A03_t05
Language/07_Classes/4_Abstract_Instance_Members_A04_t01
Language/07_Classes/4_Abstract_Instance_Members_A04_t05
Language/07_Classes/4_Abstract_Instance_Members_A04_t06

and rather than create a separate issue, it's probably more appropriate to add this here:
there's an unexpected compile-time error when overriding an abstract method with one that has the same set of named parameters, but declared in a different order.
The assertion in spec was changed, but VM hasn't been told yet
the following co19 tests illustrate this:
Language/07_Classes/4_Abstract_Instance_Members_A04_t04

[iposva-google]

Is this still a valid bug report?

---

Set owner to @gbracha.

[DartBot]

This comment was originally written by @mhausner

---

Yes. The VM needs to add abstract methods to classes so it can check whether they are used properly in an extending class. That will have an impact on how we handle noSuchMethod, since we can't rely on not finding the name in the class.

[iposva-google]

Removed Priority-Medium label.
Added Priority-Unassigned label.

[ghost]

What is the status of this one? Is Gilad still the correct owner?

[iposva-google]

Regis, you were looking at when to throw compile-time errors from within the VM.

---

cc @crelier.

[crelier]

Abstract methods should be listed as methods of the class in the VM, as Matthias commented on May 29. However, this is not relevant to this bug report, since bad overrides are not compile-time errors anymore (unless you specify --error_on_bad_override, in which case you do not get an error either, because abstract methods are not listed).

These co19 tests have the wrong expectation. They should not expect a compile-time error. Unless I miss something, this bug should be closed and a new co19 bug should be opened against these co19 tests.

[iposva-google]

Regis, can this now be closed? If the bugs have been filed agains co19, then probably you can do so.

[crelier]

I do not see any failing co19 tests related to abstract methods and I do not see any reference to issue #978. Closing issue.

---

Added AsDesigned label.