stop mentioning unsafe_op_in_unsafe_fn

Author: RalfJung

library/std/src/keyword_docs.rs

@@ -1916,10 +1916,6 @@ mod type_keyword {}
 /// - and to declare that a programmer has checked that these contracts have been upheld (`unsafe
 /// {}` and `unsafe impl`, but also `unsafe fn` -- see below).
 ///
-/// They are not mutually exclusive, as can be seen in `unsafe fn`: the body of an `unsafe fn` is,
-/// by default, treated like an unsafe block. The `unsafe_op_in_unsafe_fn` lint can be enabled to
-/// change that.
-///
 /// # Unsafe abilities
 ///
 /// **No matter what, Safe Rust can't cause Undefined Behavior**. This is
@@ -1961,13 +1957,6 @@ mod type_keyword {}
 /// - `unsafe impl`: the contract necessary to implement the trait has been
 /// checked by the programmer and is guaranteed to be respected.
 ///
-/// By default, `unsafe fn` also acts like an `unsafe {}` block
-/// around the code inside the function. This means it is not just a signal to
-/// the caller, but also promises that the preconditions for the operations
-/// inside the function are upheld. Mixing these two meanings can be confusing, so the
-/// `unsafe_op_in_unsafe_fn` lint can be enabled to warn against that and require explicit unsafe
-/// blocks even inside `unsafe fn`.
-///
 /// See the [Rustonomicon] and the [Reference] for more information.
 ///
 /// # Examples
@@ -2161,8 +2150,7 @@ mod type_keyword {}
 /// defined by the trait (or a stronger contract, i.e., weaker preconditions).
 ///
 /// Of course, the implementation may choose to call other unsafe operations, and then it needs an
-/// `unsafe` *block* to indicate it discharged the proof obligations of its callees. (We enabled
-/// `unsafe_op_in_unsafe_fn`, so the body of `idx_unchecked` is not implicitly an unsafe block.) For
+/// `unsafe` *block* to indicate it discharged the proof obligations of its callees. For
 /// that purpose it can make use of the contract that all its callers must uphold -- the fact that
 /// `idx < LEN`.
 ///