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);
}
}
```
4175: Introduce HirDisplay method for rendering source code & use it in add_function assist r=flodiebold a=TimoFreiberg
Next feature for #3639.
So far the only change in the new `HirDisplay` method is that paths are qualified, but more changes will be necessary (omitting the function name from function types, returning an error instead of printing `"{unknown}"`, probably more).
Is that approach okay?
Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
This starts the transition to a new method of documenting the cfgs that are
enabled for a given crate in the json file. This is changing from a list
of atoms and a dict of key:value pairs, to a list of strings that is
equivalent to that returned by `rustc --print cfg ..`, and parsed in the
same manner by rust-analyzer.
This is the first of two changes, which adds the new field that contains
the list of strings. Next change will complete the transition and remove
the previous fields.
E.g. in
```rust
match x {
1 => function1,
2 => function2,
}
```
we need to try coercing both to pointers. Turns out this is a special case in
rustc as well (see the link in the comment).
4377: Implement better handling of divergence r=matklad a=flodiebold
Divergence here means that for some reason, the end of a block will not be reached. We tried to model this just using the never type, but that doesn't work fully (e.g. in `let x = { loop {}; "foo" };` x should still have type `&str`); so this introduces a `diverges` flag that the type checker keeps track of, like rustc does. We also add some checking for `break`, but no support for break-with-value or labeled breaks yet.
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Divergence here means that for some reason, the end of a block will not be
reached. We tried to model this just using the never type, but that doesn't work
fully (e.g. in `let x = { loop {}; "foo" };` x should still have type `&str`);
so this introduces a `diverges` flag that the type checker keeps track of, like
rustc does.
4329: Look for `cargo`, `rustc`, and `rustup` in standard installation path r=matklad a=cdisselkoen
Discussed in #3118. This is approximately a 90% fix for the issue described there.
This PR creates a new crate `ra_env` with a function `get_path_for_executable()`; see docs there. `get_path_for_executable()` improves and generalizes the function `cargo_binary()` which was previously duplicated in the `ra_project_model` and `ra_flycheck` crates. (Both of those crates now depend on the new `ra_env` crate.) The new function checks (e.g.) `$CARGO` and `$PATH`, but also falls back on `~/.cargo/bin` manually before erroring out. This should allow most users to not have to worry about setting the `$CARGO` or `$PATH` variables for VSCode, which can be difficult e.g. on macOS as discussed in #3118.
I've attempted to replace all calls to `cargo`, `rustc`, and `rustup` in rust-analyzer with appropriate invocations of `get_path_for_executable()`; I don't think I've missed any in Rust code, but there is at least one invocation in TypeScript code which I haven't fixed. (I'm not sure whether it's affected by the same problem or not.) a4778ddb7a/editors/code/src/cargo.ts (L79)
I'm sure this PR could be improved a bunch, so I'm happy to take feedback/suggestions on how to solve this problem better, or just bikeshedding variable/function/crate names etc.
cc @Veetaha
Fixes#3118.
Co-authored-by: Craig Disselkoen <craigdissel@gmail.com>
Co-authored-by: veetaha <veetaha2@gmail.com>
4362: do not show runnables for main function outside of a binary target r=matklad a=bnjjj
close#4356
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
4346: Fix rename of enum variant visible from module r=matklad a=montekki
Probably fixes#4237
It looks like the ref is found correctly in this case but it's visibility is not correctly determined. I took a stab at fixing that by adding an implementation of `HasVisibility` for `EnumVariant` so it works more or less the same way it does for struct fields.
In other words, the `search_range` here does not contain the ref since it's not considered visible:
efd8e34c39/crates/ra_ide_db/src/search.rs (L209-L214)
Before that I tried to populate `ItemScope` with visible enum variants but that ended up with breaking tests all over the place and also it looked illogical in the end: `ItemScope` is not populated with, say, public struct fields and the same should be true for `enum` variants.
I've added two more or less identical tests: one for the case with a struct field rename and one for enum variant rename; the test for struct should probably be removed and the names should be changed.
Co-authored-by: Fedor Sakharov <fedor.sakharov@gmail.com>
4316: do not truncate display for hover r=matklad a=bnjjj
close#4311
4351: Fix Windows server path r=matklad a=lnicola
CC @Coder-256.
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: Laurențiu Nicola <lnicola@users.noreply.github.com>
4166: Defining a default target to support cross-compilation targets r=matklad a=FuriouZz
Related to #4163
Co-authored-by: Christophe MASSOLIN <christophe.massolin@gmail.com>
4306: Make incremental sync opt-out and fix line index rebuild r=matklad a=lnicola
4308: Update server binary paths in docs r=matklad a=Coder-256
Fixed incorrect macOS path and converted to a list. Also, should the Windows path include `matklad.rust-analyzer`? (I can't check)
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
Co-authored-by: Jacob Greenfield <jacob@jacobgreenfield.me>
No tests fail, and quick manual testing shows that there are no
false-positives. In general, each completion contributor should be
independent from the others.
4269: add support of use alias semantic in definition r=matklad a=bnjjj
close#4202
4293: no doctests for flycheck r=matklad a=matklad
bors r+
🤖
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
4285: add support of cfg attributes on enum variants r=edwin0cheng a=bnjjj
close#4279
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
4286: Make incremental sync opt-in r=matklad a=lnicola
@matklad do you want to merge this? I'd make it opt-out, but it's fine to test it more.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
4280: Add documents owner for ImplDef and SourceFile r=matklad a=edwin0cheng
When working on #3182, I found that `ImplDef` and `SourceFile` do not implemet `DocCommentsOwer` trait, and I tested it in `cargo doc` that `impl` could has some doc-comments.
I am not so sure about `SourceFile` case, but in theory if that file is a crate root, the doc comment of it should represent the whole crate documentation, right ?
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
4276: Don't count start of non-ASCII characters as being inside of them r=matklad a=lnicola
I'm still not sure that `utf16_to_utf8_col` is correct for code points from Supplementary Planes. These have two UTF-16 code units, and I feel we're not going to count them correctly.
Fixes the crash in https://github.com/rust-analyzer/rust-analyzer/issues/4263#issuecomment-622988258.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
4207: Add unwrap block assist #4156 r=matklad a=bnjjj
close issue #4156
4253: Remove `workspaceLoaded` setting r=matklad a=eminence
The `workspaceLoaded` notification setting was originally designed to
control the display of a popup message that said:
"workspace loaded, {} rust packages"
This popup was removed and replaced by a much sleeker message in the
VSCode status bar that provides a real-time status while loading:
rust-analyzer: {}/{} packages
This was done as part of #3587
The change in this PR simply renames this setting from `workspaceLoaded` to
`progress` to better describe what it actually controls. At the moment,
the only type of progress message that is controlled by this setting is
the initial load messages, but in theory other messages could also be
controlled by this setting.
Reviewer notes:
* If we didn't like the idea of causing minor breaking to user's config, we could keep the setting name as `workspaceLoaded`
* I think we can now close both #2719 and #3176 since the notification dialog in question no longer exists (actually I think you can close those issues even if you reject this PR 😄 )
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: Andrew Chin <achin@eminence32.net>
The `workspaceLoaded` notification setting was originally designed to
control the display of a popup message that said:
"workspace loaded, {} rust packages"
This popup was removed and replaced by a much sleeker message in the
VSCode status bar that provides a real-time status while loading:
rust-analyzer: {}/{} packages
This was done as part of #3587
The new status-bar indicator is unobtrusive and shouldn't need to be
disabled. So this setting is removed.
4244: Show unsafe trait in hover r=matklad a=DianaNites
Following on #2450 and #4210, for traits.
`unsafe` is the only qualifier they can have, though.
Co-authored-by: Diana <5275194+DianaNites@users.noreply.github.com>
4246: Validate uses of self and super r=matklad a=djrenren
This change follows on the validation of the `crate` keyword in paths. It verifies the following things:
`super`:
- May only be preceded by other `super` segments
- If in a `UseItem` then all semantically preceding paths also consist only of `super`
`self`
- May only be the start of a path
Just a note, a couple times while working on this I found myself really wanting a Visitor of some sort so that I could traverse descendants while skipping sub-trees that are unimportant. Iterators don't really work for this, so as you can see I reached for recursion. Considering paths are generally small a fancy debounced visitor probably isn't important but figured I'd say something in case we had something like this lying around and I wasn't using it.
Co-authored-by: John Renner <john@jrenner.net>
4153: Add support for incremental text synchronization r=matklad a=lnicola
Fixes#3762.
This still needs a `ra_vfs` PR, but I want to know I'm on the right track. I tested the change and it didn't crash horribly, but YMMV.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
4227: Report invalid, nested, multi-segment crate-paths r=matklad a=djrenren
There was a bug in the previous path-validating code that didn't detect multi-segment paths that started with `crate`.
```rust
// Successfully reported
use foo::{crate};
// BUG: was not being reported
use foo::{crate::bar};
```
This was due to my confusion about path-associativity. That is, the path with no qualifier is the innermost path, not the outermost. I've updated the code with a lot of comments to explain what's going on.
This bug was discovered when I found an erroneous `ok` test which I reported here:
https://github.com/rust-analyzer/rust-analyzer/issues/4226
This test now fails and has been modified, hopefully in the spirit of the original test, to be correct. Sorry about submitting the bug in the first place!
Co-authored-by: John Renner <john@jrenner.net>
4178: Validate the location of `crate` in paths r=matklad a=djrenren
**This solution does not fully handle `use` statements. See below**
This pull requests implements simple validation of usages of the `crate` keyword in `Path`s. Specifically it validates that:
- If a `PathSegment` is starts with the `crate` keyword, it is also the first segment of the `Path`
- All other usages of `crate` in `Path`s are considered errors.
This aligns with `rustc`'s rules. Unlike rustc this implementation does not issue a special error message in the case of `::crate` but it does catch the error.
Furthermore, this change does not cover all error cases. Specifically the following is not caught:
```rust
use foo::{crate}
```
This is because this check is context sensitive. From an AST perspective, `crate` is the root of the `Path`. Only by inspecting the full `UseItem` do we see that it is not in fact the root. This problem becomes worse because `UseTree`s are allowed to be arbitrarily nested:
```rust
use {crate, {{crate, foo::{crate}}}
```
So this is a hard problem to solve without essentially a breadth-first search. In a traditional compiler, I'd say this error is most easily found during the AST -> HIR conversion pass but within rust-analyzer I'm not sure where it belongs.
Under the implementation in this PR, such errors are ignored so we're *more correct* just not *entirely correct*.
Co-authored-by: John Renner <john@jrenner.net>
4119: Cache proc-macro dlls r=matklad a=edwin0cheng
This PR try to fix a deadlock in proc-macro srv by not unloading dlls.
Currently we load and unload dlls for each request, however rustc TLS is leaky , such that if we do it a lot of times, all TLS index will be consumed and it will be deadlocked inside panic (it is because panic itself is using TLS too).
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
4204: Use specific pattern when translating if-let-else to match r=matklad a=matklad
We *probably* should actually use the same machinery here, as we do
for fill match arms, but just special-casing options and results seems
to be a good first step.
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
We *probably* should actually use the same machinery here, as we do
for fill match arms, but just special-casing options and results seems
to be a good first step.
4161: lsp-types 0.74 r=kjeremy a=kjeremy
* Fixes a bunch of param types to take partial progress into account.
* Will allow us to support insert/replace text in completions
Co-authored-by: kjeremy <kjeremy@gmail.com>
4193: Make it impossible to forget to add a semantic token type / modifier r=kjeremy a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
4173: Use core instead of std for builtin derive macros r=edwin0cheng a=edwin0cheng
Fixed#4087.
We can't use `$crate` here right now because :
1. We have to able to detect `macro` 2.0 in collecting phase for finding `rustc_builtin_macro` attrs.
2. And we have to make hygiene works for builtin derive macro.
r= @flodiebold
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
So e.g. if we have `fn foo<T: SomeTrait<u32>>() -> T::Item`, we want to lower
that to `<T as SomeTrait<u32>>::Item` and not `<T as SomeTrait<_>>::Item`.
4113: Support returning non-hierarchical symbols r=matklad a=kjeremy
If `hierarchicalDocumentSymbolSupport` is not true in the client capabilites
then it does not support the `DocumentSymbol[]` return type from the
`textDocument/documentSymbol` request and we must fall back to `SymbolInformation[]`.
This is one of the few requests that use the client capabilities to
differentiate between return types and could cause problems for clients.
See https://github.com/microsoft/language-server-protocol/pull/538#issuecomment-442510767 for more context.
Found while looking at #144
4136: add support for cfg feature attributes on expression #4063 r=matklad a=bnjjj
close issue #4063
4141: Fix typo r=matklad a=Veetaha
4142: Remove unnecessary async from vscode language client creation r=matklad a=Veetaha
Co-authored-by: kjeremy <kjeremy@gmail.com>
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: veetaha <veetaha2@gmail.com>
4139: Add check for rules that no repetition which could match an empty token r=matklad a=edwin0cheng
Fix#4103
for `/ui/issues/issue-57597.rs`
This is `ParseError` of the macro rules , because it is how rustc handle it :
a58b1ed44f/src/librustc_expand/mbe/macro_rules.rs (L558)
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
4133: main: eagerly prime goto-definition caches r=matklad a=BurntSushi
This commit eagerly primes the caches used by goto-definition by
submitting a "phantom" goto-definition request. This is perhaps a bit
circuitous, but it does actually get the job done. The result of this
change is that once RA is finished its initial loading of a project,
goto-definition requests are instant. There don't appear to be any more
surprise latency spikes.
This _partially_ addresses #1650 in that it front-loads the latency of the
first goto-definition request, which in turn makes it more predictable and
less surprising. In particular, this addresses the use case where one opens
the text editor, starts reading code for a while, and only later issues the
first goto-definition request. Before this PR, that first goto-definition request
is guaranteed to have high latency in any reasonably sized project. But
after this PR, there's a good chance that it will now be instant.
What this _doesn't_ address is that initial loading time. In fact, it makes it
longer by adding a phantom goto-definition request to the initial startup
sequence. However, I observed that while this did make initial loading
slower, it was overall a somewhat small (but not insignificant) fraction
of initial loading time.
-----
At least, the above is what I _want_ to do. The actual change in this PR is just a proof-of-concept. I came up with after an evening of printf-debugging. Once I found the spot where this cache priming should go, I was unsure of how to generate a phantom input. So I just took an input I knew worked from my printf-debugging and hacked it in. Obviously, what I'd like to do is make this more general such that it will always work.
I don't know whether this is the "right" approach or not. My guess is that there is perhaps a cleaner solution that more directly primes whatever cache is being lazily populated rather than fudging the issue with a phantom goto-definition request.
I created this as a draft PR because I'd really like help making this general. I think whether y'all want to accept this patch is perhaps a separate question. IMO, it seems like a good idea, but to be honest, I'm happy to maintain this patch on my own since it's so trivial. But I would like to generalize it so that it will work in any project.
My thinking is that all I really need to do is find a file and a token somewhere in the loaded project, and then use that as input. But I don't quite know how to connect all the data structures to do that. Any help would be appreciated!
cc @matklad since I've been a worm in your ear about this problem. :-)
Co-authored-by: Andrew Gallant <jamslam@gmail.com>
This commit makes RA more aggressive about eagerly priming the caches.
In particular, this fixes an issue where even after RA was done priming
its caches, an initial goto-definition request would have very high
latency. This fixes that issue by requesting syntax highlighting for
everything. It is presumed that this is a tad wasteful, but not overly
so.
This commit also tweaks the logic that determines when the cache is
primed. Namely, instead of just priming it when the state is loaded
initially, we attempt to prime it whenever some state changes. This
fixes an issue where if a modification notification is seen before cache
priming is done, it would stop the cache priming early.
4134: Special case for empty comments in doc comment kind r=matklad a=edwin0cheng
Part of #4103
Fix `ui/empty/empty-comment.rs macros`
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
4125: Avoid lossy OsString conversions r=matklad a=lnicola
This is a bit invasive, and perhaps for not much benefit since non-UTF-8 environment variables don't work anyway.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
4128: Include correct item path for variant completions r=matklad a=jonas-schievink
The test would previously suggest `E::V`, which is not enough to name the variant as the enum is in a module. Now it correctly suggests the full path `m::E::V`.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
3998: Make add_function generate functions in other modules via qualified path r=matklad a=TimoFreiberg
Additional feature for #3639
- [x] Add tests for paths with more segments
- [x] Make generating the function in another file work
- [x] Add `pub` or `pub(crate)` to the generated function if it's generated in a different module
- [x] Make the assist jump to the edited file
- [x] Enable file support in the `check_assist` helper
4006: Syntax highlighting for format strings r=matklad a=ltentrup
I have an implementation for syntax highlighting for format string modifiers `{}`.
The first commit refactors the changes in #3826 into a separate struct.
The second commit implements the highlighting: first we check in a macro call whether the macro is a format macro from `std`. In this case, we remember the format string node. If we encounter this node during syntax highlighting, we check for the format modifiers `{}` using regular expressions.
There are a few places which I am not quite sure:
- Is the way I extract the macro names correct?
- Is the `HighlightTag::Attribute` suitable for highlighting the `{}`?
Let me know what you think, any feedback is welcome!
Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
Co-authored-by: Leander Tentrup <leander.tentrup@gmail.com>
Co-authored-by: Leander Tentrup <ltentrup@users.noreply.github.com>
If `hierarchicalDocumentSymbolSupport` is not true in the client capabilites
then it does not support the `DocumentSymbol[]` return type from the
`textDocument/documentSymbol` request and we must fall back to `SymbolInformation[]`.
This is one of the few requests that use the client capabilities to
differentiate between return types and could cause problems for clients.
See https://github.com/microsoft/language-server-protocol/pull/538#issuecomment-442510767 for more context.
Found while looking at #144
4101: Panic proc macro srv if read request failed r=matklad a=edwin0cheng
This PR fixed a bug when the rust-analyzer is killed suddenly, the `rust-analyzer proc-macro` will become stale.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
I might be reading this wrong, but it looks like we are setting it to
essentially arbitrary string at the moment, as there are no defined
order on the items in the *set* of completions.
