Rollup of 7 pull requests #126951
Merged
Rollup of 7 pull requests #126951
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
Account for `for` lifetimes when constructing closure to see if dereferencing the return value would be valid. Fix rust-lang#125634, fix rust-lang#124563.
…nkfelix Mark assoc tys live only if the corresponding trait is live r? ````@pnkfelix````
Deny `use<>` for RPITITs Precise capturing `use<>` syntax is currently a no-op on RPITITs, since GATs have no variance, so all captured lifetimes are captured invariantly. We don't currently *need* to support `use<>` on RPITITs, since `use<>` is initially intended for migrating RPIT *overcaptures* from edition 2021->2024, but since RPITITs currently capture all in-scope lifetimes, we'll never need to write `use<>` on an RPITIT. Eventually, though, it would be desirable to support precise capturing on RPITITs, since RPITITs overcapturing by default can be annoying to some folks. But let's separate that (which will likely require some delicate types team work for adding variances to GATs and adjusting the refinement rules) from the stabilization of the feature for edition 2024. r? oli-obk cc ``@traviscross`` Tracking: - rust-lang#123432
not use offset when there is not ends with brace Fixes rust-lang#126764
Do not ICE when suggesting dereferencing closure arg Account for `for` lifetimes when constructing closure to see if dereferencing the return value would be valid. Fix rust-lang#125634, fix rust-lang#124563.
Eliminate the distinction between PREC_POSTFIX and PREC_PAREN precedence level I have been tangling with precedence as part of porting some pretty-printer improvements from syn back to rustc (related to parenthesization of closures, returns, and breaks by the AST pretty-printer). As far as I have been able to tell, there is no difference between the 2 different precedence levels that rustc identifies as `PREC_POSTFIX` (field access, square bracket index, question mark, method call) and `PREC_PAREN` (loops, if, paths, literals). There are a bunch of places that look at either `prec < PREC_POSTFIX` or `prec >= PREC_POSTFIX`. But there is nothing that needs to distinguish PREC_POSTFIX and PREC_PAREN from one another. https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_ast/src/util/parser.rs#L236-L237 https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs#L2829 https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs#L1290 In the interest of eliminating a distinction without a difference, this PR collapses these 2 levels down to 1. There is exactly 1 case where an expression with PREC_POSTFIX precedence needs to be parenthesized in a location that an expression with PREC_PAREN would not, and that's when the receiver of ExprKind::MethodCall is ExprKind::Field. `x.f()` means a different thing than `(x.f)()`. But this does not justify having separate precedence levels because this special case in the grammar is not governed by precedence. Field access does not have "lower precedence than" method call syntax — you can tell because if it did, then `x.f[0].f()` wouldn't be able to have its unparenthesized field access in the receiver of a method call. Because this Field/MethodCall special case is not governed by precedence, it already requires special handling and is not affected by eliminating the PREC_POSTFIX precedence level. https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_ast_pretty/src/pprust/state/expr.rs#L217-L221
…r-errors Don't suggest awaiting in closure patterns Fixes rust-lang#126903. For ```rust async fn do_async() {} fn main() { Some(do_async()).map(|()| {}); } ``` the error is now ```rust error[E0308]: mismatched types --> src/main.rs:4:27 | 4 | Some(do_async()).map(|()| {}); | ^^ | | | expected future, found `()` | expected due to this | = note: expected opaque type `impl Future<Output = ()>` found unit type `()` ``` Ideally, if `main` were to be `async`, it should be ```rs error[E0308]: mismatched types --> src/main.rs:4:27 | 4 | Some(do_async()).map(|()| {}); | ^^ | | | expected future, found `()` | expected due to this | = note: expected opaque type `impl Future<Output = ()>` found unit type `()` help: consider `await`ing on the `Future` | 4 | Some(do_async().await).map(|()| {}); | ++++++ ``` However, this would mean `FnCtx::check_pat_top` would have to be called with an `origin_expr` in `rustc_hir_typeck::check::check_fn`, and that expr would have to be somehow plumbed through `FnCtxt::check_expr_closure` and closure signature deduction. I'm willing to work on the plumbing but unsure how to start.
De-duplicate all consecutive native libs regardless of their options Address rust-lang#126913 (comment) by no longer de-duplicating based on the "options" but by only looking at the generated link args, as to avoid consecutive libs that originated from different native-lib with different options (like `raw-dylib` on Windows) but isn't relevant for `--print=native-static-libs`. r? ``@petrochenkov``
rustbot
added
A-run-make
|
@bors r+ rollup=never p=7 |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 25, 2024
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#126618 (Mark assoc tys live only if the corresponding trait is live) - rust-lang#126746 (Deny `use<>` for RPITITs) - rust-lang#126868 (not use offset when there is not ends with brace) - rust-lang#126884 (Do not ICE when suggesting dereferencing closure arg) - rust-lang#126893 (Eliminate the distinction between PREC_POSTFIX and PREC_PAREN precedence level) - rust-lang#126915 (Don't suggest awaiting in closure patterns) - rust-lang#126943 (De-duplicate all consecutive native libs regardless of their options) r? `@ghost` `@rustbot` modify labels: rollup
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
@bors retry |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 25, 2024
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#126618 (Mark assoc tys live only if the corresponding trait is live) - rust-lang#126746 (Deny `use<>` for RPITITs) - rust-lang#126868 (not use offset when there is not ends with brace) - rust-lang#126884 (Do not ICE when suggesting dereferencing closure arg) - rust-lang#126893 (Eliminate the distinction between PREC_POSTFIX and PREC_PAREN precedence level) - rust-lang#126915 (Don't suggest awaiting in closure patterns) - rust-lang#126943 (De-duplicate all consecutive native libs regardless of their options) r? `@ghost` `@rustbot` modify labels: rollup
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
Looks like gh networks are being a bit flaky currently, #126955 failed too for something similar |
|
there are already now more than 7 rollup=always PRs. |
|
🤔 and? |
|
@bors retry |
|
@bors retry |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: fda509e817 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (31f8b70): 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 -1.4%)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 (primary -1.7%)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 sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 693.553s -> 693.94s (0.06%) |
@rustbot label: +perf-regression-triaged |
rustbot
added
the
perf-regression-triaged
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:
use<>for RPITITs #126746 (Denyuse<>for RPITITs)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup