unify query canonicalization mode
Exclude from canonicalization only the static lifetimes that appear in the param env because of #118965 . Any other occurrence can be canonicalized safely AFAICT.
r? `@lcnr`
Support async recursive calls (as long as they have indirection)
Before #101692, we stored coroutine witness types directly inside of the coroutine. That means that a coroutine could not contain itself (as a witness field) without creating a cycle in the type representation of the coroutine, which we detected with the `OpaqueTypeExpander`, which is used to detect cycles when expanding opaque types after that are inferred to contain themselves.
After `-Zdrop-tracking-mir` was stabilized, we no longer store these generator witness fields directly, but instead behind a def-id based query. That means there is no technical obstacle in the compiler preventing coroutines from containing themselves per se, other than the fact that for a coroutine to have a non-infinite layout, it must contain itself wrapped in a layer of allocation indirection (like a `Box`).
This means that it should be valid for this code to work:
```
async fn async_fibonacci(i: u32) -> u32 {
if i == 0 || i == 1 {
i
} else {
Box::pin(async_fibonacci(i - 1)).await
+ Box::pin(async_fibonacci(i - 2)).await
}
}
```
Whereas previously, you'd need to coerce the future to `Pin<Box<dyn Future<Output = ...>>` before `await`ing it, to prevent the async's desugared coroutine from containing itself across as await point.
This PR does two things:
1. Only report an error if an opaque expansion cycle is detected *not* through coroutine witness fields.
* Instead, if we find an opaque cycle through coroutine witness fields, we compute the layout of the coroutine. If that results in a cycle error, we report it as a recursive async fn.
4. Reworks the way we report layout errors having to do with coroutines, to make up for the diagnostic regressions introduced by (1.). We actually do even better now, pointing out the call sites of the recursion!
Adding alignment to the cases to test for specific error messages.
Adding alignment to the list of cases to test for specific error message. Covers `>`, `^` and `<`.
Pinging people who chimed in last time ( https://github.com/rust-lang/rust/pull/106805 ): ``@estebank`` , ``@compiler-errors`` and ``@Nilstrieb``
mir-opt and custom target fixes
From https://github.com/rust-lang/rust/issues/115642#issuecomment-1879589022
> > Could you please test the last two commits from https://github.com/onur-ozkan/rust/commits/panic-abort-mir-opt when you have the time? The first commit should resolve the error of using the nightly flag with a stable compiler, and the second one should resolve the custom target issue.
> I tested with the two commits and the errors of using nightly flag and custom target specs were not seen.
Testing was completed for the test suites like ui, run-pass-valgrind, coverage, mir-opt, codegen, assembly, incremental.
Fixes#115642
Use `assert_unsafe_precondition` for `char::from_u32_unchecked`
Use `assert_unsafe_precondition` in `char::from_u32_unchecked` so that it can be stabilized as `const`.
Add -Zuse-sync-unwind
Currently Rust uses async unwind by default, but async unwind will bring non-negligible size overhead. it would be nice to allow users to choose this.
In addition, async unwind currently prevents LLVM from generate compact unwind for MachO, if one wishes to generate compact unwind for MachO, then also needs this flag.
internal: VFS no longer stores all source files in memory
Turns out there is no need to keep the files around. We either upload them to salsa once processed, or we need to keep them around for the `DidChangeTextDocumentNotification`, but that notification is only valid for opened documents, so instead we can just keep the files around in the `MemDocs`!
Fixes https://github.com/rust-lang/rust-analyzer/issues/16301
Rewrite Iterator::position default impl
Storing the accumulating value outside the fold in an attempt to improve code generation has shown speedups on various handwritten benchmarks, see discussion at #119551.
