Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
lowstar opened this issue Oct 22, 2021 · 17 comments

Comments

@lowstar
Copy link

lowstar commented Oct 22, 2021

rust.vim version:

4aa69b8

Steps to reproduce:

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

Expected vs. actual behavior:

  • expected: file is correctly formatted
  • actual: instead, the following error is shown:
Error detected while processing function rustfmt#Format[7]..<SNR>96_RunRustfmt:
line   48:
E776: No location list

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
Copy link

I am having the same issue

@medwards
Copy link

medwards commented Dec 3, 2021

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
Copy link

medwards commented Dec 3, 2021

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
Copy link

medwards commented Dec 3, 2021

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
Copy link

roman-kashitsyn commented Dec 16, 2021

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
Copy link

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
Copy link

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
Copy link

rlcintra commented Jan 5, 2022

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
Copy link

ocfox commented Jan 13, 2022

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
Copy link

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
Copy link

emcloughlin commented Mar 1, 2023

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
Copy link

softmoth commented Mar 18, 2023

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
Copy link

oatovar commented Mar 28, 2023

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 #461 (comment).

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
Copy link

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
Copy link

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
Copy link

ghost commented Oct 3, 2023

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

Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Jan 31, 2024
@Reefersleep
Copy link

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!

Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Feb 2, 2024
Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Feb 5, 2024
Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Feb 10, 2024
Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Feb 12, 2024
Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Feb 16, 2024
Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Feb 18, 2024
Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Feb 19, 2024
Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Feb 24, 2024
Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Feb 25, 2024
Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Feb 27, 2024
Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Mar 13, 2024
Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Mar 21, 2024
Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Mar 22, 2024
Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Mar 24, 2024
Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Apr 25, 2024
Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Jul 6, 2024
Zhniing added a commit to Zhniing/Dotfiles that referenced this issue Jul 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests