Rollup of 9 pull requests
Successful merges:
- #92045 (Don't fall back to crate-level opaque type definitions.)
- #92381 (Suggest `return`ing tail expressions in async functions)
- #92768 (Partially stabilize `maybe_uninit_extra`)
- #92810 (Deduplicate box deref and regular deref suggestions)
- #92818 (Update documentation for doc_cfg feature)
- #92840 (Fix some lints documentation)
- #92849 (Clippyup)
- #92854 (Use the updated Rust logo in rustdoc)
- #92864 (Fix a missing dot in the main item heading)
Failed merges:
- #92838 (Clean up some links in RELEASES)
r? `@ghost`
`@rustbot` modify labels: rollup
Deduplicate box deref and regular deref suggestions
Remove the suggestion code special-cased for Box deref.
r? ```@camelid```
since you introduced the code in #90627
Partially stabilize `maybe_uninit_extra`
This covers:
```rust
impl<T> MaybeUninit<T> {
pub unsafe fn assume_init_read(&self) -> T { ... }
pub unsafe fn assume_init_drop(&mut self) { ... }
}
```
It does not cover the const-ness of `write` under `const_maybe_uninit_write` nor the const-ness of `assume_init_read` (this commit adds `const_maybe_uninit_assume_init_read` for that).
FCP: https://github.com/rust-lang/rust/issues/63567#issuecomment-958590287.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Suggest `return`ing tail expressions in async functions
This PR fixes#92308.
Previously, the suggestion to `return` tail expressions (introduced in #81769) did not apply to `async` functions, as the suggestion checked whether the types were equal disregarding `impl Future<Output = T>` syntax sugar for `async` functions. This PR changes that in order to fix a potential papercut.
I'm not sure if this is the "right" way to do this, so if there is a better way then please let me know.
I amended an existing test introduced in #81769 to add a regression test for this, if you think I should make a separate test I will.
Don't fall back to crate-level opaque type definitions.
That would just hide bugs, as it works accidentally if the opaque type is defined at the crate level.
Only works after #90948 which worked by accident for our entire test suite.
Currently all generators are named with a `generator$N` suffix,
regardless of where they come from. This means an `async fn` shows up as
a generator in stack traces, which can be surprising to async
programmers since they should not need to know that async functions are
implementated using generators.
This change generators a different name depending on the generator kind,
allowing us to tell whether the generator is the result of an async
block, an async closure, an async fn, or a plain generator.
`@m-ou-se` [realized][1] that because `Read` is implemented for `&mut impl
Read`, there's no need to take `&mut` in `io::read_to_string`.
Removing the `&mut` from the signature allows users to remove the `&mut`
from their calls (and thus pass an owned reader) if they don't use the
reader later.
[1]: https://github.com/rust-lang/rust/issues/80218#issuecomment-874322129
Closure capture cleanup & refactor
Follow up of #89648
Each commit is self-contained and the rationale/changes are documented in the commit message, so it's advisable to review commit by commit.
The code is significantly cleaner (at least IMO), but that could have some perf implication, so I'd suggest a perf run.
r? `@wesleywiser`
cc `@arora-aman`
Update cargo
6 commits in 358e79fe56fe374649275ca7aebaafd57ade0e8d..06b9d31743210b788b130c8a484c2838afa6fc27
2022-01-04 18:39:45 +0000 to 2022-01-11 23:47:29 +0000
- Port cargo to clap3 (rust-lang/cargo#10265)
- feat: support rustflags per profile (rust-lang/cargo#10217)
- Make bors ignore the PR template so it doesn't end up in merge messages (rust-lang/cargo#10267)
- Be resilient to most IO error and filesystem loop while walking dirs (rust-lang/cargo#10214)
- Remove the option to disable pipelining (rust-lang/cargo#10258)
- Always ask rustc for messages about artifacts, and always process them (rust-lang/cargo#10255)
rustdoc: Preserve rendering of macro_rules matchers when possible
Fixes#92331. This approach restores the behavior prior to #86282 **if** the matcher token held by the compiler **and** the matcher token found in the source code are identical TokenTrees. Thus #86208 remains fixed, but without regressing formatting for the vast majority of macros which are not macro-generated.
