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>
