Implement complex numbers and basic arithmetic

[scimind2460]

Related to #154023
This PR adds complex numbers as a lang item behind a libs feature gate and adds simple implementations for arithmetic.

[rustbot]

Some changes occurred in src/tools/cargo

cc @ehuss

[rustbot]

r? @scottmcm

rustbot has assigned @scottmcm.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @scottmcm, libs
• @scottmcm, libs expanded to 8 candidates
• Random selection from Mark-Simulacrum, joboet, scottmcm

[Kivooeo]

add a new line on the end of this file

[Kivooeo]

and this

[tgross35]

I'd recommend that the first PR only add Complex and do the compiler ABI portion. Do math in a followup.

A test in tests/codegen-llvm is needed for sure, also in tests/assembly-llvm would be ideal.

Or only do addition+subtraction first, add compiler support later

[scimind2460]

Or only do addition+subtraction first, add compiler support later

I'll do that. I'm not entirely sure how to add support for calling conventions that exactly match up with _Complex.

[bjorn3]

You can probably make it a lang item and check for it in the target specific call conv impls of rustc_target::callconv and handle it as necessary. Also make sure to annotate it with #[repr(C)] to ensure the correct memory layout. And finally is it intentional that Complex accepts arbitrary types rather than just float types? Presumably there is no standard ABI for non-float types here.

[scimind2460]

You can probably make it a lang item and check for it in the target specific call conv impls of rustc_target::callconv and handle it as necessary. Also make sure to annotate it with #[repr(C)] to ensure the correct memory layout. And finally is it intentional that Complex accepts arbitrary types rather than just float types? Presumably there is no standard ABI for non-float types here.

Thanks for the tip @bjorn3! I was planning to go with the lang item approach and #[repr(c)]. It is intentional as AFAIK libs didn't want the overhead of a full trait, and I'm not sure how we could implement it for non-float types.

[rust-log-analyzer]

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[scottmcm]

It's extremely rare that we have bounds on types in the library. Why does this have the bound rather than just being

Suggested change

	pub struct Complex<T: Copy> {
	pub struct Complex<T> {

[scimind2460]

Because it made it a bit easier to implement the functions themselves rather than think of whether they wilp be consumed or taken by reference (given that floats are Copy)

[scottmcm]

notably, this can't work as written with the bound on the type

[scottmcm]

I would suggest splitting the PRs to not do too much in one. For example, start with just adding a library type with no compiler changes. You can do another PR for lang items and such later.