Auto merge of #74019 - Manishearth:rollup-2st3jsk, r=Manishearth

Rollup of 12 pull requests

Successful merges:

 - #73140 (Fallback to xml.etree.ElementTree)
 - #73670 (Add `format_args_capture` feature)
 - #73693 (Use exhaustive match in const_prop.rs)
 - #73845 (Use &raw in A|Rc::as_ptr)
 - #73861 (Create E0768)
 - #73881 (Standardize bibliographic citations in rustc API docs)
 - #73925 (Improve comments from #72617, as suggested by RalfJung)
 - #73949 ([mir-opt] Fix mis-optimization and other issues with the SimplifyArmIdentity pass)
 - #73984 (Edit docs for rustc_data_structures::graph::scc)
 - #73985 (Fix "getting started" link)
 - #73997 (fix typo)
 - #73999 (Bump mingw-check CI image from Ubuntu 16.04 to 18.04.)

Failed merges:

 - #74000 (add `lazy_normalization_consts` feature gate)

r? @ghost

1 files changed, 10 insertions, 4 deletions

diff --git a/src/libstd/panicking.rs b/src/libstd/panicking.rs
index 97d62d958ca..9542e7209b4 100644
--- a/src/libstd/panicking.rs
+++ b/src/libstd/panicking.rs
@@ -229,10 +229,10 @@ pub mod panic_count {
     thread_local! { static LOCAL_PANIC_COUNT: Cell<usize> = Cell::new(0) }
 
     // Sum of panic counts from all threads. The purpose of this is to have
-    // a fast path in `is_zero` (which is used by `panicking`). Access to
-    // this variable can be always be done with relaxed ordering because
-    // it is always guaranteed that, if `GLOBAL_PANIC_COUNT` is zero,
-    // `LOCAL_PANIC_COUNT` will be zero.
+    // a fast path in `is_zero` (which is used by `panicking`). In any particular
+    // thread, if that thread currently views `GLOBAL_PANIC_COUNT` as being zero,
+    // then `LOCAL_PANIC_COUNT` in that thread is zero. This invariant holds before
+    // and after increase and decrease, but not necessarily during their execution.
     static GLOBAL_PANIC_COUNT: AtomicUsize = AtomicUsize::new(0);
 
     pub fn increase() -> usize {
@@ -263,6 +263,12 @@ pub mod panic_count {
             // Fast path: if `GLOBAL_PANIC_COUNT` is zero, all threads
             // (including the current one) will have `LOCAL_PANIC_COUNT`
             // equal to zero, so TLS access can be avoided.
+            //
+            // In terms of performance, a relaxed atomic load is similar to a normal
+            // aligned memory read (e.g., a mov instruction in x86), but with some
+            // compiler optimization restrictions. On the other hand, a TLS access
+            // might require calling a non-inlinable function (such as `__tls_get_addr`
+            // when using the GD TLS model).
             true
         } else {
             is_zero_slow_path()