-
Notifications
You must be signed in to change notification settings - Fork 13k
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 5 pull requests #94751
Merged
Merged
Rollup of 5 pull requests #94751
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
Each recursive call was creating an `OsString` for a `&Path`, only for it to be turned into a `CString` right away. Instead we can directly pass `.name_cstr()`, saving two allocations each time.
…bsts, r=petrochenkov Use impl substs in `#[rustc_on_unimplemented]` We were using the trait-ref substs instead of impl substs in `rustc_on_unimplemented`, even when computing the `rustc_on_unimplemented` attached to an impl block. Let's not do that. This PR also untangles impl and trait def-ids in the logic in `on_unimplemented` a bit. Fixes rust-lang#94675
…, r=Mark-Simulacrum Enable `close_read_wakes_up` test on Windows I wonder if we could/should try enabling this again? It was closed by rust-lang#38867 due to rust-lang#31657. I've tried running this test (along with other tests) on my machine a number of times and haven't seen this fail yet, Caveat: the worst that can happen is this succeeds initially but then causes random hangs in CI. This is not a great failure mode and would be a reason not to do this. If this does work out, closes rust-lang#39006 r? `@Mark-Simulacrum`
Add core::hint::must_use The example code in this documentation is minimized from a real-world situation in the `anyhow` crate where this function would have been valuable. Having this provided by the standard library is especially useful for proc macros, even more than for macro_rules. That's because proc macro crates aren't allowed to export anything other than macros, so they couldn't make their own `must_use` function for their macro-generated code to call. <br> ## Rendered documentation > An identity function that causes an `unused_must_use` warning to be triggered if the given value is not used (returned, stored in a variable, etc) by the caller. > > This is primarily intended for use in macro-generated code, in which a [`#[must_use]` attribute][must_use] either on a type or a function would not be convenient. > > [must_use]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-must_use-attribute > > ### Example > > ```rust > #![feature(hint_must_use)] > > use core::fmt; > > pub struct Error(/* ... */); > > #[macro_export] > macro_rules! make_error { > ($($args:expr),*) => { > core::hint::must_use({ > let error = $crate::make_error(core::format_args!($($args),*)); > error > }) > }; > } > > // Implementation detail of make_error! macro. > #[doc(hidden)] > pub fn make_error(args: fmt::Arguments<'_>) -> Error { > Error(/* ... */) > } > > fn demo() -> Option<Error> { > if true { > // Oops, meant to write `return Some(make_error!("..."));` > Some(make_error!("...")); > } > None > } > ``` > > In the above example, we'd like an `unused_must_use` lint to apply to the value created by `make_error!`. However, neither `#[must_use]` on a struct nor `#[must_use]` on a function is appropriate here, so the macro expands using `core::hint::must_use` instead. > > - We wouldn't want `#[must_use]` on the `struct Error` because that would make the following unproblematic code trigger a warning: > > ```rust > fn f(arg: &str) -> Result<(), Error> > > #[test] > fn t() { > // Assert that `f` returns error if passed an empty string. > // A value of type `Error` is unused here but that's not a problem. > f("").unwrap_err(); > } > ``` > > - Using `#[must_use]` on `fn make_error` can't help because the return value *is* used, as the right-hand side of a `let` statement. The `let` statement looks useless but is in fact necessary for ensuring that temporaries within the `format_args` expansion are not kept alive past the creation of the `Error`, as keeping them alive past that point can cause autotrait issues in async code: > > ```rust > async fn f() { > // Using `let` inside the make_error expansion causes temporaries like > // `unsync()` to drop at the semicolon of that `let` statement, which > // is prior to the await point. They would otherwise stay around until > // the semicolon on *this* statement, which is after the await point, > // and the enclosing Future would not implement Send. > log(make_error!("look: {:p}", unsync())).await; > } > > async fn log(error: Error) {/* ... */} > > // Returns something without a Sync impl. > fn unsync() -> *const () { > 0 as *const () > } > ```
unix: Avoid name conversions in `remove_dir_all_recursive` Each recursive call was creating an `OsString` for a `&Path`, only for it to be turned into a `CString` right away. Instead we can directly pass `.name_cstr()`, saving two allocations each time.
…, r=Dylan-DPC Reverted atomic_mut_ptr feature removal causing compilation break Fixes a regression introduced as part of rust-lang#94546 Std no longer compiles on nightly while using the following commnd: export RUSTFLAGS='-C target-feature=+atomics,+bulk-memory' cargo build --target wasm32-unknown-unknown -Z build-std=panic_abort,std I can help add tests to avoid future breaks but i couldn't understand the test framework
rustbot
added
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
rollup
A PR which is a rollup
labels
Mar 8, 2022
@bors r+ rollup=never p=5 |
📌 Commit 5629026 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
Mar 8, 2022
☀️ Test successful - checks-actions |
Finished benchmarking commit (803a759): comparison url. Summary: This benchmark run did not return any relevant results. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
merged-by-bors
This PR was explicitly merged by bors.
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.
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:
#[rustc_on_unimplemented]
#94689 (Use impl substs in#[rustc_on_unimplemented]
)close_read_wakes_up
test on Windows #94714 (Enableclose_read_wakes_up
test on Windows)remove_dir_all_recursive
#94724 (unix: Avoid name conversions inremove_dir_all_recursive
)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup