| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Don't cause a cycle when formatting query description that references a FnDef
When a function returns `-> _`, we use typeck to compute what the resulting type of the body _should_ be. If we call another query inside of typeck and hit a cycle error, we attempt to report the cycle error which requires us to compute all of the query descriptions for the stack.
However, if one of the queries in that cycle has a query description that references this function as a FnDef type, we'll cause a *second* cycle error from within the cycle error reporting code, since rendering a FnDef requires us to compute its signature. This causes an unwrap to ICE, since during the *second* cycle reporting code, we try to look for a job that isn't in the active jobs list.
We can avoid this by using `with_no_queries!` when computing these query descriptions.
Fixes #107089
The only drawback is that the rendering of opaque types in cycles regresses a bit :| I'm open to alternate suggestions about how we may handle this...
|
|
Remove confusing 'while checking' note from opaque future type mismatches
Maybe I'm just misinterpreting the wording of the note. The only value I can see in this note is that it points out where the async's opaque future is coming from, but the way it's doing it is misleading IMO.
For example:
```rust
note: while checking the return type of the `async fn`
--> $DIR/dont-suggest-missing-await.rs:7:24
|
LL | async fn make_u32() -> u32 {
| ^^^ checked the `Output` of this `async fn`, found opaque type
```
We point at the type `u32` in the HIR, but then say "found opaque type". We also say "while checking"... but we're typechecking a totally different function when we get this type mismatch!
r? ``@estebank`` but feel free to reassign and/or take your time reviewing this. I'd be inclined to also discuss reworking the presentation of this type mismatch to restore some of these labels in a way that makes it more clear what it's trying to point out.
|
|
|
|
|
|
|
|
|
|
The previous output was unintuitive to users.
|
|
|
|
|
|
Tweak E0597
CC #99430
|
|
|
|
|
|
Do not filter substs in `remap_generic_params_to_declaration_params`.
The relevant filtering should have been performed by borrowck.
Fixes https://github.com/rust-lang/rust/issues/105826
r? types
|
|
CC #99430
|
|
When suggesting writing a fully qualified path probe for appropriate types
Address the more common part of #46585.
|
|
Rollup of 8 pull requests
Successful merges:
- #103236 (doc: rewrite doc for signed int::{carrying_add,borrowing_sub})
- #103800 (Stabilize `::{core,std}::pin::pin!`)
- #106097 (Migrate mir_build diagnostics 2 of 3)
- #106170 (Move autoderef to `rustc_hir_analysis`)
- #106323 (Stabilize f16c_target_feature)
- #106360 (Tweak E0277 `&`-removal suggestions)
- #106524 (Label `struct/enum constructor` instead of `fn item`, mention that it should be called on type mismatch)
- #106739 (Remove `<dyn AstConv<'tcx>>::fun(c, ...)` calls in favour of `c.astconv().fun(...)`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Tweak E0277 `&`-removal suggestions
Fix #64068, fix #84837.
|
|
Conserve cause of `ImplDerivedObligation` in E0599
CC #86377.
|
|
Hide more of long types in E0271
Fix #40186.
|
|
Fix #40186.
|
|
|
|
Fix #46585.
|
|
|
|
CC #86377.
|
|
The relevant filtering should have been performed by borrowck.
|
|
|
