Compilation fails on Scala 2.13.11-M1 due to new -Xsource:3 change

[SethTisue]

this came up in the Scala 2 community build

when I compile Slick with 2.13.11-M1, because you use -Xsource:3 I get compilation errors such as:

[error] /Users/tisue/slick/slick/src/main/scala/slick/jdbc/OracleProfile.scala:544:21: reference to ti is ambiguous;
[error] it is both defined in the enclosing method createOptionResultConverter and inherited in the enclosing anonymous class as value ti (defined in class OptionResultConverter)
[error] In Scala 2, symbols inherited from a superclass shadow symbols defined in an outer scope.
[error] Such references are ambiguous in Scala 3. To continue using the inherited symbol, write `this.ti`.
[error]             val v = ti.getValue(pr, idx)
[error]                     ^

there are a bunch more in the same vein

it appears to me, offhand, that these errors are expected consequences of scala/scala#10220 , but if you believe otherwise, please let us know

cc @lrytz @som-snytt

[nafg]

Are you on 3.5.0-M2? That has no warnings with 2.13.10 -Xsource:3.

I saw such errors while I was rebasing nafg/dottyquery on latest main, clearly it fixes some of them. I can try to pull that out into another milestone release based on 2.13.11-M1.

But I'm not clear the point of this issue. If minor scala releases shouldn't break code that uses -Xsource:3 then it violates that either way, and if they can then what's the issue?

If the point is just to have a ticket to close when that is fixed in Slick, then sure ok thanks ;)

[SethTisue]

Are you on 3.5.0-M2? That has no warnings with 2.13.10 -Xsource:3.

I'm on c4cb91a, current HEAD of main branch

I saw such errors while I was rebasing nafg/dottyquery on latest main, clearly it fixes some of them. I can try to pull that out into another milestone release based on 2.13.11-M1.

There's no need for a release. The community build builds things from source, so as soon as a fix has been pushed here, I'll be able to pull it in.

But I'm not clear the point of this issue. If minor scala releases shouldn't break code that uses -Xsource:3 then it violates that either way, and if they can then what's the issue?

-Xsource:3 is still improving, so it's considered normal for us to "break" code that uses it — as long as that same code also "breaks" on Scala 3, which in this case it does.

If the point is just to have a ticket to close when that is fixed in Slick, then sure ok thanks ;)

Well, that, yes, it's a heads up as a courtesy to the project.

But also, I'm inviting you to let us know if you think that the errors are spurious, since it's possible (hopefully not too likely) that the change we made was somehow erroneous.

[nafg]

Probably not spurious since scala 3 itself gave a number of such errors, and the way slick is architected such collisions are probably likely.

But I could be more sure if you tell me the approximate number of such errors or I could see them (I can build on M1 on Sunday hopefully).

[SethTisue]

here's the log: https://scala-ci.typesafe.com/job/scala-2.13.x-jdk11-integrate-community-build/4352/artifact/logs/slick-build.log

[som-snytt]

Jinx, I have the same result from local compile.

[som-snytt]

Lukas was working at reducing warnings for term aliases.

  def base[T](ti: JdbcType[T], name: String, idx: Int) = (ti.scalaType match {
[snip]
    case _ => new BaseResultConverter[T](ti.asInstanceOf[JdbcType[T]], name, idx) {
      override def read(pr: ResultSet) = {
        val v = ti.getValue(pr, idx)
        if(v.asInstanceOf[AnyRef] eq null) throw new SlickException("Read NULL value ("+v+") for ResultSet column "+name)
        v
      }
    }

Here, params to BaseResultConverter are (ti, name, idx), so I have no idea in val v which is intended, but it doesn't matter.

[lrytz]

Yeah, this is really the canonical example where the new warning is annoying...

scala> class C(val thing: String)
class C

scala> def foo(thing: String) = new C(thing) { override def toString = s"some $thing" }
                                                                               ^
       error: reference to thing is ambiguous;
       it is both defined in the enclosing method foo and inherited in the enclosing anonymous class as value thing (defined in class C)
       In Scala 2, symbols inherited from a superclass shadow symbols defined in an outer scope.
       Such references are ambiguous in Scala 3. To continue using the inherited symbol, write `this.thing`.

I tried but didn't find a viable solution scala/scala#10220 (comment)

[SethTisue]

not actually sure if these changes are correct, but in case it's useful: scalacommunitybuild/slick@4ec74bf

[SethTisue]

@nafg curious how this ended up being resolved, if at all

[nafg]

It was fixed in 7d653e8

[SethTisue]

scala/community-build@c20cc62 👍