Commit graph

13254 commits

Author SHA1 Message Date
bors
1891bfa803 Auto merge of #59883 - ebarnard:clonefile, r=sfackler
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-03 07:26:46 +00:00
Jethro Beekman
1dc4a38b0e 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-02 18:15:44 -07:00
Alexey Shmalko
90d3fa223d Make tidy::version::Version a [u32; 3] 2019-05-02 16:38:29 +03:00
Edward Barnard
0fd446ea78 Make std::fs::copy attempt to create copy-on-write clones of files on MacOS. 2019-05-02 09:41:37 +01:00
bors
758dc9af50 Auto merge of #60156 - RalfJung:macos-rand, r=oli-obk,alexcrichton
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-02 07:38:36 +00:00
Tobias Bucher
bd8885d340 Fall back to /dev/urandom on EPERM for getrandom
This can happen because of seccomp or some VMs.

Fixes #52609.
2019-05-01 22:23:07 +02:00
Ralf Jung
1e47250540 as_ptr returns a read-only pointer 2019-05-01 17:59:48 +02:00
Michal 'vorner' Vaner
26199a27ff
doc: Warn about possible zombie apocalypse
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-05-01 17:46:30 +02:00
bors
96ee0ba59e Auto merge of #60204 - jethrogb:jb/rtunwrap-debug-print, r=alexcrichton
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-30 22:46:28 +00:00
Jethro Beekman
09f4008da5 SGX target: implemented vectored I/O 2019-04-29 16:48:22 -07:00
Jethro Beekman
7e624ce2c2 SGX target: don't unwind on usercall index out of bounds 2019-04-29 16:46:29 -07:00
Mazdak Farrokhzad
ead8d81301
Rollup merge of #60334 - sfackler:stable-iovec, r=alexcrichton
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-29 22:22:40 +02:00
Mazdak Farrokhzad
95abeb0705
Rollup merge of #60022 - nathankleyn:fix-issue-59543, r=Centril
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-28 14:17:08 +02:00
Matthias Geier
0967d28be7 Rename .cap() methods to .capacity()
... but leave the old names in there for backwards compatibility.
2019-04-27 22:43:10 +02:00
Steven Fackler
89ff7cde5a tidy 2019-04-27 09:19:34 -07:00
Steven Fackler
bd177f3ea3 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
2019-04-27 08:34:08 -07:00
Matthias Geier
be12ab070d Use "capacity" as parameter name in with_capacity() methods
Closes #60271.
2019-04-26 18:43:24 +02:00
Christopher Serr
cf9d6672b7 Remove feature gates from std and tests 2019-04-26 12:33:42 +02:00
varkor
aa388f1d11 ignore-tidy-filelength on all files with greater than 3000 lines 2019-04-25 21:39:09 +01:00
Mazdak Farrokhzad
3fffcd3314
Rollup merge of #60185 - NieDzejkob:int-error-kind-reexport, r=rkruppe
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-25 03:05:25 +02:00
Daiki Mizukami
902904a79a
std: Derive Default for io::Cursor 2019-04-24 20:24:57 +09:00
Mazdak Farrokhzad
48cb6bead1
Rollup merge of #59739 - cramertj:stabilize, r=withoutboats
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-24 05:16:18 +02:00
bors
0928511d3a Auto merge of #58623 - Amanieu:hashbrown3, r=alexcrichton
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-24 00:20:56 +00:00
Taylor Cramer
3f966dcd53 Stabilize futures_api 2019-04-23 16:13:53 -07:00
Amanieu d'Antras
e7f162fdd8 Update hashbrown to 0.3.0 2019-04-24 06:54:14 +08:00
Amanieu d'Antras
ae388773e1 Update hashbrown to 0.2.2 2019-04-24 06:54:14 +08:00
Amanieu d'Antras
5253366e19 Update hashbrown to 0.2.1 2019-04-24 06:54:14 +08:00
Amanieu d'Antras
e15bf96cb2 Remove broken tests 2019-04-24 06:54:14 +08:00
Amanieu d'Antras
cf46bd5037 Replace the robin-hood hash table with hashbrown 2019-04-24 06:54:14 +08:00
Amanieu d'Antras
1fa7a21534 Make libstd depend on the hashbrown crate 2019-04-24 06:54:14 +08:00
Amanieu d'Antras
556fc40a95 Mark HashSet functions with #[inline] 2019-04-24 06:54:14 +08:00
Amanieu d'Antras
a533504ca1 Add try_reserve to HashSet 2019-04-24 06:54:14 +08:00
Amanieu d'Antras
185ed988d2 Remove the Recover trait for HashSet 2019-04-24 06:54:14 +08:00
Jethro Beekman
942831eef4 Debug-print error when using rtunwrap 2019-04-23 10:06:27 -07:00
Corentin Henry
cddb838043 std::net: tests for Ipv4addr::is_shared() 2019-04-23 12:01:41 +02:00
Corentin Henry
fe718ef07f std::net: add warning in Ipv4addr::is_reserved() documentation
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-23 10:41:25 +02:00
Corentin Henry
634dcd00b4 std::net: add warning in Ipv6Addr::is_unicast_site_local() doc
site-local addresses are deprecated, so we should warn users about it.
2019-04-23 10:38:26 +02:00
bors
0f11354a9c Auto merge of #60172 - varkor:tidy-double-trailing-newline, r=kennytm
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-23 06:40:12 +00:00
bors
3bee49f42b Auto merge of #60121 - davazp:fix-sync-all-macos, r=KodrAus
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-23 03:34:21 +00:00
Jakub Kądziołka
7af0fccc88
Reexport IntErrorKind in std 2019-04-23 00:15:43 +02:00
varkor
7f0f0e31ec Remove double trailing newlines 2019-04-22 16:57:01 +01:00
Corentin Henry
66627777b5 std::net: tests for Ipv4addr::is_reserved()
Also add tests to IpAddr for make sure these addresses are not global
or multicast.
2019-04-22 17:54:27 +02:00
Corentin Henry
a2bead8761 std::net: tests for Ipv4addr::is_ietf_protocol_assignment()
Also add tests to IpAddr to make sure these addresses are not global.
2019-04-22 17:41:43 +02:00
Corentin Henry
9dcfd9f58c std::net: tests for Ipv4addr::is_benchmarking()
also add test to Ipaddr, making sure that these addresses are not
global.
2019-04-22 17:41:37 +02:00
Corentin Henry
40d0127a09 std::net: tests for Ipv6addr::is_unicast_link_local{_strict}() 2019-04-22 17:41:32 +02:00
Corentin Henry
99d9bb640f std::net: fix tests for site-local ipv6 addresses
Ipv6Addr::is_unicast_global() now returns `true` for unicast site
local addresses, since they are deprecated.
2019-04-22 16:03:39 +02:00
Corentin Henry
c302d2c78f std::net: fix Ipv4addr::is_global() tests
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-22 16:03:39 +02:00
Corentin Henry
c34bcc658b std::net: use macros to test ip properties 2019-04-22 16:03:39 +02:00
Corentin Henry
8106320009 std::net: fix documentation markdown 2019-04-22 16:03:39 +02:00
Corentin Henry
9f6a747b32 std::net: fix Ipv4Addr::is_global()
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
2019-04-22 16:03:39 +02:00