715: Use "▶" for test code lens r=matklad a=kjeremy
I find that this makes code lenses stand out more otherwise they can be easy to miss.
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
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 <36049421+djmcnab@users.noreply.github.com>
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 <eulerdisk@gmail.com>
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>
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>
681: Use the correct working directory for cargo metadata and rustfmt r=matklad a=DJMcNab
Fixes maybe #670. @bjorn3, is that true?
(Awkward wording due to GitHub's eager 'fixes' finding)
Co-authored-by: DJMcNab <36049421+djmcnab@users.noreply.github.com>
680: Struct literals should not be a `BlockLike::Block` r=DJMcNab a=DJMcNab
Fix#674.
Co-authored-by: DJMcNab <36049421+djmcnab@users.noreply.github.com>
The new rowan uses arena allocator for red nodes which helps
slightly (5% on std completion test) with performance but should help
quite a bit with avoiding memory fragmentation.
671: Makre VFS slightly less super obscure r=vemoo a=matklad
I've decided to better understand what we do in VFS, and this turns out to be really hard. Jugling threads and channels is one of the most unfortunately arcane bits of rust...
I had some success though by flattenning the structure so that all channel & thread creation routines are on one screen.
r? @vemoo
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
659: Fold blocks of mod items r=matklad a=eulerdisk
Fixes#572
As requested, we ignore `mod`s with a visibility specifier.
Co-authored-by: Andrea Pretto <eulerdisk@gmail.com>
