| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| | |
I find that this makes code lenses stand out more.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
692: [WIP] Correctly parse attributes r=matklad a=DJMcNab
Reference - https://doc.rust-lang.org/reference/attributes.html
This fixes/investigates inner attributes for:
- [x] `impl` blocks
- [x] `extern` blocks
- [x] `fn`s (fixes #689)
- [x] `mod`s (already supported)
- [x] 'block expressions' (the long text just describes all 'blocks' used as statements)
This also investigates/fixes outer attributes for:
- [ ] 'most statements' (see also: #685, https://doc.rust-lang.org/reference/expressions.html#expression-attributes)
- [x] Enum variants, Struct and Union fields (Fixed in #507)
- [ ] 'Match expression arms' (@matklad can you provide a test case which explains what this means?)
- [ ] 'Generic lifetime or type parameters'
- [ ] 'Elements of array expressions, tuple expressions, call expressions, tuple-style struct and enum variant expressions'
- [ ] 'The tail expression of block expressions'
Co-authored-by: DJMcNab <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | | |
712: Fix #667 and improvements to introduce_variable r=matklad a=eulerdisk
Fix #667 (but not re-indenting currently), plus many other improvements.
@matklad I'm not sure how to handle re-indenting here.
Co-authored-by: Andrea Pretto <[email protected]>
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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 <[email protected]>
|
| | | | |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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 :wink:
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 <[email protected]>
|
| | | | | |
|
|/ / / /
| | | |
| | | |
| | | |
| | | | |
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.
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
709: Use Crate instead of CrateId r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | | |
|
|/ / / / |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
702: Go to Implementation r=matklad a=kjeremy
First half of #620
Co-authored-by: Jeremy Kolb <[email protected]>
Co-authored-by: kjeremy <[email protected]>
|
| | | | | |
|
| | |/ /
| |/| | |
|
| | | | | |
| \ \ \ | |
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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 <[email protected]>
Co-authored-by: Jeremy Kolb <[email protected]>
|
| | |/ / / |
|
| | | | | |
|
| | | | | |
|
| |/ / / |
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
708: Clear the console when running single tasks r=matklad a=kjeremy
Co-authored-by: kjeremy <[email protected]>
|
|/ / / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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 <[email protected]>
|
| | | | |
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
700: Update insta r=matklad a=kjeremy
Fixes windows build
Co-authored-by: Jeremy A. Kolb <[email protected]>
|
|/ / /
| | |
| | |
| | | |
Fixes windows build
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
697: opt-in jemalloc r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
695: align command naming r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
678: WIP: automatically collect garbage r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
694: Sort completions in tests r=matklad a=flodiebold
Co-authored-by: Florian Diebold <[email protected]>
|
|/ / / |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|