3738: Implement ra_proc_macro client logic r=matklad a=edwin0cheng
This PR add the actual client logic for `ra_proc_macro` crate:
1. Define all necessary rpc serialization data structure, which include `ra_tt` related data and some task messages. Although adding `Serialize` and `Deserialize` trait to ra_tt directly seem to be much easier, we deliberately duplicate the `ra_tt` struct with `#[serde(with = "XXDef")]` for separation of code responsibility.
2. Define a simplified version of lsp base protocol for rpc, which basically copy from lsp-server code base.
3. Implement the actual `IO` for the client side progress spawning and message passing.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3778: Use more functional programming in ArenaMap::insert r=matklad a=kjeremy
I find this more readable and it flattens out the body a little. Others may disagree.
Co-authored-by: kjeremy <kjeremy@gmail.com>
3781: Add crate versions when running cargo -p commands. r=matklad a=o0Ignition0o
If someone (unfortunately) creates a project that happens to have the same name as one of its (future) dependencies, there is [a way for them to change the dependency's alias in the Cargo.toml file](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#renaming-dependencies-in-cargotoml), to mitigate the name conflict. Unfortunately cargo -p commands don't seem to pick it up, which seems to put rust-analyzer run commands in a tough situation:
```
> Executing task: cargo test --package config --example default -- tests --nocapture <
error: There are multiple `config` packages in your project, and the specification `config` is ambiguous.
Please re-run this command with `-p <spec>` where `<spec>` is one of the following:
config:0.1.0
config:0.9.3
The terminal process terminated with exit code: 101
```
cargo suggests us to be more specific and refer to a package by its name and version, which this PR achieves.
I passed the version as a String because I don't really understand how the ra_db types work, but I would love to switch it to [a fully fledged Version type](https://steveklabnik.github.io/semver/semver/index.html) if you guide me towards that :)
Co-authored-by: o0Ignition0o <jeremy.lempereur@gmail.com>
Until now cargo commands with the -p flag would pass the package name only.
It doesn't play super well with the toml Renaming dependencies feature.
This commit specifies the package name and version when a cargo command is run with the -p flag,
to avoid ambiguities.
3785: Attach doc-comment to declaration if there are newlines in between r=matklad a=ltentrup
This commit changes the parser to attach doc-comments to the corresponding declaration in case there are newlines in between the doc-comment and the declaration.
Implements the changes proposed in #3757
Co-authored-by: Leander Tentrup <tentrup@react.uni-saarland.de>
This commit changes the parser to attach doc-comments to the corresponding declaration in case there are newlines in between the doc-comment and the declaration.
3777: Add basic task support r=matklad a=Timmmm
This adds basic support for running `cargo build`, `cargo run`, etc.
Fixes#1935
I have tested this and it seems to work. There are two things I'm not sure about:
1. The workspace folder handling seems wrong - just get the first workspace folder? Is this just a TODO item? I don't know if it is right to lift `workspaceFolder` up to `activate()` but I couldn't see another way.
2. If you manually add an entry to `tasks.json` like this:
```
{
"type": "cargo",
"command": "build",
"problemMatcher": [
"$rustc"
],
"group": "build"
}
```
then VSCode somehow magically knows to run `cargo build`. The documentation for `resolveTask` *sounds* like I should have to implement that for it to work:
```
* Resolves a task that has no [`execution`](#Task.execution) set. Tasks are
* often created from information found in the `tasks.json`-file. Such tasks miss
* the information on how to execute them and a task provider must fill in
* the missing information in the `resolveTask`-method.
```
But then it also says this:
```
* This method will not be
* called for tasks returned from the above `provideTasks` method since those
* tasks are always fully resolved. A valid default implementation for the
* `resolveTask` method is to return `undefined`.
```
Either way, it works without implementing it so the only thing I can think is that it is doing some kind of crazy pattern matching of the tasks returned by `provideTasks()` and the ones found in `tasks.json`.
3784: Ignore createProgress request in tests r=matklad a=matklad
closes#3783
bors r+
🤖
Co-authored-by: Tim <tdhutt@gmail.com>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
