-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 7 pull requests #90975
Closed
Closed
Rollup of 7 pull requests #90975
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 commit tweaks the expansion of `thread_local!` when combined with a `const { ... }` value to help ensure that the rules which apply to `const { ... }` blocks will be the same as when they're stabilized. Previously with this invocation: thread_local!(static NAME: Type = const { init_expr }); this would generate (on supporting platforms): #[thread_local] static NAME: Type = init_expr; instead the macro now expands to: const INIT_EXPR: Type = init_expr; #[thread_local] static NAME: Type = INIT_EXPR; with the hope that because `init_expr` is defined as a `const` item then it's not accidentally allowing more behavior than if it were put into a `static`. For example on the stabilization issue [this example][ex] now gives the same error both ways. [ex]: rust-lang#84223 (comment)
The spans for "trait bound not satisfied" errors in trivial trait bounds referenced the entire item (fn, impl, struct) before. Now they only reference the obligation itself (`String: Copy`) Address rust-lang#90869
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
warn on must_use use on async fn's As referenced in rust-lang#78149 This only works on `async` fn's for now, I can also look into if I can get `Box<dyn Future>` and `impl Future` working at this level (hir)
…shtriplett Add Vec::retain_mut This is to continue the discussion started in rust-lang#83218. Original comment was: > Take 2 of rust-lang#34265, since I needed this today. The reason I think why we should add `retain_mut` is for coherency and for discoverability. For example we have `chunks` and `chunks_mut` or `get` and `get_mut` or `iter` and `iter_mut`, etc. When looking for mutable `retain`, I would expect `retain_mut` to exist. It took me a while to find out about `drain_filter`. So even if it provides an API close to `drain_filter`, just for the discoverability, I think it's worth it. cc `````@m-ou-se````` `````@jonas-schievink````` `````@Mark-Simulacrum`````
std: Tweak expansion of thread-local const This commit tweaks the expansion of `thread_local!` when combined with a `const { ... }` value to help ensure that the rules which apply to `const { ... }` blocks will be the same as when they're stabilized. Previously with this invocation: thread_local!(static NAME: Type = const { init_expr }); this would generate (on supporting platforms): #[thread_local] static NAME: Type = init_expr; instead the macro now expands to: const INIT_EXPR: Type = init_expr; #[thread_local] static NAME: Type = INIT_EXPR; with the hope that because `init_expr` is defined as a `const` item then it's not accidentally allowing more behavior than if it were put into a `static`. For example on the stabilization issue [this example][ex] now gives the same error both ways. [ex]: rust-lang#84223 (comment)
Print escaped string if char literal has multiple characters, but only one printable character Fixes rust-lang#90857 I'm not sure about the error message here, it could get rather long and *maybe* using the names of characters would be better? That wouldn't help the length any, though.
…und, r=estebank Fix span for non-satisfied trivial trait bounds The spans for "trait bound not satisfied" errors in trivial trait bounds referenced the entire item (fn, impl, struct) before. Now they only reference the obligation itself (`String: Copy`) Address rust-lang#90869
Remove workaround for the forward progress handling in LLVM this workaround was only needed for LLVM < 12 and the minimum LLVM version was updated to 12 in rust-lang#90175
…estebank Improve ManuallyDrop suggestion closes rust-lang#90585 * Fixes the recommended change to use ManuallyDrop as per the issue * Changes the note to a help * improves the span so it only points at the type.
@bors r+ rollup=never p=7 |
📌 Commit 7e1cc71 has been approved by |
bors
added
the
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
label
Nov 17, 2021
⌛ Testing commit 7e1cc71 with merge 0dd7a65ed997e377faf4caa59cbe7d3e2477e152... |
💥 Test timed out |
bors
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Nov 17, 2021
@bors retry |
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
Nov 17, 2021
⌛ Testing commit 7e1cc71 with merge c6857ab6ee2fcaf439de4c279a649b7f977d5cb7... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Nov 17, 2021
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-review
Status: Awaiting review from the assignee but also interested parties.
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:
Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup