diff options
| author | Matthias Krüger <matthias.krueger@famsik.de> | 2022-01-01 22:49:47 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2022-01-01 22:49:47 +0100 |
| commit | 30ec1f0384338351902a22d9d0e7f867f142a1f6 (patch) | |
| tree | 69263856b3a327747fb6c4157124458ecf4abf02 /tests/mir-opt/lower_array_len.array_bound_mut.NormalizeArrayLen.panic-unwind.diff | |
| parent | c145692254e86974941f2c92c643a23df0f13e82 (diff) | |
| parent | d66a9e16bae86863cfdbd033b49b672da34bdde1 (diff) | |
| download | rust-30ec1f0384338351902a22d9d0e7f867f142a1f6.tar.gz rust-30ec1f0384338351902a22d9d0e7f867f142a1f6.zip | |
Rollup merge of #84083 - ltratt:threadid_doc_tweak, r=dtolnay
Clarify the guarantees that ThreadId does and doesn't make. The existing documentation does not spell out whether `ThreadId`s are unique during the lifetime of a thread or of a process. I had to examine the source code to realise (pleasingly!) that they're unique for the lifetime of a process. That seems worth documenting clearly, as it's a strong guarantee. Examining the way `ThreadId`s are created also made me realise that the `as_u64` method on `ThreadId` could be a trap for the unwary on those platforms where the platform's notion of a thread identifier is also a 64 bit integer (particularly if they happen to use a similar identifier scheme to `ThreadId`). I therefore think it's worth being even clearer that there's no relationship between the two.
Diffstat (limited to 'tests/mir-opt/lower_array_len.array_bound_mut.NormalizeArrayLen.panic-unwind.diff')
0 files changed, 0 insertions, 0 deletions
