…r-errors

Add stubs in IR and ABI for `f16` and `f128`

This is the very first step toward the changes in rust-lang/rust#114607 and the [`f16` and `f128` RFC](https://rust-lang.github.io/rfcs/3453-f16-and-f128.html). It adds the types to `rustc_type_ir::FloatTy` and `rustc_abi::Primitive`, and just propagates those out as `unimplemented!` stubs where necessary.

These types do not parse yet so there is no feature gate, and it should be okay to use `unimplemented!`.

The next steps will probably be AST support with parsing and the feature gate.

r? `@compiler-errors`
cc `@Nilstrieb` suggested breaking the PR up in rust-lang/rust#120645 (comment)

…, 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

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

…r-errors

Add stubs in IR and ABI for `f16` and `f128`

This is the very first step toward the changes in rust-lang/rust#114607 and the [`f16` and `f128` RFC](https://rust-lang.github.io/rfcs/3453-f16-and-f128.html). It adds the types to `rustc_type_ir::FloatTy` and `rustc_abi::Primitive`, and just propagates those out as `unimplemented!` stubs where necessary.

These types do not parse yet so there is no feature gate, and it should be okay to use `unimplemented!`.

The next steps will probably be AST support with parsing and the feature gate.

r? `@compiler-errors`
cc `@Nilstrieb` suggested breaking the PR up in rust-lang/rust#120645 (comment)

…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-errors

Add stubs in IR and ABI for `f16` and `f128`

This is the very first step toward the changes in rust-lang/rust#114607 and the [`f16` and `f128` RFC](https://rust-lang.github.io/rfcs/3453-f16-and-f128.html). It adds the types to `rustc_type_ir::FloatTy` and `rustc_abi::Primitive`, and just propagates those out as `unimplemented!` stubs where necessary.

These types do not parse yet so there is no feature gate, and it should be okay to use `unimplemented!`.

The next steps will probably be AST support with parsing and the feature gate.

r? `@compiler-errors`
cc `@Nilstrieb` suggested breaking the PR up in rust-lang/rust#120645 (comment)

…ler-errors

`f16` and `f128` step 2: intrinsics

Continuation of rust-lang/rust#121728, another portion of rust-lang/rust#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 #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

…r=Amanieu

`f16` and `f128` step 4: basic library support

This is the next step after rust-lang#121926, another portion of rust-lang#114607

Tracking issue: rust-lang#116909

This PR adds the most basic operations to `f16` and `f128` that get lowered as LLVM intrinsics. This is a very small step but it seemed reasonable enough to add unopinionated basic operations before the larger modules that are built on top of them.

r? `@Amanieu` since you were pretty involved in the RFC
cc `@compiler-errors`
`@rustbot` label  T-libs-api  S-blocked  F-f16_and_f128

…r=Amanieu

`f16` and `f128` step 4: basic library support

This is the next step after rust-lang#121926, another portion of rust-lang#114607

Tracking issue: rust-lang#116909

This PR adds the most basic operations to `f16` and `f128` that get lowered as LLVM intrinsics. This is a very small step but it seemed reasonable enough to add unopinionated basic operations before the larger modules that are built on top of them.

r? ``@Amanieu`` since you were pretty involved in the RFC
cc ``@compiler-errors``
``@rustbot`` label  T-libs-api  S-blocked  F-f16_and_f128

…r=Amanieu

`f16` and `f128` step 4: basic library support

This is the next step after rust-lang#121926, another portion of rust-lang#114607

Tracking issue: rust-lang#116909

This PR adds the most basic operations to `f16` and `f128` that get lowered as LLVM intrinsics. This is a very small step but it seemed reasonable enough to add unopinionated basic operations before the larger modules that are built on top of them.

r? ```@Amanieu``` since you were pretty involved in the RFC
cc ```@compiler-errors```
```@rustbot``` label  T-libs-api  S-blocked  F-f16_and_f128

…Amanieu

`f16` and `f128` step 4: basic library support

This is the next step after rust-lang#121926, another portion of rust-lang#114607

Tracking issue: rust-lang#116909

This PR adds the most basic operations to `f16` and `f128` that get lowered as LLVM intrinsics. This is a very small step but it seemed reasonable enough to add unopinionated basic operations before the larger modules that are built on top of them.

r? `@Amanieu` since you were pretty involved in the RFC
cc `@compiler-errors`
`@rustbot` label  T-libs-api  S-blocked  F-f16_and_f128

…Amanieu

`f16` and `f128` step 4: basic library support

This is the next step after rust-lang#121926, another portion of rust-lang#114607

Tracking issue: rust-lang#116909

This PR adds the most basic operations to `f16` and `f128` that get lowered as LLVM intrinsics. This is a very small step but it seemed reasonable enough to add unopinionated basic operations before the larger modules that are built on top of them.

r? `@Amanieu` since you were pretty involved in the RFC
cc `@compiler-errors`
`@rustbot` label  T-libs-api  S-blocked  F-f16_and_f128

Rollup merge of rust-lang#122470 - tgross35:f16-f128-step4-libs-min, r=Amanieu

`f16` and `f128` step 4: basic library support

This is the next step after rust-lang#121926, another portion of rust-lang#114607

Tracking issue: rust-lang#116909

This PR adds the most basic operations to `f16` and `f128` that get lowered as LLVM intrinsics. This is a very small step but it seemed reasonable enough to add unopinionated basic operations before the larger modules that are built on top of them.

r? ```@Amanieu``` since you were pretty involved in the RFC
cc ```@compiler-errors```
```@rustbot``` label  T-libs-api  S-blocked  F-f16_and_f128

Remove `f16` and `f128` ICE paths from smir

Just chasing down some possible ICE paths. `@compiler-errors` mentioned in rust-lang#121728 (comment) that it is okay not to support these in smir, but this change seems pretty trivial?

r? `@celinval` since you reviewed rust-lang#114607 (review)

Remove `f16` and `f128` ICE paths from smir

Just chasing down some possible ICE paths. ``@compiler-errors`` mentioned in rust-lang#121728 (comment) that it is okay not to support these in smir, but this change seems pretty trivial?

r? ``@celinval`` since you reviewed rust-lang#114607 (review)

Remove `f16` and `f128` ICE paths from smir

Just chasing down some possible ICE paths. ```@compiler-errors``` mentioned in rust-lang#121728 (comment) that it is okay not to support these in smir, but this change seems pretty trivial?

r? ```@celinval``` since you reviewed rust-lang#114607 (review)

Rollup merge of rust-lang#126983 - tgross35:f16-f128-smir, r=celinval

Remove `f16` and `f128` ICE paths from smir

Just chasing down some possible ICE paths. ```@compiler-errors``` mentioned in rust-lang#121728 (comment) that it is okay not to support these in smir, but this change seems pretty trivial?

r? ```@celinval``` since you reviewed rust-lang#114607 (review)