about summary refs log tree commit diff
path: root/src/libcore
AgeCommit message (Collapse)AuthorLines
2019-02-19expand Unpin exampleRalf Jung-3/+5
2019-02-19improve wordingRalf Jung-2/+2
2019-02-19improve linked list -> drop transitionRalf Jung-5/+6
2019-02-19please the mericless tidy, oh tidyRalf Jung-1/+1
2019-02-19mention interaction with Deref in introRalf Jung-9/+38
2019-02-19examplesRalf Jung-1/+3
2019-02-19rewrite pin module introRalf Jung-24/+27
2019-02-19more work on projections and RefCell exampleRalf Jung-12/+22
2019-02-19separate section for doubly-linked list, reword projections introRalf Jung-33/+43
2019-02-19Apply suggestions from code reviewRalf Jung-12/+12
Co-Authored-By: RalfJung <post@ralfj.de>
2019-02-19apply some of the feedbackRalf Jung-25/+34
2019-02-19Stabilize iter::from_fnSimon Sapin-7/+5
FCP: https://github.com/rust-lang/rust/issues/55977#issuecomment-463964234
2019-02-19Stabilize iter::successorsSimon Sapin-7/+8
FCP: https://github.com/rust-lang/rust/issues/58045#issuecomment-464674773
2019-02-19improve Pin documentationRalf Jung-20/+190
2019-02-19Add missing fmt structs examplesGuillaume Gomez-10/+313
2019-02-19Fix typo in std::future::Future docsThomas Eizinger-1/+1
2019-02-17Use more impl header lifetime elisionScott McMurray-23/+23
There are two big categories of changes in here - Removing lifetimes from common traits that can essentially never user a lifetime from an input (particularly `Drop` & `Debug`) - Forwarding impls that are only possible because the lifetime doesn't matter (like `impl<R: Read + ?Sized> Read for &mut R`) I omitted things that seemed like they could be more controversial, like the handful of iterators that have a `Item: 'static` despite the iterator having a lifetime or the `PartialEq` implementations where the flipped one cannot elide the lifetime.
2019-02-18Auto merge of #58373 - RalfJung:maybe-uninit, r=gnzlbgbors-8/+1
update stdsimd and remove now-unused MaybeUninit::into_inner That's a huge diff for stdsimd... Cc @gnzlbg @alexcrichton
2019-02-17Review commentsSimon Sapin-2/+16
2019-02-17Remove UB in test_ptr_subtraction testKonrad Borowski-2/+4
2019-02-17Remove UB in test_is_null testKonrad Borowski-3/+2
2019-02-16Rollup merge of #58468 - RalfJung:maybe-uninit-split, r=Centrilkennytm-30/+52
split MaybeUninit into several features, expand docs a bit This splits the `maybe_uninit` feature gate into several: * `maybe_uninit` for what we will hopefully stabilize soon-ish. * `maybe_uninit_ref` for creating references into `MaybeUninit`, for which the rules are not yet clear. * `maybe_uninit_slice` for handling slices of `MaybeUninit`, which needs more API design work. * `maybe_uninit_array` for creating arrays of `MaybeUninit` using a macro (because we don't have https://github.com/rust-lang/rust/issues/49147 yet). Is that an okay thing to do? The goal is to help people avoid APIs we do not want to stabilize yet. I used this to make sure rustc itself does not use `get_ref` and `get_mut`. I also extended the docs to advise against uninitialized integers -- again this is something for which the rules are still being discussed.
2019-02-16Rollup merge of #58433 - RalfJung:miri-mark-tests, r=TimNNkennytm-38/+52
Update which libcore/liballoc tests Miri ignores, and document why
2019-02-16Rollup merge of #58074 - scottmcm:stabilize-sort_by_cached_key, r=SimonSapinkennytm-0/+4
Stabilize slice_sort_by_cached_key I was going to ask on the tracking issue (https://github.com/rust-lang/rust/issues/34447), but decided to just send this and hope for an FCP here. The method was added last March by https://github.com/rust-lang/rust/pull/48639. Signature: https://doc.rust-lang.org/std/primitive.slice.html#method.sort_by_cached_key ```rust impl [T] { pub fn sort_by_cached_key<K, F>(&mut self, f: F) where F: FnMut(&T) -> K, K: Ord; } ``` That's an identical signature to the existing `sort_by_key`, so I think the questions are just naming, implementation, and the usual "do we want this?". The implementation seems to have proven its use in rustc at least, which many uses: https://github.com/rust-lang/rust/search?l=Rust&q=sort_by_cached_key (I'm asking because it's exactly what I just needed the other day: ```rust all_positions.sort_by_cached_key(|&n| data::CITIES.iter() .map(|x| *metric_closure.get_edge(n, x.pos).unwrap()) .sum::<usize>() ); ``` since caching that key is a pretty obviously good idea.) Closes #34447
2019-02-14make Centril happyRalf Jung-2/+2
2019-02-14split MaybeUninit into several features, expand docs a bitRalf Jung-30/+52
2019-02-14remove MaybeUninit::into_innerRalf Jung-8/+0
2019-02-14update stdsimdRalf Jung-1/+0
2019-02-14fixed for libstd buildRalf Jung-0/+1
2019-02-14add missing feature flagRalf Jung-0/+1
2019-02-14Rollup merge of #57992 - Matthias247:waker4, r=cramertjMazdak Farrokhzad-263/+133
Update the future/task API This change updates the future and task API as discussed in the stabilization RFC at https://github.com/rust-lang/rfcs/pull/2592. Changes: - Replacing UnsafeWake with RawWaker and RawWakerVtable - Removal of LocalWaker - Removal of Arc-based Wake trait
2019-02-14Rollup merge of #57856 - lzutao:fix-old-first-edition, r=steveklabnikMazdak Farrokhzad-7/+4
Convert old first edition links to current edition one r? @steveklabnik
2019-02-13Add `impl From<!> for Infallible`Simon Sapin-0/+7
The reverse conversion unfortunately causes unexpected errors like: ``` error[E0277]: the trait bound `!: std::convert::From<()>` is not satisfied --> src/librustc_metadata/encoder.rs:105:9 | 105 | self.emit_usize(seq.len)?; | ^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::convert::From<()>` is not implemented for `!` | = help: the following implementations were found: <! as std::convert::From<std::convert::Infallible>> = note: the trait is implemented for `()`. Possibly this error has been caused by changes to Rust's type-inference algorithm (see: https://github.com/rust-lang/rust/issues/48950 for more info). Consider whether you meant to use the type `()` here instead. = note: required by `std::convert::From::from` ``` I don’t understand why this error happens. If I’m reading the code correctly the return types of `emit_usize` and of the method that contains line 105 are both `Result<(), !>`, so the expansion of the `?` operator should involve `!: From<!>`, not `From<()>`. Is this a type inference bug?
2019-02-13review failures in btree, stringRalf Jung-1/+0
2019-02-13the formatting issue got fixedRalf Jung-3/+3
2019-02-13review or fix remaining miri failures in libcoreRalf Jung-9/+28
2019-02-13Rollup merge of #58272 - fitzgen:num-format-code-size, r=Mark-SimulacrumMazdak Farrokhzad-74/+114
Cut down on number formating code size r? @alexcrichton
2019-02-13Stabilize TryFrom and TryIntoSimon Sapin-26/+23
2019-02-13Use convert::Infallible instead of never in the blanket TryFrom implSimon Sapin-3/+13
2019-02-13Add a convert::Infallible empty enum, make string::ParseError an aliasSimon Sapin-0/+93
2019-02-13review or fix miri failures in iter, slice, cell, timeRalf Jung-15/+11
2019-02-13mark failures expected due to panicsRalf Jung-15/+15
2019-02-13Convert old doc links to current editionLzu Tao-7/+4
Use footnote style to bypass the tidy check
2019-02-13Move the intrinsics into a submoduleValentin Tolmer-215/+249
2019-02-12Merging masterMatthias Einwag-363/+700
2019-02-12Revert "Remove mentions of unstable sort_by_cached key from stable ↵Scott McMurray-0/+4
documentation" This reverts commit 9c7b69e17909ceb090a1c4b8882a4e0924a2a755.
2019-02-13Rollup merge of #58405 - gnzlbg:remove_unused_macros, r=alexcrichtonMazdak Farrokhzad-14/+0
Remove some dead code from libcore These macros are not required to glue the `core_arch` crate anymore.
2019-02-13Rollup merge of #58200 - RalfJung:str-as-mut-ptr, r=SimonSapinMazdak Farrokhzad-7/+23
fix str mutating through a ptr derived from &self Found by Miri: In `get_unchecked_mut` (also used by the checked variants internally) uses `str::as_ptr` to create a mutable reference, but `as_ptr` takes `&self`. This means the mutable references we return here got created from a shared reference, which violates the shared-references-are-read-only discipline! For this by using a newly introduced `as_mut_ptr` instead.
2019-02-13Rollup merge of #57815 - dotdash:asserts, r=sfacklerMazdak Farrokhzad-4/+16
Speed up the fast path for assert_eq! and assert_ne! Currently, the panic!() calls directly borrow the value bindings. This causes those bindings to always be initialized, i.e. they're initialized even before the values are even compared. This causes noticeable overhead in what should be a really cheap operation. By performing a reborrow of the value in the call to panic!(), we allow LLVM to optimize that code, so that the extra borrow only happens in the error case. We could achieve the same result by dereferencing the values passed to panic!(), as the format machinery borrows them anyway, but this causes assertions to fail to compile if one of the values is unsized, i.e. it would be a breaking change.
2019-02-12Auto merge of #58051 - SimonSapin:str_escape, r=alexcrichtonbors-117/+289
Stabilize str::escape_* methods with new return types… … that implement `Display` and `Iterator<Item=char>`, as proposed in FCP: https://github.com/rust-lang/rust/issues/27791#issuecomment-376864727
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-23 17:34:59 +0000