Unexpected change in analysis results when removing extends Object

[bwilkerson]

Given a file a.dart containing

class A {
  void _foo() {}
}

class B {
  void _foo() {}
}

and another file containing

import 'a.dart';

class C extends Object with A, B {}

the analyzer produces the following expected diagnostic

error: The private name '_foo', defined by 'B', conflicts with the same name defined by 'A'. (private_collision_in_mixin_application)

But if the extends clause is removed:

import 'a.dart';

class C extends Object with A, B {}

then the diagnostic is not reported.

Is this a bug in the analyzer, or is this expected behavior?

[lrhn]

If there is a difference in behavior, then it's a bug.
A class declaration of class C with A, B {} is completely equivalent to on of class C extends Object with A, B {}.

I'll admit I can't remember the special cases around mixin-application and private names (#28809 mentions it, but I can't find anything in the spec).
Whichever is right, both programs should behave the same.

[bwilkerson]

@eernstg For clarification on the spec.

[scheglov]

I can reproduce it.

[scheglov]

https://dart-review.googlesource.com/c/sdk/+/199062

[eernstg]

Searching the language specification and other documents (but this is from 2017, so it should be in the language specification by now), I also don't see anything about this error. But it should definitely never make a difference whether extends Object is written explicitly or implied because there is no extends clause.

I proposed a specification of the private collision error in dart-lang/language#1626.

I can see that we have tests, in particular pkg/analyzer/test/src/diagnostics/private_collision_in_mixin_application_test.dart, and they are testing the case where the colliding private declarations occur directly in the superclass and mixin, so we might not have tests covering the situation where the mixin member collides with some other concrete member that the superclass has (but doesn't declare), in which case the superclass may also be declared in some other library.

[scheglov]

It was requested as #28809

[eernstg]

Yes, I did mention #28809 in the PR dart-lang/language#1626, and this comment implies, if C is intended to be an error, that there should be a conflict on get _x from 'lib.dart' even though the superclass B is not declared in 'lib.dart'.