about summary refs log tree commit diff
path: root/crates/rust-analyzer/src
AgeCommit message (Collapse)AuthorLines
2020-05-24Highlight `true` and `false` as literalsMatthew Jasper-0/+2
2020-05-24Merge pull request #4548 from bnjjj/fix_4464Aleksey Kladov-2/+87
add support of feature flag for runnables
2020-05-24Merge pull request #4474 from georgewfraser/color_attrsAleksey Kladov-0/+2
Color attribute functions
2020-05-24add support of feature flag for runnables #4464Benjamin Coenen-14/+0
Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
2020-05-23add support of feature flag for runnables #4464Benjamin Coenen-9/+98
Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
2020-05-22And a few drive-byskjeremy-6/+4
2020-05-22Merge #4571bors[bot]-3/+3
4571: KISS SourceChange r=matklad a=matklad 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. bors r+ Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-05-22KISS SourceChangeAleksey Kladov-3/+3
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.
2020-05-22Merge #4569bors[bot]-67/+19
4569: CodeAction groups r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-05-22CodeAction groupsAleksey Kladov-67/+19
2020-05-22Merge #4516bors[bot]-24/+53
4516: LSP: Two stage initialization r=kjeremy a=kjeremy Fills in server information. Derives CodeAction capabilities from the client. If code action literals are unsupported we fall back to the "simple support" which just sends back commands (this is already supported in our config). The difference being that we did not adjust our server capabilities so that if the client was checking for `CodeActionProvider: "true"` in the response that would have failed. Part of #144 Fixes #4130 (the specific case called out in that issue) Co-authored-by: kjeremy <kjeremy@gmail.com>
2020-05-22Use WorkspaceEdit for ssrAleksey Kladov-4/+5
2020-05-21Formalize JoinLines protocol extensionAleksey Kladov-18/+34
2020-05-21Cleanup TextEditAleksey Kladov-8/+3
2020-05-21Remove dead code for handling cursor positionsAleksey Kladov-53/+10
2020-05-21Transition OnEnter to WorkspaceSnippetEditAleksey Kladov-3/+3
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
2020-05-21add support of feature flag for runnables #4464Benjamin Coenen-186/+353
Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
2020-05-21add support of feature flag for runnables #4464Benjamin Coenen-1/+11
Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
2020-05-19Use a flat play icon instead of the blue emoji with test code lensAaron Loucks-2/+2
2020-05-20Use new format for all assists that don't change cursor positonAleksey Kladov-1/+2
2020-05-19Add versionkjeremy-1/+1
2020-05-19Fill code action capabilities with a functionkjeremy-29/+27
2020-05-19Update test dataAleksey Kladov-0/+2
2020-05-19Server side of SnippetTextEditAleksey Kladov-109/+200
2020-05-19Add snippetTextEdit protocol extensionAleksey Kladov-1/+8
2020-05-19Add AssistConfigAleksey Kladov-4/+9
2020-05-19LSP: Two stage initializationkjeremy-24/+55
Fills in server information. Derives CodeAction capabilities from the client. If code action literals are unsupported we fall back to the "simple support" which just sends back commands (this is already supported in our config). The difference being that we did not adjust our server capabilities so that if the client was checking for `CodeActionProvider: "true"` in the response that would have failed.
2020-05-18Color attribute functionsGeorge Fraser-0/+2
2020-05-18Add "rust-analyzer.lens.enable"vsrs-3/+12
2020-05-17code formattingvsrs-19/+21
2020-05-17CodeLens configuration options.vsrs-88/+138
2020-05-15Merge #4448bors[bot]-1/+4
4448: Generate configuration for launch.json r=vsrs a=vsrs This PR adds two new commands: `"rust-analyzer.debug"` and `"rust-analyzer.newDebugConfig"`. The former is a supplement to the existing `"rust-analyzer.run"` command and works the same way: asks for a runnable and starts new debug session. The latter allows adding a new configuration to **launch.json** (or to update an existing one). If the new option `"rust-analyzer.debug.useLaunchJson"` is set to true then `"rust-analyzer.debug"` and Debug Lens will first look for existing debug configuration in **launch.json**. That is, it has become possible to specify startup arguments, env variables, etc. `"rust-analyzer.debug.useLaunchJson"` is false by default, but it might be worth making true the default value. Personally I prefer true, but I'm not sure if it is good for all value. ---- I think that this PR also solves https://github.com/rust-analyzer/rust-analyzer/issues/3441. Both methods to update launch.json mentioned in the issue do not work: 1. Menu. It is only possible to add a launch.json configuration template via a debug adapter. And anyway it's only a template and it is impossible to specify arguments from an extension. 2. DebugConfigurationProvider. The exact opposite situation: it is possible to specify all debug session settings, but it is impossible to export these settings to launch.json. Separate `"rust-analyzer.newDebugConfig"` command looks better for me. ---- Fixes #4450 Fixes #3441 Co-authored-by: vsrs <vit@conrlab.com> Co-authored-by: vsrs <62505555+vsrs@users.noreply.github.com>
2020-05-15CleanupsAleksey Kladov-83/+74
2020-05-15Better structureAleksey Kladov-11/+9
2020-05-15Move LSP bits from flycheck to rust-analyzerAleksey Kladov-16/+2023
There should be only one place that knows about LSP, and that place is right before we spit JSON on stdout.
2020-05-14MinorAleksey Kladov-10/+8
2020-05-14Put preselect items on topAleksey Kladov-1/+3
2020-05-14Better label for a runnable.vsrs-1/+1
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-05-14Multiple binaries support for launch.json.vsrs-1/+4
Generate unique names on the LSP side.
2020-05-14Make some stuff public so that they can be reused by other toolsPavan Kumar Sunkara-1/+2
2020-05-13Remove hidden VARIATION SELECTOR-16Laurențiu Nicola-2/+2
2020-05-11Merge #4397bors[bot]-1/+1
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 <george@fivetran.com>
2020-05-11Merge #4403bors[bot]-33/+51
4403: Check client capabilities before sending progress notifications r=kjeremy a=kjeremy Fixes #4384 Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
2020-05-11Check client capabilities before sending progress notificationsJeremy Kolb-33/+51
Fixes #4384
2020-05-11Use RA_LOG instead of RUST_LOG for loggingAleksey Kladov-1/+1
RUST_LOG might be set up for debugging the user's problem, slowing down rust-analyzer considerably. That's the same reason why rustc uses RUSTC_LOG.
2020-05-10Use Property instead of Member for fieldsGeorge Fraser-1/+1
2020-05-10Merge #4394 #4414bors[bot]-27/+22
4394: Simplify r=matklad a=Veetaha 4414: Highlighting improvements r=matklad a=matthewjasper - `static mut`s are highlighted as `mutable`. - The name of the macro declared by `macro_rules!` is now highlighted. Co-authored-by: veetaha <veetaha2@gmail.com> Co-authored-by: Matthew Jasper <mjjasper1@gmail.com>
2020-05-10req -> lsp_extAleksey Kladov-42/+46
2020-05-10Don't re-export lsp_typesAleksey Kladov-119/+119
2020-05-10Better fn signatureAleksey Kladov-4/+8