about summary refs log tree commit diff
path: root/src/libstd
AgeCommit message (Collapse)AuthorLines
2019-05-05Rollup merge of #60536 - brainplot:fix-unicode-character, r=dtolnayManish Goregaokar-1/+1
Correct code points to match their textual description Probably due to a copy-paste error, in the sentence > For example, despite looking similar, the 'é' character is one Unicode code point while 'é' is two Unicode code points: the two `é`'s were actually the same character in the text (i.e. the same Unicode character U+00E9). The code listing below instead had two different Unicode characters for the two `é`s, as it was supposed to. The example shown wasn't clear at first so I started inspecting the text and found this out. I simply copied the character from the code listing to the description surrounding the code. It's a minor thing but I thought it would make things clearer for others, especially since the example is about how Rust handles `char`s.
2019-05-03Categorize WASI as an "OS" rather than as an "environment".Dan Gohman-2/+2
This distinction is fairly abstract, but in practice, the main advantage here is that LLVM's triple code considers WASI to be an OS, so this makes rustc agree with that.
2019-05-04Correct code points to match their textual descriptionGianluca Recchia-1/+1
2019-05-03Auto merge of #60496 - jethrogb:jb/address-integer-overflow, r=alexcrichtonbors-7/+17
Fix potential integer overflow in SGX memory range calculation. Thanks to Eduard Marin and David Oswald at the University of Burmingham, and Jo Van Bulck at KU Leuven for discovering this issue.
2019-05-03Rollup merge of #60373 - rasendubi:lang-features-sort-since, r=CentrilMazdak Farrokhzad-41/+41
Tidy: ensure lang features are sorted by since This is the tidy side of https://github.com/rust-lang/rust/issues/60361. What is left is actually splitting features into groups and sorting by since. This PR also likely to produce a small (a couple of lines) merge conflict with https://github.com/rust-lang/rust/pull/60362. r? @Centril
2019-05-03Auto merge of #59883 - ebarnard:clonefile, r=sfacklerbors-21/+71
Make `std::fs::copy` attempt to create copy-on-write clones of files on MacOS The behaviour of MacOS now matches Linux which uses `copy_file_range` to perform CoW file copies where available and supported by the underlying filesystem.
2019-05-02Fix potential integer overflow in SGX memory range calculation.Jethro Beekman-7/+17
Thanks to Eduard Marin and David Oswald at the University of Burmingham, and Jo Van Bulck at KU Leuven for discovering this issue.
2019-05-02Make tidy::version::Version a [u32; 3]Alexey Shmalko-41/+41
2019-05-02Make `std::fs::copy` attempt to create copy-on-write clones of files on MacOS.Edward Barnard-21/+71
2019-05-02Auto merge of #60156 - RalfJung:macos-rand, r=oli-obk,alexcrichtonbors-1/+4
use SecRandomCopyBytes on macOS in Miri This is a hack to fix https://github.com/rust-lang/miri/issues/686: on macOS, rustc will open `/dev/urandom` to initialize a `HashMap`. That's quite hard to emulate properly in Miri without a full-blown implementation of file descriptors. However, Miri needs an implementation of `SecRandomCopyBytes` anyway to support [getrandom](https://crates.io/crates/getrandom), so using it here should work just as well. This will only have an effect when libstd is compiled specifically for Miri, but that will generally be the case when people use `cargo miri`. This is clearly a hack, so I am opening this to start a discussion about whether we are okay with such a hack or not. Cc @oli-obk
2019-05-01doc: Warn about possible zombie apocalypseMichal 'vorner' Vaner-0/+12
Extend the std::process::Child docs with warning about possible zombies. The previous version mentioned that when dropping the Child, the process is not killed. However, the wording gave the impression that such behaviour is fine to do (leaving the reader believe low-level details like reaping zombies of the dead processes is taken over by std somehow; or simply leaving the reader unaware about the problem).
2019-04-30Auto merge of #60204 - jethrogb:jb/rtunwrap-debug-print, r=alexcrichtonbors-4/+6
Debug-print error when using rtunwrap When I added this macro a while back I didn't have a way to make it print the failure for all types that you might want to unwrap. Now, I came up with a solution.
2019-04-29SGX target: implemented vectored I/OJethro Beekman-13/+50
2019-04-29SGX target: don't unwind on usercall index out of boundsJethro Beekman-2/+10
2019-04-29Rollup merge of #60334 - sfackler:stable-iovec, r=alexcrichtonMazdak Farrokhzad-278/+292
Stabilized vectored IO This renames `std::io::IoVec` to `std::io::IoSlice` and `std::io::IoVecMut` to `std::io::IoSliceMut`, and stabilizes `std::io::IoSlice`, `std::io::IoSliceMut`, `std::io::Read::read_vectored`, and `std::io::Write::write_vectored`. Closes #58452 r? @alexcrichton
2019-04-28Rollup merge of #60022 - nathankleyn:fix-issue-59543, r=CentrilMazdak Farrokhzad-1/+7
Document `Item` type in `std::env::SplitPaths` iterator. Previously there wasn't any documentation to show what the type of `Item` was inside `std::env::SplitPaths`. Now, in the same format as other examples of docs in `std` for `Iterator#Item`, we mention the type. This fixes #59543. r? @steveklabnik
2019-04-27tidySteven Fackler-10/+24
2019-04-27Stabilized vectored IOSteven Fackler-276/+276
This renames `std::io::IoVec` to `std::io::IoSlice` and `std::io::IoVecMut` to `std::io::IoSliceMut`, and stabilizes `std::io::IoSlice`, `std::io::IoSliceMut`, `std::io::Read::read_vectored`, and `std::io::Write::write_vectored`. Closes #58452
2019-04-26Use "capacity" as parameter name in with_capacity() methodsMatthias Geier-10/+10
Closes #60271.
2019-04-26Remove feature gates from std and testsChristopher Serr-1/+0
2019-04-25ignore-tidy-filelength on all files with greater than 3000 linesvarkor-0/+8
2019-04-25Rollup merge of #60185 - NieDzejkob:int-error-kind-reexport, r=rkruppeMazdak Farrokhzad-0/+7
Reexport IntErrorKind in std Currently `IntErrorKind` can only be found in `core`. @Centril confirmed on Discord that this is unintentional (should I r? him in this situation?). Should there be a test for this? As far as this *specific* situation goes, I don't think so, I'll risk it and say that there's no way this regresses. However, it might be a good idea to have some tool detect public items in `core` that are not reexported in `std`. Does this belong in tidy, or should that be a separate tool? Is there some rustc-specific *linter*? Unless that's entirely a dumb idea, this should probably get an issue. Note: My local build hasn't finished yet, but it's well past the point where I would expect problems.
2019-04-24Rollup merge of #59739 - cramertj:stabilize, r=withoutboatsMazdak Farrokhzad-8/+5
Stabilize futures_api cc https://github.com/rust-lang/rust/issues/59725. Based on https://github.com/rust-lang/rust/pull/59733 and https://github.com/rust-lang/rust/pull/59119 -- only the last two commits here are relevant. r? @withoutboats , @oli-obk for the introduction of `rustc_allow_const_fn_ptr`.
2019-04-24Auto merge of #58623 - Amanieu:hashbrown3, r=alexcrichtonbors-2395/+475
Replace HashMap implementation with SwissTable (as an external crate) This is the same as #56241 except that it imports `hashbrown` as an external crate instead of copying the implementation into libstd. This includes a few API changes (all unstable): - `try_reserve` is added to `HashSet`. - Some trait bounds have been changed in the `raw_entry` API. - `search_bucket` has been removed from the `raw_entry` API (doesn't work with SwissTable).
2019-04-23Stabilize futures_apiTaylor Cramer-8/+5
2019-04-24Update hashbrown to 0.3.0Amanieu d'Antras-1/+1
2019-04-24Update hashbrown to 0.2.2Amanieu d'Antras-1/+1
2019-04-24Update hashbrown to 0.2.1Amanieu d'Antras-1/+1
2019-04-24Remove broken testsAmanieu d'Antras-74/+0
2019-04-24Replace the robin-hood hash table with hashbrownAmanieu d'Antras-2278/+405
2019-04-24Make libstd depend on the hashbrown crateAmanieu d'Antras-0/+1
2019-04-24Mark HashSet functions with #[inline]Amanieu d'Antras-0/+45
2019-04-24Add try_reserve to HashSetAmanieu d'Antras-0/+24
2019-04-24Remove the Recover trait for HashSetAmanieu d'Antras-52/+9
2019-04-23Debug-print error when using rtunwrapJethro Beekman-4/+6
2019-04-23Auto merge of #60172 - varkor:tidy-double-trailing-newline, r=kennytmbors-10/+0
Disallow double trailing newlines in tidy This wasn't done previously in https://github.com/rust-lang/rust/pull/47064#issuecomment-354533010 as it affected too many files, but I think it's best to fix it now so that the number of files with double trailing newlines doesn't keep increasing. r? kennytm
2019-04-23Auto merge of #60121 - davazp:fix-sync-all-macos, r=KodrAusbors-2/+9
Fix sync_all on macos/ios `sync_all` should flush all metadata in macos/ios, so it should call `fcntl` with the `F_FULLFSYNC` flag as `sync_data` does. Note that without this `sync_data` performs more flushes than `sync_all` on macos/ios.
2019-04-23Reexport IntErrorKind in stdJakub Kądziołka-0/+7
2019-04-22Remove double trailing newlinesvarkor-10/+0
2019-04-21use SecRandomCopyBytes on macOS in MiriRalf Jung-1/+4
2019-04-20Auto merge of #59826 - llogiq:multi-dbg, r=SimonSapinbors-1/+22
allow multiple args to `dbg!(..)` This closes #59763
2019-04-19extend ui testAndre Bogus-1/+12
2019-04-19Fix sync_all on macos/iosDavid Vázquez Púa-2/+9
sync_all should flush all metadata in macos/ios, so it should call fcntl with the F_FULLFSYNC flag as sync_data does. Fixes #55920
2019-04-19Rollup merge of #60078 - matklad:patch-1, r=shepmasterMazdak Farrokhzad-1/+1
Use more realistic example for thread builder Stack size of 10 **bytes** does not make any sense: the minimal possible stack size is greater anyway.
2019-04-19Rollup merge of #60041 - jnferner:patch-1, r=shepmasterMazdak Farrokhzad-2/+1
Simplify the returning of a Result a bit
2019-04-18Use more realistic example for thread builderAleksey Kladov-1/+1
Stack size of 10 **bytes** does not make any sense: the minimal possible stack size is greater anyway.
2019-04-18Simplify the returning of a Result a bitJan Nils Ferner-2/+1
2019-04-18Rollup merge of #59984 - gluyas:collections-with_capacity-doc-fix, r=rkruppeMazdak Farrokhzad-4/+3
Remove collection-specific `with_capacity` documentation from `std::collections` Fixes #59931 The style of `std::collections` module doc is very much a beginner friendly guide, and documenting niche, collection-specific behaviour feels out of place, if not brittle. The note about `VecDeque` is outdated (see issue), and while `Vec` probably won't change its guarantees any time soon, the users who are interested in its allocation properties will find that in its own documentation.
2019-04-17Document `Item` type in `std::env::SplitPaths` iterator.Nathan Kleyn-1/+7
Previously there wasn't any documentation to show what the type of `Item` was inside `std::env::SplitPaths`. Now, in the same format as other examples of docs in `srd` for `Iterator#Item`, we mention the type. This fixes #59543.
2019-04-16SGX target: change re-entry abort logicJethro Beekman-19/+11
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-26 14:16:52 +0000