Skip to content

rustup: update to nightly-2025-05-09 (~1.88) and Rust 2024 edition. #249

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 28 commits into
base: main
Choose a base branch
from

Conversation

eddyb
Copy link
Collaborator

@eddyb eddyb commented May 12, 2025

This PR supersedes (and includes many of the changes from):


This brings us 4 whole Rust releases ahead, to a 1.88-equivalent nightly.
(Rust 1.88.0 stable will be released on June 26th, 2025)

The many commits exist in part because of nightly bisection (to find nightly-2024-12-16, containing the GEP array change), but also because there have been several changes of note:

  • target specs no longer spuriously claim an OS of unknown
    • (the sole unknown component in e.g. spirv-unknown-vulkan1.1 is the vendor, whereas the OS is none and omitted in the "triple")
  • maybe_inbounds_gep had to be made more flexible, due to:
    Modifies the index instruction from gep [0 x %Type] to gep %Type rust-lang/rust#134117
    • (supporting that pattern was achieved by attempting pointercast first, which can itself produce a "first element of array" GEP that can then be merged with an "intra-array indexing GEP")
  • f16/f128 required some stubbing out (i.e. intrinsics)
    • it may be possible to support f16, but I've not attempted that in this PR
  • had to re-enable niches for bool (i.e. making Option<bool> byte-sized), due a transmute (from ControlFlow<bool> to u8) added to core::cmp in:
    Use the chaining methods on PartialOrd for slices too rust-lang/rust#138881
    • not sure Option<bool> ever worked in Rust-GPU (the comments I found are confusing, I thought it had users and/or tests, but maybe not)
  • (the remaining ones have to do w/ rustc_codegen_ssa patching)
  • rustc_codegen_spirv had to be switched to the Rust 2024 edition (as rustc_codegen_ssa had done the same upstream)
  • old-style #[repr(simd)] (using individual struct fields) has had even more support ripped out upstream
    • hooking/patching that support back in was possible, but it's clearly not an intended feature and we should try to move off of it sooner than later
  • some dependencies of rustc_codegen_ssa::back (i.e. object) required more patching to remove their use sites
    • only needed because nightlies have had two prebuilt versions of object, breaking extern crate object; (as it may load the wrong version)
    • this was also the original blocker for rustup to nightly-2025-04-28 #246
      (before all the other issues were discovered through testing)
    • @LegNeato has been separately working on removing that duplication upstream

While not necessary, this (just like #246) includes a full migration of the entire workspace to Rust 2024 (leading to lots of unsafe {...} in unsafe fns in spirv-std, mainly) - we can split that out if it seems better, but I at least tried to keep it in its own commit.

@eddyb eddyb enabled auto-merge May 12, 2025 18:40
@eddyb eddyb force-pushed the rustup-1.88 branch 2 times, most recently from 88fd99e to 554d850 Compare May 12, 2025 19:24
@Firestar99
Copy link
Member

Thanks for getting us up to the newest versions! 🎉
I'm currently away from home, so I'll likely won't be able to review until next week.

Copy link
Collaborator

@LegNeato LegNeato left a comment

Choose a reason for hiding this comment

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

Some minor comments. I liked how many of your changes are better than mine ha. Only rejecting so it doesn't merge and others can review.

@@ -276,6 +317,12 @@ mod maybe_pqp_cg_ssa;

println!("cargo::rustc-check-cfg=cfg(rustc_codegen_spirv_disable_pqp_cg_ssa)");

// HACK(eddyb) `if cfg!(llvm_enzyme)` added upstream for autodiff support.
println!("cargo::rustc-check-cfg=cfg(llvm_enzyme)");
Copy link
Collaborator

Choose a reason for hiding this comment

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

Oh cool, I didn't know you could put those here.

ty::Bool => {
// HACK(eddyb) we can't bypass e.g. `Option<bool>` being a byte,
// due to `core` PR https://github.com/rust-lang/rust/pull/138881
// (which adds a new `transmute`, from `ControlFlow<bool>` to `u8`).
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should we fix / backout stuff upstream?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Nope, it's our absurd problem that we want bool to have a layout Option<bool> can't have (cue "qptr will fix this").

// --- Attempt GEP Merging Path ---

// Check if the base pointer `ptr` itself was the result of a previous
// AccessChain instruction. Merging is only attempted if the input type `ty`
// matches the pointer's actual underlying pointee type `original_pointee_ty`.
// If they differ, merging could be invalid.
// HACK(eddyb) always attempted now, because we `pointercast` first, which:
Copy link
Collaborator

Choose a reason for hiding this comment

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

Just update the comment rather than having a new comment modify...we have git 😄

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

To be clear, when I do this it's because I'm already several steps deep and accurately rewording comments might not be the easiest/quickest thing at that moment (but I agree I could/should fix it before landing the PR).

Copy link
Collaborator

Choose a reason for hiding this comment

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

Or just delete the comment!

@@ -908,12 +910,21 @@ impl<'a, 'tcx> Builder<'a, 'tcx> {
// 2. The *last* index of the original AccessChain is a constant.
// 3. The *first* index (`ptr_base_index`) of the *current* GEP is a constant.
// Merging usually involves adding these two constant indices.
//
// FIXME(eddyb) the above comment seems inaccurate, there is no reason
Copy link
Collaborator

Choose a reason for hiding this comment

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

Again, just fix or delete the comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants