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.
Swift has specific syntax that desugars to `Option<T>` similar to our
`?` operator, which means that people might try to use it in Rust. Parse
it and gracefully recover.
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`
