Uh oh!
There was an error while loading. Please reload this page.
Update toolchain nightly-2026-03-14 - #545
Conversation
| _args: &[OperandRef<'tcx, Self::Value>], | ||
| _is_cleanup: bool, | ||
| ) -> Self::Value { | ||
| bug!("LLVM intrinsic call not supported in SPIR-V backend: {instance:?}") |
There was a problem hiding this comment.
I think we want to use this rather than our own home-grown replacements, but didn't want to do it in this PR.
14cdf92 to
6434ab8Comparenazar-pc
commented
Mar 7, 2026
|
nazar-pc
commented
Mar 8, 2026
Tried to update with a patched Details |
LegNeato
commented
Mar 8, 2026
Cool, I'll take a look. There were some changes in this area. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Firestar99
commented
Mar 23, 2026
Looks like cargo-gpu needs an update to work with this branch... I'll have a look tomorrow (and properly review this) |
I found a good counter argument against updating to "in the middle" nightlies: These are 4 old rust-gpu versions we no longer test cargo-gpu against due to them failing, of which 2 are broken due to using in-the-middle nightlies:
These never showed up to end users since these revs are mostly in the middle of PR #249, the edition 2025 toolchain upgrade. I've specifically chosen to test revs before and after target spec changes to make sure (past) cargo-gpu's / (now) spirv-builder's backwards compat towards older rust-gpu versions works, as these are the most likely to break. (Also this PR is also not backwards compatible, see Rust-GPU/cargo-gpu@1e4487e ci failing, will fix soon) This could also be fixed by making cargo-gpu's "rustc-codegen-spirv build" use rust-gpu's lockfile, and thus never use never deps then what we're using right now. |
Uh oh!
There was an error while loading. Please reload this page.
9e3bb73 to
c8078edComparec8078ed to
99993eeCompare99993ee to
12762d7CompareThere was a problem hiding this comment.
Had a read though it, skipping the format_args_disassembler cause that's entirely @eddyb's domain (I merely moved it to a separate mod at some point, if it shows me as having changed it).
Added some commits to make it work with cargo-gpu's backwards compat requirements.
Works for restir, nanite-at-home, rust-gpu-templates and builds nazar's abundance.
Still think we shouldn't upgrade to middle nightlies, see comment above.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Revert the `const_str` reshaping and the direct `RuntimeArray` constant-loading path in `read_from_const_alloc_at`. This restores the older behavior of treating `RuntimeArray` constants as unsupported instead of trying to materialize them from Rust constant data.
Remove the compile-fail test that casts constant data to `*const RuntimeArray<T>`. We do not want to support constructing `RuntimeArray` from Rust constant data.
I don't want to optimize for In my ideal world we are tracking rustc master. Perhaps this means cargo-gpu needs to be merged into this repo so users can depend on the same rev and have it all work (but have cargo-gpu able to compile with stable). I am not sure, that then feels a bit like |
nazar-pc
commented
Mar 25, 2026
Yes, please 🙏 |
Firestar99
commented
Mar 30, 2026
Let's get this PR merged and I'll have a look at merging cargo-gpu into this repo once everything propagates through. @nazar-pc and I have discussed this before and I think it's a great idea. On rustc in-the-middle nightlies, we decided to merge this and update again when 1.96.0 branches in 2 weeks |
Uh oh!
There was an error while loading. Please reload this page.
-Ztarget-spec-json: Destabilisetarget-spec-jsonrust-lang/rust#150151