New (?) Scala Native 3.2.1 warnings

[LeeTibbert]

Scala 3.2.1, SN 0.5.0-SNAPSHOT approx 2022-10-28T02:00

I have been trying to cut some of the build warnings out of the SN 3.2.0
(now 3.2.1) build so that I could see any build defects I might be
introducing.

When I reduced the shrubbery, this popped up. Does not look like mine
and it looks new.

javalib/src/main/scala/java/util/Hashtable.scala:102:13 
[warn] 102 |        case o: UnboxedEntry => boxedEntry.equals(o.boxedEntry)
[warn]     |             ^
[warn]     |           the type test for UnboxedEntry cannot be checked at runtime

Question before the house: Is the test broken and should be fixed or removed or did something in the compiler change?

[LeeTibbert]

Removed more shrubbery and found:

unit-tests/shared/src/test/scala/javalib/util/ArraysTest.scala:995:13 
[warn] 995 |        case that: A => this.x == that.x
[warn]     |             ^
[warn]     |             the type test for A cannot be checked at runtime

[WojciechMazur]

Probably it's a regression in the compiler. It's only present for classes defined in local scope like methods. I'll try to ask the compiler team is it actual regression or insight from the compiler about actual problem. However, I think that's just a false negative warning.

[WojciechMazur]

Created an issue in dotty scala/scala3#16259

[WojciechMazur]

Seems it's an actual issue - the local class leads to unsoundness - it's a situation when even though something might compile and have correct types it might not be actually checked in the runtime. I'm not sure if it only applies to JVM, but probably we should move the locally defined classes to the outer scope.

[LeeTibbert]

Thank you for digging into this. I will look at those two files later today or tomorrow.

Not my or our biggest problems, but it is nice to work with clean decks.

[LeeTibbert]

Wojciech,

I do not want to place you in the middle.

@Test def equals_AnyRefs(): Unit = {
    // scalastyle:off equals.hash.code                                          
    class A(private val x: Int) {
      override def equals(that: Any): Boolean = that match {
        case that: A => this.x == that.x
	case _       => false
      }
    }
    // scalastyle:on equals.hash.code      

I am only a provincial, but this looks like, smell like, and
quacks like a compiler bug.

I agree that True unsoundness is to be avoided, as it is
equals True Sin. Was there any explanation of the unsoundness
here?

The code which triggers this new(?) warning looks like the above.
With only the name changed to equals_AnyRefs, this is code from
and still active in Scala.js. Almost always, if there is something
wonky in Scala code, Scala.js will not accept the code into
their repository in the first place.

The other site in SN has the same equals idiom.

Sorry to be slow, but why can't the type check happen at runtime
if equals is ever called?

I use local classes all over the place, usually to limit scope.
This issue shakes my belief in those classes as being reliable.
I guess the compiler will tell me the cases which are suspect.

Mechanically, it appears easy enough to move the class just outside
its enclosing definition. That leads to oddness that I would like
to be able to explain in a one/two line comment.

Others reading the code will, or strongly should, surely ask about the weirdness.

Thanks,

Lee

[WojciechMazur]

In the case of the equals_AnyRef our use case seems to be safe. I ain't the compiler expert and it seems quite strange that type check cannot happen at runtime. However, the danger is real (scala/scala3#4812).