Conversation
|
We have removed snap support so you will need to rebase and remove that bit of your change, also since this adds a proxy, we must be sure to put it front-and-centre on any release blog post. (the latter there is more for my reference when I prepare changelogs) |
|
Thanks, I have resolved the conflict. |
|
This change is very timely - it's one piece of the puzzle for: There's discussion on Zulip about switching ra from a submodule to a subtree, which would make this even more useful. The sooner this lands, the better (imo). |
src/lib.rs
Outdated
| "rust-gdb", | ||
| "rust-gdbgui", | ||
| "rls", | ||
| "rust-analyzer", |
There was a problem hiding this comment.
Should it be in DUP_TOOLS? That way it won't override a rust-analyzer someone directly installed in .cargo/bin.
There was a problem hiding this comment.
Sure, I went ahead and moved it. I did not realize that the rust-analyzer documentation recommended using cargo install.
There was a problem hiding this comment.
Not cargo install, but we have an x.py-like helper for source builds, cargo xtask install, which installs it under ~/.cargo/bin.
The rust-analyzer documentation includes the step `cargo install` into `~/.cargo/bin` when building from source. Since this has a chance of accidentally overriding the user's copy, move this to DUP_TOOLS.
|
I am loathe to merge this until/unless we are certain it won't confuse others. Is the right answer to get it merged/released just before the stable release which contains r-a ? |
Most VSCode users won't be affected by this — the rust-analyzer VSCode extension will use its own bundled version of rust-analyzer, published on the marketplace within the extension itself. VSCode users who have For other editors, some can download the rust-analyzer binary themselves (e.g. |
@kinnison There's incentive to get it merged before the next Rust stable: it's part of a plan to make proc macros never break again when using rust-analyzer with rust nightly, cf. this zulip message. If this doesn't get merged, there's alternatives (teaching rust-analyzer to use |
As was outlined given
|
Can you say more why that would be? I would not expect this to have any relationship with proc-macro-server. The proxy just means there is a convenient |
|
Reason being we would use the component to also spawn the proc-macro-srv from within r-a, judging from zulip right now we might just go with a standalone proc-macro-srv component though so I retract that statement (we assumed that would take a lot longer to coordinate but that might not be the case) |
|
Based on the zulip conversation, there seems to be some confusion about how rustup works. There is already a component for I agree with pietro that if you can include a small binary in the sysroot, that would be better, though. |
Based on the zulip conversation(s), we're pursuing that path in rust-lang/rust-analyzer#12858 As pointed out by @lnicola, this PR is still valuable for other editors: rust-lang/rust-analyzer#12858 (comment) |
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 rust-lang/rustup#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 #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.
|
@kinnison Just checking in to see if we can get this merged, and get a new release in the next few weeks. |
|
@ehuss I thought r-a had switched to some kind of thing in the compiler component for proc-macros -- do we still want this? |
@kinnison yes. |
Nice to see the proxy merged -- is there a rustup release planned before 1.64 comes out? |
|
Please could someone explain the current status of rust-analyzer and rustup? I can find no mention of rust-analyzer in the rustup release notes, do I still need: Thanks. |
|
@David-Else The rust-analyzer proxy should be available in the next release (1.26) which is currently going through the motions of being released, and should be available soon. |
|
I am on 1.26.0, why do I still need to symlink it manually into |
I don't know the exact behavior here, but afaik rustup tries not to clobber anything in On a recently reinstalled macOS system, |
|
Correct, when rustup updates it won't overwrite any files that were previously added. Just to clarify, if you want to fix your installation, delete your old |
9 participants
This adds
rust-analyzeras a proxy.rust-analyzer is replacing RLS (see https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html). As part of that process, I'd like to make rust-analyzer easier to run for non-VSCode users.
The
rust-analyzercomponent has left preview mode as of rust-lang/rust#98640, which should be part of the 1.64 stable release (September 22, 2022). I think it would be nice to have rustup support that around the same time.The
rust-analyzerproxy was previously added in #2408 and then backed out in #2560 due to being nightly-only.There is some risk this could cause disruption if a user is relying on having
rust-analyzerin their PATH and this gets in the way. I suspect (hope?) that isn't too common. We may want to consider holding off on releasing this until after the 1.64 release.