Missing override errors on name collisions and default values

[sgrekhov]

Analyzer has stopped report errors (in a strong mode) in many cases. A couple of examples:

class A {
  static var f;
}
abstract class B extends A {
  f();
}
class C extends B {
  f() {}
}
main() {
  new C().f();
}

Output:
analyzer 1.20.0-dev.10.0 strong mode:
No issues found
analyzer 1.20.0-dev.10.0 nostrong mode:
[warning] 'f' collides with a static member in the superclass 'A'
[warning] 'f' collides with a static member in the superclass 'A'
analyzer 1.19.1 strong mode:
[error] 'f' collides with a static member in the superclass 'A'
[error] 'f' collides with a static member in the superclass 'A'

Another example

class A {
  foo([x = 1]) {}
}
class C extends A {
  foo([x = '']);
}
main() {
  new C().foo(1);
}

Output:
analyzer 1.20.0-dev.10.0 strong mode:
No issues found
analyzer 1.20.0-dev.10.0 nostrong mode:
[warning] Parameters cannot override default values, this method overrides 'A.foo' where this positional parameter has a different value
analyzer 1.19.1 strong mode:
[error] Parameters cannot override default values, this method overrides 'A.foo' where this positional parameter has a different value

[mit-mit]

Tagging as potential 1.20 blocker

[zoechi]

Isn't the first case correct?
A class doesn't inherit static members. I don't see a conflict.

[floitschG]

/cc @lrhn

[lrhn]

You don't inherit static members, but for some, probably very good, reason the specification does prohibit declaring an instance method with the same name as a static method of a superclass.

Section 10.1:

It is a static warning if a class Cdeclares an instance method namednand an accessible static member namedn` is declared in a superclass of C.

Here "accessible" isn't really necessary, If it's not accessible, then it's a private from another library, and then it won't have the same /name/ as any declaration in the current library.

Not a high priority problem to not warn about this particular thing.

[mit-mit]

Removing blocking 1.20 tag and lowering to P2.

[jmesserly]

Yeah I don't think it's a blocker, but great catch though.

[jmesserly]

this still repros, and neither the CFE nor Analyzer report it.