-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Rollup of 6 pull requests #128469
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Rollup of 6 pull requests #128469
Conversation
std: implement the `once_wait` feature Tracking issue: rust-lang#127527 This additionally adds a `wait_force` method to `Once` that doesn't panic on poison. I also took the opportunity and cleaned up up the code of the queue-based implementation a bit.
Cleanup sys module to match house style This moves a test file out of sys as it's just testing std types. Also cleans up some assorted bits including making the `use` statements match the house style.
Update target-spec metadata for loongarch64 targets
… r=fmease Properly mark loop as diverging if it has no breaks Due to specifics about the desugaring of the `.await` operator, HIR typeck doesn't recognize that `.await`ing an `impl Future<Output = !>` will diverge in the same way as calling a `fn() -> !`. This is because the await operator desugars to approximately: ```rust loop { match future.poll(...) { Poll::Ready(x) => break x, Poll::Pending => {} } } ``` We know that the value of `x` is `!`, however since `break` is a coercion site, we coerce `!` to some `?0` (the type of the loop expression). Then since the type of the `loop {...}` expression is `?0`, we will not detect the loop as diverging like we do with other expressions that evaluate to `!`: https://github.com/rust-lang/rust/blob/0b5eb7ba7bd796fb39c8bb6acd9ef6c140f28b65/compiler/rustc_hir_typeck/src/expr.rs#L240-L243 We can technically fix this in two ways: 1. Make coercion of loop exprs more eagerly result in a type of `!` when the only break expressions have type `!`. 2. Make loops understand that all of that if they have only diverging break values, then the loop diverges as well. (1.) likely has negative effects on inference, and seems like a weird special case to drill into coercion. However, it turns out that (2.) is very easy to implement, we already record whether a loop has any break expressions, and when we do so, we actually skip over any break expressions with diverging values!: https://github.com/rust-lang/rust/blob/0b5eb7ba7bd796fb39c8bb6acd9ef6c140f28b65/compiler/rustc_hir_typeck/src/expr.rs#L713-L716 Thus, we can consider the loop as diverging if we see that it has no breaks, which is the change implemented in this PR. This is not usually a problem in regular code for two reasons: 1. In regular code, we already mark `break diverging()` as unreachable if `diverging()` is unreachable. We don't do this for `.await`, since we suppress unreachable errors within `.await` (rust-lang#64930). Un-suppressing this code will result in spurious unreachable expression errors pointing to internal await machinery. 3. In loops that truly have no breaks (e.g. `loop {}`), we already evaluate the type of the loop to `!`, so this special case is kinda moot. This only affects loops that have `break`s with values of type `!`. Thus, this seems like a change that may affect more code than just `.await`, but it likely does not in meaningful ways; if it does, it's certainly correct to apply. Fixes rust-lang#128434
… r=compiler-errors Temporarily switch `ambiguous_negative_literals` lint to allow This PR temporarily switch the `ambiguous_negative_literals` lint to `allow-by-default`, as asked by T-lang in rust-lang#128287 (comment).
…-maybe-sized, r=compiler-errors derive(SmartPointer): require pointee to be maybe sized cc ``@Darksonn`` So `#[pointee]` has to be `?Sized` in order for deriving `SmartPointer` to be meaningful. cc ``@compiler-errors`` for suggestions in rust-lang#127681
@bors r+ rollup=never p=6 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 28a58f2fa7 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (71b2116): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (primary 6.3%, secondary 3.1%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary 6.1%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResults (primary -0.1%, secondary 0.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 757.595s -> 758.318s (0.10%) |
Successful merges:
once_wait
feature #127567 (std: implement theonce_wait
feature)ambiguous_negative_literals
lint to allow #128449 (Temporarily switchambiguous_negative_literals
lint to allow)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup