-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 7 pull requests #90966
Rollup of 7 pull requests #90966
Conversation
Since our musl targets link to a version of musl we build and bundle with the targets, if users need to debug into musl or generate backtraces which contain parts of the musl library, they will be unable to do so unless we enable and ship the debug info. This patch changes our dist builds so they enabled debug info when building musl. This patch also includes a fix for CFI detection in musl's `configure` script which has been posted upstream[1]. The net effect of this is that we now ship debug info for musl in those targets. This adds ~90kb to those artifacts but running `strip` on binaries produced removes all of that. For a "hello world" Rust binary on x86_64, the numbers are: | | debug | release | release + strip | | - | - | - | - | | without musl debuginfo | 507kb | 495kb | 410kb | | with musl debuginfo | 595kb | 584kb | 410kb | Once stripped, the final binaries are the same size (down to the byte). [1]: https://www.openwall.com/lists/musl/2021/10/21/2
This should significantly reduce the frequency of merge conflicts.
…Simulacrum Build musl dist artifacts with debuginfo enabled Since our musl targets link to a version of musl we build and bundle with the targets, if users need to debug into musl or generate backtraces which contain parts of the musl library, they will be unable to do so unless we enable and ship the debug info. This patch changes our dist builds so they enabled debug info when building musl. This patch also includes a fix for CFI detection in musl's `configure` script which has been [posted upstream](https://www.openwall.com/lists/musl/2021/10/21/2). The net effect of this is that we now ship debug info for musl in those targets. This adds ~90kb to those artifacts but running `strip` on binaries produced removes all of that. For a "hello world" Rust binary on x86_64, the numbers are: | | debug | release | release + strip | | - | - | - | - | | without musl debuginfo | 507kb | 495kb | 410kb | | with musl debuginfo | 595kb | 584kb | 410kb | Once stripped, the final binaries are the same size (down to the byte). Fixes rust-lang#90103 r? `@Mark-Simulacrum`
…r=oli-obk Add `#[inline]`s to `SortedIndexMultiMap` They're small enough and good candidates to add `#[inline]` generally.
…=lnicola ⬆️ rust-analyzer r? ``@ghost``
Fix await suggestion on non-future type Remove a match block that would suggest to add `.await` in the case where the expected type's `Future::Output` equals the found type. We only want to suggest `.await`ing in the opposite case (the found type's `Future::Output` equals the expected type). The code sample is here: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6ba6b83d4dddda263553b79dca9f6bcb Before: ``` ➜ ~ rustc --edition=2021 --crate-type=lib test.rs error[E0308]: `match` arms have incompatible types --> test.rs:4:14 | 2 | let x = match 1 { | _____________- 3 | | 1 => other(), | | ------- this is found to be of type `impl Future` 4 | | 2 => other().await, | | ^^^^^^^^^^^^^ expected opaque type, found enum `Result` 5 | | }; | |_____- `match` arms have incompatible types | = note: expected type `impl Future` found enum `Result<(), ()>` help: consider `await`ing on the `Future` | 4 | 2 => other().await.await, | ++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. ``` After: ``` ➜ ~ rustc +stage1 --edition=2021 --crate-type=lib test.rs error[E0308]: `match` arms have incompatible types --> test.rs:4:14 | 2 | let x = match 1 { | _____________- 3 | | 1 => other(), | | ------- this is found to be of type `impl Future` 4 | | 2 => other().await, | | ^^^^^^^^^^^^^ expected opaque type, found enum `Result` 5 | | }; | |_____- `match` arms have incompatible types | = note: expected type `impl Future` found enum `Result<(), ()>` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. ``` Fixes rust-lang#90931
…htriplett Alphabetize language features This should significantly reduce the frequency of merge conflicts. r? ````@joshtriplett```` ````@rustbot```` label: +A-contributor-roadblock +S-waiting-on-review
update miri This is needed to fix https://github.com/rust-lang/miri-test-libstd r? ````@ghost````
…oli-obk Mark `<*const _>::align_offset` and `<*mut _>::align_offset` as `const fn` This PR marks the following APIs as `const`: ```rust impl<T> *const T { pub const fn align_offset(self, align: usize) -> usize; } impl<T> *mut T { pub const fn align_offset(self, align: usize) -> usize; } ``` `const` implementation simply returns `usize::MAX`. --- Previous discussion: rust-lang#90607 (comment) --- r? `@oli-obk`
@bors r+ rollup=never p=7 |
📌 Commit 0c3a662 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (41301c3): comparison url. Summary: This change led to very large relevant improvements 🎉 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Successful merges:
#[inline]
s toSortedIndexMultiMap
#90787 (Add#[inline]
s toSortedIndexMultiMap
)<*const _>::align_offset
and<*mut _>::align_offset
asconst fn
#90958 (Mark<*const _>::align_offset
and<*mut _>::align_offset
asconst fn
)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup