Merge #4499

4499: CodeLens configuration options r=vsrs a=vsrs

This PR
- adds an option to granularly enable\disable all CodeLens, just like the TypeScript extension.
- fixes a minor bug for doctests. It makes no sense to show `Debug` lens for them as cargo `Can't skip running doc tests with --no-run`.

Co-authored-by: vsrs <vit@conrlab.com>

Add "rust-analyzer.lens.enable"

Merge #4496

4496: Relax VS Code version requirement r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Relax VS Code version requirement

code formatting

Runnable QuickPick with debuggees only

CodeLens configuration options.

Merge #4473

4473: Color macros r=matklad a=georgewfraser

Adds a fallback scope for macros. Before:

<img width="359" alt="Screen Shot 2020-05-15 at 7 31 03 PM" src="https://user-images.githubusercontent.com/1369240/82108339-a304d680-96e2-11ea-9521-e95d5d330c32.png">

After:

<img width="373" alt="Screen Shot 2020-05-15 at 7 29 58 PM" src="https://user-images.githubusercontent.com/1369240/82108308-81a3ea80-96e2-11ea-8660-7f6979df59bf.png">

Note how `hashset` in `maplit::hashset` is now yellow.

Fixes #4462

Co-authored-by: George Fraser <george@fivetran.com>

Merge #4489

4489: Memory allocation optimization r=matklad a=simonvandel

I did some profiling using DHAT, and this was what I could easily optimize without much knowledge of the codebase.

This speeds up analysis-stats on rust-analyser by ~4% on my local machine.

**Benchmark**
➜  rust-analyzer-base git:(master) hyperfine --min-runs=2 '/home/simon/Documents/rust-analyzer/target/release/rust-analyzer analysis-stats .' '/home/simon/Documents/rust-analyzer-base/target/release/rust-analyzer analysis-stats .'
Benchmark #1: /home/simon/Documents/rust-analyzer/target/release/rust-analyzer analysis-stats .
  Time (mean ± σ):     49.621 s ±  0.317 s    [User: 48.725 s, System: 0.792 s]
  Range (min … max):   49.397 s … 49.846 s    2 runs

Benchmark #2: /home/simon/Documents/rust-analyzer-base/target/release/rust-analyzer analysis-stats .
  Time (mean ± σ):     51.764 s ±  0.045 s    [User: 50.882 s, System: 0.756 s]
  Range (min … max):   51.733 s … 51.796 s    2 runs

Summary
  '/home/simon/Documents/rust-analyzer/target/release/rust-analyzer analysis-stats .' ran
    1.04 ± 0.01 times faster than '/home/simon/Documents/rust-analyzer-base/target/release/rust-analyzer analysis-stats .'

Co-authored-by: Simon Vandel Sillesen <simon.vandel@gmail.com>

Merge #4484

4484: Allow calling dyn trait super trait methods without the super trait in scope r=flodiebold a=flodiebold

This also removes some vestiges of the old impl trait support which I think aren't currently in use.

Co-authored-by: Florian Diebold <flodiebold@gmail.com>

Reuse Vec allocations

Reduce reallocations in ra_tt::buffer::TokenBuffer::new_inner

Shrink ra_parser::Event from 32 bytes to 16 bytes

This boxes the Error variant with the assumption that it is rarely constructed

Merge #4472

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 <git@hasali.co.uk>

Add doc comment for resolve_hir_path_qualifier

Allow calling dyn trait super trait methods without the super trait in scope

This also removes some vestiges of the old impl trait support which I think
aren't currently in use.

Merge #4479

4479: Chalk upgrade r=matklad a=flodiebold

This includes the fix for `dyn Trait` super traits, but I noticed that still a lot of `db.super_trait_method()` calls don't work because the super trait isn't in scope (because it doesn't actually need to be). Somehow, I thought we handled that already, but I'll fix it in a separate PR. Also I'll see what happens if we use more of Chalk's new built-in types and traits in a separate PR.

Co-authored-by: Florian Diebold <flodiebold@gmail.com>

Chalk upgrade

Color macros (fixes #4462)

Merge #4288

4288: Add rename self to parameter and back. r=zbsz a=zbsz

This is a first stab at #3439
I liked the idea to do this as a rename instead of separate assist, so I tried implementing that.
It mostly works, but I'm sure there are some cases that I missed, especially in regards to parameter type.

Note: I'm playing with this this as a way to learn Rust and this project. So I'm sure it could be cleaner and put in better places`. Any suggestions?

Co-authored-by: zbsz <zbigniewo@gmail.com>

Add 'self to parameter' renaming.

Fix completion and hover for module and function of same name

Merge #4470

4470: Handle `Self` in values and patterns r=matklad a=flodiebold

I.e.
 - `Self(x)` or `Self` in tuple/unit struct impls
 - `Self::Variant(x)` or `Self::Variant` in enum impls
 - the same in patterns

Fixes #4454.

Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>

Handle `Self` in values and patterns

I.e.
 - `Self(x)` or `Self` in tuple/unit struct impls
 - `Self::Variant(x)` or `Self::Variant` in enum impls
 - the same in patterns

Fixes #4454.

Merge #4448

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>

Fix occasional test run during debug configuration

Merge #4431

4431: Store proc-macro result in salsa db r=matklad a=edwin0cheng

Fixed #4315

Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>

Merge #4460

4460: Remove flycheck -> LSP dependency r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Cleanups

Better structure

Move LSP bits from flycheck to rust-analyzer

There should be only one place that knows about LSP, and that place is
right before we spit JSON on stdout.

Fix runnable naming in the client side fallback.

Merge #4273

4273: Trigger add_vis assist on paths/record fields as well r=flodiebold a=TimoFreiberg

Resolves #4037.

- [x] Function defs
- [x] ADT defs
- [x] Enum variants
- [x] Consts
- [x] Statics
- [x] Traits
- [x] Type aliases
- [x] Modules
- [x] Record fields (using different implementation)
    - [x] struct fields
    - [x] enum variant fields
    - :x:  union fields (`Semantics::resolve_record_field` seems to not work for union fields, so I think this can be handled in a future PR)
- [x] More tests?
- [x] Improve test fixture code and documentation a bit (see [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/resolve_path.20between.20fixture.20files))

Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>

Merge #4456

4456: Sort preselect items on top r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Minor

Put preselect items on top

Better label for a runnable.

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Merge #4455

4455: Prioritize locals with correct types r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Prioritize locals with correct types

Multiple binaries support for launch.json.

Generate unique names on the LSP side.

Mixed "bin" and "test" artifacts workaround.

Merge #4445

4445: Correctly fill default type parameters r=flodiebold a=montekki

Fixes #3877

So, basically even if the parameters are omitted from the `impl` block, check the parameters in `trait` if they have a default type, and if they do go from `hir` to `ast::TypeArg`. I've added a helper for that but I am not sure that it's a proper way to go from `hir` to `ast` here.

Co-authored-by: Fedor Sakharov <fedor.sakharov@gmail.com>

Ty -> Type

Multiple binaries support for launch.json.

Adds a param_idx helper

Fix "rust-analyzer.debug" for  QuickPick binaries.

Runnable quick pick with buttons

Store proc-macro result in salsa db

Merge #4405

4405: Make some stuff public so that they can be reused by other tools r=pksunkara a=pksunkara

So, my little experiment of building a code analysis tool using rust-analyzer is successful. I am going to proceed to build the tool now. This PR makes the needed things public.

I know there were some things about trying to change stuff regarding loading workspaces, which would make it more easier for other tools to reuse. But, until then, it should be okay using this `load_cargo` fn.

Btw, if I were publish my tool, I would need the `ra` crates to be released. Since @matklad told me that he doesn't want to care about breaking stuff, I would propose the following.

Every monday, during the weekly release, we release a new pre v1 minor version of all the crates. That way, we don't need to care about breaking stuff but still have rust-analyzer on crates.io.

I made https://github.com/pksunkara/cargo-workspaces to help release workspace crates easily.

So, coming week, we start with `0.1.0`, then week after that, we release `0.2.0` and then `0.3.0` etc.. until we decide on `1.0.0` which is probably when the compiler team also starts using the crates. There is no limit to the minor versions (we can even have `0.150.0` or `0.1500.0`), so I don't see anything wrong with this strategy.

Co-authored-by: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>

Make some stuff public so that they can be reused by other tools

Merge #4432

4432: Update features.md r=matklad a=bnjjj

Co-authored-by: Coenen Benjamin <benjamin.coenen@hotmail.com>

Remove "rust-analyzer.debug.useLaunchJson" option

Fix formatting

Change type_arg to type_ref func

Use generic_defaults and display_source_code

Merge #4452

4452: Use back ticks instead of single quotes around code r=matklad a=tspiteri

Also, use back ticks instead of single quotes in `rustc_unescape_error_to_string` for `EE:UnclosedUnicodeEscape`.

Co-authored-by: Trevor Spiteri <tspiteri@ieee.org>

Use back ticks instead of single quotes around code

Merge #4447

4447: Remove VARIATION SELECTOR-16 in Run arrow r=matklad a=lnicola

Closes #4446, cc @Veetaha.

Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>

Merge #4400

4400: Enhanced coloring r=georgewfraser a=georgewfraser

This PR builds on #4397 to enhance the existing syntax coloring.

## Underline mutable variables

The textmate scope `markup.underline` underlines identifiers, which is a nice way to make mutable vars stand out:

<img width="327" alt="Screen Shot 2020-05-09 at 1 18 55 PM" src="https://user-images.githubusercontent.com/1369240/81484179-8bb47d80-91f8-11ea-997d-1dcffbe44aa7.png">

## Italicize static variables

The textmate scope `markup.italic` italicizes identifiers. Italic = static is a common convention in IDEs like IntelliJ:

<img width="288" alt="Screen Shot 2020-05-09 at 1 19 14 PM" src="https://user-images.githubusercontent.com/1369240/81484236-cd452880-91f8-11ea-8478-505ee49bc8b3.png">

Co-authored-by: George Fraser <george@fivetran.com>

Remove hidden VARIATION SELECTOR-16

Correctly fill default type parameters

Use launch.json in Debug Lens sessions.

Add the possibility to use existing configurations via Debug Lens

Merge #4444

4444: Update crates r=kjeremy a=kjeremy

Documentation improvements

Co-authored-by: kjeremy <kjeremy@gmail.com>

Update crates

Documentation improvements

Merge #4440

4440: Update packages r=kjeremy a=kjeremy

Co-authored-by: kjeremy <kjeremy@gmail.com>

Bump packages

Merge #4434

4434: add more specific match postfix for Result and Option r=matklad a=bnjjj

In order to have the same behavior than `if let` and `while let`

Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>

Merge #4083

4083: Smol documentation for ast nodes r=matklad a=Veetaha

There is a tremendous amount of TODOs to clarify the topics I am not certain about.
Please @matklad, @edwin0cheng review carefully, I even left some mentions of your names in todos to put your attention where you most probably can give comments.

In order to simplify the review, I separated the codegen (i.e. changes in `ast/generated/nodes.rs`) from `ast_src` changes (they in fact just duplicate one another) into two commits.

Also, I had to hack a little bit to let the docs be generated as doc comments and not as doc attributes because it's easier to read them this way and IIRC we don't support hints for `#[doc = ""]` attributes for now...

Closes #3682

Co-authored-by: veetaha <veetaha2@gmail.com>

Merge #4441

4441: fix typo unimplementated -> unimplemented r=edwin0cheng a=tspiteri

Pretty harmless typo, but it does get exposed in lsp-rust-analyzer-expand-macro.

Co-authored-by: Trevor Spiteri <tspiteri@ieee.org>

fix typo unimplementated -> unimplemented

Pretty harmless typo, but it does get exposed in
lsp-rust-analyzer-expand-macro.

vscode engine 1.45

latest stable

Merge #4439

4439: Update crates r=kjeremy a=kjeremy

Co-authored-by: kjeremy <kjeremy@gmail.com>

Convert TODO about ParamList used in closures to a FIXME

cc @matklad (you didn't comment on this one)

Remove an equals sign from `ConstArg` (this probably pertains only to ConstParam)

(As per matklad)

Remove a comment on NameRefToken as per matklad

Convert TODO to a FIXME as per matklad

Convert TODO to a Note(matklad)

Update crates

Convert to TODOs to FIXMEs as per matklad

Revert "Remove MacroStmts as per edwin0cheng" (cc @edwin0cheng) and add a fixme to document it.

This reverts commit 7a49165f5d5c8186edd04f874eae8a98e39d3df6.
MacroStmts ast node is not used by itself, but it pertains
to SyntaxNodeKind MACRO_STMTS that is used by ra_paser, so
even tho the node itself is not used, it is better to keep it
with a FIXME to actually add a doc comment when it becomes useful.

Add a doc comment on the difference between Name and NameRef ast nodes

Leave statics alone

Mark up statics and mutables

Merge #4436

4436: Use .rust suffix on scopes r=matklad a=georgewfraser

This PR should have no effect on people using any of the default themes, but it is possible there are people with custom themes that rely on the .rust suffix on textmate scopes, which I neglected to use consistently in #4397.

Co-authored-by: George Fraser <george@fivetran.com>

Use .rust suffix on scopes

add more specific match postfix for Result and Option

Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>

Update features.md

Merge pull request #4427 from matklad/old

Use older ubuntu for releases

Use older ubuntu for releases

Merge #4423

4423: add tests module snippet r=bnjjj a=bnjjj

Request from a friend coming from intellij Rust

Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>

Merge #4358

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


Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>

add tests module snippet

Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>

Merge #4397

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>

Merge #4403

4403: Check client capabilities before sending progress notifications r=kjeremy a=kjeremy

Fixes #4384

Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>

Check client capabilities before sending progress notifications

Fixes #4384

Merge #4424

4424: Use RA_LOG instead of RUST_LOG for logging r=matklad a=matklad

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.

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Use RA_LOG instead of RUST_LOG for logging

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.

add tests module snippet

Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>

DebugConfiguration simplification.

${workspaceRoot} substitution in generated DebugConfiguration.

"rust-analyzer.newDebugConfig" command