Open
Description
Code
const SCALING_FACTOR: usize = 4096;
#[repr(align(4096))]
#[derive(Copy, Clone)]
struct HighAlignment([u8; SCALING_FACTOR]);
fn main() {
let size = 1;
let src = vec![HighAlignment([127u8; SCALING_FACTOR]); size];
let mut dst = vec![HighAlignment([254u8; SCALING_FACTOR]); size];
unsafe { core::ptr::copy_nonoverlapping(src.as_ptr(), dst.as_mut_ptr(), size) };
}
Current output
Compiling playground v0.0.1 (/playground)
warning: field `0` is never read
--> src/main.rs:4:22
|
4 | struct HighAlignment([u8; SCALING_FACTOR]);
| ------------- ^^^^^^^^^^^^^^^^^^^^
| |
| field in this struct
|
= note: `HighAlignment` has a derived impl for the trait `Clone`, but this is intentionally ignored during dead code analysis
= note: `#[warn(dead_code)]` on by default
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field
|
4 | struct HighAlignment(());
| ~~
warning: `playground` (bin "playground") generated 1 warning
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.39s
Running `target/debug/playground`
Desired output
Compiling playground v0.0.1 (/playground)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.38s
Running `target/debug/playground`
Rationale and extra context
In effect, the pointer is used to copy the inner field. The entire use of the type is for the alignment of the inner data. I believe it is inappropriate for rustc to reason about whether data written to a pointer is a "use", and the following code goes without remark:
Other cases
const SCALING_FACTOR: usize = 4096;
#[repr(align(4096))]
#[derive(Copy, Clone)]
struct HighAlignment([u8; SCALING_FACTOR]);
fn main() {
let size = 1;
let src = vec![HighAlignment([127u8; SCALING_FACTOR]); size];
let mut dst = vec![HighAlignment([254u8; SCALING_FACTOR]); size];
dst[0].0 = src[0].0; // completely silences the lint
}
Rust Version
rustc 1.80.0-nightly (9cdfe285c 2024-05-22)
binary: rustc
commit-hash: 9cdfe285ca724c801dc9f78d22b24ea69b787f26
commit-date: 2024-05-22
host: x86_64-unknown-linux-gnu
release: 1.80.0-nightly
LLVM version: 18.1.6
Anything else?
No response