Supported compiler versions?

[madsmtm]

We do not currently document our minimum supported compiler versions (or which compilers we support in general), and that makes it hard to figure out which workarounds for older versions make sense.

For example, in #1395, I wanted to argue that we should always pass the flag to avoid the overhead of checking if it's supported because I suspected it's supported everywhere, but I couldn't make that argument without knowing this piece of information. It is also hard to create a CI step that tests older versions, if we don't know the range we target.

It would also make sense to have a policy around these; maybe we only bump requirements in minor versions?

---

I'm only certain about the Apple stuff, but I tried to do a bit of research:

Compiler	Minimum supported version	Year introduced
GCC	3.2, same as required to build the minimum supported kernel version (3.2)? Or 5.1, same as currently required by the Linux kernel? Or base it on glibc version? Debian 11 has GCC 10	2002 / 2015 / 2022 / ...
Clang	Current linux kernel requires 13.0.1. Debian 11 provides Clang 11.1.0	2022 / 2021
Apple Clang	9.0.0 (LLVM 5.0.2) (Xcode 9.3, same as rustc)	2018
clang-cl	?	?
MSVC	Visual Studio 14 (12 dropped in #1046)	2015
Zig CC	?	?
vxWorks	?	?
qcc (QNX SDK)	?	?
NVIDIA CUDA Compiler Driver	?	?

Are we missing compilers in this table? Or is this the full list of compilers we support?

CC @ChrisDenton @NobodyXu WDYT?
CC @Darksonn, dunno if RfL uses cc-rs, but if you do, what would be desired for you? (Both now and in the future).

Discussion on Zulip.

[NobodyXu]

Does rustc has a minimum supported version for this? I think it might have for linking?

[NobodyXu]

Does rustc has a minimum supported version for this? I think it might have for linking?

[Darksonn]

RfL doesn't use cc-rs because we don't use cargo.

[ChrisDenton]

Does rustc has a minimum supported version for this? I think it might have for linking?

rustc has minimum versions it targets but the documentation is a bit scarce, see rust-lang/rust#129307. Bumping target tools usually requires a compiler team decision so there should be some record of it, albeit not necessarily easy to find.

I guess LLVM tools would be the exception because we regularly bump to the latest version of LLVM and additionally support up to two versions back. While technically older LLVM tools may work with the output from newer LLVM, I'm not sure that's guaranteed.

[NobodyXu]

I guess LLVM tools would be the exception because we regularly bump to the latest version of LLVM and additionally support up to two versions back. While technically older LLVM tools may work with the output from newer LLVM, I'm not sure that's guaranteed.

Thanks, so for llvm, maybe we just support the same version as the msrv of cc-rs?

[NobodyXu]

Also, since our msrv is tracking debian's rustc version, maybe we just need to support the same version as debian stable?

[wh1sky02]

This is a crucial topic for ecosystem compatibility! Here's my perspective on establishing minimum supported compiler versions:

Suggested Approach:

Policy Framework:

1. Major version bumps: Can raise minimum supported compiler versions
2. Minor version bumps: Should maintain compatibility (following SemVer)
3. Document clearly: in README, CHANGELOG, and Cargo.toml

Minimum Version Recommendations:

For 2025, I'd suggest:

• GCC 7.1+ (2017) - Good balance of modern features vs compatibility
• Clang 11.0+ (2020) - Aligns with Debian 11 baseline
• MSVC 2019 (VS 16.0) - Stable and widely deployed
• Apple Clang 12.0+ - Reasonable for Xcode users

Rationale:

• These versions support C++17 features many Rust tools expect
• Still compatible with major enterprise environments
• Covers ~95% of active development environments

Implementation Strategy:

# In CI, test matrix
compilers:
  - gcc-7, gcc-latest
  - clang-11, clang-latest  
  - msvc-2019, msvc-latest

Would this provide the clarity you need for PR #1395 while maintaining broad compatibility?

[NobodyXu]

Not sure about major version number, bumping major version typically means API incompatibility, but for compiler it's change to the environment, many crates might either stuck with v1 or have to do >=1,<=2 for ver requirements