This is duplicated in a few locations throughout the sysroot to work
around issues with not exporting a macro in libstd but still wanting it
available to sysroot crates to define blocks. Nowadays though we can
simply depend on the `cfg-if` crate on crates.io, allowing us to use it
from there!
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.
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.
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
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
This updates the `Extend` implementations to use `for_each` for many
collections: `BinaryHeap`, `BTreeMap`, `BTreeSet`, `LinkedList`, `Path`,
`TokenStream`, `VecDeque`, and `Wtf8Buf`.
Folding with `for_each` enables better performance than a `for`-loop for
some iterators, especially if they can just forward to internal
iterators, like `Chain` and `FlatMap` do.
wasi: Implement more of the standard library
This commit fills out more of the `wasm32-unknown-wasi` target's standard library, notably the `std::fs` module and all of its internals. A few tweaks were made along the way to non-`fs` modules, but the last commit contains the bulk of the work which is to wire up all APIs to their equivalent on WASI targets instead of unconditionally returning "unsupported". After this some basic filesystem operations and such should all be working in WASI!
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.
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 vectored read and write support
This functionality has lived for a while in the tokio ecosystem, where
it can improve performance by minimizing copies.
r? @alexcrichton
There are two big categories of changes in here
- Removing lifetimes from common traits that can essentially never user a lifetime from an input (particularly `Drop` & `Debug`)
- Forwarding impls that are only possible because the lifetime doesn't matter (like `impl<R: Read + ?Sized> Read for &mut R`)
I omitted things that seemed like they could be more controversial, like the handful of iterators that have a `Item: 'static` despite the iterator having a lifetime or the `PartialEq` implementations where the flipped one cannot elide the lifetime.
This commit switches the standard library to using the `backtrace-sys`
crate from crates.io instead of duplicating the logic here in the Rust
repositor with the `backtrace-sys`'s crate's logic.
Eventually this will hopefully be a good step towards using the
`backtrace` crate directly from crates.io itself, but we're not quite
there yet! Hopefully this is a small incremental first step we can take.
This commit deletes the `alloc_system` crate from the standard
distribution. This unstable crate is no longer needed in the modern
stable global allocator world, but rather its functionality is folded
directly into the standard library. The standard library was already the
only stable location to access this crate, and as a result this should
not affect any stable code.
If the test fails, output the offending addresses and a helpful error message.
Also slightly improve legibility of the preceding line that puts the addresses
into a HashMap.
