The old `vscode` package is outdated and it is recommened to switch to
these two new packages. This also solves a problem of a missing `.d.ts`
for `vscode` in Nixos.
1734: Strip indents and empty lines in check_apply_diagnostic_fix_from_position r=matklad a=matklad
Co-authored-by: Phil Ellison <phil.j.ellison@gmail.com>
1733: Parse arbitrarily complex `box` patterns. r=matklad a=ecstatic-morse
This fully resolves the pattern part of #1412 by enabling the parsing of complex `box` patterns such as:
```rust
let box Struct { box i, j: box Inner(box &x) } = todo!();
```
This introduces a new `ast::BoxPat` (in the mold of `ast::RefPat`) that gets translated to `hir::Pat::Missing`.
Co-authored-by: Dylan MacKenzie <ecstaticmorse@gmail.com>
Named structs can have `box` patterns that will bind to their fields.
This is similar to the behavior of the `ref` and `mut` fields, but is at
least a little bit surprising.
1721: Impl/dyn trait r=flodiebold a=flodiebold
This adds support for `impl Trait` and `dyn Trait` types as far as possible without Chalk. So we can represent them in the type system, and handle them in method resolution, but Chalk doesn't know about them yet. There's a small temporary hack here where we bypass Chalk during method resolution, so we can handle simple method calls on them and completion works.
Fixes#1608.
1723: Make sysroot use `RUST_SRC_PATH` if set r=matklad a=bkchr
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Co-authored-by: Bastian Köcher <git@kchr.de>
1722: Parse `box` keyword in patterns below top-level r=matklad a=ecstatic-morse
This extends the parser to handle patterns like `if let Some(box x) = ...` where the `box` keyword is not at the top-level. The last line of the added test caused a `ParseError`. This is a variant of #1412 which was not fixed by #1414.
~~I'm not familiar with `rust-analyzer`, otherwise I would fix this as well 😄.~~
Co-authored-by: Dylan MacKenzie <ecstaticmorse@gmail.com>
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
