rust-analyzer: init at unstable-2020-03-09

[oxalica]

Motivation for this change

Add rust-analyzer, an experimental modular compiler frontend for the Rust language.
Also add the vscode extension.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[arcnmx]

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 :(

[jonringer]

I would split this into two commits:

rust-analyzer: init at unstable-2020-01-13
vscode-extensions.rust-analyzer: init at unstable-2020-01-13

[oxalica]

@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.

[oxalica]

Updated to 2020-01-20

[oxalica]

• 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.

[oxalica]

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

[oxalica]

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

[oxalica]

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

[oxalica]

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

[lovesegfault]

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

[lovesegfault]

Pinging @jonringer @worldofpeace for a possible merge.

[lovesegfault]

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

Pinging @jonringer for a review.

[oxalica]

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?

[bqv]

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

[oxalica]

@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.

[bqv]

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.

[oxalica]

@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.

[bqv]

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

[Mic92]

Thanks!

[asdf8dfafjk]

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

[oxalica]

@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.