-
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 8 pull requests #114421
Closed
Closed
Rollup of 8 pull requests #114421
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 is necessary for closure captures in 2021 edition, as they capture individual fields, not the full mentioned variables. So it may try to capture a field of an opaque (because the hidden type is known to be something with a field).
@lqd commented on rust-lang#114351 asking if `sort_by_words(lookup)` is computed repeatedly. I was assuming that rustc should have no difficulties to hoist it automatically outside of the loop to avoid repeated pure computation, but according to https://godbolt.org/z/frs8Kj1rq it seems like I was wrong: original version seems to have 2 calls per loop iteration ``` .LBB16_3: mov rbx, qword ptr [r13] mov r14, qword ptr [r13 8] lea rdi, [rsp 40] mov rsi, rbx mov rdx, r14 call example::sort_by_words lea rdi, [rsp 64] mov rsi, qword ptr [rsp 8] mov rdx, qword ptr [rsp 16] call example::sort_by_words mov rdi, qword ptr [rsp 40] mov rdx, qword ptr [rsp 56] mov rsi, qword ptr [rsp 64] cmp rdx, qword ptr [rsp 80] mov qword ptr [rsp 32], rdi mov qword ptr [rsp 24], rsi jne .LBB16_5 call qword ptr [rip bcmp@GOTPCREL] test eax, eax sete al mov dword ptr [rsp 4], eax mov rsi, qword ptr [rsp 72] test rsi, rsi jne .LBB16_8 jmp .LBB16_9 ``` but the manually hoisted version just 1: ``` .LBB16_3: mov r13, qword ptr [r15] mov r14, qword ptr [r15 8] lea rdi, [rsp 64] mov rsi, r13 mov rdx, r14 call example::sort_by_words mov rdi, qword ptr [rsp 64] mov rdx, qword ptr [rsp 16] cmp qword ptr [rsp 80], rdx mov qword ptr [rsp 32], rdi jne .LBB16_5 mov rsi, qword ptr [rsp 8] call qword ptr [rip bcmp@GOTPCREL] test eax, eax sete bpl mov rsi, qword ptr [rsp 72] test rsi, rsi jne .LBB16_8 jmp .LBB16_9 ``` This code is probably not very hot, but there is no reason to leave such a low hanging fruit.
…ck-lint, r=cjgillot Expand, rename and improve `incorrect_fn_null_checks` lint This PR, - firstly, expand the lint by now linting on references - secondly, it renames the lint `incorrect_fn_null_checks` -> `useless_ptr_null_checks` - and thirdly it improves the lint by catching `ptr::from_mut`, `ptr::from_ref`, as well as `<*mut _>::cast` and `<*const _>::cast_mut` Fixes rust-lang#113601 cc ``@est31``
… r=cjgillot Match scrutinee need necessary parentheses for structs Fixes rust-lang#113459
…-2, r=cjgillot Fix wrong span for trait selection failure error reporting Fixes rust-lang#113447
…ction, r=cjgillot Perform OpaqueCast field projection on HIR, too. fixes rust-lang#105819 This is necessary for closure captures in 2021 edition, as they capture individual fields, not the full mentioned variables. So it may try to capture a field of an opaque (because the hidden type is known to be something with a field). See rust-lang#99806 for when and why we added OpaqueCast to MIR.
parser: more friendly hints for handling `async move` in the 2015 edition Fixes rust-lang#114219 An error is emitted when encountering an async move block in the 2015 edition. Another appropriate location to raise an error is after executing [let path = this.parse_path(PathStyle::Expr)?](https://github.com/rust-lang/rust/blob/master/compiler/rustc_parse/src/parser/stmt.rs#L152), but it seems somewhat premature to invoke `create_err` at that stage.
…bank Suggests turbofish in patterns Fixes rust-lang#114112 r? ``@estebank``
[rustc_span][perf] Hoist lookup sorted by words out of the loop. ``@lqd`` commented on rust-lang#114351 asking if `sort_by_words(lookup)` is computed repeatedly. I was assuming that rustc should have no difficulties to hoist it automatically outside of the loop to avoid repeated pure computation, but according to https://godbolt.org/z/frs8Kj1rq it seems like I was wrong: original version seems to have 2 calls per loop iteration ``` .LBB16_3: mov rbx, qword ptr [r13] mov r14, qword ptr [r13 8] lea rdi, [rsp 40] mov rsi, rbx mov rdx, r14 call example::sort_by_words lea rdi, [rsp 64] mov rsi, qword ptr [rsp 8] mov rdx, qword ptr [rsp 16] call example::sort_by_words mov rdi, qword ptr [rsp 40] mov rdx, qword ptr [rsp 56] mov rsi, qword ptr [rsp 64] cmp rdx, qword ptr [rsp 80] mov qword ptr [rsp 32], rdi mov qword ptr [rsp 24], rsi jne .LBB16_5 call qword ptr [rip bcmp@GOTPCREL] test eax, eax sete al mov dword ptr [rsp 4], eax mov rsi, qword ptr [rsp 72] test rsi, rsi jne .LBB16_8 jmp .LBB16_9 ``` but the manually hoisted version just 1: ``` .LBB16_3: mov r13, qword ptr [r15] mov r14, qword ptr [r15 8] lea rdi, [rsp 64] mov rsi, r13 mov rdx, r14 call example::sort_by_words mov rdi, qword ptr [rsp 64] mov rdx, qword ptr [rsp 16] cmp qword ptr [rsp 80], rdx mov qword ptr [rsp 32], rdi jne .LBB16_5 mov rsi, qword ptr [rsp 8] call qword ptr [rip bcmp@GOTPCREL] test eax, eax sete bpl mov rsi, qword ptr [rsp 72] test rsi, rsi jne .LBB16_8 jmp .LBB16_9 ``` This code is probably not very hot, but there is no reason to leave such a low hanging fruit.
fix the span in the suggestion of remove question mark Fixes rust-lang#114392 Use a more precise span.
rustbot
added
the
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
label
Aug 3, 2023
rustbot
added
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
rollup
A PR which is a rollup
labels
Aug 3, 2023
@bors r rollup=never p=8 |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Aug 3, 2023
The job Click to see the possible cause of the failure (guessed by this bot)
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
rollup
A PR which is a rollup
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
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:
incorrect_fn_null_checks
lint #113657 (Expand, rename and improveincorrect_fn_null_checks
lint)async move
in the 2015 edition #114237 (parser: more friendly hints for handlingasync move
in the 2015 edition)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup