Remove stdlib213 from community build tests

[nicolasstucki]

This test exists for historical reasons. Now we compile the Scala 2 library in the scala2-library-bootstrapped project. This one checks that it compiles (with -Ycheck:all) and is used to package the TASTy files in the scala2-library-tasty project. Furthermore, now there is a scala/scala test that checks that the library can be compiled with Scala 3.

This test is fundamentally broken but we have not noticed it because we do not use -Ycheck:all. The reason is that when we compile scala.Predef we get a conflict with scala.runtime.stdLibPatches.Predef when we patch the symbols. This also surfaced in #18738.

[sjrd]

This should also remove the submodule in https://github.com/lampepfl/dotty/tree/main/community-build/community-projects

[nicolasstucki]

We still need this project for the benchmarks.

• https://github.com/lampepfl/dotty/blob/main/bench/scripts/stdlib213
• https://dotty-bench.epfl.ch/

I need to dig deeper into benchmarks to know how to handle that case. Ideally, we want to benchmark against the same version of the sources every time. But as it is right not it seems that when someone updated the stdlib213 for the tests we also changed it for the benchmarks. This was not an ideal situation.

@mbovel @liufengyun do you have some extra insight on this?

[liufengyun]

For the benchmarks, the stdlib is used in the following files:

• https://github.com/lampepfl/dotty/blob/main/bench/scripts/stdlib213
• https://github.com/lampepfl/dotty/blob/main/bench/profiles/projects.yml#L40-L41

Ideally, we want to benchmark against the same version of the sources every time. But as it is right not it seems that when someone updated the stdlib213 for the tests we also changed it for the benchmarks. This was not an ideal situation.

The compiler is already an exception to that. Maybe the stdlib can be an exception as well to avoid maintenance overhead.

[michelou]

@nicolasstucki Good job, thanks !