publish: Merge pull request #42 from est31/now_deprecated_is_my_new_friend

generated from commit 2d41081

Author: GH Actions Runner

code-considerations/safety-and-soundness/mem-and-exclusive-refs.html

@@ -152,7 +152,7 @@ <h1 id="using-mem-to-break-assumptions"><a class="header" href="#using-mem-to-br
 <h2 id="memreplace-and-memswap"><a class="header" href="#memreplace-and-memswap"><code>mem::replace</code> and <code>mem::swap</code></a></h2>
 <p>Any value behind a <code>&amp;mut</code> reference can be replaced with a new one using <code>mem::replace</code> or <code>mem::swap</code>, so code shouldn't assume any reachable mutable references can't have their internals changed by replacing.</p>
 <h2 id="memforget"><a class="header" href="#memforget"><code>mem::forget</code></a></h2>
-<p>Rust doesn't guarantee destructors will run when a value is leaked (which can be done with <code>mem::forget</code>), so code should avoid relying on them for maintaining safety. Remember, <a href="http://cglab.ca/%7Eabeinges/blah/everyone-poops">everyone poops</a>.</p>
+<p>Rust doesn't guarantee destructors will run when a value is leaked (which can be done with <code>mem::forget</code>), so code should avoid relying on them for maintaining safety. Remember, <a href="http://cglab.ca/~abeinges/blah/everyone-poops">everyone poops</a>.</p>
 <p>It's ok not to run a destructor when a value is leaked because its storage isn't deallocated or repurposed. If the storage is initialized and is being deallocated or repurposed then destructors need to be run first, because <a href="https://doc.rust-lang.org/nightly/std/pin/index.html#drop-guarantee">memory may be pinned</a>. Having said that, there can still be exceptions for skipping destructors when deallocating if you can guarantee there's never pinning involved.</p>
 <h2 id="for-reviewers"><a class="header" href="#for-reviewers">For reviewers</a></h2>
 <p>If there's a <code>Drop</code> impl involved, look out for possible soundness issues that could come from that destructor never running.</p>

feature-lifecycle/deprecation.html

@@ -150,7 +150,7 @@ <h1 class="menu-title">Standard library developers Guide</h1>
                     <main>
                         <h1 id="deprecating-features"><a class="header" href="#deprecating-features">Deprecating features</a></h1>
 <p><strong>Status:</strong> Stub</p>
-<p>Public APIs aren't deleted from the standard library. If something shouldn't be used anymore it gets deprecated by adding a <code>#[rustc_deprecated]</code> attribute. Deprecating need to go through a Libs FCP, just like stabilizations do.</p>
+<p>Public APIs aren't deleted from the standard library. If something shouldn't be used anymore it gets deprecated by adding a <code>#[deprecated]</code> attribute. Deprecating need to go through a Libs FCP, just like stabilizations do.</p>
 <p>To try reduce noise in the docs from deprecated items, they should be moved to the bottom of the module or <code>impl</code> block so they're rendered at the bottom of the docs page. The docs should then be cut down to focus on why the item is deprecated rather than how you might use it.</p>
 
                     </main>

print.html

@@ -439,7 +439,7 @@ <h2 id="stabilization-pr-checklist"><a class="header" href="#stabilization-pr-ch
 <p>You can see an example of stabilizing a feature with <a href="https://github.com/rust-lang/rust/issues/81656">tracking issue #81656 with FCP</a> and the associated <a href="https://github.com/rust-lang/rust/pull/84642">implementation PR #84642</a>.</p>
 <div style="break-before: page; page-break-before: always;"></div><h1 id="deprecating-features"><a class="header" href="#deprecating-features">Deprecating features</a></h1>
 <p><strong>Status:</strong> Stub</p>
-<p>Public APIs aren't deleted from the standard library. If something shouldn't be used anymore it gets deprecated by adding a <code>#[rustc_deprecated]</code> attribute. Deprecating need to go through a Libs FCP, just like stabilizations do.</p>
+<p>Public APIs aren't deleted from the standard library. If something shouldn't be used anymore it gets deprecated by adding a <code>#[deprecated]</code> attribute. Deprecating need to go through a Libs FCP, just like stabilizations do.</p>
 <p>To try reduce noise in the docs from deprecated items, they should be moved to the bottom of the module or <code>impl</code> block so they're rendered at the bottom of the docs page. The docs should then be cut down to focus on why the item is deprecated rather than how you might use it.</p>
 <div style="break-before: page; page-break-before: always;"></div><h1 id="code-considerations"><a class="header" href="#code-considerations">Code considerations</a></h1>
 <p>Code considerations capture our experiences working on the standard library for all contributors. If you come across something new or unexpected then a code consideration is a great place to record it. Then other contributors and reviewers can find it by searching the guide.</p>
@@ -635,7 +635,7 @@ <h2 id="for-reviewers-9"><a class="header" href="#for-reviewers-9">For reviewers
 <h2 id="memreplace-and-memswap"><a class="header" href="#memreplace-and-memswap"><code>mem::replace</code> and <code>mem::swap</code></a></h2>
 <p>Any value behind a <code>&amp;mut</code> reference can be replaced with a new one using <code>mem::replace</code> or <code>mem::swap</code>, so code shouldn't assume any reachable mutable references can't have their internals changed by replacing.</p>
 <h2 id="memforget"><a class="header" href="#memforget"><code>mem::forget</code></a></h2>
-<p>Rust doesn't guarantee destructors will run when a value is leaked (which can be done with <code>mem::forget</code>), so code should avoid relying on them for maintaining safety. Remember, <a href="http://cglab.ca/%7Eabeinges/blah/everyone-poops">everyone poops</a>.</p>
+<p>Rust doesn't guarantee destructors will run when a value is leaked (which can be done with <code>mem::forget</code>), so code should avoid relying on them for maintaining safety. Remember, <a href="http://cglab.ca/~abeinges/blah/everyone-poops">everyone poops</a>.</p>
 <p>It's ok not to run a destructor when a value is leaked because its storage isn't deallocated or repurposed. If the storage is initialized and is being deallocated or repurposed then destructors need to be run first, because <a href="https://doc.rust-lang.org/nightly/std/pin/index.html#drop-guarantee">memory may be pinned</a>. Having said that, there can still be exceptions for skipping destructors when deallocating if you can guarantee there's never pinning involved.</p>
 <h2 id="for-reviewers-10"><a class="header" href="#for-reviewers-10">For reviewers</a></h2>
 <p>If there's a <code>Drop</code> impl involved, look out for possible soundness issues that could come from that destructor never running.</p>