How should cfg(target-feature) behave around forbidden target features? #132351
Labels
A-ABI
Area: Concerning the application binary interface (ABI)
A-target-feature
Area: Enabling/disabling target features like AVX, Neon, etc.
C-discussion
Category: Discussion or questions that doesn't represent real issues.
E-needs-design
This issue needs exploration and design to see how and if we can fix/implement it
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
See #129884 and #116344 for context explaining what a forbidden target feature is.
The plan for target features like
fpreg
on ARM is that they will be forbidden unless the target hassoft-float
in its base feature set. This means our hardfloat ARM targets requirefpregs
, but on our softfloat ARM targets users can opt-in to having the FPU avialable, it just won't be used for the ABI. See #124404 for why we can't just forbidfpregs
outright.What should the behavior of
cfg(target-feature = "fpregs")
be, then? For now, #129884 makes it so that forbidden features are never set incfg
. But for this one it seems like when we unstable addfpregs
for softfloat targets, then we'll want to unstably expose the ability to docfg(target-feature = "fpregs")
on all ARM targets. So we'll need a concept of target features that are forbidden to set, but can be unstably (and eventually, stably) queried. At the same time, other target features likesoft-float
likely should never be queried.So seems like for these more complicated features, the question whether a feature is forbidden to set is somewhat orthogonal to its stability. I have some plans for a follow-up PR to #129884 to be able to represent that, but still need to figure out the details.
The text was updated successfully, but these errors were encountered: