fix: remove whitespaces from doctest names
When rustdoc runs doctests, it removes whitespaces from the tests' path ([code](25bb1c13bd/src/librustdoc/doctest.rs (L951))). See https://github.com/rust-lang/rust/pull/89422 for details.
Interestingly enough, "Run doctest" has been working without much problem even though rust-analyzer hasn't followed the change. This is because cargo passes the test name to rustdoc via `--test-args` option, and then rustdoc [splits it by whitespace](25bb1c13bd/src/librustdoc/config.rs (L513-L514)); the last element of the split test name **always** matches the test name that rustdoc generates.
However, it may run other tests unexpectedly (to be precise, this has long since been a thing because of the split). Consider the following example:
```rust
struct A<T, U>(T, U);
struct B<T, U>(T, U);
/// ```
/// doctest here
/// ```
impl<T, U> A<T, U> {}
/// ```
/// doctest here
/// ```
impl<T, U> B<T, U> {}
```
When you "Run doctest" either of the two, rustdoc considers "U>" one of the test specs and both doctests are run. This patch fixes it by following rustdoc and removing the whitespace from the doctests' name.
internal: Update `xtask promote` and release instructions
Update `xtask` for the subtree workflow. This doesn't explain how to do a `rust -> RA` sync, since that's definitely more involved, but will probably only happen rarely.
internal: Be more explicit when filtering built-in completions
We return every built-in type here, but only have `u32` in the tests, so let's look for that one to make tests more reliable across platforms.
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.
