Unexpected compiler error when package object contains a method overload for a trait it extends

[TimoMeijer]

Reproduction steps

Scala version: Tested with 2.12.15 and 2.13.7, error does not occur with 3.0.2

package example

object Hello extends App {
  // [error] scala-bug/src/main/scala/example/Hello.scala:4:18: type mismatch;
  // [error]  found   : Int(0)
  // [error]  required: String
  // [error]   println(Bar1.f(0))
  println(Bar1.f(0))

  // Works
  println(Bar2.f(0))
  println(Bar1.f("0"))
  println(Bar2.f("0"))
}

trait Foo {
  def f(x: String): String = "foo"
}

package object Bar1 extends Foo {
  def f(x: Int): String = "bar1"
}

object Bar2 extends Foo {
  def f(x: Int): String = "bar2"
}

Problem

I would expect the overloaded method to be found by the compiler, and not lead to a compile error, as it already behaves with a non-package object

Relates to https://github.com/circe/circe-yaml/pull/284

[som-snytt]

Previously in our story, our hero was contending with https://github.com/scala/scala/pull/4756/files

[TimoMeijer]

@som-snytt Thanks for digging that up! That made me test a couple more Scala versions, to check whether this specific behavior has ever functioned correctly, but from my investigation it doesn't seem to be the case, it is only working as I would expect in 3.x versions. These were my results:

3.1.1   compile success
3.1.0   compile success
3.0.2   compile success
3.0.1   compile success
3.0.0   compile success
2.13.8  compile failed
2.13.7  compile failed
2.13.6  compile failed
2.13.5  compile failed
2.13.4  compile failed
2.13.3  compile failed
2.13.2  compile failed
2.13.1  compile failed
2.13.0  compile failed
2.12.15 compile failed
2.12.14 compile failed
2.12.13 compile failed
2.12.12 compile failed
2.12.11 compile failed
2.12.10 compile failed
2.12.9  compile failed
2.12.8  compile failed
2.12.7  compile failed
2.12.6  compile failed
2.12.5  compile failed
2.12.4  compile failed
2.12.3  compile failed
2.12.2  compile failed
2.12.1  compile failed
2.11.12 compile failed
2.11.11 compile failed
2.11.8  compile failed
2.11.7  compile failed
2.11.6  compile failed
2.11.5  compile failed
2.11.4  compile failed
2.11.2  compile failed
2.11.1  compile failed
2.11.0  compile failed
2.10.7  compile failed
2.10.6  compile failed
2.10.5  compile failed
2.10.4  compile failed
2.10.3  compile failed
2.10.2  compile failed

[som-snytt]

Thanks. I'll take a look to see if I can understand how package objects work. I would like to understand package objects before they deprecate package objects inheriting from traits and before they deprecate package objects.

[TimoMeijer]

Thanks! I'd be happy to help, but have never contributed or looked into the scala compiler before, so I wouldn't know how to begin. And indeed, the entire point seems moot for Scala 3, but it would be nice if we can still get it fixed on 2.x.

[TimoMeijer]

This is apparently undefined, from the spec(https://github.com/scala/scala/blob/2.13.x/spec/09-top-level-definitions.md):

The package object should not define a member with the same name as one of the top-level objects or classes defined in package ´p´. If there is a name conflict, the behavior of the program is currently undefined. It is expected that this restriction will be lifted in a future version of Scala.

[som-snytt]

That line is about classes. I think this is an "implementation restriction." I spent some time with it that day, but I don't remember offhand why it failed to see the symbol as overloaded. The feature (packages inheriting) is deprecated, but it works in Scala 3.

[SethTisue]

Package objects are on their way out of the language, so I wouldn't get your hopes up that someone will choose to tackle this. @TimoMeijer if you're interested in becoming a Scala 2 compiler hacker this might be a suitable ticket for you to learn that, but I strongly suspect that the level of difficulty here is at least high enough (moderate or higher) that making the learning investment is probably too costly if your interest is limited to this one issue.

[som-snytt]

Yes, I would endorse Seth's evaluation. I found it a useful exercise just to understand more how Adriaan Moors must have suffered.