rustc_codegen_llvm: handle LLVM 24 ABI constraints

[durin42]

LLVM 24 is pickier about things like hard-float being disabled but the compiled module ABI mentioning hard-float. As an example, if the user specifies target-features=-d to disable the d extension but the declared target-abi is lp64d that's now an error where before I guess it was a warning.

This fix seems somewhat inelegant, but in the name of keeping the behavior changes minimal I did gate the new behavior to only happen on LLVM 24. I'm very open to alternative solutions!

An LLM was used to identify the breaking commit and help me sort out why the commit was breaking.

@rustbot label: +llvm-main

[rustbot]

r? @mejrs

rustbot has assigned @mejrs.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 76 candidates
• Random selection from 18 candidates

[arichardson]

Apologies for this breakage. My change was intended to buy NFC but apparently there is no test coverage for this. While longer term this should probably be an error it's definitely not supposed to cause churn for downstreams.

[arichardson]

It does seem like this change is an improvement regardless of whether my commit is reverted or not so it definitely LGTM from a functional point. Not a rust expert so can't comment on style or anything else.

[beetrees]

rustc has generally been moving towards emitting hard errors when target features required by the ABI aren't enabled (e.g. #161280), so changing the target ABI we pass to LLVM seems like the wrong solution. Instead we should add RISC-V to the hard error ABI feature check.

cc @RalfJung

[RalfJung]

Agreed, the proposed behavior in this PR is IMO a very bad idea. It's basically re-introducing the broken LLVM behavior that LLVM finally fixed, of silently changing the ABI. We should never silently change the ABI, that's plain unsound.

Instead we should add RISC-V to the hard error ABI feature check.

Agreed. This matches #161280.

[RalfJung]

Apologies for this breakage. My change was intended to buy NFC but apparently there is no test coverage for this. While longer term this should probably be an error it's definitely not supposed to cause churn for downstreams.

No need to apologize, I am very happy that LLVM is finally moving towards actually complaining about nonsensical ABI requests from the frontend, rather than silently doing something arbitrary. :)

llvm/llvm-project#111334 deliberately introduced such errors for the ARM backend. I'd love for RISCV and all the other backends to do the same.