Update to nightly-2025-07-07.

[nnethercote]

• We now get warnings about unnecessary parentheses around dyn types.
• Spelling of sf.name.prefer_remapped_unconditionaly was fixed (now ends in lly).
• Pointer::into_parts has been replaced with Pointer::prov_and_relative_offset.

[nnethercote]

Currently getting failures like this:

 thread 'rustc' panicked at /home/runner/work/rust-gpu/rust-gpu/target/release/build/rustc_codegen_spirv-7aed03f54af259ed/out/pqp_cg_ssa/src/mir/operand.rs:355:13:
assertion `left == right` failed
  left: Size(4 bytes)
 right: Size(16 bytes)

I will bisect locally to work out what's happening.

[nnethercote]

Nightly 2025-07-05 is the last good one; Nightly 2025-07-06 is the first bad one.

The rust-lang/rust/ commit range between those two is e3843659e9f65f589d184d1221ac6149d5fa07b5..5adb489a8034f7b56b29f3b28af0813c866f679c.

I don't know if it's possible to bisect more finely than that because I don't know how to build rust-gpu with a locally built compiler. Having said that, the likely PR causing the problem is one of:

• Block SIMD in transmute_immediate; delete OperandValueKind rust-lang/rust#143410
• Allow enum and union literals to also create SSA values rust-lang/rust#138759

Because they are the only two PRs in the range that modify rustc_codegen_ssa, which is likely to affect rust-gpu.

I suspect it's the former (143410) because that's about SIMD and the failing assertion has this comment:

            // codegen_transmute_operand doesn't support SIMD, but since the previous
            // check handled ZSTs, the only possible field access into something SIMD
            // is to the `non_1zst_field` that's the same SIMD. (Other things, even
            // just padding, would change the wrapper's representation type.)
            assert_eq!(field.size, self.layout.size);

i.e. it's some kind of SIMD padding issue.

I'm out of my depth here, particularly on the rust-gpu side but even on the rustc side. @eddyb, do you know how to fix this?

[nazar-pc]

#380 replaces #[repr(simd)] with #[rust_gpu::vector::v1]. Does it help with this PR?

[nnethercote]

I did a whole lot of follow-up on this today. The problem identified above turned out to be a rustc bug and the change was later reverted, but then there were other problems with later nightlys as well and it got very complicated. But in short, yes, landing #380 will probably help.