It might be nice if we could split this up into an unwrapped and wrapped derivation. rustcSrc makes a fair dent in the closure size when it might just be overridden and unused (my typical use of it is to wrap it as part of a shell for a specific rust channel).

Also someone with ofborg permissions may want to initiate a darwin build. In the past I've had to include buildInputs = optionals hostPlatform.isDarwin [ darwin.cf-private darwin.apple_sdk.frameworks.CoreServices ]; but haven't checked in a while if it's still necessary.

Finally, not an important point, but I wondered if we could/should build it with the jemalloc feature? I think features still can't be combined with cargo's -p flag yet though so :(

@arcnmx
That's great. But it's not easy to build two packages with features on using a single cargo command. I read the docs of rust-analyzer, and the binary ra_cli is development-only and seems just for benchmarks. To make it easy, I just build the language server ra_lsp_server.
Also, it builds on darwin now.

@jonringer
Splitted.

Updated to 2020-01-20

• Rebased and updated to unstable-2020-01-29.
• Make the vscode extension to use unstable- prefixed version of rust-analyzer, since it is also unstable.
• Add maintainers.
• Some tiny fixes.

Latest version 2020-02-10 is blocked by #79148, which is merged into staging but not in master yet.

Rebased and bumped to 2020-02-11.
Also fixed update script.

Bumped to 2020-02-25 and fix binary name.

• Bump to 2020-03-02.
• Setup fake rustup in checkPhase to avoid patching test code.
• Fix update script.

@oxalica Oh, right, I forgot staging still hasn't been merged. :(

Pinging @jonringer @worldofpeace for a possible merge.

@oxalica 1.42 is in master, you should be able to update this now I think.

Pinging @jonringer for a review.

Do we really need to separate files and commits about rust-analyzer and vscode-extensions.rust-analyzer? They are always updated together.
Would it be better to move the extension derivation (with node-packages.nix) to pkgs/development/tools/rust/rust-analyzer and make a single update commit?

They're separate packages. It's fine for the update commits to always come in pairs, and there's no harm in more granularity

@bqv Note that vscode-extensions.rust-analyzer references rust-analyzer.src but has separated node-packages.nix. So the extension may break when someone checkout the commit of rust-analyzer, due to outdated node-packages.nix.

Granted I'm not overly familiar with vsix instrumentation in nix, but perhaps in this scenario it would be better to have the extension as an output of the main package then? I do see your point, however. My other solution would be to break the dependency between the packages. The duplication isn't too much of an issue since the source would be reused (identical hash) anyway.

@bqv

... it would be better to have the extension as an output of the main package then?

The extension is a node package but rust-analyzer itself is a rust package. We cannot mix them together.

In that case I would suggest refer to the source twice, once in each derivation/commit (unless anyone thinks that's a bad idea)

Thanks!

I like your wrapping approach and would prefer this package stays , since per project shell.nix could be different, and hence the argument to rust-analyzer, that said, its probably worth mentioning that rust-analyzer is now part of standard rust distribution. rust-lang/rust#72978

@asdf8dfafjk
As a compiler-independent tool, I think we cannot benefit a lot from using dist from rust toolchain.

In nixpkgs, we have only stable rustc and cargo, bootstrapped from previous stable version.
That's quite a long time between two stable release of rust, but rust-analyzer could be more actively updated.