-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stabilize f16c_target_feature #106323
Stabilize f16c_target_feature #106323
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @lcnr (or someone else) soon. Please see the contribution instructions for more information. |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
r? compiler |
I had the same question when seeing this PR, this x86 feature is sufficiently old. Not sure whether an FCP is needed when stabilizing a minor target feature, probably not, so I'll only ping @rust-lang/compiler. |
@bors r+ |
…ature, r=petrochenkov Stabilize f16c_target_feature Resolves rust-lang/stdarch#1234 Library PR for stabilizing corresponding intrinsics: rust-lang/stdarch#1366 See also rust-lang#44839 tracking issue for target_feature
…mpiler-errors Rollup of 8 pull requests Successful merges: - rust-lang#103236 (doc: rewrite doc for signed int::{carrying_add,borrowing_sub}) - rust-lang#103800 (Stabilize `::{core,std}::pin::pin!`) - rust-lang#106097 (Migrate mir_build diagnostics 2 of 3) - rust-lang#106170 (Move autoderef to `rustc_hir_analysis`) - rust-lang#106323 (Stabilize f16c_target_feature) - rust-lang#106360 (Tweak E0277 `&`-removal suggestions) - rust-lang#106524 (Label `struct/enum constructor` instead of `fn item`, mention that it should be called on type mismatch) - rust-lang#106739 (Remove `<dyn AstConv<'tcx>>::fun(c, ...)` calls in favour of `c.astconv().fun(...)`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
@wesleywiser pointed out to me that there is some precedent for getting lang team sign off or at least rough approval on the stabilization of target features, see e.g. #93745 I'm personally inclined to trust T-libs-api's judgement w.r.t. the specific stabilization of f16c, but I also want to keep T-lang design team or T-compiler aware of such changes in general, and give them the chance say that stabilizing even minor target features needs some kind of team sign off beyond just T-libs-api... So, I am nominating this for both T-compiler and T-lang, just so that they each note the process that was followed here (namely, trusting the judgement of @Amanieu with their T-libs-api hat on), and get a chance to say that a different process should be followed either here or in other cases in the future. (Having said all that, I don't see a need to revert this PR itself, not without input from at least one of the teams for which I nominated this for discussion.) @rustbot label: I-lang-nominated I-compiler-nominated |
My understanding is that the stabilization of the intrinsics in stdarch are under T-libs-api (rust-lang/stdarch#1366, still in FCP). However the actual target feature for |
Stabilize movbe target feature Almost all "old" x86 target features are stable. As far as I can tell, these are the last two unstable features in the `x86-64-v2` or `x86-64-v3` microarchitecture levels, so I'm not sure if it was an oversight or if they're still unstable for a reason (see rust-lang#106323 for `f16c`). Note that this only stabilizes the target features, and not the intrinsics. cc `@Amanieu` r? `@rust-lang/lang`
Stabilize movbe target feature Almost all "old" x86 target features are stable. As far as I can tell, these are the last two unstable features in the `x86-64-v2` or `x86-64-v3` microarchitecture levels, so I'm not sure if it was an oversight or if they're still unstable for a reason (see rust-lang#106323 for `f16c`). Note that this only stabilizes the target features, and not the intrinsics. cc ``@Amanieu`` r? ``@rust-lang/lang``
Stabilize movbe target feature Almost all "old" x86 target features are stable. As far as I can tell, these are the last two unstable features in the `x86-64-v2` or `x86-64-v3` microarchitecture levels, so I'm not sure if it was an oversight or if they're still unstable for a reason (see rust-lang#106323 for `f16c`). Note that this only stabilizes the target features, and not the intrinsics. cc ```@Amanieu``` r? ```@rust-lang/lang```
I assume team discussion nominations can be removed by now @rustbot label -I-compiler-nominated -I-lang-nominated |
Resolves rust-lang/stdarch#1234
Library PR for stabilizing corresponding intrinsics: rust-lang/stdarch#1366
See also #44839 tracking issue for target_feature