-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Add a lint for calling any safe functions at all within an unsafe block #14287
Comments
A commenter on IRC has reminded me that fn main() {
let x = &["One", "Two", "Three"];
std::io::println(unsafe { *x.unsafe_ref(0) });
} ...which, in fact, is hardly ugly at all. |
@pcwalton and I have previously agreed that minimizing unsafe scope is an antipattern and its better to prefer bigger scopes that contain all the unsafety than to clutter a function up with many unsafe blocks. |
That is particularly true when one function does several unsafe ops on the same data. Better to relate all the unsafety to each other than giving the impression they are different unsafeties. |
cc @steveklabnik, can this move to the RFC repo? New features such as this should go through an RFC now. |
Since new lints have a big impact on users of rustc, the policy is that they should go through the RFC process like other user-facing changes. As such, I'm going to give this one a close, but if anyone comes across this ticket and wants this lint, consider adding it to clippy and/or writing up an RFC. Thanks! |
…eykril minor: Fixup dylib extensions for rustc_private proc-macro loading Follow up to rust-lang/rust-analyzer#14282
…lang#14308) The `looks_like_refdef` function was assuming the range was valid, this just adds a check to ensure that is the case. It also works around a subtraction underflow due to the same invalid range. changelog: [`doc_nested_refdefs`]: Fix rust-lang#14287 by avoiding invalid ranges
In today's Rust we warn if your
unsafe
block contains no unsafe code whatsoever:This is really great. However, the following program produces no warning:
...despite the fact that
std::io::println
is not an unsafe function. In the interest of reducing the scope of unsafe code, I propose a lint that would warn on the above program. And yes, satisfying it would require uglifying the code like so:...but who ever said that we had an obligation to make unsafe code pretty?
As an alternative, if people find the above proposal to be too extreme, then I would ask them to consider a weaker lint that merely warned if an entire statement within an unsafe block contained no unsafe code. This weaker lint would warn on the following program which compiles without warning today:
The text was updated successfully, but these errors were encountered: