std: Depend on `backtrace` crate from crates.io
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.
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.
Add clippy and fix commands to x.py
Since they are kind of similar in nature, I have used the same approach as for `cargo check`. At least some of the boilerplate could probably be shared, but I'd prefer to gather some feedback before I decide to merge them more aggressively.
This works reasonably well for `clippy`; with `-A clippy::all` and some extra `#![feature(rustc_private)]`s almost the whole codebase can be processed. There are some concerns, though:
- unlike `check`, in order to be able to traverse all the crates, some of them need to be marked with the `#![feature(rustc_private)]` attribute
- `-W clippy::all` breaks on any error. Is there a way to produce errors but not have them break the progress?
- I'm not sure how to redirect the errors in a way that would show colors; for now I was able to de-jsonize and print them (something not needed for `check`)
`cargo fix` is much more stubborn; it refuses to acknowledge crates like `core` and `std`, so it doesn't progress much at all.
Since this is a bit more tricky than I have envisioned, I need some guidance:
- is this the right approach or am I doing something very wrong ^^?
- why are the extra `rustc_private` features necessary? I was hoping for the same treatment as `check`
- are changes in `clippy` and `cargo fix` needed e.g. in order to produce errors in the same manner as `check` or did I miss something?
- do we need this level of file granularity (e.g. for futureproofing) or can `check`, `clippy` and `fix` files be condensed?
Hopes-to-fix: https://github.com/rust-lang/rust/issues/53896
Cc @alexcrichton, @zackmdavis
Rollup of 13 pull requests
Successful merges:
- #61026 (Tweak macro parse errors when reaching EOF during macro call parse)
- #61095 (Update cargo)
- #61096 (tidy: don't short-circuit on license error)
- #61107 (Fix a couple docs typos)
- #61110 (Revert edition-guide toolstate override)
- #61111 (Fixed type-alias-bounds lint doc)
- #61113 (Deprecate `FnBox`. `Box<dyn FnOnce()>` can be called directly, since 1.35)
- #61116 (Remove the incorrect warning from README.md)
- #61118 (Dont ICE on an attempt to use GAT without feature gate)
- #61121 (improve debug-printing of scalars)
- #61125 (Updated my mailmap entry)
- #61134 (Annotate each `reverse_bits` with `#[must_use]`)
- #61138 (Move async/await tests to their own folder)
Failed merges:
r? @ghost
Move async/await tests to their own folder
This moves run-pass and ui async/await tests to their own folder `src/test/ui/async-await` and organises some into subfolders. (It does not move rustdoc tests for async/await.)
I also did some drive-by cleaning up of issues/error code tests into their own folders (which already existed). These are in separate commits, so easy to separate out if that's more desirable.
r? @cramertj
Ralf Jung
bors
Alex Crichton
Oliver Scherer
ljedrz
varkor
Eduard-Mihai Burtescu
Mazdak Farrokhzad