summary refs log tree commit diff
path: root/library/core/src
AgeCommit message (Collapse)AuthorLines
2021-10-17Rollup merge of #89953 - woppopo:option_const_as_mut, r=oli-obkYuki Okushi-1/+2
Make Option::as_mut const Adding `const` for `Option::as_mut`. Tracking issue: #67441
2021-10-17Rollup merge of #89507 - lopopolo:lopopolo/ordering-repr-i8, r=joshtriplettYuki Okushi-0/+1
Add `#[repr(i8)]` to `Ordering` Followup to #89491 to allow `Ordering` to auto-derive `AsRepr` once the proposal to add `AsRepr` (#81642) lands. cc ``@joshtriplett``
2021-10-17Make Option::as_mut constwoppopo-1/+2
2021-10-16Rollup merge of #89925 - gilescope:update-docs-atomic-usage, r=m-ou-seMatthias Krüger-1/+1
updating docs to mention usage of AtomicBool Mouse mentioned we should point out that atomic bool is used by the std lib these days. ( https://github.com/m-ou-se/getrandom/pull/1 )
2021-10-16Rollup merge of #89509 - jhpratt:stabilize-const_unreachable_unchecked, ↵Matthias Krüger-3/+2
r=oli-obk Stabilize `unreachable_unchecked` as `const fn` Closes #53188 This PR stabilizes `core::hint::unreachable_unchecked` as `const fn`. MIRI is able to detect when this method is called. Stabilization was delayed until `const_panic` was stabilized so as to avoid users calling this method in its place (thus resulting in runtime UB). With #89508, that is no longer an issue. ````@rustbot```` label +A-const-eval +A-const-fn +T-lang +S-blocked (not sure why it's T-lang, but that's what the tracking issue is)
2021-10-15updating docs to reflect current situationGiles Cope-1/+1
2021-10-15Auto merge of #88540 - ibraheemdev:swap-unchecked, r=kennytmbors-13/+46
add `slice::swap_unchecked` An unsafe version of `slice::swap` that does not do bounds checking.
2021-10-14Rollup merge of #89873 - askoufis:patch-1, r=Mark-SimulacrumMatthias Krüger-1/+1
Add missing word to `FromStr` trait documentation The doc comment is getting a bit wide, let me know if I should restructure it/add a new line.
2021-10-14don't duplicate slice `panic_bounds_check`Ibraheem Ahmed-10/+4
2021-10-14Auto merge of #89247 - fee1-dead:const-eval-select, r=oli-obkbors-0/+71
Add `const_eval_select` intrinsic Adds an intrinsic that calls a given function when evaluated at compiler time, but generates a call to another function when called at runtime. See https://github.com/rust-lang/const-eval/issues/7 for previous discussion. r? `@oli-obk.`
2021-10-14Fix const stabilityDeadbeef-0/+2
2021-10-14Avoid tupling at the calleeDeadbeef-6/+6
2021-10-14Add missing word to `FromStr` trait docsAdam Skoufis-1/+1
2021-10-13Rollup merge of #89817 - m-ou-se:int-log-10-inline, r=the8472Yuki Okushi-0/+12
Add #[inline] to int log10 functions.
2021-10-13Rollup merge of #89794 - jkugelman:must-use-to_value-conversions, r=joshtriplettYuki Okushi-1/+7
Add #[must_use] to to_value conversions `NonNull<T>::cast` snuck in when I wasn't looking. What a scamp! Parent issue: #89692 r? ````@joshtriplett````
2021-10-13Rollup merge of #89781 - Wilfred:patch-2, r=JohnTitorYuki Okushi-1/+1
Add missing words in `Infallible` docs This sentence was previously incomplete.
2021-10-12Auto merge of #89774 - the8472:inline-mut-iter-next, r=m-ou-sebors-13/+7
inline next() on &mut Iterator impl In [#87431](https://github.com/rust-lang/rust/pull/87431/files#diff-79a6b417b85ecf4f1a4ef2235135fedf540199caf6e9e1d154ac6a413b40a757R132-R136) I found that `(&mut range).fold` doesn't optimize well because the default impl for for `fold` on `&mut Iterator` doesn't inline `next`. In that particular case it was worked around by using `try_fold` which takes a `&mut self` instead of `self`. Let's see if this can be fixed more broadly.
2021-10-12Add #[inline] to int log10 functions.Mara Bos-0/+12
2021-10-12Rollup merge of #89799 - ast-ral:ready-method-spellck, r=joshtriplettthe8472-1/+1
fix minor spelling error in Poll::ready docs Fixes minor spelling error in the proposed `Poll::ready` docs. Not that my opinion matters, but +1 on the original PR (#89651), it reads much nicer to me than the `ready!` macro.
2021-10-12Rollup merge of #89796 - jkugelman:must-use-non-mutating-verb-methods, ↵the8472-0/+6
r=joshtriplett Add #[must_use] to non-mutating verb methods These are methods that could be misconstrued to mutate their input, similar to #89694. I gave each one a different custom message. I wrote that `upgrade` and `downgrade` don't modify the input pointers. Logically they don't, but technically they do... Parent issue: #89692 r? ```@joshtriplett```
2021-10-12Rollup merge of #89778 - jkugelman:must-use-as_type-conversions, r=joshtriplettthe8472-0/+30
Add #[must_use] to as_type conversions Clippy missed these: ```rust alloc::string::String fn as_mut_str(&mut self) -> &mut str; core::mem::NonNull<T> unsafe fn as_uninit_mut<'a>(&mut self) -> &'a MaybeUninit<T>; str unsafe fn as_bytes_mut(&mut self) -> &mut [u8]; str fn as_mut_ptr(&mut self) -> *mut u8; ``` Parent issue: #89692 r? ````@joshtriplett````
2021-10-12Auto merge of #89770 - jkugelman:must-use-from-and-into, r=joshtriplettbors-0/+2
Add #[must_use] to From::from and Into::into Risk of churn: **High** Magic 8-Ball says: **Outlook not so good** I figured I'd put this out there. If we don't do it now maybe we save it for a rainy day. Parent issue: #89692 r? `@joshtriplett`
2021-10-12Auto merge of #89769 - jkugelman:must-use-maybe-uninit-new, r=joshtriplettbors-0/+1
Add #[must_use] to MaybeUninit::new As discussed in https://github.com/rust-lang/rust/pull/89729#issuecomment-939775659. Parent issue: #89692 r? `@joshtriplett`
2021-10-12Add const_eval_select intrinsicDeadbeef-0/+69
2021-10-11fix minor spelling error in Poll::ready docsast-ral-1/+1
2021-10-12Auto merge of #88788 - falk-hueffner:speedup-int-log10-branchless, ↵bors-56/+51
r=joshtriplett Speedup int log10 branchless This is achieved with a branchless bit-twiddling implementation of the case x < 100_000, and using this as building block. Benchmark on an Intel i7-8700K (Coffee Lake): ``` name old ns/iter new ns/iter diff ns/iter diff % speedup num::int_log::u8_log10_predictable 165 169 4 2.42% x 0.98 num::int_log::u8_log10_random 438 423 -15 -3.42% x 1.04 num::int_log::u8_log10_random_small 438 423 -15 -3.42% x 1.04 num::int_log::u16_log10_predictable 633 417 -216 -34.12% x 1.52 num::int_log::u16_log10_random 908 471 -437 -48.13% x 1.93 num::int_log::u16_log10_random_small 945 471 -474 -50.16% x 2.01 num::int_log::u32_log10_predictable 1,496 1,340 -156 -10.43% x 1.12 num::int_log::u32_log10_random 1,076 873 -203 -18.87% x 1.23 num::int_log::u32_log10_random_small 1,145 874 -271 -23.67% x 1.31 num::int_log::u64_log10_predictable 4,005 3,171 -834 -20.82% x 1.26 num::int_log::u64_log10_random 1,247 1,021 -226 -18.12% x 1.22 num::int_log::u64_log10_random_small 1,265 921 -344 -27.19% x 1.37 num::int_log::u128_log10_predictable 39,667 39,579 -88 -0.22% x 1.00 num::int_log::u128_log10_random 6,456 6,696 240 3.72% x 0.96 num::int_log::u128_log10_random_small 4,108 3,903 -205 -4.99% x 1.05 ``` Benchmark on an M1 Mac Mini: ``` name old ns/iter new ns/iter diff ns/iter diff % speedup num::int_log::u8_log10_predictable 143 130 -13 -9.09% x 1.10 num::int_log::u8_log10_random 375 325 -50 -13.33% x 1.15 num::int_log::u8_log10_random_small 376 325 -51 -13.56% x 1.16 num::int_log::u16_log10_predictable 500 322 -178 -35.60% x 1.55 num::int_log::u16_log10_random 794 405 -389 -48.99% x 1.96 num::int_log::u16_log10_random_small 1,035 405 -630 -60.87% x 2.56 num::int_log::u32_log10_predictable 1,144 894 -250 -21.85% x 1.28 num::int_log::u32_log10_random 832 786 -46 -5.53% x 1.06 num::int_log::u32_log10_random_small 832 787 -45 -5.41% x 1.06 num::int_log::u64_log10_predictable 2,681 2,057 -624 -23.27% x 1.30 num::int_log::u64_log10_random 1,015 806 -209 -20.59% x 1.26 num::int_log::u64_log10_random_small 1,004 795 -209 -20.82% x 1.26 num::int_log::u128_log10_predictable 56,825 56,526 -299 -0.53% x 1.01 num::int_log::u128_log10_random 9,056 8,861 -195 -2.15% x 1.02 num::int_log::u128_log10_random_small 1,528 1,527 -1 -0.07% x 1.00 ``` The 128 bit case remains ridiculously slow because llvm fails to optimize division by a constant 128-bit value to multiplications. This could be worked around but it seems preferable to fix this in llvm. From u32 up, table lookup (like suggested [here](https://github.com/rust-lang/rust/issues/70887#issuecomment-881099813)) is still faster, but requires a hardware `leading_zeros` to be viable, and might clog up the cache.
2021-10-11Add #[must_use] to non-mutating verb methodsJohn Kugelman-0/+6
2021-10-11Add #[must_use] to to_value conversionsJohn Kugelman-1/+7
2021-10-11Add #[must_use] to From::from and Into::intoJohn Kugelman-0/+2
2021-10-11Rollup merge of #89785 - nbdd0121:master, r=Mark-SimulacrumMatthias Krüger-1/+2
Fix ICE when compiling nightly std/rustc on beta compiler Fix #89775 #89479 renames a lot of diagnostic items, but it happens that the beta compiler assumes that there must be DefId with `rustc_diagnostic_item = "send_trait"`, causing an ICE when compiling stage 0 std or stage 1 compiler. So gate it with `cfg(bootstrap)`. The unwrap is also removed, so that existence of the diagnostic item is not required. I ripgreped the code base and this seems the only place where `unwrap` is called on the return value of `get_diagnostic_item`.
2021-10-11Rollup merge of #89651 - ibraheemdev:poll-ready, r=dtolnayMatthias Krüger-2/+97
Add `Poll::ready` and revert stabilization of `task::ready!` This PR adds an inherent `ready` method to `Poll` that can be used with the `?` operator as an alternative to the `task::ready!` macro: ```rust let val = ready!(fut.poll(cx)); let val = fut.poll(cx).ready()?; ``` I think this form is a nice, non-breaking middle ground between changing the `impl Try for Poll`, and adding a separate macro. It looks better than `ready!` in my opinion, and it composes well: ```rust let elem = ready!(fut.poll(cx)).pop().unwrap(); let elem = fut.poll(cx).ready()?.pop().unwrap(); ``` The planned stabilization of `ready!` in 1.56 has been reverted because I think this alternate approach is worth considering. r? rust-lang/libs
2021-10-11use fold instead of try_fold now that .by_ref().next() has been inlinedThe8472-13/+6
2021-10-11improve slice::swap panic messageIbraheem Ahmed-4/+15
2021-10-11use `swap_unchecked` in `slice::reverse`ibraheemdev-5/+1
2021-10-11enable `slice_swap_unchecked` feature in doc testibraheemdev-0/+2
2021-10-11add `slice::swap_unchecked`ibraheemdev-8/+38
2021-10-11Fix ICE 89775Gary Guo-1/+2
2021-10-11Add missing words in `Infallible` docsWilfred Hughes-1/+1
This sentence was previously incomplete.
2021-10-11Add library tracking issue for poll_ready featureDavid Tolnay-7/+7
2021-10-11Update library/core/src/mem/maybe_uninit.rsJohn Kugelman-1/+1
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
2021-10-11Add #[must_use] to as_type conversionsJohn Kugelman-0/+30
2021-10-11Auto merge of #83908 - Flying-Toast:master, r=davidtwcobors-0/+1
Add enum_intrinsics_non_enums lint There is a clippy lint to prevent calling [`mem::discriminant`](https://doc.rust-lang.org/std/mem/fn.discriminant.html) with a non-enum type. I think the lint is worthy of being included in rustc, given that `discriminant::<T>()` where `T` is a non-enum has an unspecified return value, and there are no valid use cases where you'd actually want this. I've also made the lint check [variant_count](https://doc.rust-lang.org/core/mem/fn.variant_count.html) (#73662). closes #83899
2021-10-11inline next() on &mut Iterator implThe8472-0/+1
2021-10-11Auto merge of #89767 - GuillaumeGomez:rollup-sczixhk, r=GuillaumeGomezbors-1/+55
Rollup of 7 pull requests Successful merges: - #89655 (bootstrap: don't use `--merges` to look for commit hashes for downloading artifacts) - #89726 (Add #[must_use] to alloc constructors) - #89729 (Add #[must_use] to core and std constructors) - #89743 (Fix RUSTC_LOG handling) - #89753 (Add #[must_use] to from_value conversions) - #89754 (Cleanup .item-table CSS) - #89761 (:arrow_up: rust-analyzer) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-10-11Add #[must_use] to MaybeUninit::newJohn Kugelman-0/+1
2021-10-11Rollup merge of #89753 - jkugelman:must-use-from_value-conversions, ↵Guillaume Gomez-1/+42
r=joshtriplett Add #[must_use] to from_value conversions I added two methods to the list myself. Clippy did not flag them because they take `mut` args, but neither modifies their argument. ```rust core::str const unsafe fn from_utf8_unchecked_mut(v: &mut [u8]) -> &mut str; std::ffi::CString unsafe fn from_raw(ptr: *mut c_char) -> CString; ``` I put a custom note on `from_raw`: ```rust #[must_use = "call `drop(from_raw(ptr))` if you intend to drop the `CString`"] pub unsafe fn from_raw(ptr: *mut c_char) -> CString { ``` Parent issue: #89692 r? ``@joshtriplett``
2021-10-11Rollup merge of #89729 - jkugelman:must-use-core-std-constructors, ↵Guillaume Gomez-0/+13
r=joshtriplett Add #[must_use] to core and std constructors Parent issue: #89692 r? ``@joshtriplett``
2021-10-11Auto merge of #89709 - clemenswasser:apply_clippy_suggestions_2, r=petrochenkovbors-1/+3
Apply clippy suggestions for rustc and core
2021-10-11Add enum_intrinsics_non_enums lintFlying-Toast-0/+1
2021-10-11Auto merge of #89755 - jkugelman:must-use-conversions-that-move-self, ↵bors-0/+13
r=joshtriplett Add #[must_use] to conversions that move self Everything here got the same message. Is the wording okay? ```rust #[must_use = "`self` will be dropped if the result is not used"] ``` I want to draw attention to these methods in particular: ```rust alloc::sync::Arc<MaybeUninit<T>> unsafe fn assume_init(self) -> Arc<T>; alloc::sync::Arc<[MaybeUninit<T>]> unsafe fn assume_init(self) -> Arc<[T]>; core::pin::Pin<&'a mut T> const fn into_ref(self) -> Pin<&'a T>; core::pin::Pin<&'a mut T> const fn get_mut(self) -> &'a mut T; core::pin::Pin<&'a mut T> const unsafe fn get_unchecked_mut(self) -> &'a mut T; core::pin::Pin<&'a mut T> unsafe fn map_unchecked_mut(self, func: F) -> Pin<&'a mut U>; core::pin::Pin<&'a mut Pin<P>> fn as_deref_mut(self) -> Pin<&'a mut P::Target>; ``` Parent issue: #89692 r? `@joshtriplett`