rust/src/libstd/thread, branch 1.46.0

Migrate to numeric associated consts

2020-06-10T01:35:47+00:00

Warn against thread::sleep in async fn

2020-05-12T15:38:02+00:00

Fix clippy warnings

2020-05-11T15:13:32+00:00

Fixes clippy::{cone_on_copy, filter_next, redundant_closure, single_char_pattern, len_zero,redundant_field_names, useless_format, identity_conversion, map_clone, into_iter_on_ref, needless_return, option_as_ref_deref, unused_unit, unnecessary_mut_passed}

Rollup merge of #71256 - cuviper:must_use_replace, r=estebank

2020-04-22T21:19:19+00:00

Lint must_use on mem::replace This adds a hint on `mem::replace`, "if you don't need the old value, you can just assign the new value directly". This is in similar spirit to the `must_use` on `ManuallyDrop::take`.

Stop accessing module level int consts via crate::

2020-04-20T21:38:06+00:00

Fix unused results from mem::replace

2020-04-17T20:59:14+00:00

Add inline attributes for functions used in the query system

2020-03-30T12:37:44+00:00

Return NonZeroU64 from ThreadId::as_u64.

2020-03-21T18:48:23+00:00

As discussed in #67939, this allows turning Option into Option which can then be stored inside an AtomicU64.

Add an unstable conversion from thread ID to u64

2020-01-06T15:56:13+00:00

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).

Format the world

2019-12-22T22:42:47+00:00