languages/rust: move rustaceanvim to extensions submodule

[sjcobb2022]

Hi all,

Quick PR to migrate the rust away from a rustaceanvim-first config, and move it to be extension based. Related to #1195.

There are a few of caveats with this approach which I would appreciate comments on. Those being:

• For some reason rustaceanvim is unable to pick up vim.lsp.config.["rust-analyzer"].cmd even though from my reading of the source code it should be able to do so. Therefore it is set manually for now. See https://github.com/mrcjkb/rustaceanvim/blob/8727e34809a7448b10ebc660c1425c3e808a0004/lua/rustaceanvim/lsp/init.lua#L166-L173.

• rust-analyzer is inherently, and by design, dependent on rustc and cargo. The nvim-lspconfig settings use them, and rust-analyzer itself is dependent on these tools for its own operation. If they are not in PATH, rust-analyzer is quite limited in its capabilities. My question is whether we should include them in vim.extraPackages perhaps? (or place a warning message if they are not present and a rust file is loaded).

• I have used mkForce in 1 area to ensure that we let rustaceanvim do root_dir and on_attach functions. I do not think that this is the most idiomatic. Perhaps setting the default lsp.servers.rust-analyzer.root_dir to a very low mkOverride priority, and then making rustaceanvim override it? I feel like we would then need a warning or assertion because of the wacky priorities.

• Should we add a warning that is present on build saying that we no longer use rustaceanvim by default, or is the changelog enough?

Made with love and without AI.

Sanity Checking

• I have updated the changelog as per my changes
• I have tested, and self-reviewed my code
• My changes fit guidelines found in hacking nvf
• Style and consistency
  • I ran Alejandra to format my code (nix fmt)
  • My code conforms to the editorconfig configuration of the project
  • My changes are consistent with the rest of the codebase
• If new changes are particularly complex:
  • My code includes comments in particularly complex areas
  • I have added a section in the manual
  • (For breaking changes) I have included a migration guide
• Package(s) built:
  • .#nix (default package)
  • .#maximal
  • .#docs-html (manual, must build)
  • .#docs-linkcheck (optional, please build if adding links)
• Tested on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin

---

Add a 👍 reaction to pull requests you find important.

[github-actions]

🚀 Live preview deployed from 0e8df53

View it here:

Debug Information

Triggered by: snoweuph

HEAD at: feat/rustaceanvim

Reruns: 3508

[sjcobb2022]

@NotAShelf @snoweuph I did have a quick question that I think is quite interesting. The current block of nvim-lspconfig settings purely is to get it working with cargo workspaces. rustaceanvim has all of the cargo workspace stuff built in.

Perhaps we could go a different approach, and use rust-analyzer without any of the cargo workspace funk in our preset, and then rely on rustaceanvim for workspace + all its other stuff.

In that way, we could keep the rust-analyzer preset super minimal, and rely on rustaceanvim to do the rest of the cool stuff.

I would appreciate any comments.

[snoweuph]

@NotAShelf @snoweuph I did have a quick question that I think is quite interesting. The current block of nvim-lspconfig settings purely is to get it working with cargo workspaces. rustaceanvim has all of the cargo workspace stuff built in.

Perhaps we could go a different approach, and use rust-analyzer without any of the cargo workspace funk in our preset, and then rely on rustaceanvim for workspace + all its other stuff.

In that way, we could keep the rust-analyzer preset super minimal, and rely on rustaceanvim to do the rest of the cool stuff.

I would appreciate any comments.

I dont like the Idea of relying only partial on the LSP.
The Changes are fine, but the important info is:

The current block of settings purely is to get it working with cargo workspaces.

Basically add t hat as a comment and im fine.

[sjcobb2022]

Basically add t hat as a comment and im fine.

Gotcha

[sjcobb2022]

I had to do some doohickies with to get the option to work nicely. Now using a raw mkOption

Main issues were:

• Missing punctuation (no full stop after "customization")
• Newlines being funky
• Weird heredoc behaviour

If there are any other suggestions for a nicer implementation please do say.

[sjcobb2022]

Formatted

[snoweuph]

Some minor stuff.

generaly looks good to me.
Still needs a final review of @NotAShelf though.

[snoweuph]

could you do one final rebase and solve the conflicts?
I think we can then just merge it afterwards

[sjcobb2022]

oops merged not rebased.

[snoweuph]

oops merged not rebased.

Don't worry will need to squash this anyways

[snoweuph]

LGTM, just a few small docs nicks left.

also because of his nick, requires a final review of @NotAShelf

[snoweuph]

you forgot to run nix fmt after your merge so you got some invalid formatting rn.

[snoweuph]

Gootta doa squash rebase on this and merge as soon as CI passes

[snoweuph]

LGTM

[snoweuph]

@sjcobb2022

Raf will re-review tommorow morning

thanks for your work

[NotAShelf]

I've got some nitpicks, but they're mostly because we don't have established conventions yet. We'll discuss this on Matrix and establish some conventions first, then I can address my nitpicks myself.

Thank you for your good work (and patience)

[snoweuph]

rebased

[alfarelcynthesis]

I'm getting error: The option 'vim.debugger.nvim-dap.adapters.codelldb.executable' does not exist. Definition values: - In '/nix/store/508qpsfwikssr74a1l1xv9cm5c7rkqvw-source/modules/plugins/debugger/nvim-dap/presets/codelldb.nix' from here after this, seems like the correct way is a single command with the args and command together? Not sure, haven't messed with debuggers/nvim-dap much.

This is without the rustaceanvim extension enabled (codelldb is the default debugger), will test with it enabled.

[alfarelcynthesis]

With it enabled (and languages.rust.lsp.enable = false; languages.rust.dap.enable = false;),

nvf/modules/plugins/languages/rust.nix

Line 10 in c55a3a7

inherit (lib.lists) flatten getExe;

throws an error (getExe is from lib.meta).

Reading the source seems to imply that if there were no other eval errors, then with rustaceanvim.enable = true; the error from my last comment would not get hit.

[alfarelcynthesis]

Also, not sure if this is out of the ordinary, but the rustaceanvim setupOpts options that are explicitly defined don't show up in the docs.

Might just be a result of the eval error though?

[snoweuph]

please don't comment in MRs after they closed, please doc it in an issue, stuff inside MRs will get lost and forgotten.

[snoweuph]

setupOpts options that are explicitly defined don't show up in the docs.

Thats a ndg bug I reported to @NotAShelf

[alfarelcynthesis]

please don't comment in MRs after they closed, please doc it in an issue, stuff inside MRs will get lost and forgotten.

That makes sense, sorry about that (I'm used to just putting it in a fix pr). When I have the ability I'll make an issue/pr depending on the situation, will be the next couple days.