Dartc does not produce a warning when trying to call an inaccessible method

[DartBot]

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

---

What steps will reproduce the problem?
There is a library:

library('lib');

class C {
  _method() {}
}

Run the following test with Dartc:

import('lib.dart');

class D extends C {
  test() {
    super._method(); //should be a static warning
  }
}

main() {
  C c;
  c._method(); //should be a static warning
}

What is the expected output? What do you see instead?
Expected: static warnings on the marked lines.
Actual: no static warnings

What version of the product are you using? On what operating system?
Dartc, r8026. OS Ubuntu 10.04

Please provide any additional information below.
Tests in co19: Language/10_Expressions/14_Method_Invocation/1_Ordinary_Invocation_A06_t02.dart
Language/10_Expressions/14_Method_Invocation/1_Super_Invocation_A06_t02.dart

[kasperl]

Added Area-Analyzer, Triaged labels.

[danrubel]

Added this to the M1 milestone.

[scheglov]

Set owner to @scheglov.
Added Accepted label.

[scheglov]

https://chromiumcodereview.appspot.com/10537006

---

Added Started label.

[scheglov]

https://code.google.com/p/dart/source/detail?r=8291

---

Added Fixed label.

[DartBot]

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

---

This warning seems to have been changed from static type to resolver, which contradicts the spec ("Super invocation")
see the same test: Language/11_Expressions/15_Method_Invocation/4_Super_Invocation_A06_t02.dart

[bwilkerson]

This warning seems to have been changed from static type to resolver, which contradicts the spec ...

I assume you're referring to the strings "STATIC_TYPE" and "RESOLVER" that appear in the error message. Those strings refer to the portion of code from which the error was reported, not the kind of error being reported (where "kind" refers to the kinds of errors defined in the specification: "compile-time errors", "static warnings", "static type warnings", "dynamic type errors" and "run time errors"). There is not necessarily any correlation between the two.

[DartBot]

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

---

well, there ought to be some correlation, otherwise we can't test specifically for different kinds of warnings prescribed by the spec

[bwilkerson]

well, there ought to be some correlation, otherwise we can't test specifically for different kinds
of warnings prescribed by the spec

My understanding (which could easily be wrong) is that the test framework is not currently testing the type of error generated.

Nevertheless, I agree. We are re-writing the analyzer and one of the changes is that errors will no longer carry along information about where in the code they were generated but will know what kind of error they are. We can retrofit this into the current analyzer if necessary, but I'd rather not do the work unless it's essential.

[DartBot]

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

---

Tweaking two analyzers at once is hardly essential
We're looking forward to using the new one as well as an updated test harness (seems to enjoy a revived interest lately as well)
Maybe these two products will finally see eye to eye soon enough :)