Initial implementation of dyn*
This PR adds extremely basic and incomplete support for [dyn*](https://smallcultfollowing.com/babysteps//blog/2022/03/29/dyn-can-we-make-dyn-sized/). The goal is to get something in tree behind a flag to make collaboration easier, and also to make sure the implementation so far is not unreasonable. This PR does quite a few things:
* Introduce `dyn_star` feature flag
* Adds parsing for `dyn* Trait` types
* Defines `dyn* Trait` as a sized type
* Adds support for explicit casts, like `42usize as dyn* Debug`
* Including const evaluation of such casts
* Adds codegen for drop glue so things are cleaned up properly when a `dyn* Trait` object goes out of scope
* Adds codegen for method calls, at least for methods that take `&self`
Quite a bit is still missing, but this gives us a starting point. Note that this is never intended to become stable surface syntax for Rust, but rather `dyn*` is planned to be used as an implementation detail for async functions in dyn traits.
Joint work with `@nikomatsakis` and `@compiler-errors.`
r? `@bjorn3`
Emit a note that static bounds from HRTBs are a bug
This note isn't perfect, but opening this to either 1) land as is or 2) get some feedback on how to improve it
Let r? `@compiler-errors` and cc. `@nikomatsakis`
Make `compare_predicate_entailment` no longer a query
Make `compare_predicate_entailment` so it's no longer a query (again), and splits out the new logic (that equates the return types to infer RPITITs) into its own query. This means that this new query (now called `collect_trait_impl_trait_tys`) is no longer executed for non-RPITIT cases.
This should improve perf (https://github.com/rust-lang/rust/pull/101224#issuecomment-1241682203), though in practice we see that these some crates remain from the primary regressions list on the original report... They are all <= 0.43% regression and seemingly only on the incr-full scenario for all of them.
I am at a loss for what might be causing this regression other than what I fixed here, since we don't introduce much new non-RPITIT logic except for some `def_kind` query calls in some places, for example, like projection. Maybe that's it?
----
Originally this PR was opened to test enabling `cache_on_disk` (62164aaaa11) but that didn't turn out to be very useful (https://github.com/rust-lang/rust/pull/101615#issuecomment-1242403205), so that led me to just split the query (and rename the PR).
const_generics: correctly deal with bound variables
removes the hack in `resolve` which was needed because we evaluated constants without caring about their bound variables.
Each commit should be fairly self-contained, even if they build on each other
r? `@jackh726`
Migrate another part of rustc_infer to session diagnostic
Probably will migrate another file before marking this one as ready-to-merge.
`@rustbot` label +A-translation
r? rust-lang/diagnostics
cc https://github.com/rust-lang/rust/issues/100717
Update `SessionDiagnostic::into_diagnostic` to take `Handler` instead of `ParseSess`
Suggested by the team in [this Zulip Topic](https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/.23100717.20SessionDiagnostic.20on.20Handler).
`Handler` already has almost all the capabilities of `ParseSess` when it comes to diagnostic emission, in this migration we only needed to add the ability to access `source_map` from the emitter in order to get a `Snippet` and the `start_point`. Not sure if adding these two methods [`span_to_snippet_from_emitter` and `span_start_point_from_emitter`] is the best way to address this gap.
P.S. If this goes in the right direction, then we probably may want to move `SessionDiagnostic` to `rustc_errors` and rename it to `DiagnosticHandler` or something similar.
r? `@davidtwco`
r? `@compiler-errors`
Suggested by the team in this Zulip Topic https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/.23100717.20SessionDiagnostic.20on.20Handler
Handler already has almost all the capabilities of ParseSess when it comes to diagnostic emission, in this migration we only needed to add the ability to access source_map from the emitter in order to get a Snippet and the start_point. Not sure if this is the best way to address this gap
This PR will fix some typos detected by [typos].
I only picked the ones I was sure were spelling errors to fix, mostly in
the comments.
[typos]: https://github.com/crate-ci/typos
Attempt to normalize `FnDef` signature in `InferCtxt::cmp`
Stashes a normalization callback in `InferCtxt` so that the signature we get from `tcx.fn_sig(..).subst(..)` in `InferCtxt::cmp` can be properly normalized, since we cannot expect for it to have normalized types since it comes straight from astconv.
This is kind of a hack, but I will say that `@jyn514` found the fact that we present unnormalized types to be very confusing in real life code, and I agree with that feeling. Though altogether I am still a bit unsure about whether this PR is worth the effort, so I'm open to alternatives and/or just closing it outright.
On the other hand, this isn't a ridiculously heavy implementation anyways -- it's less than a hundred lines of changes, and half of that is just miscellaneous cleanup.
This is stacked onto #100471 which is basically unrelated, and it can be rebased off of that when that lands or if needed.
---
The code:
```rust
trait Foo { type Bar; }
impl<T> Foo for T {
type Bar = i32;
}
fn foo<T>(_: <T as Foo>::Bar) {}
fn needs_i32_ref_fn(f: fn(&'static i32)) {}
fn main() {
needs_i32_ref_fn(foo::<()>);
}
```
Before:
```
= note: expected fn pointer `fn(&'static i32)`
found fn item `fn(<() as Foo>::Bar) {foo::<()>}`
```
After:
```
= note: expected fn pointer `fn(&'static i32)`
found fn item `fn(i32) {foo::<()>}`
```
Do not leak type variables from opaque type relation
The "root cause" is that we call `InferCtxt::resolve_vars_if_possible` (3d9dd681f5) on the types we get back in `TypeError::Sorts` since I added a call to it in `InferCtxt::same_type_modulo_infer`. However if this `TypeError` comes from a `InferCtxt::commit_if_ok`, then it may reference type variables that do not exist anymore, which is problematic.
We avoid this by substituting the `TypeError` with the types we had before being generalized while handling opaques.
This is kinda gross, and I feel like we can get the same issue from other places where we generalize type/const inference variables. Maybe not? I don't know.
Fixes#99914Fixes#99970Fixes#100463
