Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint
This is an extension to rust-lang/rust#147382.
With this PR `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` considered as must use iif `T` must be used.
For such cases the lint will mention that `T` is wrapped in a `Result`/`ControlFlow` with an uninhabited error/break.
The reasoning here is that `Result<T, Uninhabited>` is equivalent to `T` in which values can be represented and thus the must-used-ness should also be equivalent.
Fixes https://github.com/rust-lang/rust/issues/65861
`BufWriter`: Make the soundness of `BorrowedBuf` usage clearer.
The previous safety comment was outdated as it was written before `BorrowedBuf::set_init` was changed to be a boolean. It also failed to address the possibility that `flush_buf` invalidated the assumption.
fix: Guard SizeSkeleton::compute against stack overflow
Fixesrust-lang/rust#156137
Fix: extract the recursion into a private `compute_inner` that carries a depth counter. When depth exceeds the crate's recursion limit, return `LayoutError::Unknown` and let the existing transmute size-check produce a normal error instead of crashing.
A regression test is included in `tests/ui/transmute/`.
Update example code of `std::array::from_fn`
Since the std::array::from_fn feature has been stabilized since version 1.91.1, the comment stating that it is not stable has been removed.
Additionally, the related example code has been modified into a simple example that is easy to understand.
Closerust-lang/rust#156102
Avoid invalid spans in dotdotdot rest pattern suggestions
Fixesrust-lang/rust#156316
The parser recovers Unicode confusables such as `···` as `...`, while keeping the original source span over the multibyte characters.
`recover_dotdotdot_rest_pat` built its suggestion by subtracting `BytePos(1)` from the end of that recovered token span. For multibyte characters, that can create a span boundary inside a UTF-8, causing diagnostic emission to ICE.
This changes the suggestion to replace the whole recovered token span with `..` instead of slicing off one byte.
fix incorrect suggestions in private import diagnostic
Resolvesrust-lang/rust#156060.
1. In nested imports like `use two::{One, ...}`, the diagnostic suggested replacing the `One` with a multi-segment path of a different module, producing invalid code like `use crate::two::{one::One, Two}`. Skip it when `single_nested == true`.
2. Stop unconditionally skipping the first segment of `import.module_path`, which can produce incorrect paths in edition 2018 and later.
3. Mark the suggestion as "directly" instead of "through the re-export" when the import's source is the definition itself.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#156246 (Introduce a `RerunNonErased` error type mirroring `NoSolution`, to better track when we're bailing)
- rust-lang/rust#156038 (turn `compute_goal_fast_path` into a single match)
- rust-lang/rust#156291 (Treat MSVC "performing full link" message as informational)
- rust-lang/rust#156301 (Avoid ICE when suggesting as_ref for ill-typed closure receivers)
Avoid ICE when suggesting as_ref for ill-typed closure receivers
Fixesrust-lang/rust#156299
When building mismatch suggestions, `can_use_as_ref` may inspect the receiver of a method call that is itself an ill-typed closure expression. In that recovery path, the receiver may not have a recorded type in `TypeckResults`.
Use `expr_ty_opt` instead of `expr_ty` so the optional `as_ref()` suggestion is skipped when the receiver type is unavailable.
Treat MSVC "performing full link" message as informational
When the MSVC incremental linker finds a .ilk file for incremental linking but its associated .exe file is missing, this message is printed to stdout:
```text
LINK : ...\foo.exe not found or not build by the last incremental link; performing full link
```
However, if both the .ilk and .exe files are missing (for a clean build), the message isn't printed and it still does a full link. So, the presence of the message doesn't affect the result of the build.
See rust-lang/rust#156209 for further context.
r? @mati865
cc @jyn514