| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
For `libc` types that will be initialized in FFI calls, we can just use
`MaybeUninit` and then pass around raw pointers.
For `sun_path_offset()`, which really wants `offset_of`, all callers
have a real `sockaddr_un` available, so we can use that reference.
|
|
macos tlv workaround
fixes: #60141
Includes:
* remove dead code: `requires_move_before_drop`. This hasn't been needed for a while now (oops I should have removed it in #57655)
* redox had a copy of `fast::Key` (not sure why?). That has been removed.
* Perform a `read_volatile` on OSX to reduce `tlv_get_addr` calls per `__getit` from (4-2 depending on context) to 1.
`tlv_get_addr` is relatively expensive (~1.5ns on my machine).
Previously, in contexts where `__getit` was inlined, 4 calls to `tlv_get_addr` were performed per lookup. For some reason when `__getit` is not inlined this is reduced to 2x - and performance improves to match.
After this PR, I have only ever seen 1x call to `tlv_get_addr` per `__getit`, and macos now benefits from situations where `__getit` is inlined.
I'm not sure if the `read_volatile(&&__KEY)` trick is working around an LLVM bug, or a rustc bug, or neither.
r? @alexcrichton
|
|
Print PermissionExt::mode() in octal in Documentation Examples
Printing the file permission mode on unix systems in decimal feels unintuitive. Printing it in octal gives the expected form of e.g. `664`.
|
|
|
|
This commit removes all in-tree support for generating backtraces in
favor of depending on the `backtrace` crate on crates.io. This resolves
a very longstanding piece of duplication where the standard library has
long contained the ability to generate a backtrace on panics, but the
code was later extracted and duplicated on crates.io with the
`backtrace` crate. Since that fork each implementation has seen various
improvements one way or another, but typically `backtrace`-the-crate has
lagged behind libstd in one way or another.
The goal here is to remove this duplication of a fairly critical piece
of code and ensure that there's only one source of truth for generating
backtraces between the standard library and the crate on crates.io.
Recently I've been working to bring the `backtrace` crate on crates.io
up to speed with the support in the standard library which includes:
* Support for `StackWalkEx` on MSVC to recover inline frames with
debuginfo.
* Using `libbacktrace` by default on MinGW targets.
* Supporting `libbacktrace` on OSX as an option.
* Ensuring all the requisite support in `backtrace`-the-crate compiles
with `#![no_std]`.
* Updating the `libbacktrace` implementation in `backtrace`-the-crate to
initialize the global state with the correct filename where necessary.
After reviewing the code in libstd the `backtrace` crate should be at
exact feature parity with libstd today. The backtraces generated should
have the same symbols and same number of frames in general, and there's
not known divergence from libstd currently.
Note that one major difference between libstd's backtrace support and
the `backtrace` crate is that on OSX the crates.io crate enables the
`coresymbolication` feature by default. This feature, however, uses
private internal APIs that aren't published for OSX. While they provide
more accurate backtraces this isn't appropriate for libstd distributed
as a binary, so libstd's dependency on the `backtrace` crate explicitly
disables this feature and forces OSX to use `libbacktrace` as a
symbolication strategy.
The long-term goal of this refactoring is to eventually move us towards
a world where we can drop `libbacktrace` entirely and simply use Gimli
and the surrounding crates for backtrace support. That's still aways off
but hopefully will much more easily enabled by having the source of
truth for backtraces live in crates.io!
Procedurally if we go forward with this I'd like to transfer the
`backtrace-rs` crate to the rust-lang GitHub organization as well, but I
figured I'd hold off on that until we get closer to merging.
|
|
DoubleEndedIterators."
This reverts commit 3e86cf36b5114f201868bf459934fe346a76a2d4.
|
|
convert custom try macro to `?`
resolves #60580
r? @frewsxcv
|
|
Fall back to `/dev/urandom` on `EPERM` for `getrandom`
This can happen because of seccomp or some VMs.
Fixes #52609.
|
|
This reverts commit d252f3b77f3b7d4cd59620588f9d026633c05816.
|
|
|
|
|
|
Remove bitrig support from rust
Resolves #60743
using `find` and `rg` I delete every occurence of "bitrig" in the sources, expect for the llvm submodule (is this correct?).
There's also this file https://github.com/rust-lang/rls/blob/5b8e99bb61958ca8abcb7c5eda70521726be1065/rls-analysis/test_data/rust-analysis/libstd-af9bacceee784405.json which contains a bitrig string in it. What to do with that?
|
|
fix Miri
This reverts https://github.com/rust-lang/rust/pull/60156, which turned out to be a dead end (see https://github.com/rust-lang/rust/pull/60469).
r? @oli-obk
|
|
Add implementations of last in terms of next_back on a bunch of DoubleEndedIterators
Provided a `DoubleEndedIterator` has finite length, `Iterator::last` is equivalent to `DoubleEndedIterator::next_back`. But searching forwards through the iterator when it's unnecessary is obviously not good for performance. I ran into this on one of the collection iterators.
I tried adding appropriate overloads for a bunch of the iterator adapters like filter, map, etc, but I ran into a lot of type inference failures after doing so.
The other interesting case is what to do with `Repeat`. Do we consider it part of the contract that `Iterator::last` will loop forever on it? The docs do say that the iterator will be evaluated until it returns None. This is also relevant for the adapters, it's trivially easy to observe whether a `Map` adapter invoked its closure a zillion times or just once for the last element.
|
|
This reverts commit 54aefc6a2d076b74921a8d78c5d8c68c13bfa4a7.
|
|
|
|
|
|
resolves #60580
|
|
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.
|
|
|
|
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
|
|
This can happen because of seccomp or some VMs.
Fixes #52609.
|
|
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
|
|
|
|
DoubleEndedIterators.
r?Manishearth
|
|
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
|
|
|
|
std: Add `{read,write}_vectored` for more types
This commit implements the `{read,write}_vectored` methods on more types
in the standard library, namely:
* `std::fs::File`
* `std::process::ChildStd{in,out,err}`
* `std::io::Std{in,out,err}`
* `std::io::Std{in,out,err}Lock`
* `std::io::Std{in,out,err}Raw`
Where supported the OS implementations hook up to native support,
otherwise it falls back to the already-defaulted implementation.
|
|
This commit implements the `{read,write}_vectored` methods on more types
in the standard library, namely:
* `std::fs::File`
* `std::process::ChildStd{in,out,err}`
* `std::io::Std{in,out,err}`
* `std::io::Std{in,out,err}Lock`
* `std::io::Std{in,out,err}Raw`
Where supported the OS implementations hook up to native support,
otherwise it falls back to the already-defaulted implementation.
|
|
|
|
std: Avoid usage of `Once` in `Instant`
This commit removes usage of `Once` from the internal implementation of
time utilities on OSX and Windows. It turns out that we accidentally hit
a deadlock today (#59020) via events that look like:
* A thread invokes `park_timeout`
* Internally, only on OSX, `park_timeout` calls `Instant::elapsed`
* Inside of `Instant::elapsed` on OSX we enter a `Once` to initialize
global timer data
* Inside of `Once`, it attempts to `park`
This means on the same stack frame, when there's contention, we're
calling `park` from inside `park_timeout`, causing a deadlock!
The solution implemented in this commit was to remove usage of `Once`
and instead just do a small dance with atomics. There's no real need we
need to guarantee that the global information is only learned once, only
that it's only *stored* once. This implementation may have multiple
threads invoke `mach_timebase_info`, but only one will store the global
information which will amortize the cost for all other threads.
A similar fix has been applied to windows to be uniform across our
implementations, but looking at the code on Windows no deadlock was
possible. This is purely just a consistency update for Windows and in
theory a slightly leaner implementation.
Closes #59020
|
|
This commit removes usage of `Once` from the internal implementation of
time utilities on OSX and Windows. It turns out that we accidentally hit
a deadlock today (#59020) via events that look like:
* A thread invokes `park_timeout`
* Internally, only on OSX, `park_timeout` calls `Instant::elapsed`
* Inside of `Instant::elapsed` on OSX we enter a `Once` to initialize
global timer data
* Inside of `Once`, it attempts to `park`
This means on the same stack frame, when there's contention, we're
calling `park` from inside `park_timeout`, causing a deadlock!
The solution implemented in this commit was to remove usage of `Once`
and instead just do a small dance with atomics. There's no real need we
need to guarantee that the global information is only learned once, only
that it's only *stored* once. This implementation may have multiple
threads invoke `mach_timebase_info`, but only one will store the global
information which will amortize the cost for all other threads.
A similar fix has been applied to windows to be uniform across our
implementations, but looking at the code on Windows no deadlock was
possible. This is purely just a consistency update for Windows and in
theory a slightly leaner implementation.
Closes #59020
|
|
This commit fills out the `std::fs` module and implementation for WASI.
Not all APIs are implemented, such as permissions-related ones and
`canonicalize`, but all others APIs have been implemented and very
lightly tested so far. We'll eventually want to run a more exhaustive
test suite!
For now the highlights of this commit are:
* The `std::fs::File` type is now backed by `WasiFd`, a raw WASI file
descriptor.
* All APIs in `std::fs` (except permissions/canonicalize) have
implementations for the WASI target.
* A suite of unstable extension traits were added to
`std::os::wasi::fs`. These traits expose the raw filesystem
functionality of WASI, namely `*at` syscalls (opening a file relative
to an already opened one, for example). Additionally metadata only
available on wasi is exposed through these traits.
Perhaps one of the most notable parts is the implementation of
path-taking APIs. WASI actually has no fundamental API that just takes a
path, but rather everything is relative to a previously opened file
descriptor. To allow existing APIs to work (that only take a path) WASI
has a few syscalls to learn about "pre opened" file descriptors by the
runtime. We use these to build a map of existing directory names to file
descriptors, and then when using a path we try to anchor it at an
already-opened file.
This support is very rudimentary though and is intended to be shared
with C since it's likely to be so tricky. For now though the C library
doesn't expose quite an API for us to use, so we implement it for now
and will swap it out as soon as one is available.
|
|
|
|
|
|
fs::copy() unix: set file mode early
A convenience method like fs::copy() should try to prevent pitfalls a
normal user doesn't think about.
In case of an empty umask, setting the file mode early prevents
temporarily world readable or even writeable files,
because the default mode is 0o666.
In case the target is a named pipe or special device node, setting the
file mode can lead to unwanted side effects, like setting permissons on
`/dev/stdout` or for root setting permissions on `/dev/null`.
copy_file_range() returns EINVAL, if the destination is a FIFO/pipe or
a device like "/dev/null", so fallback to io::copy, too.
Fixes: https://github.com/rust-lang/rust/issues/26933
Fixed: https://github.com/rust-lang/rust/issues/37885
|
|
Simplify checked_duration_since
This follows the same design as we updated to in #56490. Internally, all the system specific time implementations are checked, no panics. Then the panicking publicly exported API can just call the checked version of itself and make do with a single panic (`expect`) at the top.
Since the internal sys implementations are now checked, this gets rid of the extra `if self >= &earlier` check in `checked_duration_since`. Except likely making the generated machine code simpler, it also reduces the algorithm from "Check panic condition -> call possibly panicking method" to just "call non panicking method".
Added two test cases:
* Edge case: Make sure `checked_duration_since` on two equal `Instant`s produce a zero duration, not a `None`.
* Most common/intended usage: Make sure `later.checked_duration_since(earlier)`, returns an expected value.
|
|
A convenience method like fs::copy() should try to prevent pitfalls a
normal user doesn't think about.
In case of an empty umask, setting the file mode early prevents
temporarily world readable or even writeable files,
because the default mode is 0o666.
In case the target is a named pipe or special device node, setting the
file mode can lead to unwanted side effects, like setting permissons on
`/dev/stdout` or for root setting permissions on `/dev/null`.
copy_file_range() returns EINVAL, if the destination is a FIFO/pipe or
a device like "/dev/null", so fallback to io::copy, too.
Use `fcopyfile` on MacOS instead of `copyfile`.
Fixes: https://github.com/rust-lang/rust/issues/26933
Fixed: https://github.com/rust-lang/rust/issues/37885
|
|
|
|
Rollup of 18 pull requests
Successful merges:
- #59106 (Add peer_addr function to UdpSocket)
- #59170 (Add const generics to rustdoc)
- #59172 (Update and clean up several parts of CONTRIBUTING.md)
- #59190 (consistent naming for Rhs type parameter in libcore/ops)
- #59236 (Rename miri component to miri-preview)
- #59266 (Do not complain about non-existing fields after parse recovery)
- #59273 (some small HIR doc improvements)
- #59291 (Make Option<ThreadId> no larger than ThreadId, with NonZeroU64)
- #59297 (convert field/method confusion help to suggestions)
- #59304 (Move some bench tests back from libtest)
- #59309 (Add messages for different verbosity levels. Output copy actions.)
- #59321 (Unify E0109, E0110 and E0111)
- #59322 (Tweak incorrect escaped char diagnostic)
- #59323 (use suggestions for "enum instead of variant" error)
- #59327 (Add NAN test to docs)
- #59329 (cleanup: Remove compile-fail-fulldeps directory again)
- #59347 (Move one test from run-make-fulldeps to ui)
- #59360 (Add tracking issue number for `seek_convenience`)
Failed merges:
r? @ghost
|
|
Add peer_addr function to UdpSocket
Fixes #59104
This is my first pull request to Rust, so opening early for some feedback.
My biggest question is: where do I add tests?
Any comments very much appreciated!
|
|
Unify OsString/OsStr for byte-based implementations
As requested in #57860
r? @joshtriplett
|
|
|
|
dragonflybsd still uses c_char [2]
[1] https://svnweb.freebsd.org/base/releng/11.2/sys/sys/signal.h?revision=334459&view=markup#l438
[2] https://github.com/DragonFlyBSD/DragonFlyBSD/blob/master/sys/sys/signal.h#L339
|
|
|
|
Change `std::fs::copy` to use `copyfile` on MacOS and iOS
`copyfile` on MacOS is similar to `CopyFileEx` on Windows. It supports copying resource forks, extended attributes, and file ACLs, none of which are copied by the current generic unix implementation.
The API is available from MacOS 10.7 and iOS 4.3 (and possibly earlier but I haven't checked).
Closes #58895.
|
|
|
|
|
|
|
