| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
add support of feature flag for runnables
|
| |
| |
| |
| | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| |\
| | |
| | |
| | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| | |
| | |
| | |
| | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
|\ \ \
| | | |
| | | | |
Test fixtures parsing improvements
|
| | | |
| | | |
| | | |
| | | | |
Except crate name.
|
| | | | |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Color attribute functions
|
| | |/ /
| |/| | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
4559: Module name on hover shows another newline after it r=matklad a=Arthamys
This changes the display of hover information to add a newline between the module path of the item and the signature of the item, as suggested in #3813
**Before**
![before_3813](https://user-images.githubusercontent.com/11710698/82609224-5d517d80-9bbc-11ea-9a08-0a1558409c6b.png)
**After**
![after_3813](https://user-images.githubusercontent.com/11710698/82609208-562a6f80-9bbc-11ea-8cb6-4430269c5800.png)
Co-authored-by: Galilée 'Bill' Enguehard <[email protected]>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | | |
| | | | | |
| | | | | | |
modname_spacing
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Closes issue #3813
|
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The idea behind requiring the label is a noble one, but we are not
really using it consistently anyway, and it should be easy to retrofit
later, should we need it.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This also changes our handiling of snippet edits on the client side.
`editor.insertSnippet` unfortunately forces indentation, which we
really don't want to have to deal with. So, let's just implement our
manual hacky way of dealing with a simple subset of snippets we
actually use in rust-analyzer
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
They create quite a bit of friction. Really, we should just move the
tests to the same crate, rather than paper over existing split.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| |/ /
|/| |
| | |
| | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4472: Fix path resolution for module and function with same name r=hasali19 a=hasali19
This fixes #3970 and also fixes completion for the same issue.
Co-authored-by: Hasan Ali <[email protected]>
|
| | | | |
|
|/ / / |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4423: add tests module snippet r=bnjjj a=bnjjj
Request from a friend coming from intellij Rust
Co-authored-by: Benjamin Coenen <[email protected]>
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
4358: add if let and while let postfix for Option and Result #4348 r=matklad a=bnjjj
close #4348
I also added `while let` for iterator or stream it could be useful
![iflet](https://user-images.githubusercontent.com/5719034/81278000-676c6b80-9055-11ea-87ad-6b8476dd983f.gif)
Co-authored-by: Benjamin Coenen <[email protected]>
|
| | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| |\ \ \ \ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
|\ \ \ \ \ \
| |_|_|/ / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
4397: Textmate cooperation r=matklad a=georgewfraser
This PR tweaks the fallback TextMate scopes to make them more consistent with the existing grammar and other languages, and edits the builtin TextMate grammar to align with semantic coloring. Before is on the left, after is on the right:
<img width="855" alt="Screen Shot 2020-05-10 at 1 45 51 PM" src="https://user-images.githubusercontent.com/1369240/81512320-a8be7e80-92d4-11ea-8940-2c03f6769015.png">
**Use keyword.other for regular keywords instead of keyword**. This is a really peculiar quirk of TextMate conventions, but virtually *all* TextMate grammars use `keyword.other` (colored blue in VSCode Dark+) for regular keywords and `keyword.control` (colored purple in VSCode Dark+) for control keywords. The TextMate scope `keyword` is colored like control keywords, not regular keywords. It may seem strange that the `keyword` scope is not the right fallback for the `keyword` semantic token, but TextMate has a long and weird history. Note how keywords change from purple back to blue (what they were before semantic coloring was added):
**(1) Use punctuation.section.embedded for format specifiers**. This aligns with how Typescript colors formatting directives:
<img width="238" alt="Screen Shot 2020-05-09 at 10 54 01 AM" src="https://user-images.githubusercontent.com/1369240/81481258-93b5f280-91e3-11ea-99c2-c6d258c5bcad.png">
**(2) Consistently use `entity.name.type.*` scopes for type names**. Avoid using `entity.name.*` which gets colored like a keyword.
**(3) Use Property instead of Member for fields**. Property and Member are very similar, but if you look at the TextMate fallback scopes, it's clear that Member is intended for function-like-things (methods?) and Property is intended for variable-like-things.
**(4) Color `for` as a regular keyword when it's part of `impl Trait for Struct`**.
**(5) Use `variable.other.constant` for constants instead of `entity.name.constant`**. In the latest VSCode insiders, variable.other.constant has a subtly different color that differentiates constants from ordinary variables. It looks close to the green of types but it's not the same---it's a new color recently added to take advantage of semantic coloring.
I also made some minor changes that make the TextMate scopes better match the semantic scopes. The effect of this for the user is you observe less of a change when semantic coloring "activates". You can see the changes I made relative to the built-in TextMate grammar here:
https://github.com/rust-analyzer/rust-analyzer/pull/4397/files/a91d15c80c337dd1afb0eddd5eb048010d098ac7..97428b6d52d25f810dbd7d7a8d787740c58bfbd2#diff-6966c729b862f79f79bf7258eb3e0885
Co-authored-by: George Fraser <[email protected]>
|