Remove warnings in build and test

[odersky]

1. Move 2.13 source version in its proper place. It should come before 3.0. Otherwise we will get all warnings turned on for later versions when we compile the stdlib.
2. Rewrite compiler and test sources so that there are no warnings.

[hamzaremmal]

@odersky It is was put there on purpose so that we can benefit for the latest scala features and fixes but at the same time recognize that it is a Scala 2 file. The warnings will be fixed at some point and we can put -nowarn instead to avoid them.

[odersky]

I think that's very dangerous, because it means that stdlib will also undergo all changes in behavior that are source-coded. Take implicit priority inversion which kicked in at 3.6. Since there was never a proper migration process I think it is prudent to leave it at the old behavior.

What improvements and fixes did you have in mind that would not be available for stdlib if the versions had the proper ordering?

[odersky]

I am against @nowarn, that's not a solution. Our warnings should be useful and we should act on them in a timely manner.

[odersky]

I managed to remove all warnings for compiler and test sources by rewriting these sources.

Still to do:

• Remove warnings in scalajs/ir. @sjrd can you take a look?
• Remove warnings in shaded modules (e.g. SourcePos, Fansi, PPrint). What is the proper procedure to do that?

[odersky]

I now moved the 2.13 source version to its original place but disabled all migration warnings and errors for it.

That leaves us with 114 warnings (instead of 2200 before), which starts to be manageable. These warnings should be fixed directly in source. The most common one is a pattern match unchecked warning like this one:

-- [E092] Pattern Match Unchecked Warning: /Users/odersky/workspace/dotty/library/src/scala/collection/mutable/TreeSet.scala:203:11 
[warn] 203 |      case ss: scala.collection.SortedSet[E] if ordering == ss.ordering =>
[warn]     |           ^
[warn]     |the type test for scala.collection.SortedSet[E] cannot be checked at runtime because its type arguments can't be determined from IterableOnce[E]^

The warning is correct. IterableOnce is covariant but SortedSet is not, so having at the same time an IterableOnce[E] and a SortedSet[E'] does not imply E = E'. So I guess we need to add @unchecked in the match to make it pass. Which means we have to decide how the library should be updated in the future.