Incorrect Variable Name in DAP Request
Description
I encountered a bug in Vimspector while hovering over a specific variable in C++ code. When the cursor is positioned over the word "second" in the following snippet:
for (int i=0; i<6; ++i) {
auto& it = proc.modules.insert(std::make_pair(1620+i,
IMDBG::MODULE())).first->second;
}
the Debug Adapter Protocol (DAP) request to retrieve the value of the variable does not use the expected name ".first->second" Instead, it is sent with the name "."
Moreover, Vimspector does not properly capture variables with scope. For instance, when hovering over a namespaced variable like ns::var, the request sent will simply use "var" instead of "ns::var."
Additionally, Vimspector frequently sends DAP requests with clearly incorrect variable names, such as ")".
A simple check to ensure that variable names do not start with a dot, along with proper handling of variable contexts, could help reduce unnecessary DAP requests and result in cleaner logs.
Is it reproducible in vim?
Reproducible in Vim
Works with clean config?
Yes
Sample project works?
No sample project for this filetype
Minimal Reproduction
List of steps to reproduce:
for (int i=0; i<6; ++i) {
auto& it = proc.modules.insert(std::make_pair(1620+i,
IMDBG::MODULE())).first->second;
}
- Open the C++ file containing the above code snippet in Vimspector.
- Hover the cursor over the word "second."
- Monitor the DAP request generated.
Expected Behaviour
Given that the context for the expression in the parentheses is likely not available, Vimspector should ideally either:
- Construct the request name as ".first->second" to accurately reflect the variable's context.
- Cancel the request altogether when context is unavailable.
Actual Behaviour
The DAP request is sent with the name ".", leading to an incorrect retrieval attempt.
Additional information
No response
Installation Type
Other (specify in notes)
Vimspector version
0da16c67e5fc862ac8988d0580a58d40858f2456
Debug Info
Log file
Vim version
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Mar 25 2024 21:43:35)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-495
Compiled by User@QXP
Huge version with GUI. Features included (+) or not (-):
+acl +cursorbind +iconv/dyn -mzscheme -sodium +vartabs
+arabic +cursorshape +insert_expand -netbeans_intg +sound +vertsplit
+autocmd +dialog_con_gui +ipv6 +num64 +spell +vim9script
+autochdir +diff +job +ole +startuptime +viminfo
+autoservername +digraphs +jumplist +packages +statusline +virtualedit
+balloon_eval -directx +keymap +path_extra -sun_workshop +visual
-balloon_eval_term -dnd +lambda -perl +syntax +visualextra
+browse -ebcdic +langmap +persistent_undo +tag_binary +vreplace
++builtin_terms +emacs_tags +libcall +popupwin -tag_old_static -vtp
+byte_offset +eval +linebreak -postscript -tag_any_white +wildignore
+channel +ex_extra +lispindent +printer -tcl +wildmenu
+cindent +extra_search +listcmds +profile -termguicolors +windows
+clientserver -farsi +localmap -python +terminal +writebackup
+clipboard +file_in_path +lua/dyn +python3/dyn -termresponse -xfontset
+cmdline_compl +find_in_path +menu +quickfix +textobjects -xim
+cmdline_hist +float +mksession +reltime +textprop -xpm_w32
+cmdline_info +folding +modify_fname +rightleft -tgetent -xterm_save
+comments -footer +mouse -ruby +timers
+conceal +fullscreen +mouseshape +scrollbind +title
+cryptv +gettext/dyn +multi_byte_ime/dyn +signs +toolbar
+cscope -hangul_input +multi_lang +smartindent +user_commands
system vimrc file: "$VIM\vimrc"
user vimrc file: "$HOME\_vimrc"
2nd user vimrc file: "$HOME\vimfiles\vimrc"
3rd user vimrc file: "$VIM\_vimrc"
user exrc file: "$HOME\_exrc"
2nd user exrc file: "$VIM\_exrc"
system gvimrc file: "$VIM\gvimrc"
user gvimrc file: "$HOME\_gvimrc"
2nd user gvimrc file: "$HOME\vimfiles\gvimrc"
3rd user gvimrc file: "$VIM\_gvimrc"
defaults file: "$VIMRUNTIME\defaults.vim"
system menu file: "$VIMRUNTIME\menu.vim"
Compilation: gcc -I. -Iproto -static -DWIN32 -DWINVER=0x501 -D_WIN32_WINNT=0x501 -D_WIN32_IE=0x0600 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_STDINT_H -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_JOB_CHANNEL -DFEAT_IPV6 -DFEAT_TERMINAL -DFEAT_SOUND -DFEAT_GUI_MSWIN -DFEAT_CLIPBOARD -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -march=pentium -Wall -Ik:/PROJECTS/OPEN/!3RD/lua-5.3.0/dist/include -Ik:/PROJECTS/OPEN/!3RD/lua-5.3.0/dist -DFEAT_LUA -DDYNAMIC_LUA -DDYNAMIC_LUA_DLL="lua53.dll" -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL="python36.dll" -O3 -fomit-frame-pointer -freg-struct-return
Linking: gcc -I. -Iproto -static -DWIN32 -DWINVER=0x501 -D_WIN32_WINNT=0x501 -D_WIN32_IE=0x0600 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_STDINT_H -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_JOB_CHANNEL -DFEAT_IPV6 -DFEAT_TERMINAL -DFEAT_SOUND -DFEAT_GUI_MSWIN -DFEAT_CLIPBOARD -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -march=pentium -Wall -Ik:/PROJECTS/OPEN/!3RD/lua-5.3.0/dist/include -Ik:/PROJECTS/OPEN/!3RD/lua-5.3.0/dist -DFEAT_LUA -DDYNAMIC_LUA -DDYNAMIC_LUA_DLL="lua53.dll" -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL="python36.dll" -O3 -fomit-frame-pointer -freg-struct-return -s -mwindows -o gvim.exe -lkernel32 -luser32 -lgdi32 -ladvapi32 -lcomdlg32 -lcomctl32 -lnetapi32 -lversion -lwsock32 -lws2_32 -loleaut32 -lwinmm -lole32 -luuid
Python version
No response
Neovim diagnostics
Operating System
No response
Declaration
- [x] I have read and understood CONTRIBUTING.md
- [x] I have read and understood the CODE_OF_CONDUCT.md
in this situation, what expression would you expect vimspector to pick?
vimspector is very dumb about language syntax so It just gets a very simple word under the cursor.
if your expression is more complicated you should use a visual selection, like this:
But tbh in this case, I'm not sure the debugger is even going to be able to give you an evaluation for second
You are right, but it would probably be better not to send the request at all if the variable name is not fully constructed, otherwise you can get the value of another variable with the same name as a class member, I think you need to capture the name taking into account ->/::/. And if it looks incomplete (the first token is not a name), then do not send the request.
I think vimspector uses iskeyword from vim. I can check but there's little chance that I can support the syntax and semantics from every language.
If this is so broken I'll just remove the feature entirely.