#127506 added support for the "backchain" target feature, but doing so required adding some hacks to the compiler. Usually, we compute cfg(target_feature) by asking the codegen backend, but apparently that is not possible here. Those hacks already were partially fixed in #129940, but looking at them again I think the logic is still wrong: the logic here
|
// skip checking special features, as LLVM may not understand them |
|
if RUSTC_SPECIAL_FEATURES.contains(feature) { |
|
return true; |
|
} |
will conclude that the target feature is always enabled in the base target! So if someone adds a s390x target where backchain is disabled by default, we'll falsely claim that it is enabled. And right now, without a -Ctarget-feature argument, we'll say the feature is enabled. I have no clue if that makes sense, but it's definitely not future-proof. (Or even worse, if a different architecture also starts using this feature name, we'll conclude the feature is enabled.)
I think RUSTC_SPECIAL_FEATURES needs to be removed and redeveloped from scratch, the current design makes little sense. (It is also extremely easy to be confused with the very different RUSTC_SPECIFIC_FEATURES hack.)
Is this hack even still needed? There were some comments indicating that this hack exists to deal with LLVM 18 and older, which we do not support any more.
Cc @liushuyu @uweigand @cuviper
#127506 added support for the "backchain" target feature, but doing so required adding some hacks to the compiler. Usually, we compute
cfg(target_feature)by asking the codegen backend, but apparently that is not possible here. Those hacks already were partially fixed in #129940, but looking at them again I think the logic is still wrong: the logic hererust/compiler/rustc_codegen_llvm/src/llvm_util.rs
Lines 353 to 356 in c24e1c3
will conclude that the target feature is always enabled in the base target! So if someone adds a s390x target where
backchainis disabled by default, we'll falsely claim that it is enabled. And right now, without a-Ctarget-featureargument, we'll say the feature is enabled. I have no clue if that makes sense, but it's definitely not future-proof. (Or even worse, if a different architecture also starts using this feature name, we'll conclude the feature is enabled.)I think
RUSTC_SPECIAL_FEATURESneeds to be removed and redeveloped from scratch, the current design makes little sense. (It is also extremely easy to be confused with the very differentRUSTC_SPECIFIC_FEATUREShack.)Is this hack even still needed? There were some comments indicating that this hack exists to deal with LLVM 18 and older, which we do not support any more.
Cc @liushuyu @uweigand @cuviper