zeechs commented 5 years ago

Issue Prelude

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

[x] I have read and understood YCM's CONTRIBUTING document.
[ ] I have read and understood YCM's CODE_OF_CONDUCT document.
[x] I have read and understood YCM's README, especially the Frequently Asked Questions section.
[x] 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.)
[x] If filing a bug report, I have included the output of vim --version.
[x] If filing a bug report, I have included the output of :YcmDebugInfo.
[x] If filing a bug report, I have attached the contents of the logfiles using the :YcmToggleLogs command.
[x] If filing a bug report, I have included which OS (including specific OS version) I am using.
[x] 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
[x] 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.
[x] 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

Provide a clear description of the problem, including the following key questions:

Your template is missing a Hello section so I will say hi here in the wrong section :)

YCM (or Clang?) does not seem to understand the response file syntax (e.g. @CMakeFiles/MyApp.dir/includes_CXX.rsp) in the compile_commands.json file.

This does not work. It says file not found on Qt included files:

[
{
  "directory": "C:/dev/projects/myapp/_build",
  "command": "C:\\dev\\tools\\qt\\Tools\\mingw730_32\\bin\\g++.exe   -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB  @CMakeFiles/MyApp.dir/includes_CXX.rsp   -o CMakeFiles\\MyApp.dir\\main.cpp.obj -c C:\\dev\\projects\\myapp\\main.cpp",
  "file": "C:/dev/projects/myapp/main.cpp"
}
]

While this works. I manually substituted @CMakeFiles/MyApp.dir/includes_CXX.rsp with the content of the file includes_CXX.rsp:

[
{
  "directory": "C:/dev/projects/myapp/_build",
  "command": "C:\\dev\\tools\\qt\\Tools\\mingw730_32\\bin\\g++.exe  -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB -isystem C:/dev/tools/qt/5.13.1/mingw73_32/include -isystem C:/dev/tools/qt/5.13.1/mingw73_32/include/QtCore -isystem C:/dev/tools/qt/5.13.1/mingw73_32/./mkspecs/win32-g++ -isystem C:/dev/tools/qt/5.13.1/mingw73_32/include/QtWidgets -isystem C:/dev/tools/qt/5.13.1/mingw73_32/include/QtGui -isystem C:/dev/tools/qt/5.13.1/mingw73_32/include/QtANGLE    -o CMakeFiles\\MyApp.dir\\main.cpp.obj -c C:\\dev\\projects\\myapp\\main.cpp",
  "file": "C:/dev/projects/myapp/main.cpp"
}
]

What did you do?

Include steps to reproduce here.

I installed YCM plugin Started a sample C++/Qt project with CMake(3.15, but also tried 3.10 and 3.2) Exported compilation database and moved it to project root folder note: the compiler is MinGW.

Include description of a minimal test case, including any actual code required to reproduce the issue.

cmake_minimum_required(VERSION 3.2.3)

project(MyApp)

# find Qt
find_package(Qt5 REQUIRED COMPONENTS Core Widgets)

# project source files
set(SRC main.cpp)

# create executable
add_executable(${PROJECT_NAME} ${SRC})
target_link_libraries(${PROJECT_NAME} Qt5::Core Qt5::Widgets)

#include <QApplication>
#include <QWidget>
#include <iostream>

int main (int argc, char* argv[])
{
    QApplication app(argc, argv);

    QWidget win;
    win.show();

    return app.exec();
}

Here the QApplication and the QWidget headers are not found. iostream is found though and completion is triggered after typing std:: and suggests std::cout etc.

What did you expect to happen?

Include description of the expected behaviour.

The generated compile_commands.json should be parsed correctly, and all the headers included in the project should be found by YCM/Clang.

What actually happened?

Include description of the observed behaviour, including actual output, screenshots, etc.

The response file inclusions found in the compile_command.json file, such as @CMakeFiles/MyApp.dir/includes_CXX.rsp are ignored, and no include path is taken into account. The compilation fails with file not found errors. And YCM does not provide any completion suggestion.

Diagnostic data

Output of `vim --version`

Place the output here, or a link to a gist.

VIM - Vi IMproved 8.1 (2018 May 18, compiled Sep 26 2019 22:16:35)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-2080
Compiled by appveyor@APPVYR-WIN
Huge version with GUI.  Features included (+) or not (-):
+acl                +byte_offset        +conceal            -dnd                +float              +keymap             +menu               +num64              +python/dyn         +sound              +tcl/dyn            +toolbar            -vtp
+arabic             +channel            +cryptv             -ebcdic             +folding            +lambda             +mksession          +ole                +python3/dyn        +spell              -termguicolors      +user_commands      +wildignore
+autocmd            +cindent            +cscope             +emacs_tags         -footer             +langmap            +modify_fname       +packages           +quickfix           +startuptime        +terminal           +vartabs            +wildmenu
+autochdir          +clientserver       +cursorbind         +eval               +gettext/dyn        +libcall            +mouse              +path_extra         +reltime            +statusline         -termresponse       +vertsplit          +windows
+autoservername     +clipboard          +cursorshape        +ex_extra           -hangul_input       +linebreak          +mouseshape         +perl/dyn           +rightleft          -sun_workshop       +textobjects        +virtualedit        +writebackup
+balloon_eval       +cmdline_compl      +dialog_con_gui     +extra_search       +iconv/dyn          +lispindent         +multi_byte_ime/dyn +persistent_undo    +ruby/dyn           +syntax             +textprop           +visual             -xfontset
-balloon_eval_term  +cmdline_hist       +diff               -farsi              +insert_expand      +listcmds           +multi_lang         -postscript         +scrollbind         +tag_binary         -tgetent            +visualextra        -xim
+browse             +cmdline_info       +digraphs           +file_in_path       +job                +localmap           +mzscheme/dyn       +printer            +signs              -tag_old_static     +timers             +viminfo            +xpm_w32
++builtin_terms     +comments           +directx            +find_in_path       +jumplist           +lua/dyn            +netbeans_intg      +profile            +smartindent        -tag_any_white      +title              +vreplace           -xterm_save
   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: cl -c /W3 /nologo  -I. -Iproto -DHAVE_PATHDEF -DWIN32  -DFEAT_CSCOPE -DFEAT_TERMINAL -DFEAT_SOUND -DFEAT_NETBEANS_INTG -DFEAT_JOB_CHANNEL   -DFEAT_XPM_W32   -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 /MP -DHAVE_STDINT_H /Ox /GL -DNDEBUG /arch:IA32 /Zl /MT -DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_GUI_MSWIN -DFEAT_DIRECTX -DDYNAMIC_DIRECTX -DFEAT_DIRECTX_COLOR_EMOJI -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_TCL -DDYNAMIC_TCL -DDYNAMIC_TCL_DLL=\"tcl86t.dll\" -DDYNAMIC_TCL_VER=\"8.6\" -DFEAT_LUA -DDYNAMIC_LUA -DDYNAMIC_LUA_DLL=\"lua53.dll\" -DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\"python37.dll\" -DFEAT_MZSCHEME -I "C:\Program Files (x86)\Racket\include" -DMZ_PRECISE_GC -DDYNAMIC_MZSCHEME -DDYNAMIC_MZSCH_DLL=\"libracket3m_a36fs8.dll\" -DDYNAMIC_MZGC_DLL=\"libracket3m_a36fs8.dll\" -DFEAT_PERL -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"perl528.dll\" -DFEAT_RUBY -DDYNAMIC_RUBY -DDYNAMIC_RUBY_VER=24 -DDYNAMIC_RUBY_DLL=\"msvcrt-ruby240.dll\" -DFEAT_HUGE /Fd.\ObjGXOULYHTRZi386/ /Zi
Linking: link  /nolog

Output of `YcmDebugInfo`

Place the output here, or a link to a gist.

Printing YouCompleteMe debug information...
-- Client logfile: C:\Users\sylvain\AppData\Local\Temp\ycm_7tumfogn.log
-- Server Python interpreter: C:\dev\tools\python\python37_32\python.exe
-- Server Python version: 3.7.4
-- Server has Clang support compiled in: True
-- Clang version: clang version 8.0.0 (tags/RELEASE_800/final)
-- No extra configuration file found
-- C-family completer debug information:
--   Compilation database path: C:\dev\projects\myapp
--   Flags: ['C:\\dev\\tools\\qt\\Tools\\mingw730_32\\bin\\g++.exe', '-DQT_CORE_LIB', '-DQT_GUI_LIB', '-DQT_NO_DEBUG', '-DQT_WIDGETS_LIB', '-resource-dir=C:\\Users\\sylvain\\vimfiles\\pack\\plugins\\start\\YouCompleteMe\\third_party\\ycmd\\third_party\\clang\\lib\\clang\\8.0.0', '-fno-delayed-template-parsing', '-fspell-checking']
--   Translation unit: C:\dev\projects\myapp\main.cpp
-- Server running at: http://127.0.0.1:50991
-- Server process ID: 5612
-- Server logfiles:
--   C:\Users\sylvain\AppData\Local\Temp\ycmd_50991_stdout_6dwefz4e.log
--   C:\Users\sylvain\AppData\Local\Temp\ycmd_50991_stderr_5mp0bn7i.log

Contents of YCM, ycmd and completion engine logfiles

Add let g:ycm_log_level = 'debug' to vimrc, restart Vim, reproduce the issue, and include link here to a gist containing the entire logfiles for ycm, ycmd and any completer logfiles listed by :YcmToggleLogs.

ycm_ea85ph1n.log

2019-09-30 21:08:11,463 - ERROR - HTTPConnectionPool(host='127.0.0.1', port=51031): Max retries exceeded with url: /ready (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x084FA5F0>, 'Connection to 127.0.0.1 timed out. (connect timeout=0.01)'))
2019-09-30 21:08:11,579 - ERROR - HTTPConnectionPool(host='127.0.0.1', port=51031): Max retries exceeded with url: /ready (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x084FA8D0>, 'Connection to 127.0.0.1 timed out. (connect timeout=0.01)'))

ycmd_51031_stderr_0magf_fw.log

2019-09-30 21:08:11,570 - DEBUG - No global extra conf, not calling method YcmCorePreload
2019-09-30 21:08:11,696 - INFO - Received ready request
2019-09-30 21:08:11,716 - INFO - Received event notification
2019-09-30 21:08:11,716 - DEBUG - Event name: BufferVisit
2019-09-30 21:08:11,716 - INFO - Received event notification
2019-09-30 21:08:11,716 - DEBUG - Event name: FileReadyToParse
2019-09-30 21:08:11,716 - INFO - Adding buffer identifiers for file: C:\dev\projects\myapp\main.cpp
2019-09-30 21:08:11,775 - INFO - No Clangd executable found in C:\Users\sylvain\vimfiles\pack\plugins\start\YouCompleteMe\third_party\ycmd\third_party\clangd\output\bin
2019-09-30 21:08:12,266 - INFO - Received filetype completion available request
2019-09-30 21:08:28,613 - INFO - Received debug info request

ycmd_51031_stdout_7u49ildp.log

serving on http://DESKTOP-LTTIUVB:51031

OS version, distribution, etc.

Include system information here.

Windows 10 64 bits

Output of build/install commands

Include link to a gist containing the invocation and entire output of install.py if reporting an installation issue.

Not an installation issue.

bstaletic commented 5 years ago

Your template is missing a Hello section so I will say hi here in the wrong section :)

True. Hello to you as well.

Flags

Allow me to say... ughh Correctly santizing flags is super difficult and I loath messing with our flags.py.

I already know why this doesn't work with your setup.

Libclang throws a fit if the command line contains any positional arguments that are not preceded with something like -I. In other words, stray file names in the command line are a big no-no.
YCM assumes that everything that starts with a - (or / if using clang-cl) is a flag and the rest are files. There are a few exceptions, but nevermind that. This results in YCM throwing out everything that it thinks is a filename, including @foo.rsp.

That's YCM's side. I have no idea if clang knows about @foo.rsp. I know I see it for the first time.

All that said, I'd love it if clangd knows about this and everything works for you if you just switch to --clangd-completer. In clangd+compile_commands.json case, YCM completely gets out of the way and goes "Clangd, you figure out the flags!" If that works, just keep using it. If that doesn't work, then we just can't support it.

zeechs commented 5 years ago

Thank you for your fast response. I just tested as you said. Clangd seems to have the exact same behavior unfortunately. So if I understand well, as long as Clang does not understand this syntax, it is hopeless.

I might go ahead and script something to reformat the file properly. it should not be too hard. Seems fun anyway.

Another solution would be to drop MinGW in favor of Clang (would have to rebuild Qt, less fun) or msvc (too mainstream, just kidding ;) ).

bstaletic commented 5 years ago

I just tested as you said. Clangd seems to have the exact same behavior unfortunately. So if I understand well, as long as Clang does not understand this syntax, it is hopeless.

Exactly. To make sure, you can see what clangd is doing in its log (:YcmToggleLogs) when you turn on debug log level (let g:ycm_log_level='debug').

You might want to submit a feature request for clang.

MinGW

Officially, we don't claim support for MinGW or anything that is POSIX-like on Windows, because of the size of the team behind YCM. If it works, great, but if a problem is specific to MinGW that's a WONTFIX. However, if the flags without @foo.rsp work, then YCM is working.

Clangd vs libclang

If you're using compile_commands.json, then I'd advise you to stay on clangd. If for no other reason then to have GoToReferences available.

Anyway, I'm going to close this. If clang doesn't understand @foo.rsp then there's no way YCM could.

zeechs commented 5 years ago

Got it, thank you for your time and advice.

Edit: Feature already requested for Clangd https://github.com/clangd/clangd/issues/81

ycm-core / YouCompleteMe

`.rsp` file inclusion in compile_commands.json ignored #3496

Issue Prelude

Issue Details

Diagnostic data

Output of `vim --version`

Output of `YcmDebugInfo`

Contents of YCM, ycmd and completion engine logfiles

ycm_ea85ph1n.log

ycmd_51031_stderr_0magf_fw.log

ycmd_51031_stdout_7u49ildp.log

OS version, distribution, etc.

Output of build/install commands

MinGW

Clangd vs libclang

ycm-core / YouCompleteMe

`.rsp` file inclusion in compile_commands.json ignored #3496

Issue Prelude

Issue Details

Diagnostic data

Output of vim --version

Output of YcmDebugInfo

Contents of YCM, ycmd and completion engine logfiles

ycm_ea85ph1n.log

ycmd_51031_stderr_0magf_fw.log

ycmd_51031_stdout_7u49ildp.log

OS version, distribution, etc.

Output of build/install commands

MinGW

Clangd vs libclang

Output of `vim --version`

Output of `YcmDebugInfo`