bors[bot] [Sat, 2 Jan 2021 17:42:45 +0000 (17:42 +0000)]
Merge #7133
7133: Proper handling $crate and local_inner_macros r=jonas-schievink a=edwin0cheng
This PR introduces `HygineFrames` to store the macro definition/call site hierarchy in hyginee and when resolving `local_inner_macros` and `$crate`, we use the token to look up the corresponding frame and return the correct value.
See also: https://rustc-dev-guide.rust-lang.org/macro-expansion.html#hygiene-and-hierarchies
Assist is for now only implemented on if/match-statements where the assigment is the last statement in every block,
as for other cases, one would have to check whether the assignment has effects on the rest of the block and
extract a temporary variable for it in the block.
bors[bot] [Fri, 1 Jan 2021 16:33:45 +0000 (16:33 +0000)]
Merge #7123
7123: Add support for Rust 2021. r=lnicola a=m-ou-se
This adds `2021` in all places where rust-analyzer already knew about `2015` and `2018`.
The only edition-specific behaviour I could find in the source code was gated on a direct comparison with `Edition2015`, so `Edition2021` should (correctly) behave the same as `Edition2018`:
bors[bot] [Fri, 1 Jan 2021 11:06:27 +0000 (11:06 +0000)]
Merge #7116
7116: Fix deep syntax tree bug generated by proc-macro r=jonas-schievink a=edwin0cheng
This PR fixed a bug from `semver-parser` and `pest_derive` crates which generate a very deep syntax tree such that serde reject to de-serialize. To fix this bug, we disabled recursion limit in `serde` (by calling [`Deserializer::disable_recursion_limit`](https://docs.rs/serde_json/1.0.61/serde_json/struct.Deserializer.html#method.disable_recursion_limit))
I have a feeling that we still need some way to protect against bad proc-macro generating huge syntax node, but I have no idea right now.
bors[bot] [Fri, 1 Jan 2021 00:32:59 +0000 (00:32 +0000)]
Merge #7102
7102: Fix completion of Default struct update syntax r=Veykril a=nick96
Previously the inserted text was always `..Default::default()` which ends up as `...Default::default()`
if `.` was typed. Now checks if the current token is `.` and inserts `.Default::default()`
if it is, so `..Default::default()` is correctly completed.
I think there's probably a better way to implement this context aware completion because I've seen it in other parts of rust-analyzer as a user but I'm not sure how to do it.
Fixes #6969
Co-authored-by: Nick Spain <nicholas.spain@stileeducation.com>
bors[bot] [Thu, 31 Dec 2020 15:29:26 +0000 (15:29 +0000)]
Merge #7071
7071: Pass --all-targets to "cargo check" when discovering external resources r=matklad a=WasabiFan
There is a repro case and background in the linked issue.
In short, the goal of this MR is to allow rust-analyzer to discover proc-macros which come from your tests (including, most importantly, dev-dependencies).
By default, `cargo check` implies the equivalent of `--lib --bins`, meaning it'll check your libraries and binaries -- but not tests! This means proc-macros (or, I guess, build scripts as well) weren't discovered by rust-analyzer if they came from tests.
One solution would be to manually add `--lib --bins --tests` (i.e., just augment the effective options to include tests). However, in this MR, I threw in `--all-targets`, which [according to the docs](https://doc.rust-lang.org/cargo/commands/cargo-check.html#target-selection) implies `--benches --examples` too. I have absolutely no idea what repercussions that will have on rust-analyzer for other projects, nor do I know if it's a problem that build scripts will now be discovered for tests/examples/benches. But I am not aware of a reason you _wouldn't_ want to discover these things in your examples too.
I think the main drawback of this change is that it will likely slow down the `cargo check`. At a minimum, it'll now be checking your tests _and_ their dependencies. The `cargo check` docs also say that including `--tests` as I have here may cause your lib crate to be built _twice_, once for the normal target and again for unit tests. My reading of that caveat suggests that "building twice" means it's built once for the tests _inside_ your lib, with a test profile, and again for any consumers of your lib, now using a normal release profile or similar. This doesn't seem surprising.
Very minor caveat: `--tests` will not include tests within a binary if it has `test = false` set in `Cargo.toml`. (I discovered this manually by trial-and-error, but hey, it actually says that in the docs!) This is likely not an issue, but _does_ mean that if you are -- for whatever reason -- disabling tests like that and then manually specifying `cargo test --package <...> --bin <...>` to run them, rust-analyzer will remain unaware of proc-macros in your tests.
I have confirmed this fixes the original issue in my sandbox example linked in #7034 and in my own project in which I originally discovered this. I've left it configured as my default RA language server and will report back if I notice any unexpected side-effects.
bors[bot] [Thu, 31 Dec 2020 13:04:29 +0000 (13:04 +0000)]
Merge #7107
7107: add working dir to cargo metadata fail messages r=matklad a=lf-
Context: I was having an error in my workspace config that I couldn't figure out without this added output. In particular, I have a Code workspace with a docs folder and one of my top level crates [which each have their own custom target], which was picking up the Cargo workspace level Cargo.toml incorrectly [which in my project should not ever be used for the editor], and ultimately had to override it with `linkedProjects`.
Here's a sample of the changed output:
```
[INFO rust_analyzer::main_loop] handle_event(Workspaces([Err(Failed to read Cargo metadata from Cargo.toml file /home/jade/dev/mu/Cargo.toml, cargo 1.50.0-nightly (75d5d8cff 2020-12-22)
Caused by:
0: Failed to run `cargo metadata --manifest-path /home/jade/dev/mu/Cargo.toml` in `/home/jade/dev/mu`
1: Error during execution of `cargo metadata`: error: target path "../../riscv64imac-mu-shoo-elf.json" is not a valid file
Caused by:
No such file or directory (os error 2)
), Err(Failed to read Cargo metadata from Cargo.toml file /home/jade/dev/mu/shoo/Cargo.toml, cargo 1.50.0-nightly (75d5d8cff 2020-12-22)
Caused by:
0: Failed to run `cargo metadata --manifest-path /home/jade/dev/mu/shoo/Cargo.toml` in `/home/jade/dev/mu/shoo`
1: Error during execution of `cargo metadata`: error: target path "../../riscv64imac-mu-shoo-elf.json" is not a valid file
Caused by:
No such file or directory (os error 2)
)]))
```
bors[bot] [Thu, 31 Dec 2020 11:21:23 +0000 (11:21 +0000)]
Merge #7055
7055: Install rustfmt if needed during formatting request r=matklad a=kinnison
In order to fix #6052 and to fix #4249 this PR installs `rustfmt` using `rustup` if `rustfmt --help` fails.
In theory we ought to memoise the attempts (both the `--help` and the installation) so that we don't keep retrying something which will fail (e.g. if nightly is missing rustfmt), but this is a first-pass for opinions.
In order to make it possible to notify the user of what happened, I added a facility for `GlobalStateSnapshot` to send *messages* to the client indicating what happened. There may be a cleaner way to do this as well but I wasn't sure exactly what might be best given this is my first time in this codebase.
It may be worth, longer term, working with `rustup` to provide a way to detect a missing component binary since `rustup` returns `1` if `rustfmt` is not installed, which is not ideal.
Co-authored-by: Daniel Silverstone <dsilvers@digital-scurf.org>
handle_formatting: Notice if rustfmt is missing and report
In an attempt to fix #6052 and #4249 this attempts to detect
if rustfmt is a rustup proxy which isn't installed, and reports
the error message to the user for them to fix.
In theory this ought to be memoised but for now it'll do as-is.
Future work might be to ask the user if they would like us to
trigger the installation (if possible).
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
Nick Spain [Thu, 31 Dec 2020 05:22:59 +0000 (16:22 +1100)]
Fix completion of Default struct update syntax
Previously the inserted text was always `..Default::default()` which ends up as `...Default::default()`
if `.` was typed. Now checks if the current token is `.` and inserts `.Default::default()`
if it is, so `..Default::default()` is correctly completed.
bors[bot] [Wed, 30 Dec 2020 12:55:26 +0000 (12:55 +0000)]
Merge #7091
7091: Add an option for extra env vars in the Code extension r=lf- a=lf-
I was debugging some issues with the RA extension around getting `cargo check` to work and it was particularly frustrating to get the RA_LOG variable set on the server since I had to change it in a login file. This should make that easier.
bors[bot] [Tue, 29 Dec 2020 12:19:31 +0000 (12:19 +0000)]
Merge #7064
7064: Ignore qualifiers when doing autoimport completions lookup r=lnicola a=SomeoneToIgnore
A follow-up of https://github.com/rust-analyzer/rust-analyzer/pull/6918#issuecomment-748511151 and the PR itself.
Tweaks the `import_map` query api to be more flexible with the ways to match against the import path and now fuzzy imports search in names only.
This had improved the completion speed for me locally in ~5 times for `fuzzy_completion` span time, but please recheck me here.
IMO we're fast and presice enough now, so I've added the modules back to the fuzzy search output.
Also tweaks the the expect tests to display functions explicitly, to avoid confusing "duplicate" results.
bors[bot] [Sun, 27 Dec 2020 14:39:05 +0000 (14:39 +0000)]
Merge #6820
6820: Pass the crate environment to proc macros r=jonas-schievink a=jonas-schievink
In theory, fixes https://github.com/rust-analyzer/rust-analyzer/issues/6696.
This seems to result in these obscure crashes for some reason:
```
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/scoped_cell.rs:75:51
stack backtrace:
0: rust_begin_unwind
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:483
1: core::panicking::panic_fmt
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:85
2: core::panicking::panic
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:50
3: core::option::Option<T>::unwrap
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:383
4: proc_macro::bridge::scoped_cell::ScopedCell<T>::replace
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/scoped_cell.rs:75
5: proc_macro::bridge::client::BridgeState::with::{{closure}}
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:291
6: std::thread::local::LocalKey<T>::try_with
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:272
7: std::thread::local::LocalKey<T>::with
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:248
8: proc_macro::bridge::client::BridgeState::with
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:290
9: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::with
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:329
10: proc_macro::bridge::client::run_client::{{closure}}::{{closure}}
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:375
11: proc_macro::bridge::scoped_cell::ScopedCell<T>::set::{{closure}}
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/scoped_cell.rs:80
12: proc_macro::bridge::scoped_cell::ScopedCell<T>::replace
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/scoped_cell.rs:75
13: proc_macro::bridge::scoped_cell::ScopedCell<T>::set
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/scoped_cell.rs:80
14: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::enter::{{closure}}
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:325
15: std::thread::local::LocalKey<T>::try_with
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:272
16: std::thread::local::LocalKey<T>::with
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:248
17: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::enter
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:325
18: proc_macro::bridge::client::run_client::{{closure}}
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:370
19: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:308
20: std::panicking::try::do_call
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:381
21: __rust_try
22: std::panicking::try
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:345
23: std::panic::catch_unwind
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:382
24: proc_macro::bridge::client::run_client
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:369
25: proc_macro::bridge::client::Client<fn(proc_macro::TokenStream) .> proc_macro::TokenStream>::expand1::run
at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:410
26: proc_macro_srv::proc_macro::bridge::server::run_server
27: proc_macro_srv::dylib::Expander::expand
28: proc_macro_srv::ProcMacroSrv::expand
29: proc_macro_srv::cli::run
30: rust_analyzer::main
```
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
bors[bot] [Sun, 27 Dec 2020 13:30:06 +0000 (13:30 +0000)]
Merge #7047
7047: Add force_show_panics flag for proc-macro bridge r=jonas-schievink a=edwin0cheng
https://github.com/rust-lang/rust/pull/75082 and https://github.com/rust-lang/rust/pull/76292 added a new flag in `proc_macro::Bridge` such that the ABI was changed. These ABI changing are the reason of some weird panics which caused #6880 and maybe related to the panic mentioned in #6820.
These changes are landed on rust stable 1.48 so I think it is okay to apply it now.
Aleksey Kladov [Sat, 26 Dec 2020 11:11:42 +0000 (14:11 +0300)]
Simplify assists resolution API
Assist vs UnresolvedAssist split doesn't really pull its weight. This
is especially bad if we want to include `Assist` as a field of
diagnostics, where we'd have to make the thing generic.