Print regions in `type_name`.
Currently they are skipped, which is a bit weird, and it sometimes causes malformed output like `Foo<>` and `dyn Bar<, A = u32>`.
Most regions are erased by the time `type_name` does its work. So all regions are now printed as `'_` in non-optional places. Not perfect, but better than the status quo.
`c_name` is updated to trim lifetimes from MIR pass names, so that the `PASS_NAMES` sanity check still works. It is also renamed as `simplify_pass_type_name` and made non-const, because it doesn't need to be const and the non-const implementation is much shorter.
The commit also renames `should_print_region` as `should_print_optional_region`, which makes it clearer that it only applies to some regions.
Fixesrust-lang/rust#145168.
r? `@lcnr`
Change the desugaring of `assert!` for better error output
In the desugaring of `assert!`, we now expand to a `match` expression instead of `if !cond {..}`.
The span of incorrect conditions will point only at the expression, and not the whole `assert!` invocation.
```
error[E0308]: mismatched types
--> $DIR/issue-14091.rs:2:13
|
LL | assert!(1,1);
| ^ expected `bool`, found integer
```
We no longer mention the expression needing to implement the `Not` trait.
```
error[E0308]: mismatched types
--> $DIR/issue-14091-2.rs:15:13
|
LL | assert!(x, x);
| ^ expected `bool`, found `BytePos`
```
Now `assert!(val)` desugars to:
```rust
match val {
true => {},
_ => $crate::panic::panic_2021!(),
}
```
Fix#122159.
Currently they are skipped, which is a bit weird, and it sometimes
causes malformed output like `Foo<>` and `dyn Bar<, A = u32>`.
Most regions are erased by the time `type_name` does its work. So all
regions are now printed as `'_` in non-optional places. Not perfect, but
better than the status quo.
`c_name` is updated to trim lifetimes from MIR pass names, so that the
`PASS_NAMES` sanity check still works. It is also renamed as
`simplify_pass_type_name` and made non-const, because it doesn't need
to be const and the non-const implementation is much shorter.
The commit also renames `should_print_region` as
`should_print_optional_region`, which makes it clearer that it only
applies to some regions.
Fixes#145168.
In the desugaring of `assert!`, we now expand to a `match` expression
instead of `if !cond {..}`.
The span of incorrect conditions will point only at the expression, and not
the whole `assert!` invocation.
```
error[E0308]: mismatched types
--> $DIR/issue-14091.rs:2:13
|
LL | assert!(1,1);
| ^ expected `bool`, found integer
```
We no longer mention the expression needing to implement the `Not` trait.
```
error[E0308]: mismatched types
--> $DIR/issue-14091-2.rs:15:13
|
LL | assert!(x, x);
| ^ expected `bool`, found `BytePos`
```
`assert!(val)` now desugars to:
```rust
match val {
true => {},
_ => $crate::panic::panic_2021!(),
}
```
Fix#122159.
We make some minor changes to some diagnostics to avoid span overlap on
type mismatch or inverted "expected"/"found" on type errors.
We remove some unnecessary parens from core, alloc and miri.
address review comments
Ignore coroutine witness type region args in auto trait confirmation
## The problem
Consider code like:
```
async fn process<'a>() {
Box::pin(process()).await;
}
fn require_send(_: impl Send) {}
fn main() {
require_send(process());
}
```
When proving that the coroutine `{coroutine@process}::<'?0>: Send`, we end up instantiating a nested goal `{witness@process}::<'?0>: Send` by synthesizing a witness type from the coroutine's args:
Proving a coroutine witness type implements an auto trait requires looking up the coroutine's witness types. The witness types are a binder that look like `for<'r> { Pin<Box<{coroutine@process}::<'r>>> }`. We instantiate this binder with placeholders and prove `Send` on the witness types. This ends up eventually needing to prove something like `{coroutine@process}::<'!1>: Send`. Repeat this process, and we end up in an overflow during fulfillment, since fulfillment does not use freshening.
This can be visualized with a trait stack that ends up looking like:
* `{coroutine@process}::<'?0>: Send`
* `{witness@process}::<'?0>: Send`
* `Pin<Box<{coroutine@process}::<'!1>>>: Send`
* `{coroutine@process}::<'!1>: Send`
* ...
* `{coroutine@process}::<'!2>: Send`
* `{witness@process}::<'!2>: Send`
* ...
* overflow!
The problem here specifically comes from the first step: synthesizing a witness type from the coroutine's args.
## Why wasn't this an issue before?
Specifically, before 63f6845e570305a92eaf855897768617366164d6, this wasn't an issue because we were instead extracting the witness from the coroutine type itself. It turns out that given some `{coroutine@process}::<'?0>`, the witness type was actually something like `{witness@process}::<'erased>`!
So why do we end up with a witness type with `'erased` in its args? This is due to the fact that opaque type inference erases all regions from the witness. This is actually explicitly part of opaque type inference -- changing this to actually visit the witness types actually replicates this overflow even with 63f6845e570305a92eaf855897768617366164d6 reverted:
ca77504943/compiler/rustc_borrowck/src/type_check/opaque_types.rs (L303-L313)
To better understand this difference and how it avoids a cycle, if you look at the trait stack before 63f6845e570305a92eaf855897768617366164d6, we end up with something like:
* `{coroutine@process}::<'?0>: Send`
* `{witness@process}::<'erased>: Send` **<-- THIS CHANGED**
* `Pin<Box<{coroutine@process}::<'!1>>>: Send`
* `{coroutine@process}::<'!1>: Send`
* ...
* `{coroutine@process}::<'erased>: Send` **<-- THIS CHANGED**
* `{witness@process}::<'erased>: Send` **<-- THIS CHANGED**
* coinductive cycle! 🎉
## So what's the fix?
This hack replicates the behavior in opaque type inference to erase regions from the witness type, but instead erasing the regions during auto trait confirmation. This is kinda a hack, but is sound. It does not need to be replicated in the new trait solver, of course.
---
I hope this explanation makes sense.
We could beta backport this instead of the revert https://github.com/rust-lang/rust/pull/145193, but then I'd like to un-revert that on master in this PR along with landing this this hack. Thoughts?
r? lcnr
Check coroutine upvars in dtorck constraint
Fixrust-lang/rust#144155.
This PR fixes an unsoundness where we were not considering coroutine upvars as drop-live if the coroutine interior types (witness types) had nothing which required drop.
In the case that the coroutine does not have any interior types that need to be dropped, then we don't need to treat all of the upvars as use-live; instead, this PR uses the same logic as closures, and descends into the upvar types to collect anything that must be drop-live. The rest of this PR is reworking the comment to explain the behavior here.
r? `@lcnr` or reassign 😸
---
Just some thoughts --- a proper fix for this whole situation would be to consider `TypingMode` in the `needs_drop` function, and just calling `coroutine_ty.needs_drop(tcx, typing_env)` in the dtorck constraint check.
During MIR building, we should probably use a typing mode that stalls the local coroutines and considers them to be unconditionally drop, or perhaps just stall *all* coroutines in analysis mode. Then in borrowck mode, we can re-check `needs_drop` but descend into witness types properly. https://github.com/rust-lang/rust/pull/144158 implements this experimentally.
This is a pretty involved fix, and conflicts with some in-flight changes (rust-lang/rust#144157) that I have around removing coroutine witnesses altogether. I'm happy to add a FIXME to rework this whole approach, but I don't want to block this quick fix since it's obviously more correct than the status-quo.
`TyCtxt::short_string` ensures that user visible type paths aren't overwhelming on the terminal output, and properly saves the long name to disk as a side-channel. We already use these throughout the compiler and have been using them as needed when users find cases where the output is verbose. This is a proactive search of some cases to use `short_string`.
We add support for shortening the path of "trait path only".
Every manual use of `short_string` is a bright marker that that error should be using structured diagnostics instead (as they have proper handling of long types without the maintainer having to think abou tthem).
When we don't actually print out a shortened type we don't need the "use `--verbose`" note.
On E0599 show type identity to avoid expanding the receiver's generic parameters.
Unify wording on `long_ty_path` everywhere.
Three of them are named `AbsolutePathPrinter`, which is confusing, so
give those names that better indicate how they are used. And then there
is `SymbolPrinter` and `SymbolMangler`, which are renamed as
`LegacySymbolMangler` and `V0SymbolMangler`, better indicating their
similarity.
`Printer` cleanups
The trait `Printer` is implemented by six types, and the sub-trait `PrettyPrinter` is implemented by three of those types. The traits and the impls are complex and a bit of a mess. This PR starts to clean them up.
r? ``@davidtwco``
Distinguish prepending and replacing self ty in predicates
There are two kinds of functions called `with_self_ty`:
1. Prepends the `Self` type onto an `ExistentialPredicate` which lacks it in its internal representation.
2. Replaces the `Self` type of an existing predicate, either for diagnostics purposes or in the new trait solver when normalizing that self type.
This PR distinguishes these two because I often want to only grep for one of them. Namely, let's call it `with_replaced_self_ty` when all we're doing is replacing the self type.
Currently they are mostly named `cx`, which is a terrible name for a
type that impls `Printer`/`PrettyPrinter`, and is easy to confuse with
other types like `TyCtxt`. This commit changes them to `p`. A couple of
existing `p` variables had to be renamed to make way.
This helps me understand the structure of the code a lot.
If any of these are actually reachable, we can put the old code back,
add a new test case, and we will have improved our test coverage.
Remove the witness type from coroutine *args* (without actually removing the type)
This does as much of rust-lang/rust#144157 as we can without having to break rust-lang/rust#143545 and/or introduce some better way of handling higher ranked assumptions.
Namely, it:
* Stalls coroutines based off of the *coroutine* type rather than the witness type.
* Reworks the dtorck constraint hack to not rely on the witness type.
* Removes the witness type from the args of the coroutine, eagerly creating the type for nested obligations when needed (auto/clone impls).
I'll experiment with actually removing the witness type in a follow-up.
r? lcnr
This commit changes it to store a `Region` instead of a `RegionVid` for the `Var` cases:
- We avoid having to call `Region::new_var` to re-create `Region`s from
`RegionVid`s in a few places, avoiding the interning process, giving a
small perf win. (At the cost of the type allowing some invalid
combinations of values.)
- All the cases now store two `Region`s, so the commit also separates
the `ConstraintKind` (a new type) from the `sub` and `sup` arguments
in `Constraint`.
Currently there is `Ty` and `BoundTy`, and `Region` and `BoundRegion`,
and `Const` and... `BoundVar`. An annoying inconsistency.
This commit repurposes the existing `BoundConst`, which was barely used,
so it's the partner to `Const`. Unlike `BoundTy`/`BoundRegion` it lacks
a `kind` field but it's still nice to have because it makes the const
code more similar to the ty/region code everywhere.
The commit also removes `impl From<BoundVar> for BoundTy`, which has a
single use and doesn't seem worth it.
These changes fix the "FIXME: We really should have a separate
`BoundConst` for consts".
uniquify root goals during HIR typeck
We need to rely on region identity to deal with hangs such as https://github.com/rust-lang/trait-system-refactor-initiative/issues/210 and to keep the current behavior of `fn try_merge_responses`.
This is a problem as borrowck starts by replacing each *occurrence* of a region with a unique inference variable. This frequently splits a single region during HIR typeck into multiple distinct regions. As we assume goals to always succeed during borrowck, relying on two occurances of a region being identical during HIR typeck causes ICE. See the now fixed examples in https://github.com/rust-lang/trait-system-refactor-initiative/issues/27 and rust-lang/rust#139409.
We've previously tried to avoid this issue by always *uniquifying* regions when canonicalizing goals. This prevents caching subtrees during canonicalization which resulted in hangs for very large types. People rely on such types in practice, which caused us to revert our attempt to reinstate `#[type_length_limit]` in https://github.com/rust-lang/rust/pull/127670. The complete list of changes here:
- rust-lang/rust#107981
- rust-lang/rust#110180
- rust-lang/rust#114117
- rust-lang/rust#130821
After more consideration, all occurrences of such large types need to happen outside of typeck/borrowck. We know this as we already walk over all types in the MIR body when replacing their regions with nll vars.
This PR therefore enables us to rely on region identity inside of the trait solver by exclusively **uniquifying root goals during HIR typeck**. These are the only goals we assume to hold during borrowck. This is insufficient as type inference variables may "hide" regions we later uniquify. Because of this, we now stash proven goals which depend on inference variables in HIR typeck and reprove them after writeback. This closes https://github.com/rust-lang/trait-system-refactor-initiative/issues/127.
This was originally part of rust-lang/rust#144258 but I've moved it into a separate PR. While I believe we need to rely on region identity to fix the performance issues in some way, I don't know whether rust-lang/rust#144258 is the best approach to actually do so. Regardless of how we deal with the hangs however, this change is necessary and desirable regardless.
r? `@compiler-errors` or `@BoxyUwU`
