https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=perf-tmp 2025-10-03T15:02:37+00:00 2025-10-03T15:02:37+00:00 bors bors@rust-lang.org 2025-10-03T15:02:37+00:00 urn:sha1:f437c86ef829e43c6aa27641f53040a999a092af Fix backtraces with `-C panic=abort` on linux; emit unwind tables by default The linux backtrace unwinder relies on unwind tables to work properly, and generating and printing a backtrace is done by for example the default panic hook. Begin emitting unwind tables by default again with `-C panic=abort` (see history below) so that backtraces work. Closes https://github.com/rust-lang/rust/issues/81902 which is **regression-from-stable-to-stable** Closes https://github.com/rust-lang/rust/issues/94815 ### History Backtraces with `-C panic=abort` used to work in Rust 1.22 but broke in Rust 1.23, because in 1.23 we stopped emitting unwind tables with `-C panic=abort` (see https://github.com/rust-lang/rust/pull/45031 and https://github.com/rust-lang/rust/issues/81902#issuecomment-3046487084). In 1.45 a workaround in the form of `-C force-unwind-tables=yes` was added (see https://github.com/rust-lang/rust/pull/69984). `-C panic=abort` was added in [Rust 1.10](https://blog.rust-lang.org/2016/07/07/Rust-1.10/#what-s-in-1-10-stable) and the motivation was binary size and compile time. But given how confusing that behavior has turned out to be, it is better to make binary size optimization opt-in with `-C force-unwind-tables=no` rather than default since the current default breaks backtraces. Besides, if binary size is a primary concern, there are many other tricks that can be used that has a higher impact. # Release Note Entry Draft: ## Compatibility Notes * [Fix backtraces with `-C panic=abort` on Linux by generating unwind tables by default](https://github.com/rust-lang/rust/pull/143613). Build with `-C force-unwind-tables=no` to keep omitting unwind tables. try-job: aarch64-apple try-job: armhf-gnu try-job: aarch64-msvc-1 2025-10-02T17:46:41+00:00 Martin Nordholts martin.nordholts@codetale.se 2025-07-07T20:36:23+00:00 urn:sha1:fe66eaa67acc47525db6f13cf97d54780d87b805 The linux backtrace unwinder relies on unwind tables to work properly, and generating and printing a backtrace is done by for example the default panic hook. Begin emitting unwind tables by default again with `-C panic=abort` (see history below) so that backtraces work. History ======= Backtraces with `-C panic=abort` used to work in Rust 1.22 but broke in Rust 1.23, because in 1.23 we stopped emitting unwind tables with `-C panic=abort` (see 24cc38e3b00). In 1.45 (see cda994633ee) a workaround in the form of `-C force-unwind-tables=yes` was added. `-C panic=abort` was added in [Rust 1.10](https://blog.rust-lang.org/2016/07/07/Rust-1.10/#what-s-in-1-10-stable) and the motivation was binary size and compile time. But given how confusing that behavior has turned out to be, it is better to make binary size optimization opt-in with `-C force-unwind-tables=no` rather than default since the current default breaks backtraces. Besides, if binary size is a primary concern, there are many other tricks that can be used that has a higher impact. 2025-10-01T15:43:53+00:00 daxpedda daxpedda@gmail.com 2025-10-01T15:43:53+00:00 urn:sha1:3e8ce2bda9e9563c546287b4715fcde61d008d3e 2025-09-30T19:53:33+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-09-30T19:53:33+00:00 urn:sha1:0d78b1e65798f3ea684e3b056af35e5c6ffb0643 Improve the documentation around `ZERO_AR_DATE` In particular, document why we don't use the new `-reproducible` flag. I went through [the source for Apple's old linker](https://github.com/apple-oss-distributions/ld64), and compared the versions with [the mapping to Xcode versions on Wikipedia](https://en.wikipedia.org/wiki/Xcode) to find the relevant Xcode versions for these features. r? compiler 2025-09-29T05:44:55+00:00 Stuart Cook Zalathar@users.noreply.github.com 2025-09-29T05:44:55+00:00 urn:sha1:cd6f32a4eb6b53e7df0882bc396c1c36cf4736ca remove explicit deref of AbiAlign for most methods Much of the compiler calls functions on Align projected from AbiAlign. AbiAlign impls Deref to its inner Align, so we can simplify these away. Also, it will minimize disruption when AbiAlign is removed. For now, preserve usages that might resolve to PartialOrd or PartialEq, as those have odd inference. 2025-09-28T22:02:14+00:00 Jubilee Young workingjubilee@gmail.com 2025-09-28T21:40:39+00:00 urn:sha1:0c9d0dfe046f0674f0507df564504ac3bac862d9 Much of the compiler calls functions on Align projected from AbiAlign. AbiAlign impls Deref to its inner Align, so we can simplify these away. Also, it will minimize disruption when AbiAlign is removed. For now, preserve usages that might resolve to PartialOrd or PartialEq, as those have odd inference. 2025-09-28T05:13:53+00:00 Jubilee Young workingjubilee@gmail.com 2025-09-28T03:00:54+00:00 urn:sha1:b3f3e36c72952736be5b9e0360ee5b86148f2c29 This maintains AbiAlign usage in public API and most of the compiler, but direct access of these fields is now in terms of Align only. 2025-09-26T16:11:10+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-09-26T16:11:10+00:00 urn:sha1:ebe90c7ae722a1139c78fc9b1ff9118028051da8 Stop linking rs{begin,end} objects on x86_64-*-windows-gnu Until now, x86_64-pc-windows-gnu linked `rsbegin.o` and `rsend.o` just like i686-pc-windows-gnu, even though they were no-ops for it. This was likely done for the simplicity back when it was introduced. Today the things are different and these startup/end objects harm other features, like `build-std`. Given the demotion of i686-pc-windows-gnu from tier 1, there is no point in hurting x86_64-pc-windows-gnu, which remains a tier 1. The files are still shipped in case downstream crates expect them, as in case of the unmaintained `xargo`. Fixes https://github.com/rust-lang/rust/issues/146739 2025-09-26T16:11:09+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-09-26T16:11:09+00:00 urn:sha1:024fbad4a076406e45e4db78c07ac39095ca6a67 Demote both armebv7r-none-* targets. OK, slightly more controversial than https://github.com/rust-lang/rust/pull/146520 and https://github.com/rust-lang/rust/pull/146522 - I'd like to drop the bare-metal **big-endian** Armv7-R targets down to Tier 3. The reason is simple - we cannot test them in https://github.com/rust-embedded/cortex-ar/. This because QEMU support for Big Endian Armv7-R is broken. I tried quite hard, but all the strings I printed with semihosting came out byte swapped (or "etybawa depp") because of how QEMU kludges the access to memory in big-endian mode. The target also has only a single maintainer. Although, if ````@chrisnc```` wants to put up a case for keeping it at Tier 2 though, I'm happy to hear it! This PR wil be rebased once https://github.com/rust-lang/rust/pull/146419 completes the queue. 2025-09-25T10:31:53+00:00 Stuart Cook Zalathar@users.noreply.github.com 2025-09-25T10:31:53+00:00 urn:sha1:0a34928ad840f9d66d673a8cb6cf293e83efb987 Add `std` support for `armv7a-vex-v5` This PR adds standard library support for the VEX V5 Brain (`armv7a-vex-v5` target). It is more-or-less an updated version of the library-side work done in rust-lang/rust#131530. This was a joint effort between me, `@lewisfm,` `@max-niederman,` `@Gavin-Niederman` and several other members of the [`vexide` project](https://github.com/vexide/). ## Background VEXos is a fairly unconventional operating system, with user code running in a restricted enviornment with regards to I/O capabilities and whatnot. As such, several OS-dependent APIs are unsupported or have partial support (such as `std::net`, `std::process`, and most of `std::thread`). A more comprehensive list of what does or doesn't work is outlined in the [updated target documentation](https://github.com/vexide/rust/blob/vex-std/src/doc/rustc/src/platform-support/armv7a-vex-v5.md). Despite these limitations, we believe that `libstd` support on this target still has value to users, especially given the popular use of this hardware for educational purposes. For some previous discussion on this matter, see [this comment](https://github.com/rust-lang/rust/pull/131530#issuecomment-2432856841). ## SDK Linkage VEXos doesn't really ship with an official `libc` or POSIX-style platform API (and though it does port newlib, these are stubbed on top of the underlying SDK). Instead, VEX provides their own SDK for calling platform APIs. Their official SDK is kept proprietary (with public headers), though open-source implementations exist. Following the precedent of the `armv6k-nintendo-3ds` team's work in rust-lang/rust#95897, we've opted not to directly link `libstd` to any SDK with the expectation that users will provide their own with one of the following options: - [`vex-sdk-download`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-download), which downloads an official proprietary SDK from VEX using a build script. - [`vex-sdk-jumptable`](https://crates.io/crates/vex-sdk-jumptable), which is a compatible, open-source reimplementation of the SDK using firmware jumps. - [`vex-sdk-pros`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-pros), which uses the [PROS kernel](https://github.com/purduesigbots/pros) as a provider for SDK functions. - Linking their own implementation or stubbing the functions required by libstd. The `vex-sdk` crate used in the VEXos PAL provides `libc`-style FFI bindings for any compatible system library, so any of these options *should* work fine. A functional demo project using `vex-sdk-download` can be found [here](https://github.com/vexide/armv7a-vex-v5-demo/tree/main). ## Future Work This PR implements virtually everything we are currently able to implement given the current capabilities of the platform. The exception to this is file directory enumeration, though the implementation of that is sufficiently [gross enough](https://github.com/vexide/vexide/blob/c6c5bad11e035cf4e51d429dca7e427210185ed4/packages/vexide-core/src/fs/mod.rs#L987) to drive us away from supporting this officially. Additionally, I have a working branch implementing the `panic_unwind` runtime for this target, which is something that would be nice to see in the future, though given the volume of compiler changes i've deemed it out-of-scope for this PR.