Added the error message to the doc for the UnresolvedProcMacro
diagnostic, explaining that either enabling the procMacro setting
or disabling this diagnostic should make the warnings go away.
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`:
56a7bf7ede/crates/hir_def/src/nameres/path_resolution.rs (L132)
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
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.
r? @jonas-schievink
Fixes#7103
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
7117: Use stable instead of beta on macos-11 release runner r=lnicola a=lnicola
Because beta was promoted to stable yesterday.
bors r+
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
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>
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.
Fixes#7034
Co-authored-by: Kaelin Laundry <wasabifan@outlook.com>
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)
)]))
```
Co-authored-by: lf- <lf-@users.noreply.github.com>
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>
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>
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.
Fixes#6969
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.
Co-authored-by: lf- <lf-@users.noreply.github.com>
