[REJECTED] Nullary override check only current sources

[som-snytt]

Scala 3 does not enforce the override check for Scala 2 definitions. To enable compiling under both regimes, restrict the check to when the overrides are in the current run. Restore the lint option to warn for the remaining cases.

Fixes scala/bug#12695

[lrytz]

We had the warning since 2.13.3, it seems to me there's no reason to relax it at this point. Was there a discussion already somewhere about aligning Scala 3 instead?

[lrytz]

I see that 2.13 projects can currently just ignore the warning, and they will get an error when they turn on -Xsource:3 to start their migration. But then over on actual 3, it would not be an error anymore.

I agree this should be consistent, but I think we can do the stricter version.

[SethTisue]

I think an effort to make Scala 3 stricter should come first, and then only if that fails (i.e,, if there's pushback from the Scala 3 folks), should we loosen what we did here in Scala 2.

[som-snytt]

The "promotion" for 2.13.3 was imprecise at best.

Warning for legal code should be rare. That is what "lint" is for.

My example was the pos test, except I was using -Xsource:3 as usual for normal-looking imports such as

  import java.lang.Iterable as JIterable
  import scala.jdk.CollectionConverters.*

Then suddenly my parens error out, but not if I compile with Scala 3.

That is not a migration experience. That is deportation from the land of your dreams to embark on a dangerous journey governed by arbitrary rules.

[SethTisue]

For the historians, the 2.13.3 PR was @dwijnand's #8846

I guess changing from a warning to a lint is okay, as long as it's included in -Xlint and doesn't require separate opt-in.

@som-snytt so your position here is that at the time #8846 was approved and merged, we failed to give sufficient thought to the warning vs lint distinction...? I'm having trouble assembling your remarks into a clear narrative.

[som-snytt]

With the caveat that I don't have a passionate take, except to minimize friction for -Xsource:3 in an easy example such as the "pos" test here, this PR partially reverts the promotion, preserving the warning (or error under -Xsource:3) for code that will actually error using dotty.

People who want strict checking (without dotty relaxation) should use -Xlint (and dotty should provide -Xlint) (or Abide should provide the strict check).

(The PR doesn't check if the overridden member is Scala 3 under -Ytasty-reader. I see we have sym.isScala3Defined, so it should use that if we take this route. I don't know without trying it if that works for dotty class files.)

[som-snytt]

TIL it's not quite out-of-the-box.

error: error while loading T, Missing dependency 'Add -Ytasty-reader to scalac options to parse the TASTy in target/T.class', required by target/T.class

and

u.scala:2: error: could not find package scala.annotation.internal whilst reading annotation of package <empty>; perhaps it is missing from the classpath.

"whilst"

[lrytz]

Then suddenly my parens error out, but not if I compile with Scala 3.
That is not a migration experience.

I fully agree, we need to align with Scala 3, but I vote for enforcing override consistency in the Scala 3 compiler. I think the exception to treat Scala 2 libraries like Java in the Scala 3 compiler was added much earlier, before we had anything on the Scala 2 side.

If that doesn't work out, I would demote the error under -Xsource:3 to a warning, but not demote the warning to a lint.