Hack around blockers to update toolchain all the way to nightly-2024-11-22 (~1.84).#170
Hack around blockers to update toolchain all the way to nightly-2024-11-22 (~1.84).#170eddyb merged 11 commits intoRust-GPU:mainfrom
nightly-2024-11-22 (~1.84).#170Conversation
eddyb
force-pushed
the
rustup
branch
2 times, most recently
from
28929ce to
5642ab5
Compare
LegNeato
left a comment
LegNeato
left a comment
There was a problem hiding this comment.
I'm not really qualified to review this, some superficial comments.
| /// produce a "pqp" ("pre-`qptr`-patched") version that maintains compatibility | ||
| /// with "legacy" Rust-GPU pointer handling (mainly typed `alloca`s). | ||
| // | ||
| // FIXME(eddyb) get rid of this as soon as it's not needed anymore. |
There was a problem hiding this comment.
We should have a task written for this so we don't lose track
There was a problem hiding this comment.
| // or *at most* one generic type parameter with no bounds/where clause | ||
| // - relies on upstream `layout_of` not having had the non-array logic removed | ||
| // | ||
| // FIXME(eddyb) remove this once migrating beyond `#[repr(simd)]` becomes |
There was a problem hiding this comment.
Prob want a task for this too.
There was a problem hiding this comment.
| }) | ||
| .unwrap_or(InsertPoint::End) | ||
| }; | ||
| // TODO: rspirv doesn't have insert_variable function |
There was a problem hiding this comment.
Do we need a task on rspirv? If so we should file and link here
There was a problem hiding this comment.
This stuff is an old comment that can probably removed (expecting high-level APIs from rspirv is counterproductive).
eddyb
force-pushed
the
rustup
branch
7 times, most recently
from
e4d8450 to
7e75f3b
Compare
|
Looking like Still have some comments (#170 (review)) to address, but otherwise this seems to work. |
|
Are we ready to take this out of draft @eddyb ? |
…/integer variants.
Firestar99
left a comment
Firestar99
left a comment
There was a problem hiding this comment.
stamping as requested by @eddyb
3 participants
Each commit should be reviewed separately.
rustc_codegen_spirv#29(in theory, I still need to test it, which is why this is "Draft" - ideally we can test debug mode builds in CI? hopefully without a lot of time wasted etc. - also, are there any more issues that updating nightly fixes?)
That issue is in fact how I got the idea for the worst hack of this (see the very end of #29 (comment)).
The terrible hacks making this possible:
rustc_codegen_ssa's source code is now copied out of the sysroot and patchedcrates/rustc_codegen_spirv/build.rsfor most of the implementation)(Size, Align)-shaped)allocas (LLVM's name for "stack slots"/function-local variables),previously removed in Stop using LLVM struct types for alloca rust-lang/rust#122053
pqp_cg_ssato make it harder to confuse(where "pqp" = "pre-
qptr-patched", a nod to the eventual real solution)rustc_codegen_ssasource(as the
rustc-devrustup component places it in the sysroot),or the patches (most of which are very simple!), but rather the build
("nesting a crate as a module in another crate" + Cargo deps issues)
nightly-2024-04-24(last nightly before that PR)check_well_formedquery is bypassed for very simple#[repr(simd)]structs#[repr(simd)],and moving
glamover to it(something as simple as
#[spirv(vector)]might work, but 1. we didn't wantglamdepending onspirv-std*crates and 2. I haven't tried this theory, we might be relying a lot onrustc's SIMD concepts)nightly-2024-10-12(~1.83) and beyondcheck_mono_itemquery is completely disabled (replaced with a noop)(NB: query was renamed by move all mono-time checks into their own folder, and their own query rust-lang/rust#132843)
#[repr(simd)]fallout (more of a warning for now anyway)nightly-2024-11-22(~1.84) and beyondWe're lucky that 1.83 just released, so the "~1.84" nightly this PR gets to is currently in beta (to become stable 1.84 in 5 more weeks or so), so if we release Rust-GPU 0.10 in the next few weeks, we won't be behind stable at all.
There is also at least one refactor (
SpirvConst::Scalar) which could be moved into its own PR, as well as a much smaller fix forpanic_nounwind_fmt(not directly relevant, just that theformat_args!"decompiler" changes I had for some of these nightlies had assumed that change originally).