Remove chalk support from the compiler
Removes chalk (`-Ztrait-solver=chalk`) from the compiler and prunes any dead code resulting from this, mainly:
* Remove the chalk compatibility layer in `compiler/rustc_traits/src/chalk`
* Remove the chalk flag `-Ztrait-solver=chalk` and its `TraitEngine` implementation
* Remove `TypeWellFormedFromEnv` (and its many `bug!()` match arms)
* Remove the chalk migration mode from compiletest
* Remove the `chalkify` UI tests (do we want to keep any of these, but migrate them to `-Ztrait-solver=next`??)
Fulfills rust-lang/types-team#93.
r? `@jackh726`
Make RPITITs assume/require their parent method's predicates
Removes a FIXME from the `param_env` query where we were manually adding the parent function's predicates to the RPITIT's assumptions.
r? `@spastorino`
Error when RPITITs' hidden types capture more lifetimes than their trait definitions
This implements a stricter set of captures rules for RPITITs. They now may only capture:
1. Lifetimes from the impl header (both the self type and any trait substs -- we may want to restrict just to the self type's lifetimes, but the PR makes that easy to do, too)
2. Lifetimes mentioned by the `impl Trait` in the trait method's definition.
Namely, they may not mention lifetimes from the method (early or late) that are not mentioned in the `impl Trait`.
cc #105258 which I think was trying to do this too, though I'm not super familiar with what exactly differs from that or why that one was broken.
cc #112194 (doesn't fix this issue per se, because it's still an open question, but I think this is objectively better than the status quo, and gets us closer to resolving that issue.)
Technically is a fix for the ICE in #108580, but it turns that issue into an error now. We can decide separately whether or not nested RPITITs should capture lifetimes from their parents.
r? ``@oli-obk``
Encode item bounds for `DefKind::ImplTraitPlaceholder`
This was lost in a refactoring -- `hir::ItemKind::OpaqueTy` doesn't always map to `DefKind::Opaque`, specifically for RPITITs, so the check was migrated subtly wrong, and unfortunately I never had a test for this 🙃Fixes#113155
r? ``@cjgillot``
Account for late-bound vars from parent arg-position impl trait
We should be reporting an error like we do for late-bound args coming from a parent APIT.
Fixes#113016
Preserve substs in opaques recorded in typeck results
This means that we now prepopulate MIR with opaques with the right substs.
The first commit is a hack that I think we discussed, having to do with `DefiningAnchor::Bubble` basically being equivalent to `DefiningAnchor::Error` in the new solver, so having to use `DefiningAnchor::Bind` instead, lol.
r? `@lcnr`
Note user-facing types of coercion failure
When coercing, for example, `Box<A>` into `Box<dyn B>`, make sure that any failure notes mention *those* specific types, rather than mentioning inner types, like "the cast from `A` to `dyn B`".
I expect end-users are often confused when we skip layers of types and only mention the "innermost" part of a coercion, especially when other notes point at HIR, e.g. #111406.
Fix problems with backtraces in two ui tests.
`default-backtrace-ice.rs` started started failing for me recently,
because on my Ubuntu 23.04 system there are 100 stack frames, and the
current stack filtering pattern doesn't match on a stack frame with a
three digit number.
`issue-86800.rs` can also be improved, backtrace-wise.
r? `@Nilstrieb`
Because it then just has to be filtered out.
This change makes this test more like these other tests:
- tests/ui/treat-err-as-bug/err.rs
- tests/ui/treat-err-as-bug/delay_span_bug.rs
- tests/ui/mir/validate/storage-live.rs
- tests/ui/associated-inherent-types/bugs/ice-substitution.rs
- tests/ui/layout/valid_range_oob.rs
Encode def span for foreign return-position `impl Trait` in trait
Fixes#111031, yet another def-span encoding issue :/
Includes a smaller repro than the issue, but I can confirm it ICEs:
```
query stack during panic:
#0 [def_span] looking up span for `rpitit::Foo::bar::{opaque#0}`
#1 [object_safety_violations] determining object safety of trait `rpitit::Foo`
#2 [check_is_object_safe] checking if trait `rpitit::Foo` is object safe
#3 [typeck] type-checking `main`
#4 [used_trait_imports] finding used_trait_imports `main`
#5 [analysis] running analysis passes on this crate
```
Luckily since this only affects nightly, this desn't need to be backported.
