search

rust-lang / rust.vim

Vim configuration for Rust.
Apache License 2.0
3.9k stars 296 forks source link

:RustFmt Error detected while processing function rustfmt#Format[7]..<SNR>96_RunRustfmt #461

Open lowstar opened 2 years ago

lowstar commented 2 years ago

rust.vim version:

4aa69b84c8a58fcec6b6dad6fe244b916b1cf830

Steps to reproduce:

  1. open any rust file
  2. Issue command :RustFmt<CR>

Expected vs. actual behavior:

Environment:

nvim --version   
NVIM v0.6.0-dev+501-gcb15055c2
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by misko@prime

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/Users/misko/.local/share/nvim"

Run :checkhealth for more info
diegodorado commented 2 years ago

I am having the same issue

medwards commented 2 years ago

I'm having the same issue. The reported line number (eg line 48:) can vary depending on the contents of your .vim folder. I have encountered the problem with nothing but rust.vim in the folder and get line 48, but my normal setup /w other plugins results in line 104 instead.

Environment (stock Ubuntu 20.04 vim)

$ vim --version
VIM - Vi IMproved 8.1 (2018 May 18, compiled Sep 20 2021 11:42:42)
Included patches: 1-2269
Modified by team+vim@tracker.debian.org
Compiled by team+vim@tracker.debian.org
<clipped, remainder available on request>
medwards commented 2 years ago

Unsurprisingly this also occurs when using RustFmtRange.

Here is my RustInfo as well, but this is should just be defaults (I only set g:rustfmt_autosave = 1, which btw appears to be failing silently in this case):

        o
rust.vim Global Variables:

let g:ftplugin_rust_source_path = v:null
rust.vim Global Variables:
let g:ftplugin_rust_source_path = v:null
let g:loaded_syntastic_rust_cargo_checker = v:null
let g:loaded_syntastic_rust_filetype = v:null
let g:loaded_syntastic_rust_rustc_checker = v:null
let g:rust_bang_comment_leader = v:null
let g:rust_cargo_avoid_whole_workspace = v:null
let g:rust_clip_command = v:null
let g:rust_conceal = v:null
let g:rust_conceal_mod_path = v:null
let g:rust_conceal_pub = v:null
let g:rust_fold = v:null
let g:rust_last_args = v:null
let b:rust_last_args = []
let g:rust_last_rustc_args = v:null
let b:rust_last_rustc_args = []
let g:rust_original_delimitMate_excluded_regions = v:null
let g:rust_playpen_url = v:null
let g:rust_prev_delimitMate_quotes = v:null
let g:rust_recent_nearest_cargo_tol = v:null
let g:rust_recent_root_cargo_toml = v:null
let g:rust_recommended_style = v:null
let g:rust_set_conceallevel = v:null
let g:rust_set_conceallevel=1 = v:null
let g:rust_set_foldmethod = v:null
let g:rust_set_foldmethod=1 = v:null
let g:rust_shortener_url = v:null
let g:rustc_makeprg_no_percent = v:null
let g:rustc_path = v:null
let g:rustfmt_autosave = 1
let g:rustfmt_autosave_if_config_present = v:null
let g:rustfmt_command = 'rustfmt'
let g:rustfmt_emit_files = 1
let g:rustfmt_fail_silently = 0
let g:rustfmt_options = ''
let g:syntastic_extra_filetypes = ['rust']
let g:syntastic_rust_cargo_fname = v:null
rustfmt 1.4.37-nightly (574d375 2021-08-07)
rustc 1.56.0-nightly (574d37568 2021-08-07)
cargo 1.56.0-nightly (cc17afbb0 2021-08-02)
medwards commented 2 years ago

I'm not a vimscript writer and have been just jamming echo statements into autoload/rustfmt.vim so take the following /w a grain of salt.

I think there's a problem /w the command, either its construction or execution. The error message is empty because its not a v:shell_error but the error message isn't going to stderr but to normal input. echo out shows Error: file '2' does not exist but the command looks largely correct: rustfmt --emit=stdout --edition 2018 2> /tmp/v6ZzeFa/5.

Deleting the stderr redirection removes the failure and formats the buffer as expected (at the obvious expense that rustfmt errors will probably blast your buffer).

One odd thing is that I expect to be in this branch when invoking :RustFmt (RunRustfmt is called with tmpname being empty) but I end up in the other branch instead. Not sure if this is expected or related, but it delayed my debugging until I figured it out.

roman-kashitsyn commented 2 years ago

I have exactly the same issue, it seems that rustup brings some weird version of rustup with 1.55.0 toolchain:

rustfmt --emit=stdout --color=never src/lib.rs 
Unrecognized option: 'emit'

usage: rustfmt [options] <file>...

Options:
    -h, --help          show this message
    -V, --version       show version information
    -v, --verbose       print verbose output
    -f, --force         force rustfmt to actually run
        --write-mode [replace|overwrite|display|diff|coverage|checkstyle]
                        mode to write in (not usable when piping from stdin)
        --skip-children 
                        don't reformat child modules
        --config-help   show details of rustfmt configuration options
        --dump-default-config PATH
                        Dumps the default configuration to a file and exits.
        --dump-minimal-config PATH
                        Dumps configuration options that were checked during
                        formatting to a file.
        --config-path [Path for the configuration file]
                        Recursively searches the given path for the
                        rustfmt.toml config file. If not found reverts to the
                        input file path
        --file-lines JSON
                        Format specified line ranges. See README for more
                        detail on the JSON format.

There is no --emit flag that was added like 4 years ago.

Interestingly, the version of rustfmt in 1.57.0 toolchain works fine.

Executing rustup update and adding this line to my config fixed the issue

let g:rustfmt_command = '~/.rustup/toolchains/stable-x86_64-apple-darwin/bin/rustfmt'
roman-kashitsyn commented 2 years ago

it seems that rustup brings some weird version of rustup with 1.55.0 toolchain:

This statement is false, the issue is somewhat more subtle: I already had an old ~/.cargo/bin/rustfmt which I probably installed very long time ago, and rustup didn't want to replace it:

warning: tool `cargo-fmt` is already installed, remove it from `/Users/lifted/.cargo/bin`, then run `rustup update` to have rustup manage this tool.

Following the instructions of rustup fixed the issue.

medwards commented 2 years ago

The rustfmt in my .cargo/bin is fairly recent, last installed October 26:

$ ~/.cargo/bin/rustfmt --version
rustfmt 1.4.37-stable (f1edd04 2021-11-29)

The version in my stable toolchain is the same, and my nightly toolchains are all within a single micro version (ie 1.4.38).

I am able to run rustfmt with the --emit argument /wo issue.

I think there may be multiple root causes that aren't obvious because the error reporting from the shell command seems unreliable. In my case, rustup update doesn't fix the bug, nor does rustup component add rustfmt.

rlcintra commented 2 years ago

I was having this issue using NVIM v0.6.0. After some investigation I noticed that Neovim's default installation already includes and autoloads both rust.vim and rustfmt.vim. Checking these files in the repository revealed that these scripts are very old (2017).

Adding the rust-lang/rust.vim plugin to Neovim fixed the issue for me. In my case Plug 'rust-lang/rust.vim' to my nvim config since I use vim-plug. Neovim is now using the latest versions of both rust.vim and rustfmt.vim and the issue is gone.

ocfox commented 2 years ago

Executing rustup update and adding this line to my config fixed the issue

let g:rustfmt_command = '~/.rustup/toolchains/stable-x86_64-apple-darwin/bin/rustfmt'

I think adding vim.g.rustfmt_command = '~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustfmt' to lua would be a good solution.I tried it and it didn't work well. (If I do this, nvim will only print the original code in the console, and the file will not be written with changes. The result is similar to running rustfmt which is already in the PATH) But when I run ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustfmt <file> or rustfmt <file> in the terminal it works fine.

KJLankinen commented 1 year ago

Just to add some information here, I noticed this issue as well, and it seems to only happen on nightly for me.

I'd set rustup override set nightly in a directory and rustfmt gave me this error. After I'd stopped developing a macro, I unset the override, went back to stable and the problem disappeared.

Then again, the versions are different, so it might be related to that. I did have this issue with older versions of both nightly and stable, but I don't have their version information anymore (I updated today and the previous were from ~6 months ago).

Works: stable-x86_64-unknown-linux-gnu (default) rustc 1.67.1 (d5a82bbd2 2023-02-07) rustfmt 1.5.1-stable (d5a82bb 2023-02-07)

Does not work: nightly-x86_64-unknown-linux-gnu (directory override for '/...') rustc 1.69.0-nightly (2d14db321 2023-02-15) rustfmt 1.5.2-nightly (2d14db3 2023-02-15)

emcloughlin commented 1 year ago

I am having the same issue as well. Running :RustFmt in Vim gives the following output, similar to the original issue: Error detected while processing function rustfmt#Format[7]..<SNR>68_RunRustfmt: line 48: E776: No location list

I have tested it in both the current stabe and nightly builds (listed below), and for me, the problem persists regardless.

Builds Tested:

stable-x86_64-unknown-linux-gnu (default) rustc 1.67.1 (d5a82bbd2 2023-02-07) rustfmt 1.5.1-stable (d5a82bb 2023-02-07)

nightly-x86_64-unknown-linux-gnu (directory override for '/...') rustc 1.69.0-nightly (2d14db321 2023-02-15) rustfmt 1.5.2-nightly (2d14db3 2023-02-15)

EDIT: After some experimenting, I think I have determined that, in my case (and in many others on this issue), the issue was due to an issue with the YouCompleteMe plugin autoinstalling an old version of the rust language support for vim. Adding Plug 'rust-lang/rust.vim' to my .vimrc immediately fixed the issue. Given this, and the other comments on this issue, I would reccomend it be closed, as it appears not to be an issue with rust-lang/rust.vim/.

softmoth commented 1 year ago

I'm not using YouCompleteMe, but have the same issue and the same fix (add rust-lang/rust.vim to my lazy plugin manager setup).

Error detected while processing function rustfmt#Format[7]..<SNR>29_RunRustfmt:
line   48:
E776: No location list

How to reproduce

Start with an empty nvim install:

$ ls -ld ~/.local/share/nvim ~/.local/state/nvim ~/.cache/nvim
ls: cannot access '/home/trs/.local/share/nvim': No such file or directory
ls: cannot access '/home/trs/.local/state/nvim': No such file or directory
ls: cannot access '/home/trs/.cache/nvim': No such file or directory

Use this nvim config:

-- Install package manager
--    https://github.com/folke/lazy.nvim
--    `:help lazy.nvim.txt` for more info
local lazypath = vim.fn.stdpath 'data' .. '/lazy/lazy.nvim'
if not vim.loop.fs_stat(lazypath) then
    vim.fn.system {
        'git',
        'clone',
        '--filter=blob:none',
        'https://github.com/folke/lazy.nvim.git',
        '--branch=stable', -- latest stable release
        lazypath,
    }
end
vim.opt.rtp:prepend(lazypath)

require('lazy').setup({
    -- LSP plugins; see lspconfig below for configuration
    {
        'neovim/nvim-lspconfig',
        dependencies = {
            -- Automatically install language servers to stdpath for neovim
            'williamboman/mason.nvim',
            'williamboman/mason-lspconfig.nvim',

            -- Require this manually, to work around RustFmt error:
            --     https://github.com/rust-lang/rust.vim/issues/461
            --
            --'rust-lang/rust.vim',
            --
            -- Side note, this has no errors: vim.lsp.buf.format()
        },
    },
}, {})

local servers = {
    rust_analyzer = {},
}

require('mason').setup()
local mason_lspconfig = require 'mason-lspconfig'
mason_lspconfig.setup {
    ensure_installed = vim.tbl_keys(servers),
}

-- vim: sw=4 et

This is with nvim master from today: NVIM v0.9.0-dev-204a8b1

oatovar commented 1 year ago

TLDR

Install latest plugin version of rust-lang/rust.vim plugin, and if using non-standard shell, set shell to something compatible in your ~/.config/nvim/init.vim or ~/.config/nvim/init.lua.

" ~/.config/nvim/init.vim
set shell=/bin/bash
-- ~/.config/nvim/init.lua
vim.opt.shell = '/bin/bash'

Description

I ran into this issue recently as well, but in my situation, there were two reasons.

The first reason, was my usage of Neovim which comes bundled with an outdated version of this plugin. This caused some incompatibility because my version of rustfmt only supported the --emit flag. I fixed this by installing the latest version of the plugin with lazy.nvim as recommended in https://github.com/rust-lang/rust.vim/issues/461#issuecomment-1005313227.

The second reason was related to my choice of shell. For context, I use nushell as my login shell, and nushell operates quite differently in comparison to other POSIX compatible shells i.e. bash, fish etc. One major difference is the way that it handles stdout and stderr redirection. Nushell does not use 2> to redirect to stdout, so when the rustfmt command executed with the 2> redirection it would fail for me. I was able to fix this by setting my default shell in Neovim to zsh, but highly suspect that this would work for bash and other POSIX compatible shells. While it does work, there is a tradeoff that was made to enable :RustFmt to work again. Now when I launch new terminals in nvim, my shells all use zsh which isn't my shell of choice. I recognize that this part of the cost of using a shell that breaks from common conventions, but I'd like to add support for it if possible. I have very little experience in writing vimscript, but if allowed, I'd like to contribute this enhancement.

diegorodriguezv commented 1 year ago

If you are using Vim 8 it is very easy to install the rust.vim plugin. Just type this in you terminal: git clone https://github.com/rust-lang/rust.vim /.vim/pack/plugins/start/rust.vim After installing a current version the problem dissapears and :RustFmt works as expected.

andrewreeman commented 1 year ago

Just going to add what fixed this for me...I was trying out the dein plugin manager but since I'm such a vim-noob I forgot to actually run call dein#install() to install the plugin.

ghost commented 1 year ago

i still have this problem after running the latest neovim, and adding this plugin. Any idea how to troubleshoot?

Reefersleep commented 8 months ago

Install latest plugin version of rust-lang/rust.vim plugin, and if using non-standard shell, set shell to something compatible in your ~/.config/nvim/init.vim or ~/.config/nvim/init.lua.

" ~/.config/nvim/init.vim
set shell=/bin/bash

This fixed the issue for me. My shell is normally zsh. Cheers!

esmaeelE commented 3 weeks ago

If you are using Vim 8 it is very easy to install the rust.vim plugin. Just type this in you terminal: git clone https://github.com/rust-lang/rust.vim /.vim/pack/plugins/start/rust.vim After installing a current version the problem dissapears and :RustFmt works as expected.

This is exactly solution to run rustfmt command inside vim with :RustFmt

esmaeelE commented 3 weeks ago

If you are using Vim 8 it is very easy to install the rust.vim plugin. Just type this in you terminal: git clone https://github.com/rust-lang/rust.vim /.vim/pack/plugins/start/rust.vim After installing a current version the problem dissapears and :RustFmt works as expected.

This is exactly solution to run rustfmt command inside vim with :RustFmt

But on another machine with Debian sid and below packages without installing vim plugin RistFmt works fine.

$ rustc -V
rustc 1.80.1 (3f5fd8dd4 2024-08-06)
$ rustfmt -V
rustfmt 1.7.0-stable (3f5fd8d 2024-08-06)
$ vim: 9.1