| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| | |
501: Switch hover to use MarkupContent r=matklad a=kjeremy
MarkedString is deprecated
Co-authored-by: Jeremy Kolb <[email protected]>
|
|/
|
|
| |
MarkedString is deprecated
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
491: Fix assertion error in unification (hopefully) r=flodiebold a=flodiebold
Currently, all types that we handle during inference need to be resolved as far
as possible at the time. It's maybe too brittle of an invariant; I need to think
how we can do this better. This should fix #484 though, I hope (if
it's the same case as I managed to reproduce).
Co-authored-by: Florian Diebold <[email protected]>
|
|/
|
|
|
|
|
| |
Currently, all types that we handle during inference need to be resolved as far
as possible at the time. It's maybe too brittle of an invariant; I need to think
how we can do this better. This should fix #484 though, I hope (if
it's the same case as I managed to reproduce).
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
498: actually produce missing def kinds r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
| | |
|
|/ |
|
|
|
|
| |
This is much clearer about the semantics
|
|\
| |
| |
| |
| |
| |
| |
| | |
496: Include two element ranges into the nav. r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
497: prioritize event handing over indexing r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/
|
|
|
|
| |
If we index gazillion libraries simultaneously, we fill the threadpool
and so the main loop fails to turn, although there isn't really any
significant blocking inside the loop itself.
|
|\
| |
| |
| |
| |
| |
| |
| | |
495: Fix on type handlers r=matklad a=matklad
Looks like our on type handlers didn't actually worked, this shoud fix that!
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
493: force serde in ra_syntax r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
489: support std r=matklad a=matklad
closes #465
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
490: dont depend on tools from lsp-server r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
463: Use name resolution for goto definition r=matklad a=flodiebold
This tries proper name resolution before falling back on the index.
@matklad There was currently no way of getting the location of a `DefId` from outside `ra_hir`. I added something, but it's probably not the best API, maybe you have a better idea?
Co-authored-by: Florian Diebold <[email protected]>
|
|/ / |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| | |
470: Type inference for enum variants r=flodiebold a=marcusklaas
Opened a new PR instead of https://github.com/rust-analyzer/rust-analyzer/pull/461. Totally botched that one.
I think I resolved all the issues mentioned there.
Co-authored-by: Marcus Klaas de Vries <[email protected]>
|
| |
| |
| |
| |
| |
| | |
We already have their names when anyway, and when in all (current)
situations where we're interested in an Enum's variants, we want
their names.
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
488: switch CargoWorkspace to arena r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
487: dont complete () if they are already there r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / / |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
486: Fix handling of where clauses in tuple structs r=matklad a=DJMcNab
Originally reported by @max-frai on discord.
As I was writing this, I was wondering if there's any way we can compare our test suite against libsyntax (i.e. check that it similarly fails/succeeds). Any ideas?
Co-authored-by: DJMcNab <[email protected]>
|