about summary refs log tree commit diff
path: root/src/libstd
AgeCommit message (Collapse)AuthorLines
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-01Fall back to `/dev/urandom` on `EPERM` for `getrandom`Tobias Bucher-1/+6
This can happen because of seccomp or some VMs. Fixes #52609.
2019-05-01as_ptr returns a read-only pointerRalf Jung-2/+7
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-27Rename .cap() methods to .capacity()Matthias Geier-7/+7
... but leave the old names in there for backwards compatibility.
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-24std: Derive `Default` for `io::Cursor`Daiki Mizukami-1/+1
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-23std::net: tests for Ipv4addr::is_shared()Corentin Henry-0/+15
2019-04-23std::net: add warning in Ipv4addr::is_reserved() documentationCorentin Henry-0/+7
See @the8472 comment's on Github: https://github.com/rust-lang/rust/pull/60145#issuecomment-485424229 > I don't think is_reserved including ranges marked for future use is > a good idea since those future uses may be realized at at some point > and then old software with is_reserved filters may have false > positives. This is not a hypothetical concern, such issues have been > encountered before when IANA assigned previously reserved /8 address > blocks.
2019-04-23std::net: add warning in Ipv6Addr::is_unicast_site_local() docCorentin Henry-0/+8
site-local addresses are deprecated, so we should warn users about it.
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-22std::net: tests for Ipv4addr::is_reserved()Corentin Henry-0/+15
Also add tests to IpAddr for make sure these addresses are not global or multicast.
2019-04-22std::net: tests for Ipv4addr::is_ietf_protocol_assignment()Corentin Henry-0/+16
Also add tests to IpAddr to make sure these addresses are not global.
2019-04-22std::net: tests for Ipv4addr::is_benchmarking()Corentin Henry-16/+30
also add test to Ipaddr, making sure that these addresses are not global.
2019-04-22std::net: tests for Ipv6addr::is_unicast_link_local{_strict}()Corentin Henry-20/+49
2019-04-22std::net: fix tests for site-local ipv6 addressesCorentin Henry-2/+2
Ipv6Addr::is_unicast_global() now returns `true` for unicast site local addresses, since they are deprecated.
2019-04-22std::net: fix Ipv4addr::is_global() testsCorentin Henry-4/+4
Ipv4addr::is_global() previously considered 0/8 was global, but has now been fixed, so these tests needed to be fixed as well.
2019-04-22std::net: use macros to test ip propertiesCorentin Henry-143/+381
2019-04-22std::net: fix documentation markdownCorentin Henry-3/+5
2019-04-22std::net: fix Ipv4Addr::is_global()Corentin Henry-8/+64
As per @therealbstern's comment[0]: The implementation of Ipv4::is_global is not complete, according to the IANA IPv4 Special-Purpose Address Registry. - It compares the address to 0.0.0.0, but anything in 0.0.0.0/8 should not be considered global. - 0/8 is not global and is currently forbidden because some systems used to treat it as the local network. - The implementation of Ipv4::is_unspecified is correct. 0.0.0.0 is the unspecified address. - It does not examine 100.64.0.0/10, which is "Shared Address Space" and not global. - Ditto 192.0.0.0/24 (IETF Protocol Assignments), except for 192.0.0.9/32 and 192.0.0.10/32, which are carved out as globally reachable. - 198.18.0.0/15 is for "Benchmarking" and should not be globally reachable. - 240.0.0.0/4 is reserved and not currently reachable
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-22 00:37:31 +0000