Rollup merge of rust-lang#67566 - Mark-Simulacrum:thread-id-u64, r=al…

…excrichton

Add an unstable conversion from thread ID to u64

We see multiple cases inside rustc and ecosystem code where ThreadId is
transmuted to u64, exploiting the underlying detail. This is suboptimal
(can break unexpectedly if we change things in std).

It is unlikely that ThreadId will ever need to be larger than u64 --
creating even 2^32 threads over the course of a program is quite hard,
2^64 is even harder. As such, we do not choose to return a larger sized
type (e.g. u128). If we choose to shrink ThreadId in the future, or
otherwise change its internals, it is likely that a mapping to u64 will
still be applicable (though may become more complex).

I will file a tracking issue as soon as this is loosely approved.

src/libstd/thread/mod.rs

@@ -1072,6 +1072,19 @@ impl ThreadId {
             ThreadId(NonZeroU64::new(id).unwrap())
         }
     }
+
+    /// This returns a numeric identifier for the thread identified by this
+    /// `ThreadId`.
+    ///
+    /// As noted in the documentation for the type itself, it is essentially an
+    /// opaque ID, but is guaranteed to be unique for each thread. The returned
+    /// value is entirely opaque -- only equality testing is stable. Note that
+    /// it is not guaranteed which values new threads will return, and this may
+    /// change across Rust versions.
+    #[unstable(feature = "thread_id_value", issue = "67939")]
+    pub fn as_u64(&self) -> u64 {
+        self.0.get()
+    }
 }
 
 ////////////////////////////////////////////////////////////////////////////////