about summary refs log tree commit diff
path: root/src/liballoc
AgeCommit message (Collapse)AuthorLines
2017-11-21fix some typosMartin Lindhe-8/+8
2017-11-21Rollup merge of #46128 - Coding-Doctors:patch-1, r=dtolnaykennytm-1/+1
Fix doc tests for trim_right_matches First pr, but isn't anything big so hopefully it should all be good.
2017-11-21Rollup merge of #46122 - malbarbo:docs, r=steveklabnikkennytm-1/+1
Fix some docs summary nits
2017-11-20Fix result for assert_eqBenjamin Hoffmeyer-1/+1
2017-11-20Fix doc tests for trim_right_matchesBenjamin Hoffmeyer-1/+1
2017-11-20Print the address of the pointed value in Pointer impl for Rc and ArcMarco A L Barbosa-2/+2
2017-11-20Fix some docs summary nitsMarco A L Barbosa-1/+1
2017-11-19rustc: don't special-case Box<T> as having a pointer layout.Eduard-Mihai Burtescu-4/+14
2017-11-14examples in Cow::into_owned don't need to wrap result in CowsQuietMisdreavus-2/+2
2017-11-14Fixed several pulldown warnings when documenting libstd.kennytm-1/+1
2017-11-10Rollup merge of #45878 - jhford:use-get-in-get-example, r=kennytmkennytm-4/+4
get() example should use get() not get_mut() I'm really new to Rust, this is the first thing I've ever actually pushed to github in a rust project, so please double check that it's correct. I noticed that the in-doc example for the string's get() function was referring to get_mut(). Looks like a copy/paste issue. ```rust fn main() { let v = String::from("πŸ—»βˆˆπŸŒ"); assert_eq!(Some("πŸ—»"), v.get(0..4)); // indices not on UTF-8 sequence boundaries assert!(v.get(1..).is_none()); assert!(v.get(..8).is_none()); // out of bounds assert!(v.get(..42).is_none()); } ``` results in: ``` jhford-work:~/rust/redish $ cat get-example.rs fn main() { let v = String::from("πŸ—»βˆˆπŸŒ"); assert_eq!(Some("πŸ—»"), v.get(0..4)); // indices not on UTF-8 sequence boundaries assert!(v.get(1..).is_none()); assert!(v.get(..8).is_none()); // out of bounds assert!(v.get(..42).is_none()); } jhford-work:~/rust/redish $ rustc get-example.rs jhford-work:~/rust/redish $ ./get-example ; echo $? 0 ``` I did not build an entire rust toolchain as I'm not totally sure how to do that.
2017-11-08std: Remove `rand` crate and moduleAlex Crichton-2/+10
This commit removes the `rand` crate from the standard library facade as well as the `__rand` module in the standard library. Neither of these were used in any meaningful way in the standard library itself. The only need for randomness in libstd is to initialize the thread-local keys of a `HashMap`, and that unconditionally used `OsRng` defined in the standard library anyway. The cruft of the `rand` crate and the extra `rand` support in the standard library makes libstd slightly more difficult to port to new platforms, namely WebAssembly which doesn't have any randomness at all (without interfacing with JS). The purpose of this commit is to clarify and streamline randomness in libstd, focusing on how it's only required in one location, hashmap seeds. Note that the `rand` crate out of tree has almost always been a drop-in replacement for the `rand` crate in-tree, so any usage (accidental or purposeful) of the crate in-tree should switch to the `rand` crate on crates.io. This then also has the further benefit of avoiding duplication (mostly) between the two crates!
2017-11-08get() example should use get() not get_mut()John Ford-4/+4
I'm really new to Rust, this is the first thing I've ever actually pushed to github in a rust project, so please double check that it's correct. I noticed that the in-doc example for the string's get() function was referring to get_mut(). Looks like a copy/paste issue. ```rust fn main() { let v = String::from("πŸ—»βˆˆπŸŒ"); assert_eq!(Some("πŸ—»"), v.get(0..4)); // indices not on UTF-8 sequence boundaries assert!(v.get(1..).is_none()); assert!(v.get(..8).is_none()); // out of bounds assert!(v.get(..42).is_none()); } ``` results in: ``` jhford-work:~/rust/redish $ cat get-example.rs fn main() { let v = String::from("πŸ—»βˆˆπŸŒ"); assert_eq!(Some("πŸ—»"), v.get(0..4)); // indices not on UTF-8 sequence boundaries assert!(v.get(1..).is_none()); assert!(v.get(..8).is_none()); // out of bounds assert!(v.get(..42).is_none()); } jhford-work:~/rust/redish $ rustc get-example.rs jhford-work:~/rust/redish $ ./get-example ; echo $? 0 ``` I did not build an entire rust toolchain as I'm not totally sure how to do that.
2017-11-05Auto merge of #44042 - LukasKalbertodt:ascii-methods-on-instrinsics, ↡bors-16/+490
r=alexcrichton Copy all `AsciiExt` methods to the primitive types directly in order to deprecate it later **EDIT:** [this PR is ready now](https://github.com/rust-lang/rust/pull/44042#issuecomment-333883548). I edited this post to reflect the current status of discussion, which is (apart from code review) pretty much settled. --- This is my current progress in order to prepare stabilization of #39658. As discussed there (and in #39659), the idea is to deprecated `AsciiExt` and copy all methods to the type directly. Apparently there isn't really a reason to have those methods in an extension traitΒΉ. ~~This is **work in progress**: copy&pasting code while slightly modifying the documentation isn't the most exciting thing to do. Therefore I wanted to already open this WIP PR after doing basically 1/4 of the job (copying methods to `&[u8]`, `char` and `&str` is still missing) to get some feedback before I continue. Some questions possibly worth discussing:~~ 1. ~~Does everyone agree that deprecating `AsciiExt` is a good idea? Does everyone agree with the goal of this PR?~~ => apparently yes 2. ~~Are my changes OK so far? Did I do something wrong?~~ 3. ~~The issue of the unstable-attribute is currently set to 0. I would wait until you say "Ok" to the whole thing, then create a tracking issue and then insert the correct issue id. Is that ok?~~ 4. ~~I tweaked `eq_ignore_ascii_case()`: it now takes the argument `other: u8` instead of `other: &u8`. The latter was enforced by the trait. Since we're not bound to a trait anymore, we can drop the reference, ok?~~ => I reverted this, because the interface has to match the `AsciiExt` interface exactly. ΒΉ ~~Could it be that we can't write `impl [u8] {}`? This might be the reason for `AsciiExt`. If that is the case: is there a good reason we can't write such an impl block? What can we do instead?~~ => we couldn't at the time this PR was opened, but Simon made it possible. /cc @SimonSapin @zackw
2017-11-04Rollup merge of #45681 - Ljzn:patch-1, r=kennytmkennytm-1/+1
Fix typo.
2017-11-03Mark several ascii methods as unstable againLukas Kalbertodt-20/+25
We don't want to stabilize them now already. The goal of this set of commits is just to add inherent methods to the four types. Stabilizing all of those methods can be done later.
2017-11-03Remove unused AsciiExt imports and fix tests related to ascii methodsLukas Kalbertodt-16/+0
Many AsciiExt imports have become useless thanks to the inherent ascii methods added in the last commits. These were removed. In some places, I fully specified the ascii method being called to enforce usage of the AsciiExt trait. Note that some imports are not removed but tagged with a `#[cfg(stage0)]` attribute. This is necessary, because certain ascii methods are not yet available in stage0. All those imports will be removed later. Additionally, failing tests were fixed. The test suite should exit successfully now.
2017-11-03Copy `AsciiExt` methods to `str` directlyLukas Kalbertodt-1/+277
This is done in order to deprecate AsciiExt eventually. Note that this commit contains a bunch of `cfg(stage0)` statements. This is due to a new compiler feature this commit depends on: the `slice_u8` lang item. Once this lang item is available in the stage0 compiler, all those cfg flags (and more) can be removed.
2017-11-03Copy `AsciiExt` methods to `[u8]` directlyLukas Kalbertodt-0/+209
This is done in order to deprecate AsciiExt eventually. Note that this commit contains a bunch of `cfg(stage0)` statements. This is due to a new compiler feature I am using: the `slice_u8` lang item. Once this lang item is available in the stage0 compiler, all those cfg flags (and more) can be removed.
2017-11-02Auto merge of #45306 - whitequark:ref_slice, r=alexcrichtonbors-0/+3
Bring back slice::ref_slice as slice::from_ref. These functions were deprecated and removed in 1.5, but such simple functionality shouldn't require using unsafe code, and it isn't cluttering libstd too much. The original removal was quite contentious (see #27774), since then we've had precedent for including such nuggets of functionality (see rust-lang/rfcs#1789), and @nikomatsakis has provided a lot of use cases in https://github.com/rust-lang/rfcs/pull/1789#issuecomment-314640034. Hence this PR. I'm not too sure what to do with stability, feel free to correct me. It seems pointless to go through stabilization for these functions though. cc @aturon
2017-11-01De-stabilize core::slice::{from_ref, from_ref_mut}.whitequark-1/+2
2017-11-01Fix typo.Lance John-1/+1
2017-10-23Bring back slice::ref_slice as slice::from_ref.whitequark-0/+2
These functions were deprecated and removed in 1.5, but such simple functionality shouldn't require using unsafe code, and it isn't cluttering libstd too much.
2017-10-20Fix most rendering warnings from switching to CommonMarksteveklabnik-4/+3
2017-10-17added non trivial examples of closures for str::findChristian Poveda-2/+2
2017-10-17added examples of closuresChristian Poveda-1/+3
2017-10-13Rollup merge of #45133 - GuillaumeGomez:usize-index-msg, r=dtolnaykennytm-1/+25
usize index message for vec
2017-10-10Auto merge of #44877 - nvzqz:box-conversions, r=alexcrichtonbors-4/+40
Improve raw Box conversions This PR has two goals: - Reduce use of `mem::transmute` in `Box` conversions I understand that `mem::transmute`-ing non `#[repr(C)]` types is implementation-defined behavior. This may not matter within the reference implementation of Rust, but I believe it's important to remain consistent. For example, I noticed that `str::from_utf8_unchecked` went from using `mem::transmute` to using pointer casts. - Make `Box` pointer conversions more straightforward regarding `Unique`
2017-10-09usize index message for vecGuillaume Gomez-1/+25
2017-10-08Rollup merge of #45052 - steveklabnik:gh44105, r=dtolnaykennytm-3/+5
Modify Rc/Arc language around mutability There are a few exceptions to the rule that Arc/Rc are immutable. Rather than dig into the details, add "generally" to hint at this difference, as it's kind of a distraction at this point in the docs. Additionally, Arc's docs were slightly different here generally, so add in both the existing language and the exception. Fixes #44105
2017-10-06Add unique feature in Box::from_unique docsNikolai Vazquez-3/+7
2017-10-06Add missing word in Box::from_unique docsNikolai Vazquez-2/+2
2017-10-06Create Box::from_unique functionNikolai Vazquez-3/+35
Provides a reasonable interface for Box::from_raw implementation. Does not get around the requirement of mem::transmute for converting back and forth between Unique and Box.
2017-10-06Revert to using mem::transmute in Box::from_rawNikolai Vazquez-1/+1
Same reasons as commit 904133e1e28b690e2bbd101b719509aa897539a0.
2017-10-06Revert to using mem::transmute in Box::into_uniqueNikolai Vazquez-3/+1
Seems to cause this error: "Cannot handle boxed::Box<[u8]> represented as TyLayout".
2017-10-06Auto merge of #44734 - mchlrhw:wip/hashmap-entry-and-then, r=BurntSushibors-0/+34
Implement `and_modify` on `Entry` ## Motivation `Entry`s are useful for allowing access to existing values in a map while also allowing default values to be inserted for absent keys. The existing API is similar to that of `Option`, where `or` and `or_with` can be used if the option variant is `None`. The `Entry` API is, however, missing an equivalent of `Option`'s `and_then` method. If it were present it would be possible to modify an existing entry before calling `or_insert` without resorting to matching on the entry variant. Tracking issue: https://github.com/rust-lang/rust/issues/44733.
2017-10-06Implement `entry_and_modify`mchlrhw-0/+34
2017-10-05Modify Rc/Arc language around mutabilitysteveklabnik-3/+5
There are a few exceptions to the rule that Arc/Rc are immutable. Rather than dig into the details, add "generally" to hint at this difference, as it's kind of a distraction at this point in the docs. Additionally, Arc's docs were slightly different here generally, so add in both the existing language and the exception. Fixes #44105
2017-10-05Auto merge of #44943 - nivkner:fixme_fixup, r=dtolnaybors-3/+3
address some FIXME whose associated issues were marked as closed part of #44366
2017-10-04Auto merge of #44890 - nvzqz:str-box-transmute, r=alexcrichtonbors-8/+4
Remove mem::transmute used in Box<str> conversions Given that https://github.com/rust-lang/rust/pull/44877 is failing, I decided to make a separate PR. This is done with the same motivation: to avoid `mem::transmute`-ing non `#[repr(C)]` types.
2017-10-01Resolves #36284 - vec.rs documentationSean Prashad-5/+1
2017-09-30address some `FIXME`s whose associated issues were marked as closedNiv Kaminer-3/+3
remove FIXME(#13101) since `assert_receiver_is_total_eq` stays. remove FIXME(#19649) now that stability markers render. remove FIXME(#13642) now the benchmarks were moved. remove FIXME(#6220) now that floating points can be formatted. remove FIXME(#18248) and write tests for `Rc<str>` and `Rc<[u8]>` remove reference to irelevent issues in FIXME(#1697, #2178...) update FIXME(#5516) to point to getopts issue 7 update FIXME(#7771) to point to RFC 628 update FIXME(#19839) to point to issue 26925
2017-09-29Rollup merge of #44824 - dtolnay:22really21, r=alexcrichtonMark Simulacrum-6/+6
Backport libs stabilizations to 1.21 beta Includes the following stabilizations: - tcpstream_connect_timeout https://github.com/rust-lang/rust/pull/44563 - iterator_for_each https://github.com/rust-lang/rust/pull/44567 - ord_max_min https://github.com/rust-lang/rust/pull/44593 - compiler_fences https://github.com/rust-lang/rust/pull/44595 - needs_drop https://github.com/rust-lang/rust/pull/44639 - vec_splice https://github.com/rust-lang/rust/pull/44640 These have been backported in https://github.com/rust-lang/rust/pull/44823.
2017-09-27Remove mem::transmute used in Box<str> conversionsNikolai Vazquez-8/+4
2017-09-27Auto merge of #44709 - Badel2:inclusive-range-dotdoteq, r=petrochenkovbors-39/+39
Initial support for `..=` syntax #28237 This PR adds `..=` as a synonym for `...` in patterns and expressions. Since `...` in expressions was never stable, we now issue a warning. cc @durka r? @aturon
2017-09-26Remove uses of mem::transmute in Box methodsNikolai Vazquez-3/+5
Makes use of conversions via Unique.
2017-09-24Backport libs stabilizations to 1.21 betaDavid Tolnay-6/+6
This includes the following stabilizations: - tcpstream_connect_timeout https://github.com/rust-lang/rust/pull/44563 - iterator_for_each https://github.com/rust-lang/rust/pull/44567 - ord_max_min https://github.com/rust-lang/rust/pull/44593 - compiler_fences https://github.com/rust-lang/rust/pull/44595 - needs_drop https://github.com/rust-lang/rust/pull/44639 - vec_splice https://github.com/rust-lang/rust/pull/44640
2017-09-23Fix capacity comparison in reserveSteven Fackler-1/+1
You can otherwise end up in a situation where you don't actually resize but still call into handle_cap_increase which then corrupts head/tail. Closes #44800
2017-09-22Add support for `..=` syntaxAlex Burka-39/+39
Add ..= to the parser Add ..= to libproc_macro Add ..= to ICH Highlight ..= in rustdoc Update impl Debug for RangeInclusive to ..= Replace `...` to `..=` in range docs Make the dotdoteq warning point to the ... Add warning for ... in expressions Updated more tests to the ..= syntax Updated even more tests to the ..= syntax Updated the inclusive_range entry in unstable book
2017-09-22Add missing links for ArcGuillaume Gomez-5/+8
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-24 08:51:22 +0000