901: Add basic support for showing fn signature when hovering r=matklad a=vipentti
This adds basic support for displaying function signature when hovering over a usage of a function.
Additionally refactored `hover` to return `HoverResult` to ease with testing and in general to be more robust.
Co-authored-by: Ville Penttinen <villem.penttinen@gmail.com>
903: Work around for issue in vscode reporting a failure in request r=matklad a=vipentti
vscode would report "A request has failed" when it got "Content modified"
message and this would cause a pop-up to appear. This works around the issue by
returning an "empty" response that vscode can ignore.
Co-authored-by: Ville Penttinen <villem.penttinen@gmail.com>
vscode would report "A request has failed" when it got "Content modified"
message and this would cause a pop-up to appear. This works around the issue by
returning an "empty" response that vscode can ignore.
This replaces places where we would use node + node.type_ref() with things that
have an ascribed type, with using the TypeAscriptionOwner as the trait bound so
we can simply pass the node.
899: Change default value of highlightingOn to false r=matklad a=vipentti
This changes the default value for the vscode setting `rust-analyzer.highlightingOn` to `false`. Since currently the highlighting only supports Zenburn, which people may not be using, I think it makes sense to have this feature disabled by default.
This was discussed in #896
Co-authored-by: Ville Penttinen <villem.penttinen@gmail.com>
897: Add basic const/static type inference r=flodiebold a=vipentti
This adds basic const/static type inference discussed in #887.
Currently the inference does not work for const/static declared inside a block. In addition the inference does not work inside the bodies of const/static.
Co-authored-by: Ville Penttinen <villem.penttinen@gmail.com>
892: Type aliases r=matklad a=flodiebold
This implements type aliases (i.e. `type` definitions).
There's just one snag: handling recursion. E.g. `type Foo = Foo` makes type inference panic with a query cycle. I think the best way to handle this would be if Salsa provided the ability to catch cycle errors? It seems that there's some work underway to support this [here](https://github.com/salsa-rs/salsa/issues/6) and [here](https://github.com/salsa-rs/salsa/pull/147). Should we wait for this? I don't see a good way to handle this without help from Salsa.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
893: Completion presentation r=matklad a=matklad
Just moves completion code around a bit, to keep logic for producing completions and logic for rendering them into completion items separate.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
889: Refactor assits r=matklad a=matklad
* assign unique IDs to assists so that clients could do custom stuff
* specify kinds for assists,
* make introduce_variable a `refactoring.extract` and make it available only when expression is selected
* introduce marks to assists
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
885: Parse token trees directy r=matklad a=matklad
This takes advantage of the recent macro refactoring to directly parse token stream into a syntax tree.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
