-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New lint: suggest ptr::read
instead of mem::replace(..., uninitialized())
#5575
Labels
A-lint
Area: New lints
good-first-issue
These issues are a good way to get started with Clippy
L-correctness
Lint: Belongs in the correctness lint group
Comments
flip1995
added
A-lint
Area: New lints
L-correctness
Lint: Belongs in the correctness lint group
good-first-issue
These issues are a good way to get started with Clippy
labels
May 7, 2020
Hello, I'm interested in working on this issue, if this is still available. All I need to do should be just:
Right? If yes, I can start working on this 👍 |
Yes that sounds good. :-) |
Okay, adding that to the test case 👍 |
bors
added a commit
that referenced
this issue
Jun 23, 2020
New lint: suggest `ptr::read` instead of `mem::replace(..., uninitialized())` resolves: #5575 changelog: - add a new test case in `tests/ui/repl_uninit.rs` to cover the case of replacing with `mem::MaybeUninit::uninit().assume_init()`. - modify the existing `MEM_REPLACE_WITH_UNINIT` when replacing with `mem::uninitialized` to suggest using `ptr::read` instead. - lint with `MEM_REPLACE_WITH_UNINIT` when replacing with `mem::MaybeUninit::uninit().assume_init()`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-lint
Area: New lints
good-first-issue
These issues are a good way to get started with Clippy
L-correctness
Lint: Belongs in the correctness lint group
I have now at least twice seen code like this:
Most recently here, but I saw this before somewhere (not sure where).
Could Clippy suggest to replace this code by the following:
The latter is more clear, avoids the mess that is uninitialized memory (both of the cases where I saw this were actually UB because of this), and can never be wrong when the former is right. Indeed, LLVM will likely (but not always) compile the former to the latter, because "write of uninitialized data to memory" can be just optimized away to nothing.
The text was updated successfully, but these errors were encountered: