C/C++ language server supporting multi-million line code base, powered by libclang. Emacs, Vim, VSCode, and others with language server protocol support. Cross references, completion, diagnostics, semantic highlighting and more

Overview

Archived

cquery is no longer under development. clangd and ccls are both good replacements.

cquery

Join the chat at https://gitter.im/cquery-project/Lobby

cquery is a highly-scalable, low-latency language server for C/C++/Objective-C. It is tested and designed for large code bases like Chromium. cquery provides accurate and fast semantic analysis without interrupting workflow.

Demo

cquery implements almost the entire language server protocol and provides some extra features to boot:

>>> Getting started (CLICK HERE) <<<

Packaging status

Limitations

cquery is able to respond to queries quickly because it caches a huge amount of information. When a request comes in, cquery just looks it up in the cache without running many computations. As a result, there's a large memory overhead. For example, a full index of Chrome will take about 10gb of memory. If you exclude v8, webkit, and third_party, it goes down to about 6.5gb.

License

MIT

Comments
  • Improve formatting of comments shown in hover pop-ups

    Improve formatting of comments shown in hover pop-ups

    • 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++".
    opened by romix 48
  • Errors using cquery on Windows

    Errors using cquery on Windows

    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?

    windows 
    opened by andschwa 29
  • cquery always passes -fms-compatibility [on windows], which breaks cross-compiled projects

    cquery always passes -fms-compatibility [on windows], which breaks cross-compiled projects

    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

    opened by HotelCalifornia 27
  • [VSCode] Standard library headers don't get coloring

    [VSCode] Standard library headers don't get coloring

    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.
    opened by HighCommander4 22
  • Reliance on llvm-config for clang's path doesn't work with nix

    Reliance on llvm-config for clang's path doesn't work with nix

    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?

    opened by acowley 22
  • Crash on text changed

    Crash on text changed

    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.

    opened by YaLTeR 21
  • [Feature request] On the fly client-specified compiler flags

    [Feature request] On the fly client-specified compiler flags

    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

    opened by bstaletic 20
  • cacheDirectory takes too much space

    cacheDirectory takes too much space

    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

    opened by MaskRay 20
  • Error during index

    Error during index

    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'
    
    
    opened by ambihelical 19
  • Autocompletion doesnt work with smartpointers

    Autocompletion doesnt work with smartpointers

    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 ->.

    opened by Hein-Bloed 19
  • Symbol highlighting + flycheck error

    Symbol highlighting + flycheck error

    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.

    opened by innerout 18
  • Checksums fail on Fedora 30

    Checksums fail on Fedora 30

    $ 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
    
    opened by jnordwick3x 1
  • Fix crash on VSCode Gitlens paths (e.g. in diffview)

    Fix crash on VSCode Gitlens paths (e.g. in diffview)

    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.

    opened by phogy 0
  • Fix path normalizations with correct case for all directories.

    Fix path normalizations with correct case for all directories.

    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.

    opened by phogy 0
  • Two folders in the cache directory for the same project root

    Two folders in the cache directory for the same project 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 @[email protected]@[email protected]. The other is @@[email protected]@[email protected]. (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:

    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.

    opened by liushapku 0
  • Suggesting alternative projects due to development inactivity

    Suggesting alternative projects due to development inactivity

    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 .

    opened by amosbird 0
Releases(v20180718)
Owner
Jacob Dufault
author of cquery and full serializer
Jacob Dufault
A C/C++ minor mode for Emacs powered by libclang

Irony-Mode A C/C++ minor mode powered by libclang irony-mode is an Emacs minor-mode that aims at improving the editing experience for the C, C++ and O

Guillaume Papin 893 Nov 14, 2022
Visual Studio extension for assembly syntax highlighting and code completion in assembly files and the disassembly window

Asm-Dude Assembly syntax highlighting and code assistance for assembly source files and the disassembly window for Visual Studio 2015, 2017 and 2019.

Henk-Jan Lebbink 4k Nov 16, 2022
Vimb - the vim like browser is a webkit based web browser that behaves like the vimperator plugin for the firefox and usage paradigms from the great editor vim.

Vimb - the vim like browser is a webkit based web browser that behaves like the vimperator plugin for the firefox and usage paradigms from the great editor vim. The goal of vimb is to build a completely keyboard-driven, efficient and pleasurable browsing-experience.

Daniel Carl 1.2k Nov 16, 2022
split89 keyboard - a 3d printed 89 key split TKL keyboard base powered by ATmega32U4 Pro Micro controllers with QMK Configurator support.

split89 keyboard - a 3d printed 89 key split TKL keyboard base powered by ATmega32U4 Pro Micro controllers with QMK Configurator support. This keyboar

null 46 Nov 21, 2022
All lab practicals c++ source code will be stored here, for future references.

Karnataka-State-Ist-PU-LAB-practicals-source-code All lab practicals c++ source code will be stored here, for future references. Sourced from this web

Sachit 1 Feb 1, 2022
ESP Insights is a remote diagnostics solution that allows users to remotely monitor the health of ESP devices in the field.

ESP Insights is a remote diagnostics solution that allows users to remotely monitor the health of ESP devices in the field.

Espressif Systems 43 Oct 24, 2022
Phan Sang 13 Nov 12, 2022
3D GPUs Strange Attractors and Hypercomplex Fractals explorer - up to 256 Million particles in RealTime

glChAoS.P ⋅ wglChAoS.P - Ver 1.5.3 glChAoS.P / wglChAoS.P ⋅ opengl / webgl ⋅ Chaotic Attractors of Slight (dot) Particles RealTime 3D Strange Attracto

Michele Morrone 700 Nov 16, 2022
Zep - An embeddable editor, with optional support for using vim keystrokes.

Zep - A Mini Editor Zep is a simple embeddable editor, with a rendering agnostic design and optional Vim mode. It is built as a shared modern-cmake li

Rezonality - 697 Nov 19, 2022
Realtime Micro Kernel -- Event-driven Run-to-Completion RTOS with Active Objects, Timed Events, Memory Pools, and Message Queues

Realtime Micro Kernel Features Active Objects Message queues Variable sized, custom messages Periodic and single timed events Memory pools Supported P

null 3 Nov 7, 2022
A C library for RP2040-powered boards to control LCDs via the I2C protocol

picoi2clcd A C library to control I2C LCD displays using the Rapsberry Pi Pico (or really any board using the RP2040 microcontroller). License All of

Kosmas Raptis 2 Oct 16, 2021
A cross platform shader language with multi-threaded offline compilation or platform shader source code generation

A cross platform shader language with multi-threaded offline compilation or platform shader source code generation. Output json reflection info and c++ header with your shaders structs, fx-like techniques and compile time branch evaluation via (uber-shader) "permutations".

Alex Dixon 285 Nov 16, 2022
The whole design is modular, parametric (cost and others), field repairable, and super extensible

Easy-Transceiver The whole design is modular, parametric (cost and others), field repairable, and super extensible. It is almost trivial to add suppor

Dhiru Kholia 8 Oct 2, 2022
C parsing, semantic analys, generate a graph from a source code. An educational project during my third year of Computer Science Licence.

Pour compiler le programme, il suffit d'exécuter compiler.sh avec la commande "./compiler.sh" en se trouvant dans le dossier racine du projet. Un fich

Jean Philippe Carlens 3 Feb 3, 2022
BSD-licensed Yamaha FM sound cores (OPM, OPN, OPL, and others)

ymfm ymfm is a collection of BSD-licensed Yamaha FM sound cores (OPM, OPN, OPL, and others), written by Aaron Giles Supported environments This code s

Aaron Giles 158 Nov 25, 2022
Allows you to easily control via MQTT any Micronova equiped pellet stove. (MCZ, Extraflame, Laminox, and many others brands!)

micronova_controller Kits are available on Tindie! Currently out of stock. V2 will be in stock soon! Here is an overview of the additions: possibility

Philibert Cheminot 33 Nov 19, 2022
C++ font-lock for Emacs

Syntax highlighting support for "Modern C++" - until C++20 and Technical Specification. This package aims to provide a simple highlight of the C++ lan

Ludwig PACIFICI 168 Jul 13, 2022
MINCE is an Emacs-like text editor from Mark of the Unicorn, Inc.

MINCE Is Not Complete[ly] EMACS Overview MINCE is an Emacs-like text editor from Mark of the Unicorn, Inc. Versions were available for many oper

Jeffrey H. Johnson 20 Nov 5, 2022
tree-sitter grammar for emacs lisp

Tree-sitter Grammar for Emacs Lisp A simple tree-sitter grammar for elisp. Syntax supported: Atoms (integers, floats, strings, characters, symbols) Li

Wilfred Hughes 28 Oct 27, 2022