ffevotte / clang-tags Goto Github PK
View Code? Open in Web Editor NEWC/C++ source code indexing tool based on libclang
clang-tags's People
Contributors
Stargazers
Watchers
Forkers
rsrinivasara deepestthought42 cameronwhite gpderetta uikit0 inlinechan zhongxingzhi asenac azurepine toddlipcon lilixiong nrnrnr innokentiy-alaytsev hankw507 ring2003 sinojelly johnzeng kevinxusz artisdom greyblue9 dandurilclang-tags's Issues
quickStart.html is Inconsistent
http://ffevotte.github.io/clang-tags/quickStart.html#sec-2-1 sees to switch between MyClass::display and Cursor::location. There might be other discrepancies.
License
Why a license different than clangs? Even the project your naming it after (clang) couldn't use the code.
GPLv3 is incompatible with basically every other license. One of the major reasons clang exists is not to deal with license problems anymore.
Excessive loading time
I just built and ran clang-tags on its own source code - and it took almost 3 hours at 100% CPU to complete the 'load' command. Is this to be expected?
This is running on a Mac OS X 10.9 system, built with clang 3.3 and boost 1.54 (both installed from MacPorts), as follows:
$ CC=clang-mp-3.3 CXX=clang++-mp-3.3 cmake -DCMAKE_BUILD_TYPE=Release -DLIBCLANG_ROOT=/opt/local/libexec/llvm-3.3/ -DCMAKE_EXPORT_COMPILE_COMMANDS=1 ..
$ make
Note that there is no support for strace on this system, so I had to comment out the relevant line in CMakeLists.txt. This seemed OK - at least it correctly picked up the compile_commands.json file.
I have the output of the load command but it's a bit too long to attach to this issue. I can email it if needed. However from observation of the progress, it seemed that the bulk of the time was spent in header files such as boost.
clang-tags won't build (Debian jessie, libclang-3.4-dev and libclang-3.5-dev installed)
I'm following the instructions at http://ffevotte.github.io/clang-tags/install.html when I trip over the following error:
: nr@labrador 67171 ; cmake ../src
-- Boost version: 1.55.0
-- Found the following Boost libraries:
-- system
CMake Error at /usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:136 (message):
Could NOT find Libclang (missing: Libclang_LIBRARY Libclang_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:343 (_FPHSA_FAILURE_MESSAGE)
cmake/Modules/FindLibclang.cmake:13 (find_package_handle_standard_args)
CMakeLists.txt:34 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/nr/net/clang-tags/build/CMakeFiles/CMakeOutput.log".
: nr@labrador 67172 ; less -N /usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake
: nr@labrador 67173 ; less cmake/Modules/FindLibclang.cmake
cmake/Modules/FindLibclang.cmake: No such file or directory
: nr@labrador 67174 ; less ../src/cmake/Modules/FindLibclang.cmake
: nr@labrador 67175 ; wd
~/net/clang-tags/build
: nr@labrador 67176 ; cd ..
: nr@labrador 67177 ; rm -rf build
: nr@labrador 67178 ; md build
: nr@labrador 67179 ; cd build
: nr@labrador 67180 ; cmake ../src
-- The C compiler identification is GNU 4.9.2
-- The CXX compiler identification is GNU 4.9.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Boost version: 1.55.0
-- Found the following Boost libraries:
-- system
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.28")
-- Found LibJsoncpp: /usr/lib/libjsoncpp.so
CMake Error at /usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:136 (message):
Could NOT find Libclang (missing: Libclang_LIBRARY Libclang_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:343 (_FPHSA_FAILURE_MESSAGE)
cmake/Modules/FindLibclang.cmake:13 (find_package_handle_standard_args)
CMakeLists.txt:34 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/nr/net/clang-tags/build/CMakeFiles/CMakeOutput.log".
Investigation reveals that the build script seems to be looking for clang 3.2.
I have clang 3.4 and clang 3.5 installed (which is what's on offer from Debian jessie):
: nr@labrador 67181 ; cat -n ../src/cmake/Modules/FindLibclang.cmake
1 find_path (Libclang_INCLUDE_DIR clang-c/Index.h
2 HINTS "${LIBCLANG_ROOT}/include"
3 PATH "/usr/lib/llvm-3.2/include")
4
5 find_library (Libclang_LIBRARY clang
6 HINTS "${LIBCLANG_ROOT}/lib"
7 PATH "/usr/lib/llvm-3.2/lib")
8
9 set (Libclang_LIBRARIES ${Libclang_LIBRARY})
10 set (Libclang_INCLUDE_DIRS ${Libclang_INCLUDE_DIR})
11
12 include (FindPackageHandleStandardArgs)
13 find_package_handle_standard_args (Libclang DEFAULT_MSG
14 Libclang_LIBRARY Libclang_INCLUDE_DIR)
15
16 mark_as_advanced (Libclang_INCLUDE_DIR Libclang_LIBRARY)
I understand nothing of cmake or libclang, so not sure if blithely changing to /usr/lib/llvm-3.5 is really desirable here.
Adherence to system-specific settings
- The
CMakesetup doesn't work out of the box for systems which don't supportstrace(although it is not a strict requirement) -
env.shcannot be sourced flawlessly from non-bash shells
Invalid syntax while archiving
[still trying to index v8...]
CXX(target) /v8/out/x64.debug/obj.target/v8_base/src/accessors.o
AR(target) /v8/out/x64.debug/obj.target/tools/gyp/libv8_base.a
LINK(target) /v8/out/x64.debug/mksnapshot
Traceback (most recent call last):
File "clang-tags", line 550, in <module> sys.exit (main_argparse())
File "clang-tags", line 541, in main_argparse return args.fun (args)
File "clang-tags", line 156, in trace
(programName, command) = eval(line)
File "<string>", line 1
("/bin/ar", ["ar", "crsT", ...
"/v8/out/x64.debug/obj.target/v8_base/src/heap/gc-idle-time-handler.o", ...]) ^
SyntaxError: invalid syntax
Automatic update of the index when source files change
This work is done in the inotify branch
- use Linux'
inotifysystem to watch for source files modifications on the file system and update the index accordingly - update the documentation
- merge into master
typo on jsoncpp
Hi,
there is an inconsistency, since in there is a call to the method Json::Reader::getFormattedErrorMessages (in storage.hxx). But the real interface in jsoncpp has only one 't': getFormatedErrorMessages
Paolo Crosetto
Parallel processing
I'd like clang-tags to use all my CPU cores, not just one. Please consider detecting CPU count, spawn worker threads to index/update faster. Alternatively, a user might want to define how many threads to use when daemon is starting.
Invalid execve regex
The regex tracing the execve syscall fails to include a return value. As a result, failed system call will still considered valid, where they should not be and will both be included to the compilation database
For exemple:
[pid 30681] execve("/invalid/path/to/clang++", ["clang++", ..., "../src/compiler/js-builtin-reducer.cc"], [/* 58 vars */]) = -1 ENOENT (No such file or directory)
[pid 30681] execve("/valid/path/to/clang++", ["clang++", ..., "../src/compiler/js-builtin-reducer.cc"], [/* 58 vars */]) = 0
clang-tags database does not identify definitions
I'm finding the clang-tags sqlite database incredibly useful for my project, but it would be even more useful if a new column were added to the tags table, containing the results of the libclang API call
CINDEX_LINKAGE unsigned clang_isCursorDefinition (CXCursor)
If there could be an isDefn column along with the isDecl column, that would be awesome.
I am willing to try to help make this happen with a fork and a pull request, but although I am a decent C programmer, my C++ skills are minimal. Can you give any guidance? What's a good way to proceed?
Is it documented how to construct a Unified Symbol Resolution (USR)?
I'm indexing a C99 program. Suppose I want to find all references to, say, a local variable e in a function eval in a file evalstack.c. How do I construct the appropriate USR for use with clang-tags grep?
Is there documentation that can be found on the construction and meaning of valid USRs?
Use multiple source directories (Suggestion)
Simplest use case: Be able to work on project A using libraries from project B, project C, etc. Be able to navigate to the source code of B for reference or simply just to fix it.
Ambitious use case: Share an index between a group of related projects: A uses B uses C. Be able to find users of B in A while working on B which uses C.
BTW, the command-line access to scan, index and look up code is great just on its own. The emacs integration is a bonus.
List of all defined symbols?
Is there a way to get a list of all defined symbols? If I could do that, I could dump the entire index to find out what is there? Or maybe I should try to discover the format of the configuration file used by the Emacs mode?
The problem I am trying to solve is to incorporate my source code into a LaTeX document and to include a link from each use of each identifier to the place in the LaTeX document where that identifier is defined. I have the information linking C source code locations to the LaTeX document, and I am hoping to integrate that with the cross-reference information from clang-tags.
Vim plugin
Hi!
I really like this tool and I've started to use it in my projects. I've made an small Vim plugin to use clang-tags from Vim. Here is the URL of the plugin https://github.com/asenac/vim-clang-tags if you could add a reference in your website.
Regards,
Andres
Advantages compared to similar tools & no mentions of rtags?
Hello,
In the "Similar tools" of the README, I was surprised not to see https://github.com/Andersbakken/rtags
It's also hard to know wether clang-tags has improvements over rtags... but probably I didn't search the documentation hard enough.
The list of source files is not updated when new compilation database is loaded
This leads to bugs when source files are deleted from the project: no compilation command allows compiling removed files, which leads to a server infinite loop when running clang-tags update
Patch to avoid gcc warnings
Build failure - link issues
This doesn't build out of the box on FC31 (gcc (GCC) 9.3.1 20200317 (Red Hat 9.3.1-1)). It looks like -lpthread in missing from the link flags.
[ 72%] Built target test_sqlite++
/usr/bin/cmake -E cmake_link_script CMakeFiles/clang-tags-server.dir/link.txt --verbose=1
/usr/lib64/ccache/c++ -rdynamic CMakeFiles/clang-tags-server.dir/main.cxx.o CMakeFiles/clang-tags-server.dir/request/request.cxx.o CMakeFiles/clang-tags-server.dir/compilationDatabase.cxx.o CMakeFiles/clang-tags-server.dir/index.cxx.o CMakeFiles/clang-tags-server.dir/findDefinition.cxx.o CMakeFiles/clang-tags-server.dir/grep.cxx.o CMakeFiles/clang-tags-server.dir/complete.cxx.o -o clang-tags-server -lboost_system -ljsoncpp -lclang -lsqlite3 libsqlite++.a libclang++.a libgetopt++.a
/usr/bin/ld: CMakeFiles/clang-tags-server.dir/main.cxx.o: undefined reference to symbol 'pthread_join@@GLIBC_2.2.5'
/usr/bin/ld: /usr/lib64/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/clang-tags-server.dir/build.make:198: clang-tags-server] Error 1
make[2]: Leaving directory '/home/uday/Downloads/clang-tags'
make[1]: *** [CMakeFiles/Makefile2:301: CMakeFiles/clang-tags-server.dir/all] Error 2
make[1]: Leaving directory '/home/uday/Downloads/clang-tags'
make: *** [Makefile:158: all] Error 2
Adding it makes it fine.
clang-tags missing some uses of a function
After using clang-tags successfully for some years, I had to rebuild it after a major OS upgrade. Now I have noticed some difficulty: it is not identifying every use of a function. Putting together a minimal test case might take several hours, but if there is a chance of the issue being fixed, I will do so. Meanwhile, here is some evidence.
clang-tags grep finds declaration, definition, and two uses of function topframe. I'm not sure why the uses are listed twice:
nr@homedog /t/b/p/uschemeplus> clang-tags grep c:@F@topframe
Server response:
all.h:434:Frame *topframe(Stack s); // NULL if empty
context-stack.c:36:Frame *topframe (Stack s) {
eval-stack.c:153:topframe(evalstack)->syntax = e;
eval-stack.c:153:topframe(evalstack)->syntax = e;
eval-stack.c:216:fr = topframe(evalstack);
eval-stack.c:216:fr = topframe(evalstack);
The number of actual uses is found by grep:
nr@homedog /t/b/p/uschemeplus> grep -nw topframe *.h *.c
all.h:434:Frame *topframe(Stack s); // NULL if empty
context-stack.c:36:Frame *topframe (Stack s) {
eval-stack.c:106:fr = topframe(evalstack);
eval-stack.c:133:fr = topframe(evalstack);
eval-stack.c:153:topframe(evalstack)->syntax = e;
eval-stack.c:216:fr = topframe(evalstack);
eval-stack.c:387: fr = topframe(evalstack); // fr now points to the next youngest frame
eval-stack.c:435: Frame *f = optimize_tail_calls ? topframe(s) : NULL;
stack-debug.c:33: if (topframe(s))
Efforts to use clang-tags find-def at that location produce only eval, which is the function containing the call.
Unreliable trace method
The trace method currently used, relying on strance, is unreliable. It fails to handle build system spawning sub-make command. For exemple:
# ls src/
a.cc
# make -C build
Entering .../build/
# clang++ [...] ../src/a.cc
Will fail because clang-tags will fail to intercept the newly spawned instance of make. As a result, its cwd will be ./ instead of ./build and ../src/a.cc will not be considered existent.
Command-line switches handling
From issue #8:
By the way I think there is a typo in one the commands above. I think you meant to write
config -a index.exclude /opt/localinstead ofconfig index.exclude -a /opt/local. The latter will cause the default exclude path of/usrto be replaced with.../-aand/opt/local. This means everything in/usris indexed.
when compiled with libclang 3.8, clang-tags fails a regression test
At the moment, I'm continuing to use clang 3.5, which seems to work.
clang-tags compiles against llvm/clang 3.8, but it fails one of its regression tests.
Translation unit cache is never cleared
When indexing a project of mine, the memory usage of clang-tags-server grows to over 4GB after parsing about 100 files - the main cause of the memory usage seems to be the caching of translation units.
The simplest fix would be to just disable the caching of translation units while indexing, but I think a better fix would be to limit the cache to a maximum number of translation units and/or a maximum memory size so that this problem doesn't occur for clang-tags complete as well.
What do you think?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.