Increase spacing for suggestions in diagnostics
Make the spacing between the code snippet and verbose structured
suggestions consistent with note and help messages.
r? @Centril
Remove blanket silencing of "type annotation needed" errors
Remove blanket check for existence of other errors before emitting "type annotation needed" errors, and add some eager checks to avoid adding obligations when they refer to types that reference `[type error]` in order to reduce unneeded errors.
Fix#64084.
Remove blanket check for existence of other errors before emitting
"type annotation needed" errors, and add some eager checks to avoid
adding obligations when they refer to types that reference
`[type error]` in order to reduce unneded errors.
Currently the default is "inherited" from context, so e.g. `&impl
Foo<Item = dyn Bar>` would default to `&'x impl Foo<Item = dyn Bar +
'x>`, but this triggers an ICE and is not very consistent.
This patch doesn't implement what I expect would be the correct
semantics, because those are likely too complex. Instead, it handles
what I'd expect to be the common case -- where the trait has no
lifetime parameters.
Object-lifetime-default elision is distinct from other forms of
elision; it always refers to some enclosing lifetime *present in the
surrounding type* (e.g., `&dyn Bar` expands to `&'a (dyn Bar + 'a)`.
If there is no enclosing lifetime, then it expands to `'static`.
Therefore, in an `impl Trait<Item = dyn Bar>` setting, we don't expand
to create a lifetime parameter for the `dyn Bar + 'X` bound. It will
just be resolved to `'static`.
Annoyingly, the responsibility for this resolution is spread across
multiple bits of code right now (`middle::resolve_lifetimes`,
`lowering`). The lowering code knows that the default is for an object
lifetime, but it doesn't know what the correct result would be.
Probably this should be fixed, but what we do now is a surgical fix:
we have it generate a different result for elided lifetimes in a
object context, and then we can ignore those results when figuring out
the lifetimes that are captured in the opaque type.
This commit prohibits return position `impl Trait` types that "inherit
lifetimes" from the parent scope. The intent is to forbid cases that are
challenging until they can be addressed properly.
Cleanup some surrounding code.
Support resolution of intra doc links in unnamed block scopes.
(Paths from rustdoc now use early resolution and no longer need results of late resolution like all the built ribs.)
Fix one test hitting file path limits on Windows.
resolve: Improve candidate search for unresolved macro suggestions
Use same scope visiting machinery for both collecting suggestion candidates and actually resolving the names.
The PR is better read in per-commit fashion with whitespace changes ignored (the first commit in particular moves some code around).
This should be the last pre-requisite for https://github.com/rust-lang/rust/pull/62086.
r? @davidtwco
Normalize projections appearing in `impl Trait`
Fixes#60414
This does not try to do the same for `existential type`s (which have the same bug), since that always seems to lead to cycle errors.
Migrate `compile-pass` annotations to `build-pass`
This is a part of #62277.
As a first step, the `compile-pass` tests are migrated to `build-pass`.
r? @cramertj
cc @Centril
This commit merges the logic used for opaque type type inference for
impl Trait and non-impl Trait cases. This fixes an ICE where
existential types used in the return types of functions would be allowed
to have an out-of-scope generic type parameter.
