Add core::num::Complex - #158885
Open
folkertdev wants to merge 8 commits into
Open
Conversation
rustbot
added
A-attributes
Collaborator
|
|
folkertdev
commented
Jul 6, 2026
Contributor
Author
There was a problem hiding this comment.
Commit e4c802f shows how our LLVM IR representation differs from clang. For instance instead of <2 x float> we just use double, and sometimes we pass { double, double} instead of two separate double arguments.
Based on what I know that is perfectly compatible on an ABI-level, it's just textually different from clang.
Contributor
Author
There was a problem hiding this comment.
Right, so this whole file has been set up so that, hopefully, it will be easy to review that when we deviate from clang, it's only a textual difference, not an abi difference.
8 tasks
mejrs
reviewed
Jul 6, 2026
teor2345
approved these changes
Jul 6, 2026
Member
|
Is it me or is the callconv implementation missing? I don't see any users of |
This comment has been minimized.
This comment has been minimized.
Contributor
Author
For x86_64 we only need custom behavior for f80. I've not yet implemented a target where it is needed, and I'd kind of prefer to do that in a follow-up |
| use FfiResult::*; | ||
|
|
||
| if !def.repr().c() && !def.repr().transparent() { | ||
| if !def.repr().c() && !def.repr().transparent() && !def.repr().complex() { |
Contributor
There was a problem hiding this comment.
This likely needs some work, for example Complex<{integer}> or even weirder types like Complex<String> (if that's even allowed by the compiler) should not be considered FFI safe. Easily done in a followup however.
Contributor
There was a problem hiding this comment.
Actually Complex<{integer}> might be de-facto fine under GCC and Clang, I'm not certain. It's a non-standard C extension though, so not sure what we want to do about that.
Member
There was a problem hiding this comment.
I recommend we err conservatively and treat it as nonsense for now until anyone asks for it.
Contributor
Author
There was a problem hiding this comment.
Right, takes some more logic but we now only accept (transparently wrapped) float types, anything else triggers improper_ctypes.
Contributor
Author
There was a problem hiding this comment.
btw it is my intention to make Complex<{integer}> just be abi-compatible in practice, but whether we actually guarantee it can be discussed later.
AndyGauge
added a commit
to AndyGauge/rust-reviewer
that referenced
this pull request
Jul 6, 2026
Part 18: runs rust-lang/rust#158885 (Add Complex type / repr(complex), a novel feature) through the full pipeline. Critic emits 26 comments; base judge keeps 6 (6 accept / 20 reject). The 6 survivors are a real maintainer review; the rejects expose a NEW failure mode distinct from Part 17's knowledge blind spot — grounding failures, where the critic asks for what the diff already contains because it's pattern-matching the form of a review, not reading the hunk. Argues the judge's accept rate (8/12 cookbook vs 6/26 here) is a distribution meter: an unlabeled readout of how far out of depth the critic is on a given PR. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
folkertdev
force-pushed
the
complex-layout
branch
2 times, most recently
from
July 7, 2026 12:21
7300c0a to
a63e0f1
Compare
folkertdev
commented
Jul 7, 2026
Comment on lines
+1557
to
+1558
| // repr(complex) is internal, so this check is not as thorough as we'd require if it were | ||
| // user-facing. |
Contributor
Author
There was a problem hiding this comment.
Lmk if we should be more thorough here, but given that we never want to stabilize repr(complex), only Complex<T>, this seems (more than) adequate.
| use FfiResult::*; | ||
|
|
||
| if !def.repr().c() && !def.repr().transparent() { | ||
| if !def.repr().c() && !def.repr().transparent() && !def.repr().complex() { |
Contributor
Author
There was a problem hiding this comment.
Right, takes some more logic but we now only accept (transparently wrapped) float types, anything else triggers improper_ctypes.
Comment on lines
+110
to
+113
| #[repr(complex)] | ||
| //~^ ERROR attribute cannot be used on macro calls | ||
| //~| ERROR `repr(complex)` is experimental | ||
| unreachable!(); |
Contributor
Author
There was a problem hiding this comment.
added this, it's already an error because there is no compatibility concern
This comment has been minimized.
This comment has been minimized.
mejrs
approved these changes
Jul 7, 2026
folkertdev
force-pushed
the
complex-layout
branch
from
July 7, 2026 13:14
a63e0f1 to
39d6ddf
Compare
This comment has been minimized.
This comment has been minimized.
folkertdev
force-pushed
the
complex-layout
branch
from
July 7, 2026 14:45
39d6ddf to
faadfa3
Compare
folkertdev
marked this pull request as ready for review
July 7, 2026 16:13
rustbot
added
the
S-waiting-on-review
Collaborator
|
Some changes occurred in compiler/rustc_passes/src/check_attr.rs cc @jdonszelmann, @JonathanBrouwer Some changes occurred in compiler/rustc_hir/src/attrs cc @jdonszelmann, @JonathanBrouwer Some changes occurred in compiler/rustc_attr_parsing |
rustbot
removed
the
S-waiting-on-author
This comment has been minimized.
This comment has been minimized.
workingjubilee
approved these changes
Aug 13, 2026
Member
|
@bors r+ rollup |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Aug 13, 2026
…ngjubilee Add `core::num::Complex` tracking issue: rust-lang#154023 See also [#t-compiler > representing &rust-lang#96;_Complex&rust-lang#96;](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/representing.20.60_Complex.60/with/608308993). The RFC states that the `Complex` type should match the ABI of `_Complex` in C, but provides little detail on how to actually achieve this. We concluded that `repr(complex)` is probably the best approach. Like clang, that means we "desugar" the representation early: `_Complex` is not natively represented in LLVM IR. I've derived the ABI from `clang` for 28 targets, a decent sample of what we actually support. For now I'm only actually testing `x86_64` because (as you'll see) updating the tests is quite labor-intensive. If we're happy with this direction I can fill more of them in, likely in a separate PR. The libs side of the type is very bare-bones: I'm not as interested in that part. Others can fill in the various instances, methods, write tests for those, and improve the docs. r? workingjubilee
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Aug 13, 2026
…ngjubilee Add `core::num::Complex` tracking issue: rust-lang#154023 See also [#t-compiler > representing &rust-lang#96;_Complex&rust-lang#96;](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/representing.20.60_Complex.60/with/608308993). The RFC states that the `Complex` type should match the ABI of `_Complex` in C, but provides little detail on how to actually achieve this. We concluded that `repr(complex)` is probably the best approach. Like clang, that means we "desugar" the representation early: `_Complex` is not natively represented in LLVM IR. I've derived the ABI from `clang` for 28 targets, a decent sample of what we actually support. For now I'm only actually testing `x86_64` because (as you'll see) updating the tests is quite labor-intensive. If we're happy with this direction I can fill more of them in, likely in a separate PR. The libs side of the type is very bare-bones: I'm not as interested in that part. Others can fill in the various instances, methods, write tests for those, and improve the docs. r? workingjubilee
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 13, 2026
Rollup of 14 pull requests Successful merges: - #158918 (x86_64-win: Enable f128 on LLVM 23+) - #160288 (rustdoc: use anonymous constant for primitives/keywords/attribute docs) - #160440 (Couple of misc improvements to the unwind infrastructure) - #160441 (PowerPC inline ASM: Fix scalar floats being in the wrong vector lane on little endian) - #160896 (tidy: Update Python version requirements to 3.11) - #160972 (std: map ERROR_NEGATIVE_SEEK to ErrorKind::InvalidInput on Windows) - #161040 (Optimize CStr backing slice bounds checks) - #158885 (Add `core::num::Complex`) - #160928 (check `mut`-restriction when tuple constructor is used as a value) - #161002 (disallow `#[cold]` on `extern "custom"` functions) - #161016 (Fix invalid suggestion from try unlabled block) - #161020 (io: Use `NonNull` for all `Custom` API related to `Box`, update documentation for `Custom`) - #161044 (rustc-dev-guide subtree update) - #161046 (Enable unrolling feature of bors)
Contributor
Author
|
Failed in CI #161056 (comment), has a simple fix I'll push in a bit @bors r- |
rust-bors
Bot
added
S-waiting-on-author
Contributor
|
This pull request was unapproved. This PR was contained in a rollup (#161056), which was unapproved. |
folkertdev
force-pushed
the
complex-layout
branch
from
August 13, 2026 17:32
daf4a0e to
534309d
Compare
Contributor
|
This PR was contained in a rollup (#161056), which was closed. |
Contributor
Author
|
@bors try jobs=x86_64-gnu-nopt |
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 13, 2026
Add `core::num::Complex` try-job: x86_64-gnu-nopt
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Contributor
Contributor
Author
|
@bors r=workingjubilee |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
View all comments
tracking issue: #154023
See also #t-compiler > representing `_Complex`. The RFC states that the
Complextype should match the ABI of_Complexin C, but provides little detail on how to actually achieve this. We concluded thatrepr(complex)is probably the best approach. Like clang, that means we "desugar" the representation early:_Complexis not natively represented in LLVM IR.I've derived the ABI from
clangfor 28 targets, a decent sample of what we actually support. For now I'm only actually testingx86_64because (as you'll see) updating the tests is quite labor-intensive. If we're happy with this direction I can fill more of them in, likely in a separate PR.The libs side of the type is very bare-bones: I'm not as interested in that part. Others can fill in the various instances, methods, write tests for those, and improve the docs.
r? workingjubilee