Skip to content

Atomic intrinsics : use const generic ordering, part 2 #141700

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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented May 28, 2025

This completes what got started in #141507 by using a const generic for the ordering for all intrinsics. It is based on that PR; only the last commit is new.

Blocked on:

r? @bjorn3

@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels May 28, 2025
@rustbot
Copy link
Collaborator

rustbot commented May 28, 2025

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

@RalfJung RalfJung changed the title Atomic intrinsics part2 Atomic intrinsics : use const generic ordering, part 2 May 28, 2025
@rust-log-analyzer

This comment has been minimized.

Comment on lines -225 to -231
} else if intrinsic_name == sym::contract_check_ensures {
// contract_check_ensures::<Ret, C>(Ret, C) -> Ret
// where C: for<'a> Fn(&'a Ret) -> bool,
//
// so: two type params, 0 lifetime param, 0 const params, two inputs, no return
(2, 0, 0, vec![param(0), param(1)], param(1), hir::Safety::Safe)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@celinval do you know why this intrinsic is handled separately rather than in the big match with all the others?

@RalfJung RalfJung force-pushed the atomic-intrinsics-part2 branch from 28cacd2 to b35d186 Compare May 28, 2025 16:54
@rust-log-analyzer

This comment has been minimized.

@RalfJung RalfJung added the S-blocked Status: Blocked on something else such as an RFC or other implementation work. label May 29, 2025
@bors
Copy link
Collaborator

bors commented May 29, 2025

☔ The latest upstream changes (presumably #141716) made this pull request unmergeable. Please resolve the merge conflicts.

@RalfJung RalfJung force-pushed the atomic-intrinsics-part2 branch from b35d186 to 1b4ba1f Compare May 30, 2025 09:47
#[rustc_intrinsic]
pub unsafe fn atomic_xchg_seqcst<T>(dst: *mut T, src: T) -> T;
pub unsafe fn atomic_xchg<T, const ORD: AtomicOrdering>(dst: *mut T, src: T) -> T;
Copy link
Member

@bjorn3 bjorn3 May 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this test use core::intrinsics instead?
Edit: Nope, that would invalidate the test. It seems like it could use a different intrinsic though.
Edit2: This test was added in 22e3a85

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I don't know what this is testing so I changed it as little as possible...

@rust-log-analyzer

This comment has been minimized.

@RalfJung RalfJung force-pushed the atomic-intrinsics-part2 branch from 1b4ba1f to bfcece2 Compare May 30, 2025 10:05
@rustbot
Copy link
Collaborator

rustbot commented May 30, 2025

⚠️ Warning ⚠️

  • Some commits in this PR modify submodules.

@rust-log-analyzer

This comment has been minimized.

@RalfJung RalfJung force-pushed the atomic-intrinsics-part2 branch from bfcece2 to 581de04 Compare May 30, 2025 12:01
@rust-log-analyzer

This comment has been minimized.

@RalfJung
Copy link
Member Author

RalfJung commented May 30, 2025

Uh, how could this PR possibly break that incremental test... (incremental/issue-39569.rs)?
This reproduces when I try it locally.
Cc @compiler-errors @oli-obk @BoxyUwU
(we desperately need an expert map, I have only a vague idea whom to ping for incremental issues)

@BoxyUwU
Copy link
Member

BoxyUwU commented May 30, 2025

I don't really know much about incremental 🙏 Hope you manage to figure it out

@compiler-errors
Copy link
Member

I can look later if you are willing to wait a day or so 🤔

@RalfJung
Copy link
Member Author

The PR is blocked on some other stuff anyway.

@compiler-errors
Copy link
Member

compiler-errors commented May 31, 2025

This isn't an incremental bug per se, but instead a bug that has to do with debug printing query keys when debug assertions and -Z query-dep-graph is enabled. We end up printing a const (b/c we're using generic const args here) whose debug printing for -Z query-dep-graph requires invoking the same query cyclically 😃

I've pushed a commit which should fix this.

@rustbot rustbot added the A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) label May 31, 2025
@rust-log-analyzer
Copy link
Collaborator

The job aarch64-gnu-llvm-19-1 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
---- [ui] tests/ui/transmutability/structs/repr/transmute_infinitely_recursive_type.rs stdout ----
Saved the actual stderr to `/checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/transmutability/structs/repr/transmute_infinitely_recursive_type/transmute_infinitely_recursive_type.stderr`
diff of stderr:

12 error[E0391]: cycle detected when computing layout of `should_pad_explicitly_packed_field::ExplicitlyPadded`
13    |
14    = note: ...which immediately requires computing layout of `should_pad_explicitly_packed_field::ExplicitlyPadded` again
-    = note: cycle used when evaluating trait selection obligation `(): core::mem::transmutability::TransmuteFrom<should_pad_explicitly_packed_field::ExplicitlyPadded, core::mem::transmutability::Assume { alignment: false, lifetimes: false, safety: false, validity: false }>`
+    = note: cycle used when evaluating trait selection obligation `(): core::mem::transmutability::TransmuteFrom<should_pad_explicitly_packed_field::ExplicitlyPadded, ValTree(Branch([Leaf(0x00), Leaf(0x00), Leaf(0x00), Leaf(0x00)]): core::mem::transmutability::Assume)>`
16    = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information
17 
18 error: aborting due to 2 previous errors


The actual stderr differed from the expected stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args transmutability/structs/repr/transmute_infinitely_recursive_type.rs`

error: 1 errors occurred comparing output.
status: exit status: 1
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/ui/transmutability/structs/repr/transmute_infinitely_recursive_type.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2" "--target=aarch64-unknown-linux-gnu" "--check-cfg" "cfg(test,FALSE)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/transmutability/structs/repr/transmute_infinitely_recursive_type" "-A" "unused" "-A" "internal_features" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/aarch64-unknown-linux-gnu/native/rust-test-helpers"
stdout: none
--- stderr -------------------------------
error[E0072]: recursive type `ExplicitlyPadded` has infinite size
##[error]  --> /checkout/tests/ui/transmutability/structs/repr/transmute_infinitely_recursive_type.rs:21:5
   |
LL |     struct ExplicitlyPadded(ExplicitlyPadded);
   |     ^^^^^^^^^^^^^^^^^^^^^^^ ---------------- recursive without indirection
   |
help: insert some indirection (e.g., a `Box`, `Rc`, or `&`) to break the cycle
   |
LL |     struct ExplicitlyPadded(Box<ExplicitlyPadded>);
   |                             ++++                +

error[E0391]: cycle detected when computing layout of `should_pad_explicitly_packed_field::ExplicitlyPadded`
   |
   = note: ...which immediately requires computing layout of `should_pad_explicitly_packed_field::ExplicitlyPadded` again
   = note: cycle used when evaluating trait selection obligation `(): core::mem::transmutability::TransmuteFrom<should_pad_explicitly_packed_field::ExplicitlyPadded, ValTree(Branch([Leaf(0x00), Leaf(0x00), Leaf(0x00), Leaf(0x00)]): core::mem::transmutability::Assume)>`
   = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0072, E0391.
For more information about an error, try `rustc --explain E0072`.

@bors
Copy link
Collaborator

bors commented Jun 1, 2025

☔ The latest upstream changes (presumably #139118) made this pull request unmergeable. Please resolve the merge conflicts.

@compiler-errors
Copy link
Member

Ah, sorry, needs bless tests due to my changes. I can probably pull it out into a separate PR, lemme do that tomorrow.

@RalfJung
Copy link
Member Author

RalfJung commented Jun 1, 2025

Sounds good, thanks for looking into this. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) S-blocked Status: Blocked on something else such as an RFC or other implementation work. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants