Autocomplete always triggers in Rust doc comments

[sersorrel]

Issue Prelude

Please complete these steps and check these boxes (by putting an x inside
the brackets) before filing your issue:

• I have read and understood YCM's CONTRIBUTING document.
• I have read and understood YCM's CODE_OF_CONDUCT document.
• I have read and understood YCM's README, especially the
  Frequently Asked Questions section.
• I have searched YCM's issue tracker to find issues similar to the one I'm
  about to report and couldn't find an answer to my problem. (Example Google
  search.)
• If filing a bug report, I have included the output of vim --version.
• If filing a bug report, I have included the output of :YcmDebugInfo.
• If filing a bug report, I have attached the contents of the logfiles using
  the :YcmToggleLogs command.
• If filing a bug report, I have included which OS (including specific OS
  version) I am using.
• If filing a bug report, I have included a minimal test case that reproduces
  my issue, including what I expected to happen and what actually happened.
• If filing a installation failure report, I have included the entire output
  of install.py (or cmake/make/ninja) including its invocation
• I understand this is an open-source project staffed by volunteers and
  that any help I receive is a selfless, heartfelt gift of their free time. I
  know I am not entitled to anything and will be polite and courteous.
• I understand my issue may be closed if it becomes obvious I didn't
  actually perform all of these steps.

Thank you for adhering to this process! It ensures your issue is resolved
quickly and that neither your nor our time is needlessly wasted.

Issue Details

• What did you do?

I started typing a Rust doc comment (starting with /// instead of //), and the autocomplete menu popped up, even though completion doesn't happen in normal comments.

Type this in a Rust file (extension .rs):

fn main() {}
/// ma

and main will be suggested for autocomplete. If you instead only type two slashes, no autocomplete will happen, because YCM realises that is a comment.

• What did you expect to happen?

When autocompletion in comments is disabled, autocompletion should also not occur in doc comments.

• What actually happened?

Autocompletion always occurs in Rust doc comments.

The line of code here returns Special when in a doc comment (Comment for a normal comment). However, vim-scriptease's zS command prints rustCommentLineDoc.

Removing the call to synIDtrans, i.e. changing the code from

let syntax_group = synIDattr(
        \ synIDtrans( synID( line( '.' ), col( '.' ) - 1, 1 ) ), 'name')

to

let syntax_group = synIDattr(
        \ synID( line( '.' ), col( '.' ) - 1, 1 ), 'name')

seems to fix the problem (since the call now returns rustCommentLineDoc, which contains the string Comment), and I didn't notice any obvious problems caused by that. However, I didn't test very much, hence the issue and not a PR :)

Looking back in the git history, the synIDtrans call was introduced in c3a6ac2, to fix #102 (which was also a "YCM completes in comments" bug...); maybe the real solution would be for YCM to check both the translated and untranslated syntax IDs to see if they contain Comment?

Diagnostic data

Output of vim --version

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Mar  5 2018 09:33:17)
Included patches: 1-1567
Modified by pkg-vim-maintainers@lists.alioth.debian.org
Compiled by pkg-vim-maintainers@lists.alioth.debian.org
Huge version without GUI.  Features included (+) or not (-):
+acl               +farsi             +mouse_sgr         -tag_any_white
+arabic            +file_in_path      -mouse_sysmouse    -tcl
+autocmd           +find_in_path      +mouse_urxvt       +termguicolors
-autoservername    +float             +mouse_xterm       +terminal
-balloon_eval      +folding           +multi_byte        +terminfo
+balloon_eval_term -footer            +multi_lang        +termresponse
-browse            +fork()            -mzscheme          +textobjects
++builtin_terms    +gettext           +netbeans_intg     +timers
+byte_offset       -hangul_input      +num64             +title
+channel           +iconv             +packages          -toolbar
+cindent           +insert_expand     +path_extra        +user_commands
-clientserver      +job               -perl              +vertsplit
-clipboard         +jumplist          +persistent_undo   +virtualedit
+cmdline_compl     +keymap            +postscript        +visual
+cmdline_hist      +lambda            +printer           +visualextra
+cmdline_info      +langmap           +profile           +viminfo
+comments          +libcall           -python            +vreplace
+conceal           +linebreak         +python3           +wildignore
+cryptv            +lispindent        +quickfix          +wildmenu
+cscope            +listcmds          +reltime           +windows
+cursorbind        +localmap          +rightleft         +writebackup
+cursorshape       -lua               -ruby              -X11
+dialog_con        +menu              +scrollbind        -xfontset
+diff              +mksession         +signs             -xim
+digraphs          +modify_fname      +smartindent       -xpm
-dnd               +mouse             +startuptime       -xsmp
-ebcdic            -mouseshape        +statusline        -xterm_clipboard
+emacs_tags        +mouse_dec         -sun_workshop      -xterm_save
+eval              +mouse_gpm         +syntax
+ex_extra          -mouse_jsbterm     +tag_binary
+extra_search      +mouse_netterm     +tag_old_static
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H   -Wdate-time  -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc   -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o vim        -lm -ltinfo -lnsl  -lselinux  -lacl -lattr -lgpm -ldl     -L/usr/lib/python3.5/config-3.5m-arm-linux-gnueabihf -lpython3.5m -lpthread -ldl -lutil -lm

Output of YcmDebugInfo

Printing YouCompleteMe debug information...
-- Client logfile: /tmp/ycm_9hfqgqad.log
-- Server Python interpreter: /usr/bin/python3.6
-- Server Python version: 3.6.3
-- Server has Clang support compiled in: False
-- Clang version: None
-- No extra configuration file found
-- Rust completer debug information:
--   Racerd running at: http://127.0.0.1:36876
--   Racerd process ID: 30206
--   Racerd executable: /home/josh/.vim/plugged/YouCompleteMe/third_party/ycmd/third_party/racerd/target/release/racerd
--   Racerd logfiles:
--     /tmp/racerd_36876_stdout_zokxuuw_.log
--     /tmp/racerd_36876_stderr_7erxn5w3.log
--   Rust sources: /home/josh/.rustup/toolchains/stable-armv7-unknown-linux-gnueabihf/lib/rustlib/src/rust/src
-- Server running at: http://127.0.0.1:53765
-- Server process ID: 30148
-- Server logfiles:
--   /tmp/ycmd_53765_stdout_v6ar1va0.log
--   /tmp/ycmd_53765_stderr_e9zahlkr.log

Contents of YCM, ycmd and completion engine logfiles

Logs

OS version, distribution, etc.

Ubuntu 16.04.4

[micbou]

Thanks for the report. PR #3002 should fix the issue. It's based on your suggestion to check the translated and untranslated name of the syntax item (and also on the use of synstack to get the list of syntax items at the cursor position).

[puremourning]

The linked PR is not likely to be completed any time soon.

[puremourning]

Very old issue with little support for the closed PR.