-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
f16
and f128
step 2: intrinsics
#121841
f16
and f128
step 2: intrinsics
#121841
Conversation
Some changes occurred in exhaustiveness checking cc @Nadrieril The Miri subtree was changed cc @rust-lang/miri Some changes occurred in compiler/rustc_codegen_gcc Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri Some changes occurred in src/librustdoc/clean/types.rs cc @camelid Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 Some changes occurred in match checking cc @Nadrieril Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
e4816c3
to
5f14869
Compare
Sorry for the noise, accidentally included my commits from #121728. Most of the mentions in that comment are unchanged in this PR. |
e39b853
to
78c618e
Compare
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One nit, also needs CI to pass. r=me after.
78c618e
to
f375424
Compare
@bors r+ |
Actually just fix both of these issues now, there's no rush to get this PR merged. @bors r- |
f375424
to
01755e3
Compare
Easy enough, fixed both things |
@bors r+ |
Rollup of 5 pull requests Successful merges: - rust-lang#120761 (Add initial support for DataFlowSanitizer) - rust-lang#121622 (Preserve same vtable pointer when cloning raw waker, to fix Waker::will_wake) - rust-lang#121716 (match lowering: Lower bindings in a predictable order) - rust-lang#121731 (Now that inlining, mir validation and const eval all use reveal-all, we won't be constraining hidden types here anymore) - rust-lang#121841 (`f16` and `f128` step 2: intrinsics) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#121841 - tgross35:f16-f128-step2-intrinsics, r=compiler-errors `f16` and `f128` step 2: intrinsics Continuation of rust-lang#121728, another portion of rust-lang#114607. This PR adds `f16` and `f128` intrinsics, and hooks them up to both HIR and LLVM. This is all still unexposed to the frontend, which will probably be the next step. Also update itanium mangling per `@rcvalle's` in https://github.com/rust-lang/rust/pull/121728/files#r1506570300, and fix a typo from step 1. Once these types are usable in code, I will add the codegen tests from rust-lang#114607 (codegen is passing on that branch) This does add more `unimplemented!`s to Clippy, but I still don't think we can do better until library support is added. r? `@compiler-errors` cc `@Nilstrieb` `@rustbot` label +T-compiler +F-f16_and_f128
…te, r=compiler-errors `f16` and `f128` step 3: compiler support & feature gate Continuation of rust-lang#121841, another portion of rust-lang#114607 This PR exposes the new types to the world and adds a feature gate. Marking this as a draft because I need some feedback on where I did the feature gate check. It also does not yet catch type via suffixed literals (so the feature gate test will fail, probably some others too because I haven't belssed). If there is a better place to check all types after resolution, I can do that. If not, I figure maybe I can add a second gate location in AST when it checks numeric suffixes. Unfortunately I still don't think there is much testing to be done for correctness (codegen tests or parsed value checks) until we have basic library support. I think that will be the next step. Tracking issue: rust-lang#116909 r? `@compiler-errors` cc `@Nilstrieb` `@rustbot` label +F-f16_and_f128
…te, r=compiler-errors `f16` and `f128` step 3: compiler support & feature gate Continuation of rust-lang#121841, another portion of rust-lang#114607 This PR exposes the new types to the world and adds a feature gate. Marking this as a draft because I need some feedback on where I did the feature gate check. It also does not yet catch type via suffixed literals (so the feature gate test will fail, probably some others too because I haven't belssed). If there is a better place to check all types after resolution, I can do that. If not, I figure maybe I can add a second gate location in AST when it checks numeric suffixes. Unfortunately I still don't think there is much testing to be done for correctness (codegen tests or parsed value checks) until we have basic library support. I think that will be the next step. Tracking issue: rust-lang#116909 r? ``@compiler-errors`` cc ``@Nilstrieb`` ``@rustbot`` label +F-f16_and_f128
…te, r=compiler-errors `f16` and `f128` step 3: compiler support & feature gate Continuation of rust-lang#121841, another portion of rust-lang#114607 This PR exposes the new types to the world and adds a feature gate. Marking this as a draft because I need some feedback on where I did the feature gate check. It also does not yet catch type via suffixed literals (so the feature gate test will fail, probably some others too because I haven't belssed). If there is a better place to check all types after resolution, I can do that. If not, I figure maybe I can add a second gate location in AST when it checks numeric suffixes. Unfortunately I still don't think there is much testing to be done for correctness (codegen tests or parsed value checks) until we have basic library support. I think that will be the next step. Tracking issue: rust-lang#116909 r? ```@compiler-errors``` cc ```@Nilstrieb``` ```@rustbot``` label +F-f16_and_f128
…, r=compiler-errors `f16` and `f128` step 2: intrinsics Continuation of rust-lang#121728, another portion of rust-lang#114607. This PR adds `f16` and `f128` intrinsics, and hooks them up to both HIR and LLVM. This is all still unexposed to the frontend, which will probably be the next step. Also update itanium mangling per `@rcvalle's` in https://github.com/rust-lang/rust/pull/121728/files#r1506570300, and fix a typo from step 1. Once these types are usable in code, I will add the codegen tests from rust-lang#114607 (codegen is passing on that branch) This does add more `unimplemented!`s to Clippy, but I still don't think we can do better until library support is added. r? `@compiler-errors` cc `@Nilstrieb` `@rustbot` label +T-compiler +F-f16_and_f128
…, r=compiler-errors,petrochenkov `f16` and `f128` step 3: compiler support & feature gate Continuation of rust-lang#121841, another portion of rust-lang#114607 This PR exposes the new types to the world and adds a feature gate. Marking this as a draft because I need some feedback on where I did the feature gate check. It also does not yet catch type via suffixed literals (so the feature gate test will fail, probably some others too because I haven't belssed). If there is a better place to check all types after resolution, I can do that. If not, I figure maybe I can add a second gate location in AST when it checks numeric suffixes. Unfortunately I still don't think there is much testing to be done for correctness (codegen tests or parsed value checks) until we have basic library support. I think that will be the next step. Tracking issue: rust-lang#116909 r? `@compiler-errors` cc `@Nilstrieb` `@rustbot` label +F-f16_and_f128
…, r=compiler-errors,petrochenkov `f16` and `f128` step 3: compiler support & feature gate Continuation of rust-lang#121841, another portion of rust-lang#114607 This PR exposes the new types to the world and adds a feature gate. Marking this as a draft because I need some feedback on where I did the feature gate check. It also does not yet catch type via suffixed literals (so the feature gate test will fail, probably some others too because I haven't belssed). If there is a better place to check all types after resolution, I can do that. If not, I figure maybe I can add a second gate location in AST when it checks numeric suffixes. Unfortunately I still don't think there is much testing to be done for correctness (codegen tests or parsed value checks) until we have basic library support. I think that will be the next step. Tracking issue: rust-lang#116909 r? `@compiler-errors` cc `@Nilstrieb` `@rustbot` label +F-f16_and_f128
…ler-errors,petrochenkov `f16` and `f128` step 3: compiler support & feature gate Continuation of rust-lang/rust#121841, another portion of rust-lang/rust#114607 This PR exposes the new types to the world and adds a feature gate. Marking this as a draft because I need some feedback on where I did the feature gate check. It also does not yet catch type via suffixed literals (so the feature gate test will fail, probably some others too because I haven't belssed). If there is a better place to check all types after resolution, I can do that. If not, I figure maybe I can add a second gate location in AST when it checks numeric suffixes. Unfortunately I still don't think there is much testing to be done for correctness (codegen tests or parsed value checks) until we have basic library support. I think that will be the next step. Tracking issue: rust-lang/rust#116909 r? `@compiler-errors` cc `@Nilstrieb` `@rustbot` label +F-f16_and_f128
Continuation of #121728, another portion of #114607.
This PR adds
f16
andf128
intrinsics, and hooks them up to both HIR and LLVM. This is all still unexposed to the frontend, which will probably be the next step. Also update itanium mangling per @rcvalle's in https://github.com/rust-lang/rust/pull/121728/files#r1506570300, and fix a typo from step 1.Once these types are usable in code, I will add the codegen tests from #114607 (codegen is passing on that branch)
This does add more
unimplemented!
s to Clippy, but I still don't think we can do better until library support is added.Tracking issue: #116909
r? @compiler-errors
cc @Nilstrieb
@rustbot label +T-compiler +F-f16_and_f128