-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Open
Labels
A-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: Lints (warnings about flaws in source code) such as unused_mut.C-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
As a follow up to fixing #69173 via #69245, we would like to see a lint, starting as allow
-by-default which would trigger on the following situation:
#![warn(unsafe_in_unsafe_fn)]
unsafe fn foo() {} // Stand-in for any unsafe operation.
unsafe fn bar() {
foo();
//~^ WARN unsafe operation directly in `unsafe fn`
//~| HELP move the operation into an `unsafe { ... }` block.
}
Eventually, over time, we would like to consider moving this lint to be warn
-by-default, but we would like to give the ecosystem time to adapt before doing so. We have not discussed what the timescale of "eventually" entails.
Context (this has already been tentatively accepted by the language team in meetings, though not FCP):
- RFC for unsafe blocks in unsafe fn rfcs#2585 (comment)
- RFC for unsafe blocks in unsafe fn rfcs#2585 (comment)
cc @rust-lang/lang @RalfJung
This issue has been assigned to @LeSeulArtichaut via this comment.
programmerjake and memoryruins
Metadata
Metadata
Assignees
Labels
A-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: Lints (warnings about flaws in source code) such as unused_mut.C-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.