Deprecate numeric widening of numeric literals which are not representable with Float/Double

[fabianpage]

follow up for: #8679
fixes scala/bug#10773

[fabianpage]

I forgot to do the same check for Doubles, working on that now.

[som-snytt]

How does it compare to #8730 ?

[fabianpage]

@som-snytt i don't have enough knowledge of the compiler to answer that question. I could add your tests to my solution to check if they also warn.

[lrytz]

(context: https://twitter.com/darjutak/status/1232599151537512448, we're on the left in the first photo. i missed / didn't remember your PR, @som-snytt)

[som-snytt]

Thanks, I see. Previously, I was only reading tpolecat on twitter, but now I will also read darjutak. I may even read darjutak first. Maybe we could use a spree tag here.

The "roundtrip" test in the other PR, borrowed from doti, is more generous.

[fabianpage]

But with the roundtrip you will have Integer values which are okay, but the value one bigger or one smaller would not be okay. In my opinion it's nicer to war a soon as you start to truncate.

[som-snytt]

Yes, I don't have a strong opinion about the ergonomics. I was trying to "align with doti" a bit, but dotty has sharp edges, such as Array(3.14f, 0x_7FFF_FFFE) infers Float unlike Seq[AnyVal].

The use case is if I can get my integral value out again, for example it's a sentinel, then there is no reason to warn. If I am computing with it, the opinion on the other ticket was not to warn about operations; I asked why is 3.14f + 1 different from any other f(1: Float)?

What is the use case for warning about conversion to a float that is never used in a computation? I computed an int, but my spreadsheet report generator only takes a float?

The doti use case is just about the type inference.

[fabianpage]

@lrytz @som-snytt thanks for your work!

[lrytz]

Thanks for your contribution and the friendly pair-coding!