support aarch64 for linux and macos

[joske]

The rustfmt (neo)vim plugins installed via mason fetches releases from github. However there are only x86_64 assets in the release. This means on linux aarch64, rustfmt vim plugin is not installable, and on macOS it's installing the x86_64 version so it runs in rosetta, this is not ideal. Note that if you run neovim inside a docker container on apple silicon macs, you also get this problem (it's running aarch64 linux inside).

This PR adds support for aarch64 for linux and macos. The workflows pass, but no artifacts are generated in my fork.

Please let me know if there's anything else needed besides this PR.

[joske]

bump?

[calebcartwright]

Sorry I've been meaning to post here for a bit but haven't really had the time.

This is definitely something I would've been interested in prior to some semi-recent upstream changes, but now I'm leaning towards closing this.

In short, there were some upstream changes made in rustc around how certain modules were packaged (some of the rustc internals rustfmt depends upon). Those changes have in turn made it quite infeasible for us to be able to ship our own self-contained binaries, and practically requires users to have a full toolchain with requisite components.

I haven't had the cycles to see if it's even possible for us to statically link things in from the sysroot, and I'm not sure if we ever will, so the most likely outcome is that we'll stop bundling the binaries in our github releases altogether.

I'm going to test some things out after our next release (perhaps as early as today), and if it seems like this round of binaries are still generally working then I may merge this for expanded arch support within the status quo. If not, then I'll close since we'll just end up deleting the workflow files anyway

Longer term though, I think this model will need to change 👇

The rustfmt (neo)vim plugins installed via mason fetches releases from github.

[joske]

Thanks for replying. I had first created a PR where the rustfmt binary was built from scratch during mason builds, but this idea was rejected there.

If you can not make it work in the status quo like you say, what is the way forward? If you stop producing binaries for all platforms, that means all vim installations will have no rustfmt support anymore :-(.

[calebcartwright]

Thanks for replying. I had first created a PR where the rustfmt binary was built from scratch during mason builds, but this idea was rejected there.

If you can not make it work in the status quo like you say, what is the way forward? If you stop producing binaries for all platforms, that means all vim installations will have no rustfmt support anymore :-(.

Most editor plugins rely on the user to acquire rustfmt via standard models (rustup) and fork out to it. Are there reasons why the vim plugin couldn't do so?

[calebcartwright]

I mean technically the official binaries generated as part of the official Rust release and what rustup grabs are accessible on the internet, though afaik the infra team still strongly discourages people from grabbing those directly

[joske]

I don't know why it was done this way, I guess because the binaries were easily available here. I'm not even sure why it needs to download them at all, I'd wager that if someone wants the rustfmt plugin, he'd have rust installed (and so also rustfmt). For some other vim plugins, mason even builds the needed binaries on the fly (that's what I tried first time as I said).

Anyway, I'll wait a bit to see if you manage to make this work. Please let me know if not and I'll try to find another solution for the mason (build from source or copy from OS path).

[calebcartwright]

Unfortunately the expected behavior with these binaries has started appearing (see #5805). I understand the value having these pre-built binaries can provide, but we're the only official tool that was/is doing so and I just don't think it's going to be feasible for us to continue doing so.

Sorry for the inconvenience, let us know if there's anything else we could do to help on the editor plugin side (even if it's just docs, pinned issue, etc. on our end)

[joske]

thanks for letting me know, this means rustfmt will be broken for all archs going forward, so we'll have to find a solution anyway (as otherwise there won't be any fixes anymore).

What do you propose we can do? The mason team expects plugin installation to take seconds rather than minutes, so building from source locally is not really an option.

[calebcartwright]

My recommendation remains to shift the responsibility of acquiring rustfmt to users. That's the standard model in all other IDE/editor scenarios that I'm aware of, and it feels reasonable to me as well.

Most users will have a toolchain already, and the default rustup profile includes rustfmt amongst other components. The only subset of the audience I could see this burdening would be those that obtained Rust via some default system installation or their system package manager. Even then, I believe the majority of distros have the dev tools available as well through those models, including rustfmt