Calculate version range in init-compiler.sh script

[am11]

Guesstimations based on https://releases.llvm.org/ and https://gcc.gnu.org/releases.html, which is close enough.
Testing CI, shall upstream once green.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[am11]

cc @janvorli, upstream PR dotnet/arcade#14963. This will allow us to switch to latest version in a periodic manner (without needing to update this file).

[akoeplinger]

Clever, but one downside is that we'd automatically opt-in to newer versions even in servicing branches.

[am11]

one downside is that we'd automatically opt-in to newer versions even in servicing branches.

When someone will update the container reference in servicing branch (all linux legs are using containers these days), at that time it will show up red with the compiler error. This is same as what we do today. The only difference with this change is that we won't need to update this file in addition to backporting the compilation fixes.

Containers only have one toolchain version installed at a time.

[janvorli]

I am also worried about a new version automatically. I don't see a big problem in the case when the build fails. The problematic case is when the new compiler has some subtle bug that causes random or rare runtime failures. We have had this kind of problem recently on Windows with MSVC where it was generating instructions that were not supported on some of the intel CPUs that are otherwise supported. Due to those we have decided to stay on a fixed version of the compiler until the new one is fully tested. I'd prefer not getting into this problem on Linux too, especially not with servicing branches.

[am11]

@janvorli can you please explain how that is even possible with dotnet-buildtools-prereqs-docker flow? If we think of how all the piece are flowing, it is not possible to pick up the unintended version. We are using these images: https://github.com/dotnet/runtime/blob/5fd965d7bf0196fad051a9cc1e8ebe093ed94fa8/docs/workflow/building/coreclr/linux-instructions.md#docker-images all of them are azurelinux 3.0 based (or the old ones with CBL Mariner). Both Azure Linux and CBL mariner images are skipping this branch because we have our "custom" clang without suffix. The suffix version is only relavant for distro source-builds and local environments. Therefore, servicing branches won't be affected.

[am11]

@janvorli this is the branch which all the official/service pipelines hit., which remained untouched.

[janvorli]

@am11 I didn't remember that we are using self-built clang of a specific version in the CI and for the official builds. So what I was afraid of is not a problem.

Then I don't have any worries about the change other than that people building .NET on their own machines can bump into subtle issues with their builds that we would not know about. Long time ago, I was trying to verify each newly added clang version using the coreclr / libraries tests to make sure they pass. But I've stopped doing that around version 12 and we've kept adding new versions possibly without full verification (unless you were doing that, of course). So this change doesn't change much of the risks.

[am11]

@janvorli, yup, since dotnet/dotnet-buildtools-prereqs-docker#832, we moved the official and other CI legs to just use clang without version suffix. Now it is so when we update clang in cbl/azurelinux crossdeps-builder file, it just gets updated everywhere and we rely on testing (initial version was 12 now azurelinux images have v18). Also, we are now using floating container tags e.g. azurelinux-3.0-cross-arm64-net9.0 instead of pinned azurelinux-3.0-cross-arm64-net9.0-20240712200413-56767ed, which presents much higher chance of subtle breakages than the old approach; pinned clang version and container tags. The current approach is to fix the issues as they are discovered.

Compared to that, the local or source build selecting latest clang (iff multiple clang versions are installed) poses no risk as those user can pass -clang18 or -gcc14 etc. to build.sh on the off-chance there is a need to do so.

[janvorli]

LGTM, thank you!

[akoeplinger]

I merged dotnet/arcade#14963, thanks!