do not map llvm_features_by_flags back into Rust-level cfg(target_feature) - #160465
do not map llvm_features_by_flags back into Rust-level cfg(target_feature)#160465RalfJung wants to merge 1 commit into
Conversation
|
r? @mati865 rustbot has assigned @mati865. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
I think it's reasonable to consider the |
|
Looking at that CI failure... What I did not realize is that we put "forbidden" target features into For this PR that means we have to be on the look for things checking for the retpoline stuff or reserved-x18 in |
For some reason, we currently apply
llvm_features_by_flagsalso to the "informational LLVM target machine" that we create to populatecfg(target_feature). This strikes me as odd: these are things that we do not treat as target features on the Rust level, why should they affectcfg(target_feature)?From what I was able to find, the only LLVM target feature set by
llvm_features_by_flagsthat has a corresponding Rust target feature is wasm'sexception-handling. That one is unstable (tracking: #150260), so this PR should change nothing for stable users. On unstable, this PR means that if you set-Cpanic=unwindyou no longer getcfg(target_feature = "exception-handling"). Is that okay? Is that a problem? I don't know. This behavior has been around since #121438 but it does not look like it was discussed much in that PR; it is not clear whether this was even intentional (this code is a total mess, after all).What is even supposed to happen in cases like
-Cpanic=unwind -Ctarget-feature=-exception-handling? It is very strange to have two flags both affect the same LLVM target feature. The easiest way to resolve this would be to mark theexception-handlingtarget feature as "forbidden" so it can no longer be toggled via-Ctarget-feature. But that may be a bad idea?Cc @bjorn3 @alexcrichton @cuviper @coolreader18