Rollup of 5 pull requestsSuccessful 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 ofrust-lang#121841 - tgross35:f16-f128-step2-intrinsics, r=compiler-errors`f16` and `f128` step 2: intrinsicsContinuation ofrust-lang#121728, another portion ofrust-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` inhttps://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 fromrust-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 gateContinuation ofrust-lang#121841, another portion ofrust-lang#114607This 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#116909r? `@compiler-errors`cc `@Nilstrieb``@rustbot` label +F-f16_and_f128

…te, r=compiler-errors`f16` and `f128` step 3: compiler support & feature gateContinuation ofrust-lang#121841, another portion ofrust-lang#114607This 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#116909r? ``@compiler-errors``cc ``@Nilstrieb````@rustbot`` label +F-f16_and_f128

…te, r=compiler-errors`f16` and `f128` step 3: compiler support & feature gateContinuation ofrust-lang#121841, another portion ofrust-lang#114607This 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#116909r? ```@compiler-errors```cc ```@Nilstrieb``````@rustbot``` label +F-f16_and_f128

…, r=compiler-errors`f16` and `f128` step 2: intrinsicsContinuation ofrust-lang#121728, another portion ofrust-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` inhttps://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 fromrust-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 gateContinuation ofrust-lang#121841, another portion ofrust-lang#114607This 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#116909r? `@compiler-errors`cc `@Nilstrieb``@rustbot` label +F-f16_and_f128

…, r=compiler-errors,petrochenkov`f16` and `f128` step 3: compiler support & feature gateContinuation ofrust-lang#121841, another portion ofrust-lang#114607This 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#116909r? `@compiler-errors`cc `@Nilstrieb``@rustbot` label +F-f16_and_f128

…ler-errors,petrochenkov`f16` and `f128` step 3: compiler support & feature gateContinuation ofrust-lang/rust#121841, another portion ofrust-lang/rust#114607This 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#116909r? `@compiler-errors`cc `@Nilstrieb``@rustbot` label +F-f16_and_f128