| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <[email protected]>
|
|/
|
|
| |
resolve "~" in raLspServerPath
|
|\
| |
| |
| |
| |
| |
| |
| | |
1695: update lsp r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <[email protected]>
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Unlike ast::BinOp, it has significantly more structure to it, so it's
easier to, say, handle all assignment-like operations in the same way.
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1693: Remove cpuprofile dependencies r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1692: :arrow_up: deps r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1691: Show inherent and trait impls of structs and enums r=viorina a=viorina
Co-authored-by: Ekaterina Babshukova <[email protected]>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1689: Update deps r=kjeremy a=kjeremy
Co-authored-by: kjeremy <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1686: :arrow_up: deps r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
| | | |
|
| | | |
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1685: fix error of RangeFrom in for-loop r=DJMcNab a=bravomikekilo
fix [issue-1542](https://github.com/rust-analyzer/rust-analyzer/issues/1542) @matklad
Co-authored-by: bravomikekilo <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
1676: Fix for<'lifetime> for types specified by path r=matklad a=eupn
Fixes #1467.
Co-authored-by: Evgenii P <[email protected]>
|
| | | |
|
| | | |
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | | |
1636: fix block parse problem r=matklad a=bravomikekilo
try to fix [issue-1598](https://github.com/rust-analyzer/rust-analyzer/issues/1598).
Co-authored-by: bravomikekilo <[email protected]>
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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 <[email protected]>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
I.e. `<T as Trait>::Foo`.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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`.
|
|/ / / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1683: Use Source in Diagnostic r=matklad a=eupn
Closes #1681.
Co-authored-by: Evgenii P <[email protected]>
|
|/ / / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1682: Drop support for old extendSelection API r=matklad a=matklad
Emacs now handles this via native LSP request
https://github.com/emacs-lsp/lsp-mode/commit/dc86bbb227147aa8141e690ad5648fdbd2ebdb9f
r? @flodiebold
(Have not actually tried elisp code)
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / /
| | |
| | |
| | |
| | |
| | | |
Emacs now handles this via native LSP request
https://github.com/emacs-lsp/lsp-mode/commit/dc86bbb227147aa8141e690ad5648fdbd2ebdb9f
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1667: Show backtraces in lens runnables r=matklad a=SomeoneToIgnore
Co-authored-by: Kirill Bulatov <[email protected]>
|
| | | | |
|
| | | | |
|