fix: Do completions in path qualifier position
Fixes https://github.com/rust-lang/rust-analyzer/issues/12566
Not too happy with the duplication needed for this, but it is what it is. Completions in path qualifiers will have to be filtered properly still, but its better to show too many completions for this than too few for now.
fix: Insert spaces when inlining a function defined in a macro.
(partially) fixes#12860.
This PR (only) addresses the whitespace issue when inlining functions defined in macros.
Additionally, the indentation/spacing is not ideal, but works, e.g.
```rs
macro_rules! define_function {
() => { fn test_function_macro() {
if let Some(3) = 3i32.checked_add(0) {
println!("3 + 0 == 3");
}
} };
}
define_function!();
fn main() {
test_function_macro();
}
// previously became
// ...
fn main() {
ifletSome(3)=3i32.checked_add(0){println!("3 + 0 == 3");};
}
// now becomes
// ...
fn main() {
if let Some(3) = 3i32.checked_add(0){
println!("3 + 0 == 3");
};
}
```
The `self` -> `this` problem[^this] is (probably?) a separate problem that I am also looking into.
[^this]: As mentioned in [my comment on the above issue](https://github.com/rust-lang/rust-analyzer/issues/12860#issuecomment-1193231766), inlining a method defined in a macro does not properly replace `self` with the new local `this`.
Add `rust-analyzer-proc-macro-srv` binary, use it if found in sysroot
This adds a `bin` crate which simply runs `proc_macro_srv::cli::run()` (it does no CLI argument parsing, nothing).
The intent is to build that crate in Rust CI as part of the `dist::Rustc` component, then ship it in the sysroot: it would probably land in something like `~/.rustup/toolchains/nightly-2022-07-23-x86_64-unknown-linux-gnu/libexec/proc-macro-srv-cli`.
This makes https://github.com/rust-lang/rustup/pull/3022 less pressing. (Instead of teaching RA about rustup components, we simply teach it to look in the sysroot via `rustc --print sysroot`. If it can't find `proc-macro-srv-cli`, it falls back to its own `proc-macro` subcommand).
This is closely related to https://github.com/rust-lang/rust-analyzer/issues/12803 (but doesn't close it yet).
Things to address now:
* [ ] What should the binary be named? What should the crate be named? We can pick different names with `[bin]` in the `Cargo.toml`
Things to address later:
* Disable the "multi ABI compatibility scheme" when building that binary in Rust CI (that'll probably happen in `rust-lang/rust`)
* Teaching RA to look in the sysroot
Things to address much, much later:
* Is JSON a good fit here
* Do we want to add versioning to future-proof it?
* Other bikesheds
When built with `--features sysroot` on `nightly-2022-07-23-x86_64-unknown-linux-gnu`, the binary is 7.4MB. After stripping debuginfo, it's 2.6MB. When compressed to `.tar.xz`, it's 619KB.
In a Zulip discussion, `@jyn514` and `@Mark-Simulacrum` seemed to think that those sizes weren't a stopper for including the binary in the rustc component, even before we shrink it down further.
feat: Spawn a proc-macro-srv instance per workspace
cc https://github.com/rust-lang/rust-analyzer/issues/12855
The idea is to have each server be spawned with the appropriate toolchain, that way workspaces with differing toolchains shouldn't suffer from proc-macro abi mismatches.
