Skip to content
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 6 pull requests #90967

Closed
wants to merge 17 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

guswynn and others added 17 commits November 8, 2021 14:38
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
@rustbot rustbot added the rollup A PR which is a rollup label Nov 16, 2021
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=6

@bors
Copy link
Contributor

bors commented Nov 16, 2021

📌 Commit 0d7697a has been approved by matthiaskrgr

@bors 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 16, 2021
@bors
Copy link
Contributor

bors commented Nov 17, 2021

⌛ Testing commit 0d7697a with merge 6d666e6a422cb69413a9f6b195f9291d625fd905...

@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
.......... (50/51)
.          (51/51)


An exception occured: connect ECONNREFUSED 127.0.0.1:36721
== STACKTRACE ==
Error
    at innerRunTestCode (/node-v14.4.0-linux-x64/lib/node_modules/browser-ui-test/src/index.js:442:16)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async main (/checkout/src/tools/rustdoc-gui/tester.js:223:13)


command did not execute successfully: "/node-v14.4.0-linux-x64/bin/node" "/checkout/src/tools/rustdoc-gui/tester.js" "--jobs" "16" "--doc-folder" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/rustdoc-gui/doc" "--tests-folder" "/checkout/src/test/rustdoc-gui"


Build completed unsuccessfully in 0:00:27

@bors
Copy link
Contributor

bors commented Nov 17, 2021

💔 Test failed - checks-actions

@bors 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
@matthiaskrgr matthiaskrgr deleted the rollup-6g5ocf7 branch November 20, 2021 15:03
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.