4934: Remove special casing for library symbols r=matklad a=matklad
We might as well handle them internally, via queries.
I am not sure, but it looks like the current LibraryData setup might
even predate salsa? It's not really needed and creates a bunch of
complexity.
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
We might as well handle them internally, via queries.
I am not sure, but it looks like the current LibraryData setup might
even predate salsa? It's not really needed and creates a bunch of
complexity.
4927: Better encapsulate reverse-mapping of files to cargo targets r=matklad a=matklad
We need to find a better way to do it...
CrateGraph by itself is fine, CargoWorkspace as well, but the mapping
between the two seems arbitrary...
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
4913: Remove debugging code for incremental sync r=matklad a=lnicola
4915: Inspect markdown code fences to determine whether to apply syntax highlighting r=matklad a=ltentrup
Fixes#4904
4916: Warnings as hint or info r=matklad a=GabbeV
Fixes#4229
This PR is my second attempt at providing a solution to the above issue. My last PR(#4721) had to be rolled back(#4862) due to it overriding behavior many users expected. This PR solves a broader problem while trying to minimize surprises for the users.
### Problem description
The underlying problem this PR tries to solve is the mismatch between [Rustc lint levels](https://doc.rust-lang.org/rustc/lints/levels.html) and [LSP diagnostic severity](https://microsoft.github.io/language-server-protocol/specification#diagnostic). Rustc currently doesn't have a lint level less severe than warning forcing the user to disable warnings if they think they get to noisy. LSP however provides two severitys below warning, information and hint. This allows editors like VSCode to provide more fine grained control over how prominently to show different diagnostics.
Info severity shows a blue squiggly underline in code and can be filtered separately from errors and warnings in the problems panel.
Hint severity doesn't show up in the problems panel at all and only show three dots under the affected code or just faded text if the diagnostic also has the unnecessary tag.
### Solution
The solution provided by this PR allows the user to configure lists of of warnings to report as info severity and hint severity respectively. I purposefully only convert warnings and not errors as i believe it's a good idea to have the editor show the same severity as the compiler as much as possible.
### Open questions
#### Discoverability
How do we teach this to new and existing users? Should a section be added to the user manual? If so where and what should it say?
#### Defaults
Other languages such as TypeScript report unused code as hint by default. Should rust-analyzer similarly report some problems as hint/info by default?
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
Co-authored-by: Leander Tentrup <leander.tentrup@gmail.com>
Co-authored-by: Gabriel Valfridsson <gabriel.valfridsson@gmail.com>
Anchoring to the SourceRoot wont' work if the path is absolute:
#[path = "/tmp/foo.rs"]
mod foo;
Anchoring to a file will.
However, we *should* anchor, instead of just producing an abs path.
I can imagine a situation where, for example, rust-analyzer processes
crates from different machines (or, for example, from in-memory git
branch), where the same absolute path in different crates might refer
to different files in the end!
4876: Syntactic highlighting of NAME_REF for injections r=matklad a=ltentrup
This commit adds a function that tries to determine the syntax highlighting class of NAME_REFs based on the usage.
It is used for highlighting injections (such as highlighting of doctests) as the semantic logic will most of the time result in unresolved references.
It also adds a color to unresolved references in HTML encoding.
Follow up of #4683.
Fixes#4809.
Co-authored-by: Leander Tentrup <leander.tentrup@gmail.com>
This commit adds a function that tries to determine the syntax highlighting class of NAME_REFs based on the usage.
It is used for highlighting injections (such as highlighting of doctests) as the semantic logic will most of the time result in unresolved references.
It also adds a color to unresolved references in HTML encoding.
4860: Accept relative paths in rust-project.json r=matklad a=tweksteen
If a relative path is found as part of Crate.root_module or Root.path, interpret it as relative to the location of the rust-project.json file.
Fixes: #4816
Co-authored-by: Thiébaud Weksteen <tweek@google.com>
4882: _match.rs: improve comment formatting r=matklad a=jonas-schievink
This results in much nicer rustdoc output
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
It's a good idea to distinguish between absolute and relative paths at
the type level, to avoid accidental dependency on the cwd, which
really shouldn't matter for rust-analyzer service
4700: Add top level keywords completion r=matklad a=mcrakhman
This fixes the following issue: https://github.com/rust-analyzer/rust-analyzer/issues/4566.
Also added simple logic which filters the keywords which can be used with unsafe on the top level.
Co-authored-by: Mikhail Rakhmanov <rakhmanov.m@gmail.com>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
4857: Fix invalid shorthand initialization diagnostic for tuple structs r=jonas-schievink a=OptimalStrategy
Initializing tuple structs explicitly, like in the example below, produces a "Shorthand struct initialization" diagnostic that leads to a compilation error when applied:
```rust
struct S(usize);
fn main() {
let s = S { 0: 0 }; // OK, but triggers the diagnostic
// let s = S { 0 }; // Compilation error
}
```
This PR adds a check that the field name is not a literal.
Co-authored-by: OptimalStrategy <george@usan-podgornov.com>
Co-authored-by: OptimalStrategy <17456182+OptimalStrategy@users.noreply.github.com>
4833: Separating parsing of `for` in predicates and types r=matklad a=matthewjasper
We now correctly accept `for<'a> (&'a F): Fn(&'a str)` in a where clause and correctly reject `for<'a> &'a u32` as a type.
Co-authored-by: Matthew Jasper <mjjasper1@gmail.com>
4849: Make known paths use `core` instead of `std` r=matklad a=jonas-schievink
I'm not sure if this causes problems today, but it seems like it easily could, if rust-analyzer processes the libstd sources for the right `--target` and that target is a `#![no_std]`-only target.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
4819: Add an FST index to `ImportMap` and use it to speed up auto import r=matklad a=jonas-schievink
For the importing crate, we still use the symbol index, but I've modified it to only look at files that comprise that crate (instead of the whole workspace).
Oh, and since now the symbol query limit is respected correctly, it's possible that some results from the local crate now disappear if there are many matches.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/4763
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
4834: In field patterns, don't highlight local binding as a field r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
4822: Let checkOnSafe default to some of the options of cargo r=matklad a=clemenswasser
This will fix#4631
The implementation works (as far as I have tested) but is suboptimal because I am copying the "cargo.features".
Co-authored-by: Clemens Wasser <clemens.wasser@gmail.com>
4824: Correct "debug_assertion" to "debug_assertions" to match the cfg that the rust debug assert macros use. r=matklad a=woody77
This is for #4823.
Co-authored-by: Aaron Wood <aaronwood@google.com>
4576: Add implementation of extract struct from enum variant r=matklad a=mcrakhman
Hi guys! I implemented the extraction functionality including modifying multiple files. The only thing I didn't change the cursor position. I've done it with a previous API, but now snippets have been introduced and I need to figure out how to do it.
Please bear in mind that I am a newcomer in the rust-analyzer (and also Rust) world, so I tried to implement the feature to the best of my knowledge, but the API is very new to me, so I am very welcome to introducing changes etc.
Co-authored-by: Mikhail Rakhmanov <rakhmanov.m@gmail.com>
4784: Change management of test cfg to better support json projects r=Nashenas88 a=Nashenas88
This helps support json projects where they can decide whether to add the `test` cfg or not. One alternative is to add support for marking json project crates as a sysroot crate, and adding logic to remove the `test` cfg in those cases. In my opinion, that option gives less flexibility to json projects and leads to more functionality that needs to be maintained.
Fixes#4508
cc @woody77
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
Co-authored-by: Paul Daniel Faria <nashenas88@users.noreply.github.com>
4775: Add goto def for enum variant field r=matklad a=unexge
Closes#4764. I'm not familiar with ra codebase, there might be better ways to do that 😄
Co-authored-by: unexge <unexge@gmail.com>
4683: Implement syntax highlighting for doctests r=ltentrup a=ltentrup
The implementation is more complicated than the previous injection logic as the doctest comments consist of multiple ranges. The implementation extracts the doctests together with an offset-mapping, applies the syntax highlighting, and updates the text ranges.
<img width="478" alt="Bildschirmfoto 2020-06-01 um 15 45 25" src="https://user-images.githubusercontent.com/201808/83415249-1f0b5800-a41f-11ea-8fa6-c282434d6ff7.png">
Part of #4170.
Co-authored-by: Leander Tentrup <leander.tentrup@gmail.com>
4781: Remove redundancy in syntax highlighting tests r=matklad a=ltentrup
Follow up from #4683. Improves syntax highlighting testing by introducing a function that contains the boilerplate comparison code. Keeps the `ra_fixture` argument in the first position, thus, the editor syntax highlighting injection still works.
Co-authored-by: Leander Tentrup <leander.tentrup@gmail.com>
4770: Clean up handling of int/float literal types r=matklad a=flodiebold
'Unknown' int/float types actually never exist as such, they get replaced by type variables immediately. So the whole `Uncertain<IntTy>` thing was unnecessary and just led to a bunch of match branches that were never hit.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
'Unknown' int/float types actually never exist as such, they get replaced by
type variables immediately. So the whole `Uncertain<IntTy>` thing was
unnecessary and just led to a bunch of match branches that were never hit.
4689: Implement return position impl trait / opaque type support r=matklad a=flodiebold
This is working, but I'm not that happy with how the lowering works. We might need an additional representation between `TypeRef` and `Ty` where names are resolved and `impl Trait` bounds are separated out, but things like inference variables don't exist and `impl Trait` is always represented the same way.
Also note that this doesn't implement correct handling of RPIT *inside* the function (which involves turning the `impl Trait`s into variables and creating obligations for them). That intermediate representation might help there as well.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
4729: Hover actions r=matklad a=vsrs
This PR adds a `hoverActions` LSP extension and a `Go to Implementations` action as an example:
4748: Add an `ImportMap` and use it to resolve item paths in `find_path` r=matklad a=jonas-schievink
Removes the "go faster" queries I added in https://github.com/rust-analyzer/rust-analyzer/pull/4501 and https://github.com/rust-analyzer/rust-analyzer/pull/4506. I've checked this PR on the rustc code base and the assists are still fast.
This should fix https://github.com/rust-analyzer/rust-analyzer/issues/4515.
Note that this does introduce a change in behavior: We now always refer to items defined in external crates using paths through the external crate. Previously we could also use a local path (if for example the extern crate was reexported locally), as seen in the changed test. If that is undesired I can fix that, but the test didn't say why the previous behavior would be preferable.
Co-authored-by: vsrs <vit@conrlab.com>
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
This is working, but I'm not that happy with how the lowering works. We might
need an additional representation between `TypeRef` and `Ty` where names are
resolved and `impl Trait` bounds are separated out, but things like inference
variables don't exist and `impl Trait` is always represented the same
way.
Also note that this doesn't implement correct handling of RPIT *inside* the
function (which involves turning the `impl Trait`s into variables and creating
obligations for them). That intermediate representation might help there as
well.
4740: Remove unneeded "./" prefix affecting error messages r=kjeremy a=dtolnay
I noticed this in the error in the commit message of https://github.com/rust-analyzer/rust-analyzer/pull/4739.
Before:
```console
error[E0599]: no method named `initialize_finish` found for struct `lsp_server::Connection` in the current scope
--> crates/rust-analyzer/./src/bin/main.rs:99:16
|
99 | connection.initialize_finish(initialize_id, initialize_result)?;
| ^^^^^^^^^^^^^^^^^ method not found in `lsp_server::Connection`
```
After:
```console
error[E0599]: no method named `initialize_finish` found for struct `lsp_server::Connection` in the current scope
--> crates/rust-analyzer/src/bin/main.rs:99:16
|
99 | connection.initialize_finish(initialize_id, initialize_result)?;
| ^^^^^^^^^^^^^^^^^ method not found in `lsp_server::Connection`
```
```diff
- --> crates/rust-analyzer/./src/bin/main.rs:99:16
+ --> crates/rust-analyzer/src/bin/main.rs:99:16
```
Co-authored-by: David Tolnay <dtolnay@gmail.com>
4739: Declare required lsp-server dependency of rust-analyzer crate r=jonas-schievink a=dtolnay
My codebase already depended on lsp-server and introducing a dependency on rust-analyzer failed at first because it assumes some functions that were first present in lsp-server 0.3.2.
Without this change:
```console
error[E0599]: no method named `initialize_start` found for struct `lsp_server::Connection` in the current scope
--> crates/rust-analyzer/./src/bin/main.rs:83:57
|
83 | let (initialize_id, initialize_params) = connection.initialize_start()?;
| ^^^^^^^^^^^^^^^^ method not found in `lsp_server::Connection`
error[E0599]: no method named `initialize_finish` found for struct `lsp_server::Connection` in the current scope
--> crates/rust-analyzer/./src/bin/main.rs:99:16
|
99 | connection.initialize_finish(initialize_id, initialize_result)?;
| ^^^^^^^^^^^^^^^^^ method not found in `lsp_server::Connection`
```
Co-authored-by: David Tolnay <dtolnay@gmail.com>
This code is broken by an `impl From<kv::Error> for fmt::Error` in the
log crate when building in a codebase that has the log/kv_unstable
feature enabled.
$ cargo check --manifest-path crates/ra_hir_def/Cargo.toml
Checking ra_hir_def v0.1.0
Finished dev [unoptimized] target(s) in 0.75s
$ cargo check --manifest-path crates/ra_hir_def/Cargo.toml --features log/kv_unstable
Checking ra_hir_def v0.1.0
error[E0282]: type annotations needed for the closure `fn(&str) -> std::result::Result<(), _>`
--> crates/ra_hir_def/src/path.rs:278:17
|
278 | f.write_str("::")?;
| ^^^^^^^^^^^^^^^^^^ cannot infer type
|
help: give this closure an explicit return type without `_` placeholders
|
276 | let mut add_segment = |s| -> std::result::Result<(), _> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Before:
error[E0599]: no method named `initialize_finish` found for struct `lsp_server::Connection` in the current scope
--> crates/rust-analyzer/./src/bin/main.rs:99:16
|
99 | connection.initialize_finish(initialize_id, initialize_result)?;
| ^^^^^^^^^^^^^^^^^ method not found in `lsp_server::Connection`
After:
error[E0599]: no method named `initialize_finish` found for struct `lsp_server::Connection` in the current scope
--> crates/rust-analyzer/src/bin/main.rs:99:16
|
99 | connection.initialize_finish(initialize_id, initialize_result)?;
| ^^^^^^^^^^^^^^^^^ method not found in `lsp_server::Connection`
My codebase already depended on lsp-server and introducing a dependency
on rust-analyzer failed at first because it assumes some functions that
were first present in lsp-server 0.3.2.
Without this change:
error[E0599]: no method named `initialize_start` found for struct `lsp_server::Connection` in the current scope
--> crates/rust-analyzer/./src/bin/main.rs:83:57
|
83 | let (initialize_id, initialize_params) = connection.initialize_start()?;
| ^^^^^^^^^^^^^^^^ method not found in `lsp_server::Connection`
error[E0599]: no method named `initialize_finish` found for struct `lsp_server::Connection` in the current scope
--> crates/rust-analyzer/./src/bin/main.rs:99:16
|
99 | connection.initialize_finish(initialize_id, initialize_result)?;
| ^^^^^^^^^^^^^^^^^ method not found in `lsp_server::Connection`
4660: Enable hover and autocomplete docs on macro generated items r=aloucks a=aloucks
Enable hover and autocomplete docs on macro generated items. This de-sugars doc comments into `doc` attributes in some cases, but not all. Comments and `doc` attributes are then merged together.
This PR is essentially a partial implementation of what's being suggested #3182, but it's not all the way there yet. ~I still need to add unit tests~, but I wanted to first get feedback on whether or not this was an acceptable path forward.
Fixes#4564Fixes#3984Fixes#3180
Related #3182
Co-authored-by: Aaron Loucks <aloucks@cofront.net>
Removes the duplicated `expand_doc_attrs` and `merge_doc_comments_and_attrs`
functions from `ra_ide` and exposes the same functionality via
`ra_hir::Documentation::from_ast`.
Eventually, we should support "just open random rust file" use case,
we don't really do this now, so let's avoid spending time on it until
we fix it properly.
4721: Hide squiggly for unused and unnecessary diagnostics r=matklad a=GabbeV
Fixes#4229
When working with JavaScript or TypeScript in VSCode unused valiables are faded but don't have a squiggle. This PR makes rust-analyzer work similarly by setting the severity to hint when applying the unnecessary tag.
VSCode usually shows a squiggle for error, warning and information and shows three dots for hint. When the unnecessary tag is present the squiggles will still show up but the three dots will not.
This is my first contribution to open source. Please tell me if i need to do anything more to get this PR considered.
Co-authored-by: Gabriel Valfridsson <gabriel.valfridsson@gmail.com>
4658: Fix problem with format string tokenization r=matklad a=ruabmbua
Fixed by just not handling closing curlybrace escaping.
Closes https://github.com/rust-analyzer/rust-analyzer/issues/4637
Co-authored-by: Roland Ruckerbauer <roland.rucky@gmail.com>
4580: Fix invoking cargo without consulting CARGO env var or standard installation paths r=matklad a=Veetaha
Followup for #4329
The pr essentially fixes [this bug](https://youtu.be/EzQ7YIIo1rY?t=2189)
cc @lefticus
Co-authored-by: veetaha <veetaha2@gmail.com>
As per matklad, we now pass the responsibility for finding the binary to the frontend.
Also, added caching for finding the binary path to reduce
the amount of filesystem interactions.
4651: Use first match branch in case of type mismatch, not last r=kjeremy a=flodiebold
The comment says this was intentional, but I do agree with #4304 that it makes
more sense the other way around (for if/else as well).
Fixes#4304.
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
4641: Upgrade Chalk r=matklad a=flodiebold
Chalk newly added TypeName::Never and Array; I implemented the conversion for
Never, but not Array since that expects a const argument.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
4592: fix textedit range returned for completion when left token is a keyword r=bnjjj a=bnjjj
close#4545
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
4596: Strip leading underscores of argument names in function/method r=matklad a=kuy
Closes#4510
### Goal
When I select a function/method from completions, I get a snippet that doesn't contain leading underscores of argument names.
### Solution
- Option 1: All signatures don't contain underscores
- Option 2: Keep same signature, but inserted snippet doesn't contain underscores
I choose Option 2 because I think that leading underscores is a part of "signature". Users should get correct signatures. On the other hand, trimming underscores is an assist by IDE.
### Other impls.
rls: Complete argument names with underscores (same as actual ra)
IntelliJ Rust: Doesn't complete argument names
VSCode (TypeScript): Doesn't complete argument names
### Working example
Co-authored-by: Yuki Kodama <endflow.net@gmail.com>
4625: Partially fix displaying inlay hints in Github PR diff views r=matklad a=Veetaha
See the comment in https://github.com/rust-analyzer/rust-analyzer/issues/4608#issuecomment-63424257
It partially fixes the left side of diff view (the one where old code is displayed), but the diff editor with new code changes still has `file` scheme and will proceed displaying inlay hints...
4629: Fix the `should_panic` snippet r=matklad a=eminence
Closes#4628
Co-authored-by: veetaha <veetaha2@gmail.com>
Co-authored-by: Andrew Chin <achin@eminence32.net>
4534: Add call postfix completion r=matklad a=vain0x
To make it easier to wrap an expression with Ok/Some/Rc::new etc.
Note I agree with conclusion of the discussion in #1431 that adding many completions is not the way to go. However, this PR still could be justified due to versatility of use.
Co-authored-by: vain0x <vainzerox@gmail.com>
The line separator is moved below the function signature to split
regions between the docs. This is very similar to how IntelliJ
displays tooltips. Adding an additional separator between the module
name and function signature currently has rendering issues.
Fixes#4594
Alternative to #4615
4602: Add boolean literal semantic token type to package.json r=matklad a=lnicola
Closes#4583.
CC @GrayJack
4603: Add self keyword semantic token type r=matklad a=lnicola
Not sure if this is warranted a new token type or just a modifier.
---
CC #4583, @GrayJack
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
* Done at line 243: "Add validation of `crate` keyword not appearing in the middle of the symbol path"
* Already happened: "Remove validation of unterminated literals (it is already implemented in `tokenize()`)"
* Happens in `unescape()`: "Add validation of character literal containing only a single char"
* Missing: "raw string literals and raw byte string literals"
4555: VSCode: added patchelf after download for NixOS support r=matklad a=cab404
This adds Nix support, and fixes#4542
4575: Use Chalk's built-in representations for fn items and pointers r=matklad a=flodiebold
The `TypeName::FnDef` was just added; the function pointer variant has existed for a while, I just forgot about it because it's special (because fn pointers can be higher-ranked over lifetimes).
We *could* also make `FnPtr` a separate `Ty` variant instead of a `TypeCtor` variant, which would make the conversion code a bit less special-casey, but it doesn't seem worth doing right now.
Co-authored-by: Vladimir Serov <me@cab404.ru>
Co-authored-by: Cabia Rangris <me@cab404.ru>
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
Function pointers can be 'higher-ranked' over lifetimes, which is why they're
not an application type in Chalk, but since we don't model lifetimes it doesn't
matter for us yet.
4570: Use Chalk's built-in impls r=matklad a=flodiebold
This contains two changes:
- Chalk has begun adding built-in representations of primitive types; use these in our type conversion logic. There's one somewhat 'iffy' part here, namely references; we don't keep track of lifetimes, but Chalk does, so it will expect a lifetime parameter on references. If we didn't provide that, it could cause crashes in Chalk code that expects the lifetime, so I rather hackily add an (always the same) lifetime placeholder during conversion. I expect that we'll fully switch to using Chalk's types everywhere before we add lifetime support, so I think this is the best solution for now.
- let Chalk know about well-known traits (from lang items), so it can apply its built-in impls.
Before:
```
Total expressions: 181485
Expressions of unknown type: 2940 (1%)
Expressions of partially unknown type: 2884 (1%)
Type mismatches: 901
Inference: 37.821210245s, 0b allocated 0b resident
Total: 53.399467609s, 0b allocated 0b resident
```
After:
```
Total expressions: 181485
Expressions of unknown type: 2923 (1%)
Expressions of partially unknown type: 2879 (1%)
Type mismatches: 734
Inference: 39.157752509s, 0b allocated 0b resident
Total: 54.110767621s, 0b allocated 0b resident
```
(I will start splitting up `chalk.rs` in a separate PR, since it's getting pretty big...)
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
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>
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.
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 #144Fixes#4130 (the specific case called out in that issue)
Co-authored-by: kjeremy <kjeremy@gmail.com>
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
4506: Make `find_path_inner` a query r=matklad a=jonas-schievink
This eliminates the remaining performance problems in the "Implement default members" assist (at least those that I've found).
Closes https://github.com/rust-analyzer/rust-analyzer/issues/4498
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
4526: Use a flat play icon instead of the blue emoji with test code lens r=kjeremy a=aloucks
@lnicola
Restores this commit:
55e914a2a1
That was effectively wiped out by this code formatting commit:
dc217bdf903d445256fe
Co-authored-by: Aaron Loucks <aloucks@cofront.net>
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.
4501: Querify `importable_locations_in_crate` r=jonas-schievink a=jonas-schievink
This brings the time needed to compute the `add_missing_impl_members` assist down from ~5 minutes to 20 seconds on my test workload (which is editing within an impl of a MIR [`MutVisitor`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/visit/trait.MutVisitor.html))
cc #4498
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
4497: Create LowerCtx on the fly r=matklad a=edwin0cheng
Previously we create `LowerCtx` at the beginning of lowering, however, the hygiene content is in fact changing between macro expression expanding.
This PR change it to create the `LowerCtx` on the fly to fix above bug.
However, #4465 is not fixed by this PR, the goto-def is still not work yet. It only fixed the infer part.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
4493: Provide builtin impls of Fn traits for fn-pointers r=flodiebold a=hban
Meant to be, but isn't actually a fix for #2880.
Consider this snippet:
```rust
use std::marker::PhantomData;
use std::ops::Deref;
struct Lazy<T, F/* = fn() -> T*/>(F, PhantomData<T>);
impl<T, F> Lazy<T, F> {
pub fn new(f: F) -> Lazy<T, F> {
Lazy(f, PhantomData)
}
}
impl<T, F: FnOnce() -> T> Deref for Lazy<T, F> {
type Target = T;
fn deref(&self) -> &T { todo!() }
}
fn test() {
let lazy1: Lazy<u32, _> = Lazy::new(|| 0u32);
let r1 = lazy1.to_string();
fn make_u32_fn() -> u32 { todo!() }
let make_u32_fn_ptr: fn() -> u32 = make_u32_fn;
let lazy2: Lazy<u32, _> = Lazy::new(make_u32_fn_ptr);
let r2 = lazy2.to_string();
}
```
* On current master:
* When type default is commented-out, `r1` is correctly inferred, `r2` in _{unknown}_.
* When type default is not commented-out, both `r1` and `r2` are _{unknown}_.
* With this PR:
* When type default is commented-out, both `r1` and `r2` are correctly inferred.
* When type default is not commented-out, both `r1` and `r2` are _{unknown}_.
Well, it's a improvement at least. I guess this thing with type defaults is a different problem.
I also tried add Fn impls for fn items, but wasn't successful. So this PR only adds those impls for fn pointers.
Co-authored-by: Hrvoje Ban <hban@users.noreply.github.com>
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>
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>
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>
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#4450Fixes#3441
Co-authored-by: vsrs <vit@conrlab.com>
Co-authored-by: vsrs <62505555+vsrs@users.noreply.github.com>
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
- ❌ 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>
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>
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>
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>
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>
This reverts commit 7a49165f5d.
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.
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>
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:
a91d15c80c..97428b6d52 (diff-6966c729b862f79f79bf7258eb3e0885)
Co-authored-by: George Fraser <george@fivetran.com>
4421: Find references to a function outside module r=flodiebold a=montekki
Fixes#4188
Yet again, it looks like although the code in
da1f316b02/crates/ra_ide_db/src/search.rs (L128-L132)
may be wrong, it is not hit since the `vis` is `None` at this point. The fix is similar to the #4237 case: just add another special case to `Definition::visibility()`.
Co-authored-by: Fedor Sakharov <fedor.sakharov@gmail.com>
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>
4406: Update cargo-metadata r=matklad a=edwin0cheng
This PR update `cargo-metadata` to 0.10.0 and it also relax the` serde-derive` deps to 1.0 for tests in `proc-macro-srv`.
cc @robojumper
r= @matklad , I think you would have something to say related to https://github.com/serde-rs/json/issues/647#issue-593788429 ?
4410: Improve wording in comment r=matklad a=edwin0cheng
4411: do not remove then block when you unwrap else block #4361 r=matklad a=bnjjj
close#4361
4417: Omit default types in HirDisplay SourceCode mode r=matklad a=TimoFreiberg
Closes#4390
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
This fixes an issue where the following code sample would fail to infer
the type contained in the option:
```rust
fn main() {
let mut end = None; // TODO: Fix inference for this in RA
loop {
end = Some(true);
}
}
```
