Commit Graph

1951 Commits

Author SHA1 Message Date
est31
43bfbb10bf Add column number support to Backtrace
Backtrace frames might include column numbers.
Print them if they are included.
2020-11-15 13:09:56 +01:00
Dylan DPC
d57212d49e
Rollup merge of #78988 - alexcrichton:one-more-intrinsic, r=sfackler
Fix an intrinsic invocation on threaded wasm

This looks like it was forgotten to get updated in #74482 and wasm with
threads isn't built on CI so we didn't catch this by accident.
2020-11-15 03:02:57 +01:00
Dylan DPC
dbb37fb1ee
Rollup merge of #78590 - DeveloperC286:issue_60302, r=varkor
refactor: removing alloc::collections::vec_deque ignore-tidy-filelength

This PR removes the need for ignore-tidy-filelength for alloc::collections::vec_deque which is part of the issue https://github.com/rust-lang/rust/issues/60302

It is probably easiest to review this PR by looking at it commit by commit rather than looking at the overall diff.
2020-11-15 03:02:37 +01:00
bors
30e49a9ead Auto merge of #75272 - the8472:spec-copy, r=KodrAus
specialize io::copy to use copy_file_range, splice or sendfile

Fixes #74426.
Also covers #60689 but only as an optimization instead of an official API.

The specialization only covers std-owned structs so it should avoid the problems with #71091

Currently linux-only but it should be generalizable to other unix systems that have sendfile/sosplice and similar.

There is a bit of optimization potential around the syscall count. Right now it may end up doing more syscalls than the naive copy loop when doing short (<8KiB) copies between file descriptors.

The test case executes the following:

```
[pid 103776] statx(3, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=17, ...}) = 0
[pid 103776] write(4, "wxyz", 4)        = 4
[pid 103776] write(4, "iklmn", 5)       = 5
[pid 103776] copy_file_range(3, NULL, 4, NULL, 5, 0) = 5

```

0-1 `stat` calls to identify the source file type. 0 if the type can be inferred from the struct from which the FD was extracted
𝖬 `write` to drain the `BufReader`/`BufWriter` wrappers. only happen when buffers are present. 𝖬 ≾ number of wrappers present. If there is a write buffer it may absorb the read buffer contents first so only result in a single write. Vectored writes would also be an option but that would require more invasive changes to `BufWriter`.
𝖭 `copy_file_range`/`splice`/`sendfile` until file size, EOF or the byte limit from `Take` is reached. This should generally be *much* more efficient than the read-write loop and also have other benefits such as DMA offload or extent sharing.

## Benchmarks

```

OLD

test io::tests::bench_file_to_file_copy         ... bench:      21,002 ns/iter (+/- 750) = 6240 MB/s    [ext4]
test io::tests::bench_file_to_file_copy         ... bench:      35,704 ns/iter (+/- 1,108) = 3671 MB/s  [btrfs]
test io::tests::bench_file_to_socket_copy       ... bench:      57,002 ns/iter (+/- 4,205) = 2299 MB/s
test io::tests::bench_socket_pipe_socket_copy   ... bench:     142,640 ns/iter (+/- 77,851) = 918 MB/s

NEW

test io::tests::bench_file_to_file_copy         ... bench:      14,745 ns/iter (+/- 519) = 8889 MB/s    [ext4]
test io::tests::bench_file_to_file_copy         ... bench:       6,128 ns/iter (+/- 227) = 21389 MB/s   [btrfs]
test io::tests::bench_file_to_socket_copy       ... bench:      13,767 ns/iter (+/- 3,767) = 9520 MB/s
test io::tests::bench_socket_pipe_socket_copy   ... bench:      26,471 ns/iter (+/- 6,412) = 4951 MB/s
```
2020-11-14 12:01:55 +00:00
The8472
bbfa92c82d Always handle EOVERFLOW by falling back to the generic copy loop
Previously EOVERFLOW handling was only applied for io::copy specialization
but not for fs::copy sharing the same code.

Additionally we lower the chunk size to 1GB since we have a user report
that older kernels may return EINVAL when passing 0x8000_0000
but smaller values succeed.
2020-11-13 22:38:27 +01:00
The8472
4854d418a5 do direct splice syscall and probe availability to get android builds to work
Android builds use feature level 14, the libc wrapper for splice is gated
on feature level 21+ so we have to invoke the syscall directly.
Additionally the emulator doesn't seem to support it so we also have to
add ENOSYS checks.
2020-11-13 22:38:27 +01:00
The8472
3dfc377aa1 move sendfile/splice/copy_file_range into kernel_copy module 2020-11-13 22:38:27 +01:00
The8472
888b1031bc limit visibility of copy offload helpers to sys::unix module 2020-11-13 22:38:27 +01:00
The8472
18bfe2a66b move copy specialization tests to their own module 2020-11-13 22:38:27 +01:00
The8472
7f5d2722af move copy specialization into sys::unix module 2020-11-13 22:38:23 +01:00
The8472
ad9b07c7e5 add benchmarks 2020-11-13 19:46:37 +01:00
The8472
46e7fbe60b reduce syscalls by inferring FD types based on source struct instead of calling stat()
also adds handling for edge-cases involving large sparse files where sendfile could fail with EOVERFLOW
2020-11-13 19:46:35 +01:00
The8472
0624730d9e add forwarding specializations for &mut variants
`impl Write for &mut T where T: Write`, thus the same should
apply to the specialization traits
2020-11-13 19:45:38 +01:00
The8472
cd3bddc044 prioritize sendfile over splice since it results in fewer context switches when sending to pipes
splice returns to userspace when the pipe is full, sendfile
just blocks until it's done, this can achieve much higher throughput
2020-11-13 19:45:38 +01:00
The8472
67a6059aa5 move tests module into separate file 2020-11-13 19:45:38 +01:00
The8472
5eb88fa5c7 hide unused exports on other platforms 2020-11-13 19:45:38 +01:00
The8472
16236470c1 specialize io::copy to use copy_file_range, splice or sendfile
Currently it only applies to linux systems. It can be extended to make use
of similar syscalls on other unix systems.
2020-11-13 19:45:27 +01:00
C
75dfc711da refactor: vec_deque ignore-tidy-filelength
commit c547d5fabcd756515afa7263ee5304965bb4c497
Author: C <DeveloperC@protonmail.com>
Date:   Sat Oct 31 11:22:23 2020 +0000

    test: updating ui/hygiene/panic-location.rs expected

commit 2af03769c4ffdbbbad75197a1ad0df8c599186be
Author: C <DeveloperC@protonmail.com>
Date:   Sat Oct 31 10:43:30 2020 +0000

    fix: documentation unresolved link

commit c4b0df361ce27d7392d8016229f2e0265af32086
Author: C <DeveloperC@protonmail.com>
Date:   Sat Oct 31 02:58:31 2020 +0000

    style: compiling with Rust's style guidelines

commit bdd2de5f3c09b49a18e3293f2457fcab25557c96
Author: C <DeveloperC@protonmail.com>
Date:   Sat Oct 31 02:56:31 2020 +0000

    refactor: removing ignore-tidy-filelength

commit fcc4b3bc41f57244c65ebb8e4efe4cbc9460b5a9
Author: C <DeveloperC@protonmail.com>
Date:   Sat Oct 31 02:51:35 2020 +0000

    refactor: moving trait RingSlices to ring_slices.rs

commit 2f0cc539c06d8841baf7f675168f68ca7c21e68e
Author: C <DeveloperC@protonmail.com>
Date:   Sat Oct 31 02:46:09 2020 +0000

    refactor: moving struct PairSlices to pair_slices.rs

commit a55d3ef1dab4c3d85962b3a601ff8d1f7497faf2
Author: C <DeveloperC@protonmail.com>
Date:   Sat Oct 31 02:31:45 2020 +0000

    refactor: moving struct Iter to iter.rs

commit 76ab33a12442a03726f36f606b4e0fe70f8f246b
Author: C <DeveloperC@protonmail.com>
Date:   Sat Oct 31 02:24:32 2020 +0000

    refactor: moving struct IntoIter into into_iter.rs

commit abe0d9eea2933881858c3b1bc09df67cedc5ada5
Author: C <DeveloperC@protonmail.com>
Date:   Sat Oct 31 02:19:07 2020 +0000

    refactor: moving struct IterMut into iter_mut.rs

commit 70ebd6420335e1895e2afa2763a0148897963e24
Author: C <DeveloperC@protonmail.com>
Date:   Sat Oct 31 01:49:15 2020 +0000

    refactor: moved macros into macros.rs

commit b08dd2add994b04ae851aa065800bd8bd6326134
Author: C <DeveloperC@protonmail.com>
Date:   Sat Oct 31 01:05:36 2020 +0000

    refactor: moving vec_deque.rs to vec_deque/mod.rs
2020-11-13 17:56:39 +00:00
Guillaume Gomez
ef32ef7baf
Rollup merge of #77996 - tkaitchuck:master, r=m-ou-se
Doc change: Remove mention of `fnv` in HashMap

Disclaimer: I am the author of [aHash](https://github.com/tkaitchuck/aHash).

This changes the Rustdoc in `HashMap` from mentioning the `fnv` crate to mentioning the `aHash` crate, as an alternative `Hasher` implementation.

### Why

Fnv [has poor hash quality](https://github.com/rurban/smhasher), is [slow for larger keys](https://github.com/tkaitchuck/aHash/blob/master/compare/readme.md#speed), and does not provide dos resistance, because it is unkeyed (this can also cause [other problems](https://accidentallyquadratic.tumblr.com/post/153545455987/rust-hash-iteration-reinsertion)).

Fnv has acceptable performance for integers and has very poor performance with keys >32 bytes. This is the reason it was removed from the standard library in https://github.com/rust-lang/rust/pull/37229 .

Because regardless of which dimension you value, there are better alternatives, it does not make sense for anyone to consider using `fnv`.

The text mentioning `fnv` in the standard library continues to create confusion: https://github.com/rust-lang/hashbrown/issues/153  https://github.com/rust-lang/hashbrown/issues/9 . There are also a number of [crates using it](https://crates.io/crates/fnv/reverse_dependencies) a great many of which are hashing strings (Which is when Fnv is the [worst](https://github.com/cbreeden/fxhash#benchmarks), [possible](https://github.com/tkaitchuck/aHash#speed), [choice](http://cglab.ca/~abeinges/blah/hash-rs/).)

I think aHash makes the most sense to mention as an alternative because it is the most credible option (in my obviously biased opinion). It offers [good performance on numbers and strings](https://github.com/tkaitchuck/aHash/blob/master/compare/readme.md#speed), is [of high quality](https://github.com/tkaitchuck/aHash#hash-quality), and [provides dos resistance](https://github.com/tkaitchuck/aHash/wiki/How-aHash-is-resists-DOS-attacks). It is popular (see [stats](https://crates.io/crates/ahash)) and is the default hasher for [hashbrown](https://crates.io/crates/hashbrown) and [dashmap](https://crates.io/crates/dashmap) which are the most popular alternative hashmaps. Finally it does not have any of the [`gotcha` cases](https://github.com/tkaitchuck/aHash#fxhash) that `FxHash` suffers from. (Which is the other popular hashing option when DOS attacks are not a concern)

Signed-off-by: Tom Kaitchuck <tom.kaitchuck@emc.com>
2020-11-13 15:26:10 +01:00
Tom Kaitchuck
4e5848349c
Update library/std/src/collections/hash/map.rs
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
2020-11-12 20:14:57 -08:00
Mara Bos
40889819ee
Rollup merge of #78857 - SkiFire13:bheap-opt, r=KodrAus
Improve BinaryHeap performance

By changing the condition in the loops from `child < end` to `child < end - 1` we're guaranteed that `right = child + 1 < end` and since finding the index of the biggest sibling can be done with an arithmetic operation we can remove a branch from the loop body. The case where there's no right child, i.e. `child == end - 1` is instead handled outside the loop, after it ends; note that if the loops ends early we can use `return` instead of `break` since the check `child == end - 1` will surely fail.

I've also removed a call to `<[T]>::swap` that was hiding a bound check that [wasn't being optimized by LLVM](https://godbolt.org/z/zrhdGM).

A quick benchmarks on my pc shows that the gains are pretty significant:

|name                 |before ns/iter  |after ns/iter  |diff ns/iter  |diff %    |speedup |
|---------------------|----------------|---------------|--------------|----------|--------|
|find_smallest_1000   | 352,565        | 260,098       |     -92,467  | -26.23%  | x 1.36 |
|from_vec             | 676,795        | 473,934       |    -202,861  | -29.97%  | x 1.43 |
|into_sorted_vec      | 469,511        | 304,275       |    -165,236  | -35.19%  | x 1.54 |
|pop                  | 483,198        | 373,778       |    -109,420  | -22.64%  | x 1.29 |

The other 2 benchmarks for `BinaryHeap` (`peek_mut_deref_mut` and `push`) weren't impacted and as such didn't show any significant change.
2020-11-12 19:46:11 +01:00
Alex Crichton
010265a439 Fix an intrinsic invocation on threaded wasm
This looks like it was forgotten to get updated in #74482 and wasm with
threads isn't built on CI so we didn't catch this by accident.
2020-11-12 07:23:00 -08:00
bors
55794e4396 Auto merge of #78965 - jryans:emscripten-threads-libc, r=kennytm
Update thread and futex APIs to work with Emscripten

This updates the thread and futex APIs in `std` to match the APIs exposed by
Emscripten. This allows threads to run on `wasm32-unknown-emscripten` and the
thread parker to compile without errors related to the missing `futex` module.

To make use of this, Rust code must be compiled with `-C target-feature=atomics`
and Emscripten must link with `-pthread`.

I have confirmed this works well locally when building multithreaded crates.
Attempting to enable `std` thread tests currently fails for seemingly obscure
reasons and Emscripten is currently disabled in CI, so further work is needed to
have proper test coverage here.
2020-11-12 05:52:17 +00:00
J. Ryan Stinnett
bf3be09ee8 Fix timeout conversion 2020-11-12 03:40:15 +00:00
J. Ryan Stinnett
951576051b Update thread and futex APIs to work with Emscripten
This updates the thread and futex APIs in `std` to match the APIs exposed by
Emscripten. This allows threads to run on `wasm32-unknown-emscripten` and the
thread parker to compile without errors related to the missing `futex` module.

To make use of this, Rust code must be compiled with `-C target-feature=atomics`
and Emscripten must link with `-pthread`.

I have confirmed this works well locally when building multithreaded crates.
Attempting to enable `std` thread tests currently fails for seemingly obscure
reasons and Emscripten is currently disabled in CI, so further work is needed to
have proper test coverage here.
2020-11-12 01:41:49 +00:00
Jonas Schievink
56e0806a1a
Rollup merge of #78417 - ssomers:btree_chop_up_2, r=Mark-Simulacrum
BTreeMap: split off most code of append

To complete #78056, move the last single-purpose pieces of code out of map.rs into a separate module. Also, tweaked documentation and safeness - I doubt think this code would be safe if the iterators passed in wouldn't be as sorted as the method says they should be - and bounds on MergeIterInner.

r? ```@Mark-Simulacrum```
2020-11-11 20:59:00 +01:00
Jonas Schievink
62f0a78056
Rollup merge of #78216 - workingjubilee:duration-zero, r=m-ou-se
Duration::zero() -> Duration::ZERO

In review for #72790, whether or not a constant or a function should be favored for `#![feature(duration_zero)]` was seen as an open question. In https://github.com/rust-lang/rust/issues/73544#issuecomment-691701670 an invitation was opened to either stabilize the methods or propose a switch to the constant value, supplemented with reasoning. Followup comments suggested community preference leans towards the const ZERO, which would be reason enough.

ZERO also "makes sense" beside existing associated consts for Duration. It is ever so slightly awkward to have a series of constants specifying 1 of various units but leave 0 as a method, especially when they are side-by-side in code. It seems unintuitive for the one non-dynamic value (that isn't from Default) to be not-a-const, which could hurt discoverability of the associated constants overall. Elsewhere in `std`, methods for obtaining a constant value were even deprecated, as seen with [std::u32::min_value](https://doc.rust-lang.org/std/primitive.u32.html#method.min_value).

Most importantly, ZERO costs less to use. A match supports a const pattern, but const fn can only be used if evaluated through a const context such as an inline `const { const_fn() }` or a `const NAME: T = const_fn()` declaration elsewhere. Likewise, while https://github.com/rust-lang/rust/issues/73544#issuecomment-691949373 notes `Duration::zero()` can optimize to a constant value, "can" is not "will". Only const contexts have a strong promise of such. Even without that in mind, the comment in question still leans in favor of the constant for simplicity. As it costs less for a developer to use, may cost less to optimize, and seems to have more of a community consensus for it, the associated const seems best.

r? ```@LukasKalbertodt```
2020-11-11 20:58:52 +01:00
Nicholas-Baron
261ca04c92 Changed unwrap_or to unwrap_or_else in some places.
The discussion seems to have resolved that this lint is a bit "noisy" in
that applying it in all places would result in a reduction in
readability.

A few of the trivial functions (like `Path::new`) are fine to leave
outside of closures.

The general rule seems to be that anything that is obviously an
allocation (`Box`, `Vec`, `vec![]`) should be in a closure, even if it
is a 0-sized allocation.
2020-11-10 20:07:47 -08:00
Jonas Schievink
42fae6bb65
Rollup merge of #78910 - tmiasko:intrinsics-link, r=jyn514
Fix links to stabilized versions of some intrinsics
2020-11-10 14:45:34 +01:00
Jonas Schievink
354098ccdd
Rollup merge of #78897 - hyd-dev:alloc-error-hook-newline, r=m-ou-se
Add missing newline to error message of the default OOM hook

Currently the default OOM hook in libstd does not end the error message with a newline:
```
memory allocation of 4 bytes failedtimeout: the monitored command dumped core
/playground/tools/entrypoint.sh: line 11:     7 Aborted                 timeout --signal=KILL ${timeout} "$`@"`
```
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=030d8223eb57dfe47ef157709aa26542

This is because the `fmt::Arguments` passed to `dumb_print()` does not end with a newline. All other calls to `dumb_print()` in libstd pass a `\n`-ended `fmt::Arguments` to `dumb_print()`. For example:
25f6938da4/library/std/src/sys_common/util.rs (L18)
I think the `\n` was forgotten in #51264.

This PR appends `\n` to the error string.

~~Note that I didn't add a test, because I didn't find tests for functions in ` library/std/src/alloc.rs` or a test that is similar to the test of this change would be.~~ *Edit: CI told me there is an existing test. Sorry.*
2020-11-10 14:45:28 +01:00
Jonas Schievink
87ecb0afac
Rollup merge of #78896 - cyqsimon:master, r=m-ou-se
Clarified description of write! macro

Reordered the list of arguments in the description to match that in the actual macro.

Suggested and discussed [here](https://discord.com/channels/442252698964721669/443492145567891458/774341262609219624).
2020-11-10 14:45:27 +01:00
Jonas Schievink
e15fee9fe4
Rollup merge of #78854 - the8472:workaround-normalization-regression-master, r=Mark-Simulacrum
Workaround for "could not fully normalize" ICE

Workaround for "could not fully normalize" ICE (#78139) by removing the `needs_drop::<T>()` calls triggering it.
Corresponding beta PR: #78845

Fixes #78139 -- the underlying bug is likely not fixed but we don't have another test case isolated for now, so closing.
2020-11-10 14:45:19 +01:00
Giacomo Stevanato
387568cd56 Added SAFETY comment as request 2020-11-09 22:34:31 +01:00
hyd-dev
70e175b551
Add missing newline to error message of the default OOM hook 2020-11-10 00:15:07 +08:00
cyqsimon
bf982a52f6 Bad grammar 2020-11-09 23:52:33 +08:00
cyqsimon
2633e93aa0 Clarified description of write! macro 2020-11-09 23:00:31 +08:00
Stein Somers
7ca6e8f767 BTreeMap: fix pointer provenance rules, make borrowing explicit 2020-11-09 09:13:50 +01:00
Dylan DPC
a8beaa3b3c
Rollup merge of #78878 - shepmaster:intersecting-ignores, r=Mark-Simulacrum
Avoid overlapping cfg attributes when both macOS and aarch64

r? ``@Mark-Simulacrum``
2020-11-09 01:13:48 +01:00
Dylan DPC
5639d9793f
Rollup merge of #78476 - RalfJung:btree-alias, r=Mark-Simulacrum
fix some incorrect aliasing in the BTree

This line is wrong:
```
ptr::copy(slice.as_ptr().add(idx), slice.as_mut_ptr().add(idx + 1), slice.len() - idx);
```
When `slice.as_mut_ptr()` is called, that creates a mutable reference to the entire slice, which invalidates the raw pointer previously returned by `slice.as_ptr()`. (Miri currently misses this because raw pointers are not tracked properly.)

Cc ````````@ssomers````````
2020-11-09 01:13:40 +01:00
Dylan DPC
4e5b7add7f
Rollup merge of #78437 - ssomers:btree_no_ord_at_node_level, r=Mark-Simulacrum
BTreeMap: stop mistaking node for an orderly place

A second mistake in #77612 was to ignore the node module's rightful comment "this module doesn't care whether the entries are sorted". And there's a much simpler way to visit the keys in order, if you check this separately from a single pass checking everything.

r? ````````@Mark-Simulacrum````````
2020-11-09 01:13:38 +01:00
Dylan DPC
41134be153
Rollup merge of #78026 - sunfishcode:symlink-hard-link, r=dtolnay
Define `fs::hard_link` to not follow symlinks.

POSIX leaves it [implementation-defined] whether `link` follows symlinks.
In practice, for example, on Linux it does not and on FreeBSD it does.
So, switch to `linkat`, so that we can pick a behavior rather than
depending on OS defaults.

Pick the option to not follow symlinks. This is somewhat arbitrary, but
seems the less surprising choice because hard linking is a very
low-level feature which requires the source and destination to be on
the same mounted filesystem, and following a symbolic link could end
up in a different mounted filesystem.

[implementation-defined]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/link.html
2020-11-09 01:13:28 +01:00
Dylan DPC
d69ee57f97
Rollup merge of #77640 - ethanboxx:int_error_matching_attempt_2, r=KodrAus
Refactor IntErrorKind to avoid "underflow" terminology

This PR is a continuation of #76455

# Changes

- `Overflow` renamed to `PosOverflow` and `Underflow` renamed to `NegOverflow` after discussion in #76455
- Changed some of the parsing code to return `InvalidDigit` rather than `Empty` for strings "+" and "-". https://users.rust-lang.org/t/misleading-error-in-str-parse-for-int-types/49178
- Carry the problem `char` with the `InvalidDigit` variant.
- Necessary changes were made to the compiler as it depends on `int_error_matching`.
- Redid tests to match on specific errors.

r? ```@KodrAus```
2020-11-09 01:13:25 +01:00
Tomasz Miąsko
f1739575ef Fix links to stabilized versions of some intrinsics 2020-11-09 00:00:00 +00:00
Stein Somers
685fd53ada BTreeMap: split off most code of append, slightly improve interfaces 2020-11-08 18:58:46 +01:00
Jake Goulding
b13817a795 Avoid overlapping cfg attributes when both macOS and aarch64 2020-11-08 09:43:51 -05:00
Mara Bos
96975e515a
Rollup merge of #78852 - camelid:intra-doc-bonanza, r=jyn514
Convert a bunch of intra-doc links

An intra-doc link bonanza!

This was accomplished using a bunch of trial-and-error with sed.
2020-11-08 13:36:28 +01:00
Mara Bos
77f333b304
Rollup merge of #78811 - a1phyr:const_io_structs, r=dtolnay
Make some std::io functions `const`

Tracking issue: #78812

Make the following functions `const`:
- `io::Cursor::new`
- `io::Cursor::get_ref`
- `io::Cursor::position`
- `io::empty`
- `io::repeat`
- `io::sink`

r? `````@dtolnay`````
2020-11-08 13:36:19 +01:00
Mara Bos
3541280753
Rollup merge of #78788 - jhpratt:isize-impl-fix, r=m-ou-se
Correct unsigned equivalent of isize to be usize

See [#74913 (comment)](https://github.com/rust-lang/rust/issues/74913#issuecomment-722334456) for why this matters. Apparently it hasn't been used anywhere else, though CI will tell for sure.
2020-11-08 13:36:18 +01:00
Mara Bos
2967e58be3
Rollup merge of #78728 - a1phyr:const_cell_into_inner, r=dtolnay
Constantify `UnsafeCell::into_inner` and related

Tracking issue: #78729

This PR constantifies:
- `UnsafeCell::into_inner`
- `Cell::into_inner`
- `RefCell::into_inner`
- `Atomic*::into_inner`

r? `````@dtolnay`````
2020-11-08 13:36:14 +01:00
Mara Bos
eef9951e44
Rollup merge of #78572 - de-vri-es:bsd-cloexec, r=m-ou-se
Use SOCK_CLOEXEC and accept4() on more platforms.

This PR enables the use of `SOCK_CLOEXEC` and `accept4` on more platforms.

-----

Android uses the linux kernel, so it should also support it.

DragonflyBSD introduced them in 4.4 (December 2015):
https://www.dragonflybsd.org/release44/

FreeBSD introduced them in 10.0 (January 2014):
https://wiki.freebsd.org/AtomicCloseOnExec

Illumos introduced them in a commit in April 2013, not sure when it was released. It is quite possible that is has always been in Illumos:
5dbfd19ad5
https://illumos.org/man/3socket/socket
https://illumos.org/man/3socket/accept4

NetBSD introduced them in 6.0 (Oktober 2012) and 8.0 (July 2018):
https://man.netbsd.org/NetBSD-6.0/socket.2
https://man.netbsd.org/NetBSD-8.0/accept.2

OpenBSD introduced them in 5.7 (May 2015):
https://man.openbsd.org/socket https://man.openbsd.org/accept
2020-11-08 13:36:07 +01:00