about summary refs log tree commit diff
path: root/src/rustllvm/PassWrapper.cpp
diff options
context:
space:
mode:
authorYuki Okushi <huyuumi.dev@gmail.com>2020-01-07 13:45:58 +0900
committerGitHub <noreply@github.com>2020-01-07 13:45:58 +0900
commitc671fc1ca2d9cb01406ac330faa31a4ad2d73fb5 (patch)
tree63c99ac6a7d2d38b7a7d9c99567ee3f9e23ff2b5 /src/rustllvm/PassWrapper.cpp
parentef92009c1dbe2750f1d24a6619b827721fb49749 (diff)
parentd9a7db901e33940cb2ccda6afe21b9916e66d9d2 (diff)
downloadrust-c671fc1ca2d9cb01406ac330faa31a4ad2d73fb5.tar.gz
rust-c671fc1ca2d9cb01406ac330faa31a4ad2d73fb5.zip
Rollup merge of #67566 - Mark-Simulacrum:thread-id-u64, r=alexcrichton
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.
Diffstat (limited to 'src/rustllvm/PassWrapper.cpp')
0 files changed, 0 insertions, 0 deletions