Autocomplete 'Pattern not found' when using RLS

[64]

Information

VIM version

NVIM v0.3.1
Build type: Release

Operating System: Arch Linux x86_64

What went wrong

Typing anything results in the message: -- Omni completion (^O^N^P) Pattern not found at the bottom of vim. This seems to be an ALE issue and not a RLS issue since the lints seem to be working fine, only the autocomplete is problematic.

Reproducing the bug

Using this ALE config:

Plug 'w0rp/ale'
let g:ale_sign_column_always = 1
let g:ale_set_highlights = 0
let g:ale_lint_on_enter = 0
let g:ale_completion_enabled = 1
let g:ale_rust_rls_toolchain = 'stable'
let g:ale_linters = {
\ 'python': [],
\ 'javascript': [],
\ 'json': [],
\ 'asm': [],
\ 'c': ['gcc'],
\ 'rust': ['rls'],
\}

1. Download RLS on stable: rustup component add rls-preview
2. Open a rust file, and start typing some code. Any time the autocomplete popup should be triggered, it gives the error message mentioned above and no popup is displayed at all.

:ALEInfo

 Current Filetype: rust
Available Linters: ['cargo', 'rls', 'rustc']
  Enabled Linters: ['rls']
 Suggested Fixers: 
  'remove_trailing_lines' - Remove all blank lines at the end of a file.
  'rustfmt' - Fix Rust files with Rustfmt.
  'trim_whitespace' - Remove all trailing whitespace characters at the end of every line.
 Linter Variables:

let g:ale_rust_rls_executable = 'rls'
let g:ale_rust_rls_toolchain = 'stable'
 Global Variables:

let g:ale_cache_executable_check_failures = v:null
let g:ale_change_sign_column_color = 0
let g:ale_command_wrapper = ''
let g:ale_completion_delay = 100
let g:ale_completion_enabled = 1
let g:ale_completion_max_suggestions = 50
let g:ale_echo_cursor = 1
let g:ale_echo_msg_error_str = 'Error'
let g:ale_echo_msg_format = '%code: %%s'
let g:ale_echo_msg_info_str = 'Info'
let g:ale_echo_msg_warning_str = 'Warning'
let g:ale_enabled = 1
let g:ale_fix_on_save = 0
let g:ale_fixers = {}
let g:ale_history_enabled = 1
let g:ale_history_log_output = 1
let g:ale_keep_list_window_open = 0
let g:ale_lint_delay = 200
let g:ale_lint_on_enter = 0
let g:ale_lint_on_filetype_changed = 1
let g:ale_lint_on_insert_leave = 0
let g:ale_lint_on_save = 1
let g:ale_lint_on_text_changed = 'always'
let g:ale_linter_aliases = {}
let g:ale_linters = {'c': ['gcc'], 'asm': [], 'json': [], 'rust': ['rls'], 'javascript': [], 'python': []}
let g:ale_linters_explicit = 0
let g:ale_list_vertical = 0
let g:ale_list_window_size = 10
let g:ale_loclist_msg_format = '%code: %%s'
let g:ale_max_buffer_history_size = 20
let g:ale_max_signs = -1
let g:ale_maximum_file_size = v:null
let g:ale_open_list = 0
let g:ale_pattern_options = {'.*byteos/.*\.[ch]$': {'ale_linters': {'c': ['gcc']}, 'ale_c_gcc_executable': 'x86_64-elf-gcc', 'ale_c_gcc_options': '-std=gnu11 -Wall -Wextra -Iinclude -ffreestanding -Iinclude/kernel'}}
let g:ale_pattern_options_enabled = v:null
let g:ale_set_balloons = 0
let g:ale_set_highlights = 0
let g:ale_set_loclist = 1
let g:ale_set_quickfix = 0
let g:ale_set_signs = 1
let g:ale_sign_column_always = 1
let g:ale_sign_error = '>>'
let g:ale_sign_info = '--'
let g:ale_sign_offset = 1000000
let g:ale_sign_style_error = '>>'
let g:ale_sign_style_warning = '--'
let g:ale_sign_warning = '--'
let g:ale_statusline_format = v:null
let g:ale_type_map = {}
let g:ale_use_global_executables = v:null
let g:ale_virtualtext_cursor = 0
let g:ale_warn_about_trailing_blank_lines = 1
let g:ale_warn_about_trailing_whitespace = 1
  Command History:

(started) ['/usr/bin/zsh', '-c', '''rls'' +''stable''']

My full init.vim can be found here.

See also this vi stackexchange question I asked, to no avail.

[w0rp]

Sounds like it could be a bug. I'm not sure what the cause will be. Do you have some steps for repeating the bug? A recording on https://asciinema.org/ would be really helpful.

[64]

Here you go: https://asciinema.org/a/EYKWgI05gFJFJ5L5vzNSodknL

I have no clue about how you'd reproduce it. That's just how it is on my machine, all I need to do to trigger that behaviour is open a Rust file as shown.

[gagbo]

For what it's worth, I tried to reproduce it very quickly using my setup, but could not:

• I use the nightly channel of rust, but since we want to see if it's an ALE issue, I thought it would not matter much
• I also use the rust-lang/rust.vim plugin, but as set omnifunc? and a quick search in repo show, it seems like omnifunc is not touched at all by this plugin, so it should not matter either. (It just gives me the cargo compiler to be able to run :make build
• I have all the info I want from completion, even when trying to type use std:: on the first line, as you can see on the asciinema below (I am a slow writer though, please bear with me)

All this to say that I don't think it's an ALE issue (to be complete, I tested it on 92668b6 : 92668b6b (HEAD -> master, origin/master, origin/HEAD) Merge pull request #2117 from gitter-badger/gitter-badge), but either something related to rls (and ALE not being able to handle properly failures from the server ?), or something I don't know/understand.

Maybe having the logs of the communication between ALE and the server would help at this point.

EDIT : I just saw that your bug was on nvim, but I have the exact same working results with

NVIM v0.3.1
Build type: RelWithDebInfo

[64]

How can I obtain those logs? I’m happy to help investigate this further.

[gagbo]

It's part of #2137 , as far as I understand, LSP debugging is something that's been on @w0rp's mind for a while now, and debugging this with Neovim is not very easy. I don't know much about the subject, just that

• Vim provides a ch_logfile() function that would be a very good first step to see what's happening between ale and the server.
• Neovim does not.

[davidcarne]

For what its worth, I ran into this same symptom. Lints seemed to be fine, but completion didn't work.

Root cause was that I didn't have the 'rust-src' component installed. I'm not sure if this is the case for @64, but using rustup to add it fixed it for me.

(I discovered afterword that completion worked for things locally defined; but of course all my tests on completion used std and types from std).

[gagbo]

Good catch. rust-src is necessary to get completion to work with rls (or at least having the sources of the standard library and somehow find a way to tell rls where it is)

[64]

I already have rust-src installed and am still getting the same error. Completion doesn't work for either local or std identifiers.

[johnpangalos]

It could be because you need a Cargo.toml file. I was trying this then tried VSCode. Got that error, went back and added one and then things work. A Cargo.toml is required for rls to work

[frnsys]

I had this same issue (I had rust-src installed, only local definitions were autocompleting, and I had a Cargo.toml file). I managed to fix it by switching over to nightly instead of stable:

let g:ale_completion_enabled = 1
let g:ale_completion_autoimport = 1
let g:ale_rust_rls_toolchain = 'nightly'

And installing rls and rust-src for the nightly toolchain:

rustup component add rust-src rls --toolchain nightly

[sukima]

I ran into this issue as well. When the LSP is spawned omni completion function shows "Pattern not found" But if I run :ALEComplete (via a map) the list populates and from that point on the omni complete function works normally.

This was with tsserver as the LSP. I also let g:ale_completion_enabled = 0 as I cannot stand things changing as I type. I need completion only on demand via ^X^O

[nospam2998]

This seems to be a rls specific issue. That language server has been deprecated and sunset. With it rls no longer available nor working, can we suggest this ticket to be closed?