Repository navigation
[Migrated] core::mem::swap used to work, then broke (and later accidentally got unbroken again). #117
Description
Issue automatically imported from old repo: EmbarkStudios/rust-gpu#804
Old labels: t: bug,a: rust-lang,t: external,s: qptr may fix
Originally creatd by hatoo on 2021-11-21T13:05:53Z
Expected Behaviour
Codes that uses core::mem::swap
#![cfg_attr(
target_arch = "spirv",
no_std,
feature(register_attr),
register_attr(spirv)
)]
#[cfg(not(target_arch = "spirv"))]
use spirv_std::macros::spirv;
use spirv_std as _;
#[spirv(vertex)]
pub fn test_vs() {
let mut x1 = 0.0f32;
let mut x2 = 1.0f32;
core::mem::swap(&mut x1, &mut x2);
}will compile. it's OK in previous version at least b9867d0.
Example & Steps To Reproduce
- Clone https://github.com/hatoo/rust-gpu-issue/tree/swap-fail (note: swap-fail branch)
- cargo build and error
> cargo build
Compiling builder v0.1.0 (C:\Users\hato2\Desktop\rust-gpu-issue\builder)
error: failed to run custom build command for `builder v0.1.0 (C:\Users\hato2\Desktop\rust-gpu-issue\builder)`
Caused by:
process didn't exit successfully: `C:\Users\hato2\Desktop\rust-gpu-issue\target\debug\build\builder-caf084bc583adeed\build-script-build` (exit code: 1)
--- stderr
Compiling shader v0.1.0 (C:\Users\hato2\Desktop\rust-gpu-issue\shader)
error: Cannot memcpy dynamically sized data
--> C:\Users\hato2\.rustup\toolchains\nightly-2021-10-26-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\intrinsics.rs:2057:14
|
2057 | unsafe { copy_nonoverlapping(src, dst, count) }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: could not compile `shader` due to previous error
Error: BuildFailed
It's OK in the previous version. Please see https://github.com/hatoo/rust-gpu-issue/tree/swap-succ.
System Info
- Rust: rustc 1.58.0-nightly (29b124802 2021-10-25)
- OS: Windows 11
- GPU: RTX2080ti
- SPIR-V: SPIRV-Tools v2021.3 v2021.3
Backtrace
Backtrace
<backtrace>
Activity
rust-gpu-bot commentedon Nov 13, 2024
Comment from eddyb (CONTRIBUTOR) on 2021-11-22T14:33:16Z 👍: 1
In #716 we updated to a version that supports
mem::replaceagain, thanks to rust-lang/rust#87827, butmem::swapindeed did not get fixed the same way - if someone wants to try and land upstream something like that PR but formem::swap, feel free to.I gave up on it because of how rare
mem::swapis compared tomem::replace(which gets used everywhere incore, e.g.Option::take(self)ismem::replace(self, None)and range iterators also depend on it).There's a more general fix at rust-lang/rust#86699 but it requires a bunch of unstable feature-gating stuff I haven't gone back to for.
rust-gpu-bot commentedon Nov 13, 2024
Comment from oisyn (CONTRIBUTOR) on 2023-03-29T13:32:12Z
Closing as won't fix, it's very unlikely we will address this in the forseeable future.
rust-gpu-bot commentedon Nov 13, 2024
Comment from eddyb (CONTRIBUTOR) on 2023-10-01T17:15:11Z
This actually works in Rust-GPU 0.4, and more specifically since
nightly-2022-02-28, thanks to:(the function being modified there,
swap_simple, is always used on SPIR-V, and the change that actually unblocked it wasptr::copy_nonoverlapping(y, x, 1)being replaced with aptr::{read,write}pair)But at the same time, I wanted to propose to upstream that they can remove the
target_arch = "spirv"hack, as it got brought up in this issue:Now I'm worried that people may be relying on it, since it works, but I'm not sure how to check.coreitself seems to mostly use for sorting/partitioning-like tasks.Oh, according to sourcegraph, it's definitely gotten used, oh well.
So we might want to do nothing for now, and only remove the upstream hack if
qptrcan supersede it.Update Add Example & Getting Started (Rust-GPU#117)