Rollup of 7 pull requests #89560
Closed
Rollup of 7 pull requests #89560
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The reference automatically coerces to a pointer. Writing an explicit cast here is slightly misleading because that's most commonly used when a pointer needs to be converted from one pointer type to another, e.g. `*const c_void` to `*const sigaction` or vice versa.
This decomposes an error message in generic constants into more specific branches, for better readability.
When `cargo report future-incompatibilities` is stabilized (see rust-lang#71249), this will cause dependencies that trigger this lint to be included in the report.
Use `libc::sigaction()` instead of `sys::signal()` to prevent a deadlock Fixes rust-lang#88585. POSIX [specifies](https://man7.org/linux/man-pages/man3/fork.3p.html) that after forking, > to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. Rust's standard library does not currently adhere to this, as evidenced by rust-lang#88585. The child process calls [`sys::signal()`](https://github.com/rust-lang/rust/blob/7bf0736e130e2203c58654f7353dbf9575e49d5c/library/std/src/sys/unix/android.rs#L76), which on Android calls [`libc::dlsym()`](https://github.com/rust-lang/rust/blob/7bf0736e130e2203c58654f7353dbf9575e49d5c/library/std/src/sys/unix/weak.rs#L101), which is [**not**](https://man7.org/linux/man-pages/man7/signal-safety.7.html) async-signal-safe, and in fact causes a deadlock in the example in rust-lang#88585. I think the easiest solution here would be to just call `libc::sigaction()` instead, which [is](https://man7.org/linux/man-pages/man7/signal-safety.7.html) async-signal-safe, provides the functionality we need, and is apparently available on all Android versions because it is also used e.g. [here](https://github.com/rust-lang/rust/blob/7bf0736e130e2203c58654f7353dbf9575e49d5c/library/std/src/sys/unix/stack_overflow.rs#L112-L114).
Move generic error message to separate branches This decomposes an error message in generic constants into more specific branches, for better readability. r? `@lcnr`
…, r=estebank Add check for duplicated doc aliases r? `@estebank`
…lett Fix Lower/UpperExp formatting for integers and precision zero Fixes the integer part of rust-lang#89493 (I daren't touch the floating-point formatting code). The issue is that the "subtracted" precision essentially behaves like extra trailing zeros, but this is not currently reflected in the code properly.
…esleywiser Make `proc_macro_derive_resolution_fallback` a future-breakage lint When `cargo report future-incompatibilities` is stabilized (see rust-lang#71249), this will cause dependencies that trigger this lint to be included in the report.
…um, r=oli-obk,tmiasko Document behavior of `MaybeLiveLocals` regarding enums and field-senstivity This arose from a [discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/MaybeLiveLocals.20and.20Discriminants) where a new contributor attempted to implement a dead-store elimination pass using this analysis. They ran into a nasty hack around `SetDiscriminant` the effect of which is to lets handle assignments of literals to enum-typed locals (e.g. `x = Some(4)`) correctly. This took me a while to figure out. Document this oddity, so the next person will have an easier time, and add a test to enshrine the current behavior. r? `@tmiasko`
…r=petrochenkov Make an initial guess for metadata size to reduce buffer resizes When reading metadata, the compiler starts with a `Vec::new()`, which will need to grow repeatedly as the metadata gets decompressed into it. Reduce the number of resizes by starting out at the size of the compressed data.
|
@bors r+ p=5 |
|
📌 Commit f1dab12 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit f1dab12 with merge 71d38a5aa29a1e6b19483b32f27739b394daa8da... |
|
☀️ Test successful - checks-actions |
|
👀 Test was successful, but fast-forwarding failed: 422 Update is not a fast forward |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
libc::sigaction()instead ofsys::signal()to prevent a deadlock #88828 (Uselibc::sigaction()instead ofsys::signal()to prevent a deadlock)proc_macro_derive_resolution_fallbacka future-breakage lint #89523 (Makeproc_macro_derive_resolution_fallbacka future-breakage lint)MaybeLiveLocalsregarding enums and field-senstivity #89532 (Document behavior ofMaybeLiveLocalsregarding enums and field-senstivity)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup