• Remove different comment markers from the beginning and end of each comment line, perform some other kinds of preprocessing. - This is a very simplistic approach to parse comments. In the future, a more advanced real comment parser may need to be used.

• Return two marked strings as a response to hover requests:

  • The first line is the formatted comment, which is reported as a markup string of type "text". This ensures that no C/C++ highlighting is used for the comment text.
    • The second line is the declaration/signature, which is reported as a markup string of type "c" or "c++".

Hello,

I am trying to get cquery up and running for Mesos on Windows. I've succesfully built cquery and got Emacs setup to use it; and I have Mesos successfully building with Ninja on Windows (which lets me use the CMake generated compile_commands.json. However, when cquery tries to index one of my files, I get this error:

2018-02-17 21:42:06.474 (   4.013s) [indexer2     ]clang_translation_unit.cc:117   libclang had ast read error for C:/Users/andschwa/src/mesos/src/tests/utils.cpp. Please try running the following, identify which flag causes the issue, and report a bug. cquery will then filter the flag for you  automatically:
$ /TP -working-directory C:/Users/andschwa/src/mesos/build -xc++ -std=c++14 -DBUILD_DIR="C:/Users/andschwa/src/mesos/build" -DCURL_STATICLIB -DGOOGLE_GLOG_DLL_DECL= -DHAVE_LIBZ -DLIBDIR="WARNINGDONOTUSEME" -DLIBSASL_EXPORTS=1 -DNOGDI -DNOMINMAX -DPICOJSON_USE_INT64 -DPKGDATADIR="" -DPKGLIBEXECDIR="WARNINGDONOTUSEME" -DPKGMODULEDIR="WARNINGDONOTUSEME" -DSBINDIR="WARNINGDONOTUSEME" -DSOURCE_DIR="C:/Users/andschwa/src/mesos" -DTESTLIBEXECDIR="WARNINGDONOTUSEME" -DUSE_CMAKE_BUILD_CONFIG -DUSE_STATIC_LIB -DVERSION="1.6.0" -DZOOKEEPER_VERSION="3.4.8" -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_WARNINGS -D_SCL_SECURE_NO_WARNINGS -D_SILENCE_TR1_NAMESPACE_DEPRECATION_WARNING -D__STDC_FORMAT_MACROS -D__WINDOWS__ -I..\include -Iinclude -Iinclude\mesos -Isrc -I..\src -I..\3rdparty\libprocess\src\..\include -I..\3rdparty\stout\include -I3rdparty\libapr-1.5.2\src\libapr-1.5.2\include -I3rdparty\libapr-1.5.2\src\libapr-1.5.2-build -I3rdparty\boost-1.65.0\src\boost-1.65.0 -I3rdparty\curl-7.57.0\src\curl-7.57.0\include -I3rdparty\elfio-3.2\src\elfio-3.2 -I3rdparty\glog-da816ea70\src\glog-da816ea70\src\windows -I3rdparty\picojson-1.3.0\src\picojson-1.3.0 -I3rdparty\protobuf-3.5.0\src\protobuf-3.5.0\src -I3rdparty\zlib-1.2.8\src\zlib-1.2.8 -I3rdparty\zlib-1.2.8\src\zlib-1.2.8-build -I3rdparty\http_parser-2.6.2\src\http_parser-2.6.2 -I3rdparty\sasl2-2.1.27rc3\src\sasl2-2.1.27rc3-build\include -I3rdparty\zookeeper-3.4.8\src\zookeeper-3.4.8\src\c\include -I3rdparty\zookeeper-3.4.8\src\zookeeper-3.4.8\src\c\generated -I3rdparty\googletest-1.8.0\src\googletest-1.8.0\googlemock\include -I3rdparty\googletest-1.8.0\src\googletest-1.8.0\googletest\include /DWIN32 /D_WINDOWS /W3 /GR /EHsc /bigobj /vd2 /EHsc -DUNICODE -D_UNICODE /w /MDd /Zi /Ob0 /Od /RTC1 /MTd /Fosrc\tests\CMakeFiles\test-helper.dir\utils.cpp.obj /FdTARGET_COMPILE_PDB /FS C:/Users/andschwa/src/mesos/build/C:/Users/andschwa/src/mesos/src/tests/utils.cpp -resource-dir=c:/Users/andschwa/.emacs.d/cquery/build/debug/lib/LLVM-5.0.1-win64/lib/clang/5.0.1 -Wno-unknown-warning-option -fparse-all-comments -fms-extensions -fms-compatibility -fdelayed-template-parsing -fsyntax-only

I've tried doing what it said, and under clang++.exe directly, it fails because the syntax is cl.exe syntax. (Note: I cannot compile the whole project with clang on Windows, some our dependencies e.g. GoogleTest don't support it, but the Mesos sources themselves compile with clang on other platforms).

Running the same arguments under clang-cl.exe gets me a bit further (after putting double quotes around the paths because the embedded dashes otherwise cause more syntax errors), and finally I got to this error and am stumped:

clang-cl.exe  /TP -working-directory C:/Users/andschwa/src/mesos/build -xc++ -std=c++14 -DBUILD_DIR="C:/Users/andschwa/src/mesos/build" -DCURL_STATICLIB -DGOOGLE_GLOG_DLL_DECL= -DHAVE_LIBZ -DLIBDIR="WARNINGDONOTUSEME" -DLIBSASL_EXPORTS=1 -DNOGDI -DNOMINMAX -DPICOJSON_USE_INT64 -DPKGDATADIR="" -DPKGLIBEXECDIR="WARNINGDONOTUSEME" -DPKGMODULEDIR="WARNIN GDONOTUSEME" -DSBINDIR="WARNINGDONOTUSEME" -DSOURCE_DIR="C:/Users/andschwa/src/mesos" -DTESTLIBEXECDIR="WARNINGDONOTUSEME" -DUSE_CMAKE_BUILD_CONFIG -DUSE_STATIC_LIB -DVERSION="1.6.0" -DZOOKEEPER_VERSI ON="3.4.8" -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_WARNINGS -D_SCL_SECURE_NO_WARNINGS -D_SILENCE_TR1_NAMESPACE_DEPRECATION_WARNING -D__STDC_FORMAT_MACROS -D__WINDOWS__ -I..\include -Iinclude -I"in clude\mesos" -Isrc -I"..\src" -I"..\3rdparty\libprocess\src\..\include" -I"..\3rdparty\stout\include" -I"3rdparty\libapr-1.5.2\src\libapr-1.5.2\include" -I"3rdparty\libapr-1.5.2\src\libapr-1.5.2-build " -I"3rdparty\boost-1.65.0\src\boost-1.65.0" -I"3rdparty\curl-7.57.0\src\curl-7.57.0\include" -I"3rdparty\elfio-3.2\src\elfio-3.2" -I"3rdparty\glog-da816ea70\src\glog-da816ea70\src\windows" -I"3rdpart y\picojson-1.3.0\src\picojson-1.3.0" -I"3rdparty\protobuf-3.5.0\src\protobuf-3.5.0\src" -I"3rdparty\zlib-1.2.8\src\zlib-1.2.8" -I"3rdparty\zlib-1.2.8\src\zlib-1.2.8-build" -I"3rdparty\http_parser-2.6. 2\src\http_parser-2.6.2" -I"3rdparty\sasl2-2.1.27rc3\src\sasl2-2.1.27rc3-build\include" -I"3rdparty\zookeeper-3.4.8\src\zookeeper-3.4.8\src\c\include" -I"3rdparty\zookeeper-3.4.8\src\zookeeper-3.4.8\s rc\c\generated" -I"3rdparty\googletest-1.8.0\src\googletest-1.8.0\googlemock\include" -I"3rdparty\googletest-1.8.0\src\googletest-1.8.0\googletest\include" /DWIN32 /D_WINDOWS /W3 /GR /EHsc /bigobj /vd 2 /EHsc -DUNICODE -D_UNICODE /w /MDd /Zi /Ob0 /Od /RTC1 /MTd /Fosrc\tests\CMakeFiles\test-helper.dir\utils.cpp.obj /FdTARGET_COMPILE_PDB /FS "C:/Users/andschwa/src/mesos/src/tests/utils.cpp" -Wno-unkn own-warning-option -fparse-all-comments -fms-extensions -fms-compatibility -fdelayed-template-parsing -fsyntax-only
clang-cl.exe: error: cannot specify '/Fosrc\tests\CMakeFiles\test-helper.dir\utils.cpp.obj' when compiling multiple source files

There is only one source file specified, so the error doesn't make sense to me.

Has anyone gotten cquery to work on Windows with a CMake-generated Ninja-driven MSVC project?

https://github.com/cquery-project/cquery/blob/eadc53abe9af1e28d0a1abba40da7a16864de919/src/platform_win.cc#L132-L144

I'm working on a project that cross-compiles for Arm, and after a bit of hair-pulling, we were able to attribute our issues to the -fms-compatibility flag. Is there some way this could be made configurable?

My initial thoughts were to either:

• add some sort of --no-ms-compat option to running the language server, or
• somehow parse the target flag (if specified) in a compile_commands.json

The real issue may also be a confusion between the platform and the target

There are two variants of this issue:

1. Files without an extension, like <vector>, don't get any coloring, syntax or semantic.
2. Files with an extension, like <bits/stl_vector.h>, get syntax coloring, but not semantic.

I've had to incorporate a patch in the nix derivation I use for cquery to force the build to rely on the clang found on PATH rather than using llvm-config --bindir output. The latter gives a useful path for various LLVM executables (e.g. llc, opt, etc.), but, at least with nix, clang is found elsewhere.

What I'm not sure of is how to support this configuration. Should there be a nix variant of the build that we key off of to set such things, or perhaps just a flag to specify which clang executable?

I'm using neovim + LanguageClient-neovim.

In one of my projects, the language server works fine (hover, goto def, list references and so on) until I try changing the text, at which point it crashes. Here's the log from LanguageClient-neovim's /tmp/LanguageServer.log:

2017-12-24 14:57:04.141 (   0.035s) [include_scanner ]               utils.cc:144   WARN| Unable to open directory /usr/include/rapidjson/include/
cquery: ../../third_party/rapidjson/include/rapidjson/document.h:1233: rapidjson::GenericValue::MemberIterator rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >::FindMember(const GenericValue<Encoding, SourceAllocator> &) [Encoding = rapidjson::UTF8<char>, Allocator = rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator>, SourceAllocator = rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator>]: Assertion `IsObject()' failed.
#0 0x00007fe03790d735 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/yalter/.local/cquery/bin/../lib/clang+llvm-4.0.0-x86_64-linux-gnu-ubuntu-14.04/lib/libclang.so.4+0x158a735)
#1 0x00007fe03790dd76 SignalHandler(int) (/home/yalter/.local/cquery/bin/../lib/clang+llvm-4.0.0-x86_64-linux-gnu-ubuntu-14.04/lib/libclang.so.4+0x158ad76)
#2 0x00007fe0399e6da0 __restore_rt (/usr/lib/libpthread.so.0+0x11da0)
#3 0x00007fe035715860 __GI_raise (/usr/lib/libc.so.6+0x34860)
#4 0x00007fe035716ec9 __GI_abort (/usr/lib/libc.so.6+0x35ec9)
#5 0x00007fe03570e0bc __assert_fail_base (/usr/lib/libc.so.6+0x2d0bc)
#6 0x00007fe03570e133 (/usr/lib/libc.so.6+0x2d133)
#7 0x0000559748a6fc44 rapidjson::GenericMemberIterator<false, rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> > rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >::FindMember<rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >(rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> > const&) /home/yalter/Source/cpp/cquery/build/release/../../third_party/rapidjson/include/rapidjson/document.h:1234:9
#8 0x0000559748a6fc44 rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >::FindMember(char const*) /home/yalter/Source/cpp/cquery/build/release/../../third_party/rapidjson/include/rapidjson/document.h:1213:0
#9 0x0000559748a6fc44 void ReflectMember<lsPosition>(rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >&, char const*, lsPosition&) /home/yalter/Source/cpp/cquery/build/release/../../src/serializer.h:181:0
#10 0x0000559748a8cb7e void Reflect<rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> > >(rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >&, lsRange&) /home/yalter/Source/cpp/cquery/build/release/../../src/language_server_api.h:172:1
#11 0x0000559748a8cb7e void ReflectMember<lsRange>(rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >&, char const*, lsRange&) /home/yalter/Source/cpp/cquery/build/release/../../src/serializer.h:184:0
#12 0x0000559748a973f8 void Reflect<rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> > >(rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >&, lsTextDocumentContentChangeEvent&) /home/yalter/Source/cpp/cquery/build/release/../../src/language_server_api.h:999:1
#13 0x0000559748a973f8 void Reflect<lsTextDocumentContentChangeEvent>(rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >&, std::vector<lsTextDocumentContentChangeEvent, std::allocator<lsTextDocumentContentChangeEvent> >&) /home/yalter/Source/cpp/cquery/build/release/../../src/serializer.h:160:0
#14 0x0000559748a972b7 void ReflectMember<std::vector<lsTextDocumentContentChangeEvent, std::allocator<lsTextDocumentContentChangeEvent> > >(rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >&, char const*, std::vector<lsTextDocumentContentChangeEvent, std::allocator<lsTextDocumentContentChangeEvent> >&) /home/yalter/Source/cpp/cquery/build/release/../../src/serializer.h:0:5
#15 0x0000559748a96e94 void ReflectMember<lsTextDocumentDidChangeParams>(rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >&, char const*, lsTextDocumentDidChangeParams&) /home/yalter/Source/cpp/cquery/build/release/../../src/language_server_api.h:0:1
#16 0x0000559748a96bc5 std::_Head_base<0ul, BaseIpcMessage*, false>::_Head_base<BaseIpcMessage*&>(BaseIpcMessage*&) /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../include/c++/7.2.1/tuple:133:4
#17 0x0000559748a96bc5 std::_Tuple_impl<0ul, BaseIpcMessage*, std::default_delete<BaseIpcMessage> >::_Tuple_impl<BaseIpcMessage*&, std::default_delete<(anonymous namespace)::Ipc_TextDocumentDidChange>, void>(BaseIpcMessage*&, std::default_delete<(anonymous namespace)::Ipc_TextDocumentDidChange>&&) /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../include/c++/7.2.1/tuple:218:0
#18 0x0000559748a96bc5 std::tuple<BaseIpcMessage*, std::default_delete<BaseIpcMessage> >::tuple<BaseIpcMessage*&, std::default_delete<(anonymous namespace)::Ipc_TextDocumentDidChange>, true>(BaseIpcMessage*&, std::default_delete<(anonymous namespace)::Ipc_TextDocumentDidChange>&&) /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../include/c++/7.2.1/tuple:972:0
#19 0x0000559748a96bc5 std::__uniq_ptr_impl<BaseIpcMessage, std::default_delete<BaseIpcMessage> >::__uniq_ptr_impl<std::default_delete<(anonymous namespace)::Ipc_TextDocumentDidChange> >(BaseIpcMessage*, std::default_delete<(anonymous namespace)::Ipc_TextDocumentDidChange>&&) /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../include/c++/7.2.1/bits/unique_ptr.h:144:0
#20 0x0000559748a96bc5 std::unique_ptr<BaseIpcMessage, std::default_delete<BaseIpcMessage> >::unique_ptr<(anonymous namespace)::Ipc_TextDocumentDidChange, std::default_delete<(anonymous namespace)::Ipc_TextDocumentDidChange>, void>(std::unique_ptr<(anonymous namespace)::Ipc_TextDocumentDidChange, std::default_delete<(anonymous namespace)::Ipc_TextDocumentDidChange> >&&) /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../include/c++/7.2.1/bits/unique_ptr.h:253:0
#21 0x0000559748a96bc5 std::_Function_handler<std::unique_ptr<BaseIpcMessage, std::default_delete<BaseIpcMessage> > (rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >&), MessageRegistryRegister<(anonymous namespace)::Ipc_TextDocumentDidChange>::MessageRegistryRegister()::{lambda(rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >&)#1}>::_M_invoke(std::_Any_data const&, rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >&) /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../include/c++/7.2.1/bits/std_function.h:301:0
#22 0x0000559748a40d6d std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_data() const /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../include/c++/7.2.1/bits/basic_string.h:176:28
#23 0x0000559748a40d6d std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_is_local() const /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../include/c++/7.2.1/bits/basic_string.h:211:0
#24 0x0000559748a40d6d std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose() /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../include/c++/7.2.1/bits/basic_string.h:220:0
#25 0x0000559748a40d6d std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../include/c++/7.2.1/bits/basic_string.h:647:0
#26 0x0000559748a40d6d MessageRegistry::Parse(rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >&) /home/yalter/Source/cpp/cquery/build/release/../../src/language_server_api.cc:179:0
#27 0x0000559748a40730 rapidjson::GenericDocument<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator>, rapidjson::CrtAllocator>::Destroy() /home/yalter/Source/cpp/cquery/build/release/../../third_party/rapidjson/include/rapidjson/document.h:2473:9
#28 0x0000559748a40730 rapidjson::GenericDocument<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator>, rapidjson::CrtAllocator>::~GenericDocument() /home/yalter/Source/cpp/cquery/build/release/../../third_party/rapidjson/include/rapidjson/document.h:2151:0
#29 0x0000559748a40730 MessageRegistry::ReadMessageFromStdin(bool) /home/yalter/Source/cpp/cquery/build/release/../../src/language_server_api.cc:159:0
#30 0x0000559748a14bde std::unique_ptr<BaseIpcMessage, std::default_delete<BaseIpcMessage> >::operator bool() const /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../include/c++/7.2.1/bits/unique_ptr.h:351:22
#31 0x0000559748a14bde LaunchStdinLoop(Config*, std::unordered_map<IpcId, Timer, std::hash<IpcId>, std::equal_to<IpcId>, std::allocator<std::pair<IpcId const, Timer> > >*)::$_0::operator()() const /home/yalter/Source/cpp/cquery/build/release/../../src/command_line.cc:249:0
#32 0x0000559748a14bde std::_Function_handler<WorkThread::Result (), LaunchStdinLoop(Config*, std::unordered_map<IpcId, Timer, std::hash<IpcId>, std::equal_to<IpcId>, std::allocator<std::pair<IpcId const, Timer> > >*)::$_0>::_M_invoke(std::_Any_data const&) /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../include/c++/7.2.1/bits/std_function.h:301:0
#33 0x0000559748b70356 WorkThread::StartThread(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::function<WorkThread::Result ()> const&)::$_0::operator()() const /home/yalter/Source/cpp/cquery/build/release/../../src/work_thread.cc:19:18
#34 0x0000559748b70356 void std::__invoke_impl<void, WorkThread::StartThread(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::function<WorkThread::Result ()> const&)::$_0>(std::__invoke_other, WorkThread::StartThread(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::function<WorkThread::Result ()> const&)::$_0&&) /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../include/c++/7.2.1/bits/invoke.h:60:0
#35 0x0000559748b70356 std::__invoke_result<WorkThread::StartThread(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::function<WorkThread::Result ()> const&)::$_0>::type std::__invoke<WorkThread::StartThread(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::function<WorkThread::Result ()> const&)::$_0>(WorkThread::StartThread(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::function<WorkThread::Result ()> const&)::$_0&&) /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../include/c++/7.2.1/bits/invoke.h:95:0
#36 0x0000559748b70356 _ZNSt6thread8_InvokerISt5tupleIJZN10WorkThread11StartThreadERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt8functionIFNS2_6ResultEvEEE3$_0EEE9_M_invokeIJLm0EEEEDTclsr3stdE8__invokespcl10_S_declvalIXT_EEEEESt12_Index_tupleIJXspT_EEE /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../include/c++/7.2.1/thread:234:0
#37 0x0000559748b70356 std::thread::_Invoker<std::tuple<WorkThread::StartThread(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::function<WorkThread::Result ()> const&)::$_0> >::operator()() /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../include/c++/7.2.1/thread:243:0
#38 0x0000559748b70356 std::thread::_State_impl<std::thread::_Invoker<std::tuple<WorkThread::StartThread(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::function<WorkThread::Result ()> const&)::$_0> > >::_M_run() /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../include/c++/7.2.1/thread:186:0
#39 0x00007fe0360b5a6f std::default_delete<std::thread::_State>::operator()(std::thread::_State*) const /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/unique_ptr.h:78:0
#40 0x00007fe0360b5a6f std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >::~unique_ptr() /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/unique_ptr.h:268:0
#41 0x00007fe0360b5a6f execute_native_thread_routine /build/gcc/src/gcc/libstdc++-v3/src/c++11/thread.cc:79:0
#42 0x00007fe0399dc08a start_thread (/usr/lib/libpthread.so.0+0x708a)
#43 0x00007fe0357d742f __GI___clone (/usr/lib/libc.so.6+0xf642f)

The warning about being unable to open the include is output when the server loads, the rest is output upon a crash.

Rationale

Clients (namely ycmd) can have the means of getting the flags from the user other than the compilation_database.json. It would be very useful if there was a way to take advantage of already working methods.

More specifically, ycmd has .ycm_extra_conf.py, which, in theory, can be more powerful than compilation_database.json and is definitely a much better way of getting the flags from the user than .cquery.

In the gitter room there were more than a few ideas on how to make these compatible. Though for every suggestion a concern was raised - either about performancee or functionality.

Generally, this would have to be another LSP extension, be it a request or a message.

Some of the ideas that were mentioned in the gitter room

By @puremourning:

• For every file that the server decides to parse, it should ask the client for the flags.

My take on this is that we need to also take compilation database into account or we lose cross-TU capabilities (maybe the server could fall back to the compilation database). Other than that, this approach is fine from the ycmd's point of view. @jacobdufault however raised a question of performance.

By @jacobdufault:

• The client could make a request $cquery/updateFlagsForFile, which would allow lazy "updating" of the compilation database by the client.

Once again, I see nothing wrong with this from ycmd's point of view. But I have to note that this approach would have to read the compilation database first. Otherwise we lose the cross-TU capabilities.

By @MarkZ3

maybe there should be a separate .ycm -> compile_commands.json converter?

Personally, I'd rather have a request/response or a message kind of set up. Not sure what other's think. Another reason this is not perfect is because it benefits only ycmd.

ping @puremourning @micbou @valloric

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
wget 'https://git.archlinux.org/svntogit/packages.git/plain/trunk/config?h=packages/linux' -O .config
yes '' | make config
bear make -j bzImage modules

Open a file with Emacs and then cquery creates cacheDirectory

% du -sh .vscode/cquery_cached_index
6.4G    .vscode/cquery_cached_index

@khng300 @yshui

I'm getting this error while indexing a cross-compiled project, many if not all files have the same issue. The following was in Emacs buffer lsp-cquery stderr". Any help in debugging this would be appreciated. In the following, I replaced some job-sensitive information with [censored].

I'm on commit 13015693bd1e88167c1ff15d3fc315a41a5307ed

2018-03-15 10:11:35.036 ( 0.072s) [indexer0 ]clang_translation_unit.cc:99 libclang generic failure for /home/[censored]/dev/[censored]/[censored]/External/tinyxml/tinyxml.cpp. Please try running the following, identify which flag causes the issue, and report a bug. cquery will then filter the flag for you automatically: $ /home/[censored]/dev/[censored]/android-sdk/toolchain/arm-linux-androideabi-4.9/bin/arm-linux-androideabi-g++ -working-directory=/home/[censored]/dev/[censored]/build/External/tinyxml -DANDROID -DBOARD="Android" -DLOCALE="usa" -DMANUFACTURER="[censored]" -DPLATFORM_SETTINGS_FILE="/home/[censored]/dev/[censored]/[censored]/[censored]util/platform/AndroidPlatformSettings.h" -DUNQUOTED_BOARD=Android -Dtinyxml_EXPORTS -Wno-psabi --sysroot=/home/[censored]/dev/[censored]/android-sdk/toolchain/arm-linux-androideabi-4.9/sysroot -funwind-tables -fsigned-char -no-canonical-prefixes -march=armv7-a -fdata-sections -ffunction-sections -Wa,--noexecstack -std=c++11 -L/home/[censored]/dev/[censored]/[censored]/app/android/build/libs/armeabi-v7a/ -lgnustl_shared -llog -DANDROID -pipe -Wall -Wtype-limits -Wuninitialized -fmessage-length=0 -ftabstop=4 -Wno-unknown-pragmas -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DVERBOSE_LOGGING -DBUILD_DEBUG -DBUILD_TYPE=DEBUG -DREVISION_STRING="" -DVERSION_STRING="DEBUG" -g -ffunction-sections -fdata-sections -Os -ffast-math -fasynchronous-unwind-tables -fPIC -isystem /home/[censored]/dev/[censored]/android-sdk/toolchain/arm-linux-androideabi-4.9/sysroot/usr/include -isystem /home/[censored]/dev/[censored]/android-sdk/toolchain/arm-linux-androideabi-4.9/include/c++/4.9 -isystem /home/[censored]/dev/[censored]/android-sdk/toolchain/arm-linux-androideabi-4.9/include/c++/4.9/arm-linux-androideabi/armv7-a -fPIC /home/[censored]/dev/[censored]/[censored]/External/tinyxml/tinyxml.cpp -resource-dir=/home/[censored]/extern/cquery/build/release/lib/clang+llvm-6.0.0-x86_64-linux-gnu-ubuntu-14.04/lib/clang/6.0.0 -Wno-unknown-warning-option -fparse-all-comments -fsyntax-only

The result of doing what it requests is as follows:

arm-linux-androideabi-g++: error: unrecognized command line option '-working-directory=/home/[censored]/dev/[censored]/build/External/tinyxml'
arm-linux-androideabi-g++: error: unrecognized command line option '-resource-dir=/home/[censored]/extern/cquery/build/clang+llvm-6.0.0-x86_64-linux-gnu-ubuntu-14.04/lib/clang/6.0.0'
arm-linux-androideabi-g++: error: unrecognized command line option '-fparse-all-comments'

When I declare a variable like this auto str = std::make_shared<std::string>("Hello Cquery); cquery is not able to perform autocompletion for members of str. neither members accessed with . nor members accessed with ->.

Suppose we have for example the code below to explain the error.

int main(void){
    int hash;
    hash = 1;
    return 0;
}

If i rename the hash variable to something else like hash_value and fix the hash = 1 line to match the new name sometimes it will not find that i have typed the correct name in the buffer and report unknown variable hash_valu while i have typed the variable correctly.(Wrong typing the name of the variable in the last sentence is intentional its the way cquery reports usually the wrong name) In addition to that symbol highlighting stops working after that in the buffer and flycheck starts reporting errors in irrelevant places that have no errors. Usually the error occurs after renaming a variable. The error happens randomly after coding some time in a session. I have Arch linux with Emacs 25.3.1 and cquery package from aur. I do not know if this happens in master branch the package has not been updated for 20 days in aur.

$ cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=release -DCMAKE_EXPORT_COMPILE_COMMANDS=YES 
-- The CXX compiler identification is GNU 9.2.1
-- Check for working CXX compiler: /usr/lib64/ccache/c++
-- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Using downloaded Clang
-- Downloading Clang 7.0.0 (https://releases.llvm.org/7.0.0/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz) ...
CMake Error at cmake/DownloadAndExtractClang.cmake:94 (message):
  SHA256 hash of downloaded Clang does not match expected hash.  Remove the
  build directory and try running CMake again.  If this keeps happening, file
  an issue to report the problem.
Call Stack (most recent call first):
  CMakeLists.txt:94 (download_and_extract_clang)


-- Configuring incomplete, errors occurred!
See also "/home/jnordwick/rdev/cquery/build/CMakeFiles/CMakeOutput.log".

here is what i get

$ sha256sum clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz 
5c90e61b06d37270bc26edb305d7e498e2c7be22d99e0afd9f2274ef5458575a  clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz

I am using cquery in conjunction with the cquery VS Code plugin. I also use Gitlens. I have found that cquery crashes instantly upon entering a diff view. As it turns out, being unable to normalize the path in these cases exposed a problem with not dealing with the optional<> not being set which specifically led to my crashes.

When using cquery inside VS Code I often got files "out of workspace" even though they are in it. This has unwanted effects like creating file save conflicts and breakpoints are incorrectly associated with their "out of workspace" counter part. Now, GetLongPathName is used to ensure all directory names are transformed into their correct case (as stated by the comments). However, it seems like path elements already in the long format are kept as-is by the Windows API. Or at least there is something not working as intended with the call to GetLongPathName. So, as it seems, by first transforming the path into its "short" 8.3 representation, I am able to force a subsequent call to GetLongPathName to transform all path elements into the correct case. This in turn means the internal path matching in VS Code still identifies paths within the workspace to be correctly relative to the workspace root.

I use cquery in neovim through LanguageClient-neovim. I found whenever I open a file in a project /site/home/xxx/project (this is the project root), there are two separate folders created in the cache directory. One is @site@home@xxx@project. The other is @@site@home@xxx@project. (let's call them the @-dir and the @@-dir)

NOTE: In my system, /home is a symlink to /site/home.

Some of the files inside these folders duplicates. Assume there is a file /site/home/xxx/project/include/a.hpp, two separate cache files exists:

• @site@home@xxx@project/[email protected]
• @@site@home@xxx@project/@home@xxx@project@[email protected] (NOTE: no site appeared in the filename)

with exactly the same content. When I query some definitions, both of them will popup in the list.

Is this the normal behavior? What are the differences between the two directories.

cquery project seems to be no longer maintained by anyone. Perhaps we can have it archived and add a description suggesting users to choose alternatives? Could be a fork project like https://github.com/MaskRay/ccls or official one like https://clang.llvm.org/extra/clangd .