1696: fix#1424 r=matklad a=coderfox
- resolve "~" in raLspServerPath
I think expanding simply `~/` is quite simple as node provides `homedir`, but expanding `~foo/` is difficult as there is no cross-platform approach of reading home directory of another user. So this pull request only resolves `~/` in `raLspServerPath`.
Besides, the source code is arranged in a way hard to write tests. Would anyone provide me with instructions of writing tests for this feature, or no test is required for this feature?
Co-authored-by: xfoxfu <i@xfox.me>
1694: Implement initial type-inference support for Index r=flodiebold a=matklad
This doesn't actually infer indexing types, but at least it walks sub-expressions!
Initially, I wanted to make `Index` just a new kind of `BinOp` (b/c indexing is kind of a binary op), so I've refactoring binop handing a bit.
However, in the end I've decided to add a separate expr kind for Index, because `foo[0]`, `&foo[1]` and `&mut foo[1]` all seem to need slightly different handing, which is not binop-like
r? @flodiebold
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
1445: Use the new "durability" infrastructure from salsa r=matklad a=matklad
Based on https://github.com/nikomatsakis/salsa/tree/durability
Durability allows us to skip *validation* work for sysroot and crates.io libraries, which massively speeds up some workloads
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
1677: Associated types r=flodiebold a=flodiebold
This implements basic support for (fully qualified) associated type projections:
- handle fully qualified paths like `<T as Trait>::AssocType` (basically desugaring to something like `Trait<Self=T>::AssocType`)
- lower these to a new `Ty::Projection` enum variant
- also introduce `Ty::UnselectedProjection` for cases like `T::AssocType` where the trait from which the type comes isn't specified, but these aren't handled further so far
- in inference, normalize these projections using Chalk: basically, when encountering a type e.g. from a type annotation or signature, we replace these `Ty::Projection`s by type variables and add obligations to normalize the associated type
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
This adds three different representations, copied from the Chalk model:
- `Ty::Projection` is an associated type projection written somewhere in the
code, like `<Foo as Trait>::Bar`.
- `Ty::UnselectedProjection` is similar, but we don't know the trait
yet (`Foo::Bar`).
- The above representations are normalized to their actual types during type
inference. When that isn't possible, for example for `T::Item` inside an `fn
foo<T: Iterator>`, the type is normalized to an application type with
`TypeCtor::AssociatedType`.
