check coroutines with `TypingMode::Borrowck` to avoid cyclic reasoning
MIR borrowck taints its output if an obligation fails. This could then cause `check_coroutine_obligations` to silence its error, causing us to not emit and actual error and ICE.
Fixes the ICE in https://github.com/rust-lang/trait-system-refactor-initiative/issues/199. It is unfortunately still a regression.
r? compiler-errors
MIR borrowck taints its output if an obligation fails. This could then cause
`check_coroutine_obligations` to silence its error, causing us to not emit
and actual error and ICE.
Do not emit help when shorthand from macro when suggest `?` or `expect`
Fixes#140659
I didn't fully minimize the original bug, but I found a similar test case, and they have perhaps the same root cause. For the bug mentioned in #140659 , I also tested it locally and passed it.
Jieyou has worked on this part before, maybe r? `@jieyouxu`
Async drop fix for dropee from another crate (#140858)
Fixes https://github.com/rust-lang/rust/issues/140858.
For `AsyncDestructor` impl def id was wrongly kept as a LocalDefId, which causes crash when dropee is declared in another crate.
Also, potential problem found:
when user crate drops type with async drop in dependency crate, and user crate doesn't enable `feature(async_drop)`, then sync drop version will be used.
Is it a problem? Do we need some notification about such situations?
Make well-formedness predicates no longer coinductive
This PR makes well-formedness no longer coinductive. It was made coinductive in https://github.com/rust-lang/rust/pull/98542, but AFAICT this was only to fix UI tests since we stopped lowering `where Ty:` to an empty-region outlives predicate but to a WF predicate instead.
Arguably it should lower to something completely different, something like a "type mentioned no-op predicate", but well-formedness serves this purpose fine today, and since no code (according to crater) relies on this coinductive behavior, we'd like to avoid having to emulate it in the new solver.
Fixes#123456 (I didn't want to add a test since it seems low-value to have a ICE test for a fuzzer minimization that is basically garbage code.)
Fixes#109764 (not sure if this behavior is emulatable w/o coinductive WF?)
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/169
r? lcnr
Add negative test coverage for `-Clink-self-contained` and `-Zlinker-features`
Noticed while reviewing stabilization #140525 that we don't have any negative test coverage for these flags. Feel free to cherry-pick these tests into the stabilization PR, or we can land these before separately.
r? `@lqd`
Remove manual WF hack
We do not need this hack anymore since we fixed the candidate selection problems with `Sized` bounds. We prefer built-in sized bounds now since #138176, which fixes the only regression this hack was intended to fix.
While this theoretically is broken for some code, for example, when there a param-env bound that shadows an impl or built-in trait, we don't see it in practice and IMO it's not worth the burden of having to maintain this wart in `compare_method_predicate_entailment`.
The code that regresses is, for example:
```rust
trait Bar<'a> {}
trait Foo<'a, T> {
fn method(&self)
where
Self: Bar<'a>;
}
struct W<'a, T>(&'a T)
where
Self: Bar<'a>;
impl<'a, 'b, T> Bar<'a> for W<'b, T> {}
impl<'a, 'b, T> Foo<'a, T> for W<'b, T> {
fn method(&self) {}
}
```
Specifically, I don't believe this is really going to be encountered in practice. For this to fail, there must be a where clause in the *trait method* that would shadow an impl or built-in (non-`Sized`) candidate in the trait, and this shadowing would need to be encountered when solving a nested WF goal from the impl self type.
See #108544 for the original regression. Crater run is clean!
r? lcnr
Improve `dangerous_implicit_aurorefs` diagnostic output
This PR *greatly* improves the `dangerous_implicit_aurorefs` lint diagnostic output.
Kind of related to #140721.
r? ```@jieyouxu``` (maybe)
Use the new solver in the `impossible_predicates`
The old solver is unsound for many reasons. One of which was weaponized by `@lcnr` in #140212, where the old solver was incompletely considering a dyn vtable method to be impossible and replacing its vtable entry with a null value. This null function could be called post-mono.
The new solver is expected to be less incomplete due to its correct handling of higher-ranked aliases in relate. This PR switches the `impossible_predicates` query to use the new solver, which patches this UB.
r? lcnr
the size of `AsyncStruct`'s destructor depends on whether the configured
panic strategy is 'unwind' or 'abort' so factor that into the test using
conditional compilation
fixesrust-lang/rust#140939
Async drop fix for async_drop_in_place<T> layout for unspecified T
Fix for https://github.com/rust-lang/rust/issues/140423.
Layout of `async_drop_in_place<T>::{closure}` is calculated for unspecified T from dataflow_const_prop `try_make_constant`.
`@oli-obk,` do you think, it may be a better solution to add check like `if !args[0].is_fully_specialized() { return None; }` in `fn async_drop_coroutine_layout`?
And could you, pls, recommend, how to implement `is_fully_specialized()` in a most simple way?
Partially stabilize LoongArch target features
Stabilization PR for the LoongArch target features. This PR stabilizes some of the target features tracked by #44839.
Specifically, this PR stabilizes the following target features:
* f
* d
* frecipe
* lasx
* lbt
* lsx
* lvz
Docs PR: https://github.com/rust-lang/reference/pull/1707
r? `@Amanieu`
Prefer to suggest stable candidates rather than unstable ones
Fixes#140240
The logic is to replace unstable suggestions if we meet a new stable one, and do nothing if any other situation. In old logic, we just use the first candidate we meet as the suggestion for the same items.
E.g., `std::range::legacy::Range` vs `std::ops::Range`, `legacy` in the former is unstable, we prefer to suggest use the latter.
remove intrinsics::drop_in_place
This was only ever accidentally stable, and has been marked as deprecated since Rust 1.52, released almost 4 years ago. We've removed the old serialization `derive`s, maybe we can remove this one as well?
As suggested by ``@jhpratt,`` let's see what crater says for this one.
Merge typeck loop with static/const item eval loop
r? `@ghost`
Let's try a small one first. Doing this in general has some bad cache coherence issues because the query caches are laid out in `Vec<QueryResult>` lists per query where each index refers to a `DefId` in the same order as we're iterating. Iterating two or more lists at the same time does have cache issues, so I want to poke a bit at it to see if we can't merge just a few of them at a time.
Improved error message for top-level or-patterns
I was confused by "top-level or-patterns are not allowed in `let` bindings" error, because it sounded like or-patterns were completely unsupported.
This error has an auto-fix suggestion that shows otherwise, but the auto-fix isn't always visible in IDEs.
I've changed the wording to be consistent with "`Fn` bounds require arguments in parentheses", and it doesn't sound like a dead-end any more.
León Orell Valerian Liehr