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
6434ab8
Compare
|
|
|
Tried to update with a patched Details |
|
Cool, I'll take a look. There were some changes in this area. |
This disassembly test only cares about the rotate lowering pattern, not source line tables. Strip OpLine records entirely so line-number drift across toolchains does not require reblessing the test.
|
cc @Firestar99 for some testing |
This is handled above.
|
@Firestar99 did you get a chance to test this? |
Add a UI compile-fail test for casting a 3-byte constant allocation to `*const RuntimeArray<u16>`. This exercises the existing trailing-bytes diagnostic for unsupported unsized constants and guards the review concern that this shape must fail instead of silently lowering.
fee1-dead
left a comment
There was a problem hiding this comment.
LGTM, had one last nit, otherwise this is ready to go and feel free to merge after CI green and testing (cc @Firestar99?)!
| && let Some(init) = self.try_read_from_const_alloc(alloc, pointee) | ||
| { | ||
| return self.static_addr_of(init, alloc.inner().align, None); | ||
| if let Some(init) = self.try_read_from_const_alloc(alloc, pointee) { |
There was a problem hiding this comment.
nit: should move back to the let chain instead of putting another check inside.
There was a problem hiding this comment.
Clippy caught it in CI, already fixed: 3cce05f#diff-0125001c97c174d9f3ce82c4aa79adbe742cfccdb92a38165daa7136952bb4e7R349
The generic unsized constant reader already handles `RuntimeArray` constants, including the trailing-bytes error case covered by the new compile-fail test. Keep `const_bitcast` on the direct `try_read_from_const_alloc` path instead of carrying a second fallback that no longer changes behavior.
ed2c27e to
3cce05f
Compare
|
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. |
9e3bb73 to
c8078ed
Compare
c8078ed to
99993ee
Compare
99993ee to
12762d7
Compare
There 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.
tests/compiletests/ui/lang/consts/runtime-array-invalid-const-bitcast.rs
Outdated
Show resolved
Hide resolved
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 |
Yes, please 🙏 |
-Ztarget-spec-json: Destabilisetarget-spec-jsonrust-lang/rust#150151