Closed
Description
openedon Feb 26, 2023
Summary
The uninit_vec and uninit_assumed_init lints use a helper to check whether a type may be uninit.
rust-clippy/clippy_utils/src/ty.rs
Lines 541 to 548 in 3d193fa
This helper is incorrect for newtypes around MaybeUninit<T>, ZSTs and unions in general.
This should be fixed by just deleting this helper function and using rustc's check_validity_of_init (the name may change in rust-lang/rust#108505). It doesn't currently support uninit checks but that should be really easy to add upstream (and needed for rust-lang/rust#100423 anyways).
Lint Name
uninit_vec,uninit_assumed_init
Reproducer
I tried this code:
use core::mem::MaybeUninit;
#[repr(transparent)]
struct Transparent<T>(MaybeUninit<T>);
pub fn foo<T>() {
let mut vec = Vec::<Transparent<T>>::new();
vec.reserve(20);
unsafe { vec.set_len(20) };
}I saw this happen:
error: calling `set_len()` immediately after reserving a buffer creates uninitialized values
--> src/lib.rs:8:5
|
8 | vec.reserve(20);
| ^^^^^^^^^^^^^^^^
9 | unsafe { vec.set_len(20) };
| ^^^^^^^^^^^^^^^
|
= help: initialize the buffer or wrap the content in `MaybeUninit`
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninit_vec
= note: `#[deny(clippy::uninit_vec)]` on by default
I expected to see this happen: Everything is fine
Version
rustc 1.69.0-nightly (34e6673a0 2023-02-25)
binary: rustc
commit-hash: 34e6673a0473e90ef01a18eb575392c9e3859747
commit-date: 2023-02-25
host: x86_64-unknown-linux-gnu
release: 1.69.0-nightly
LLVM version: 15.0.7
Additional Labels
No response
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
