It's a bit complicated because we basically have to 'undo' the desugaring, and
the result is very dependent on the specifics of the desugaring and will
probably produce weird results otherwise.
When we have one of these, the `Trait` doesn't need to be in scope to call its
methods. So we need to consider this when looking for method
candidates. (Actually I think the same is true when we have a bound `T:
some::Trait`, but we don't handle that yet).
At the same time, since Chalk doesn't handle these types yet, add a small hack
to skip Chalk in method resolution and just consider `impl Trait: Trait` always
true. This is enough to e.g. get completions for `impl Trait`, but since we
don't do any unification we won't infer the return type of e.g. `impl
Into<i64>::into()`.
- refactor bounds handling in the AST a bit
- add HIR for bounds
- add `Ty::Dyn` and `Ty::Opaque` variants and lower `dyn Trait` / `impl Trait`
syntax to them
1562: Continue support for .await r=matklad a=unrealhoang
- add await expr to ast and HIR Expr
- infer type for `.await`
Co-authored-by: Unreal Hoang <unrealhoang@gmail.com>
1515: Trait environment r=matklad a=flodiebold
This adds the environment, i.e. the set of `where` clauses in scope, when solving trait goals. That means that e.g. in
```rust
fn foo<T: SomeTrait>(t: T) {}
```
, we are able to complete methods of `SomeTrait` on the `t`. This affects the trait APIs quite a bit (since every method that needs to be able to solve for some trait needs to get this environment somehow), so I thought I'd do it rather sooner than later ;)
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
This wasn't a right decision in the first place, the feature flag was
broken in the last rustfmt release, and syntax highlighting of imports
is more important anyway
