Rollup of 10 pull requests #89572
Merged
Rollup of 10 pull requests #89572
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
This fixes rust-lang#88609. Previously, the return type of `fn main()` would not have any associated type projections within normalized before checking if it implements the standard library trait `std::process::Termination`. This commit appears to fix it. This feels vaguely symptomatic of a problem in the underlying trait solving engine, but I am not sure how I would solve that. I am unsure why the example in rust-lang#88609 with `assert_impl_termination` and `fn foo()` work, but simply `fn main()` doesn't. The way that I solved this is also probably not the best way to do this, so please let me know if there is a better way to do this. I have added a build-pass regression test for this issue.
Use register_predicate_obligations rather than a for loop, since I didn't see that before. Also destructure in the `let` rather than projecting the fields individually
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.
Since the wrapped remainder is going to be 0 for all cases when the rhs is -1, there is no need to divide in this case. Comparing the lhs with MIN is only done for the overflow bool. In particular, this results in better code generation for wrapping remainder, which discards the overflow bool completely.
Normalize associated type projections when checking return type of main This fixes rust-lang#88609. Previously, the return type of `fn main()` would not have any associated type projections within normalized before checking if it implements the standard library trait `std::process::Termination`. This commit appears to fix it. This feels vaguely symptomatic of a problem in the underlying trait solving engine, but I am not sure how I would solve that. I am unsure why the example in rust-lang#88609 with `assert_impl_termination` and `fn foo()` work, but simply `fn main()` doesn't. The way that I solved this is also probably not the best way to do this, so please let me know if there is a better way to do this. I have added a build-pass regression test for this issue.
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).
Fix suggestion for nested struct patterns Fixes rust-lang#88403, and also a similar problem where the unused binding is in a function parameter pattern.
Move generic error message to separate branches This decomposes an error message in generic constants into more specific branches, for better readability. r? ``@lcnr``
for signed wrapping remainder, do not compare lhs with MIN Since the wrapped remainder is going to be 0 for all cases when the rhs is -1, there is no need to compare the lhs with MIN.
…, 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 5f8b161 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (98a5a98): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
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