Rollup merge of rust-lang#146799 - cuviper:dangling-count-latch, r=lcnr

Fix a dangling reference in `rustc_thread_pool`

This diverged from `rayon` in rust-lang#142384, where a cleanup commit turned the matched `worker_index` into a reference, which is read _after_ the `set` that may kill it. I've moved that read beforehand, and I hope the new comments will emphasize the subtlety of this unsafe code.

Hopefully fixes rust-lang#146677.

Author: matthiaskrgr

compiler/rustc_thread_pool/src/latch.rs

@@ -388,13 +388,17 @@ impl Latch for CountLatch {
     #[inline]
     unsafe fn set(this: *const Self) {
         if unsafe { (*this).counter.fetch_sub(1, Ordering::SeqCst) == 1 } {
-            // NOTE: Once we call `set` on the internal `latch`,
+            // SAFETY: Once we call `set` on the internal `latch`,
             // the target may proceed and invalidate `this`!
             match unsafe { &(*this).kind } {
                 CountLatchKind::Stealing { latch, registry, worker_index } => {
                     let registry = Arc::clone(registry);
+                    let worker_index = *worker_index;
+                    // SAFETY: We don't use any references from `this` after this call.
                     if unsafe { CoreLatch::set(latch) } {
-                        registry.notify_worker_latch_is_set(*worker_index);
+                        // We **must not** access any part of `this` anymore, which
+                        // is why we read and shadowed these fields beforehand.
+                        registry.notify_worker_latch_is_set(worker_index);
                     }
                 }
                 CountLatchKind::Blocking { latch } => unsafe { LockLatch::set(latch) },