-
Notifications
You must be signed in to change notification settings - Fork 10
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
Request Clippy lints for antipatterns we discover #21
Comments
rust-lang/rust-clippy#4375 is another example |
One thing is that uninitialized() can be replaced with zeroed() in all cases. All of them. Any time memory can't be zeroed() it couldn't have been uninitialized() anyway. So even if they don't want to switch to MaybeUninit (eg: want to support an old compiler), they can switch to zeroed(). It's not definitely safe, but it safer at least. |
I thought "why document stuff if we can ask for clippy lints right away?" And then this happened: rust-lang/rust-clippy#4483 I'll need to review the unsafe code I've already purged, but this is already a big, multi-faceted work item right there. |
Requested another lint based on a bug in real-world code: rust-lang/rust-clippy#4774 I've also requested improvements to an existing lint, although this one might be tricky: rust-lang/rust-clippy#4765 |
I already requested a lint for the problem case I hit XD gotta check existing issues! |
Another lint requested: rust-lang/rust-clippy#4862 |
We encounter a lot of unsafe code that can be converted to safe. We should start cataloguing the antipatterns we discover and document how to convert them to safe code.
Also, for every antipattern discovered we should open an issue against Clippy to detect it - that way we can effectively prevent such cases in the future. This already has precedent, see e.g. rust-lang/rust-clippy#3237
The text was updated successfully, but these errors were encountered: