Nightly Dotty workflow of 2021-11-04 failed

[github-actions]

See https://github.com/lampepfl/dotty/actions/runs/1419651199

[nicolasstucki]

We are getting a new waring from #13792 wich changes the failure in tests/neg-custom-args/deprecation/t3235-minimal.scala.

@dwijnand could you check if this is the intended behavior?

[SethTisue]

Dale and I are in the Twilight Zone on this. We are seeing some crazy, inexplicable shit that's making us doubt our own sanity. Stay tuned.

[SethTisue]

class C { def x: Long = 123456789L.round }

we've got the compiler giving different results on compiling this code depending on the filename you put it in. we've got the above code in two identical files:

% sum tests/neg-custom-args/deprecation/t3235-{minimal,widen}.scala
8684 1 tests/neg-custom-args/deprecation/t3235-minimal.scala
8684 1 tests/neg-custom-args/deprecation/t3235-widen.scala

but then compiling one of them gives the expected "Widening conversion from Long to Float" warning and the other doesn't.

% ./dist/target/pack/bin/scalac -deprecation tests/neg-custom-args/deprecation/t3235-minimal.scala       
-- Deprecation Warning: tests/neg-custom-args/deprecation/t3235-minimal.scala:1:35 
1 |class C { def x: Long = 123456789L.round }
  |                        ^^^^^^^^^^^^^^^^
  |method round in class RichLong is deprecated since 2.11.0: this is an integer type; there is no reason to round it.  Perhaps you meant to call this on a floating-point value?
1 warning found
% ./dist/target/pack/bin/scalac -deprecation tests/neg-custom-args/deprecation/t3235-widen.scala
-- [E167] Lossy Conversion Warning: tests/neg-custom-args/deprecation/t3235-widen.scala:1:24 
1 |class C { def x: Long = 123456789L.round }
  |                        ^^^^^^^^^^
  |                   Widening conversion from Long to Float loses precision.
  |                   Write `.toFloat` instead.
1 warning found

and this is reproducible on both Dale's machine and my machine

and it's deterministic. some filenames reproducibly give one result, other filenames reproducibly give the other.

[SethTisue]

some yak hair may need to hit the barbershop floor before we can even effectively troubleshoot this

[soronpo]

I just hit a related problem in my own library. I had to change to explicit math.min and math.max, because the wrong function was invoked, causing an inlined recursion.

[SethTisue]

@soronpo I guess I'm not in a position to judge yet whether that might be the same, but I hope you'll circle back and test it again after we merge a fix to this

[dwijnand]

So I have a small diff of changes that allow me to build bootstrapped jars and cause the reproduction, while being able to actually see all the log messages (including when typerState.fresh changes the reporter to be a store reporter!!), and the behaviour change seems to come from a different order of implicits leading to a different "best implicit" being selected:

 [log typer]         ==> try insert impl on qualifier 123456789L.round Long?
 [log typer]           ==> inferView(123456789L, ?{ round: ? })?
 [log typer]             ==> typedImplicit(Candidate(implicitRef=ImplicitRef/
-  (floatWrapper : (x: Float): scala.runtime.RichFloat)
+  (doubleWrapper : (x: Double): scala.runtime.RichDouble)

[Adam-Vandervorst]

Maybe a good time to suggest: (an option to enable) a warning when it's up to luck which implicit is selected.