701: Minor type inference tweaks r=flodiebold a=marcusklaas
Pass down expectation for reference expressions and type the guard in match expressions.
I wasn't able to add a test for the former addition because the type variable previously introduced would always resolve to the right type in the things I tried!
Co-authored-by: Marcus Klaas de Vries <mail@marcusklaas.nl>
711: Rename FnScopes and move them below the expr module r=matklad a=flodiebold
Extracted from #693 to reduce the diff and make rebasing easier for me 😉
The scopes belong to a body, which could be that of a function, but also a constant, static or array size. So this moves them to a submodule of `expr`.
Also move the `expr_scopes` query from `query_definitions` to that module.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
The reason for this is that it describes scopes for any body expression, not
just that of a function. It did not actually refer to functions at all anymore.
702: Go to Implementation r=matklad a=kjeremy
First half of #620
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
Co-authored-by: kjeremy <kjeremy@gmail.com>
704: Feat/jinstall lsp r=matklad a=DJMcNab
Add `cargo jinstall-lsp` as a shorthand to include jemalloc support
Also activate the extension when the commands are run which is makes sense to activate.
I still need to work out what `Run` actually does to give it a better name, and other extensions through some voodoo magic are able to hide their commands from the command palette before the extension is activated, which would be a better fix.
705: Pass Documentation up to LSP and add "rust" to our codeblocks there r=matklad a=kjeremy
Fixes#699
Co-authored-by: DJMcNab <36049421+djmcnab@users.noreply.github.com>
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
698: Added support for primitive types type inference with std::ops::Not r=flodiebold a=WizardOfMenlo
On the guideline of #544 , this allows for type inference for all primitive types implementing [std::ops::Not](https://doc.rust-lang.org/beta/std/ops/trait.Not.html). I think this should be relevant #394 as well?
Co-authored-by: WizardOfMenlo <giacomofenzi@outlook.com>
661: Implement type generics for functions r=flodiebold a=marcusklaas
Pretty printing of function types isn't as nice any more since the current implementation does not store its argument types directly. We could store some more information to print more information on the argument and return types, at a cost of course.
Co-authored-by: Marcus Klaas de Vries <mail@marcusklaas.nl>
