-
Notifications
You must be signed in to change notification settings - Fork 620
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cxx: extract reference tags #3535
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #3535 +/- ##
==========================================
+ Coverage 82.83% 82.88% +0.05%
==========================================
Files 226 227 +1
Lines 54754 54870 +116
==========================================
+ Hits 45353 45478 +125
+ Misses 9401 9392 -9
☔ View full report in Codecov by Sentry. |
For the latest linux kernel source, ctags with this pull request generates 8GB tags file.
It takes about 10 minutes for generating a tags file. Citre works fine but I think we can improve UI for reference tags. This unknown kind +ref role approach can be applied to all token-based parsers like python and javascript parsers. |
No built-in parser users |
Citre now takes a pluggable backend design,
Currently the only "find reference" backend is global backend. I could create a tags backend. |
@AmaiKinono Thank you for your response. I have used this branch + citre (87e2cbf3b2ae6d59ec919a2dcb38e56ccfa5ec14, a bit othreeder) for 3 days to read Linux kernel. M-. becomes slower maybe because readtags reports too many tags. The question is whether M-. of citre users becomes slower or not if I merge this branch today.
The instructions (https://github.com/universal-ctags/citre/blob/master/docs/user-manual/about-tags-file.md#create-informative-tags-file) about the way to run ctags, do not enable the "ref" role of "unknown" kind. So I can say merging this branch today doesn't get citre users in trouble. |
…an-local See universal-ctags#3535 (comment). Signed-off-by: Masatake YAMATO <yamato@redhat.com>
…an-local target See universal-ctags#3535 (comment). Signed-off-by: Masatake YAMATO <yamato@redhat.com>
The problem is until now, Citre assumes tags files don't contain "reference tags" in the general sense. u-ctags only emits reference tags that point to external modules/files (let's call them dependency references for now). They are useful and aren't too many, so Citre doesn't filter them out when finding definitions. But after this PR, uctags emits reference tags pointing to general entities (let's call them general reference for now). Citre should exclude them when finding definitions, and include them when finding references. We could do this in 2 ways:
Personally I feel the second way is better.
It won't become slower as you already pointed out. P.S. Actually I think tagsfile is not the best format for references. If we create a tagline for every symbol in a codebase, the tagsfile could become larger than the codebase itself. A binary database (like GNU global does) could save much space. But this is only my own thoughts. It may be unrealistic to make necessary changes to uctags for solving this problem. |
@AmaiKinono You wrote what I thought but I could not write.
I agree with you. The "space" is one of the biggest reasons why I have not implemented reference tags. |
Good ideas. These proposals help me when extending our man pages. |
c85f0a5
to
ef9e6b4
Compare
Python may extract too many 'self'. |
8f52d02
to
678461c
Compare
Though breaking compatibilities, I will change the letters for unknown to Y. |
82c5627
to
78fde67
Compare
25a5d78
to
ddf135e
Compare
As I expected, the new idea, "assigning a cork index to a token", allows us to implement reference tags more than the "unknown" kind. input1.c:
output1.tags
|
ddf135e
to
e47cb40
Compare
e47cb40
to
cda022b
Compare
There are still many TODO items, ctags running locally successfully extracted We should add the rule, "unknown+ref should have lower priority" to Citre's sorting engine. |
1921b66
to
21ddab6
Compare
When I looked up a rather generic name like "inode", M-. took very long time. So for evaluation of this pull request, I added some code to Citre:
|
Thanks! This is really helpful. May I ask you for a PR to Citre, or can I use your code directly? |
This is a quick hack. Can you please add a new code for M-?. What I didn't add was code for 'C-u M-?'. I want to have it. You wrote:
I agree with you.
I agree with you. However, I would like to use the tags output till I understand what I want. |
This one is hard. When finding references of a user-inputted symbol, what xref does is get the symbol by Citre is an xref backend and itself also has backends. Suppose a Citre backend A can give us all symbols in a project (so it could support Before passing a symbol to This may be solved by some jump wire code but it needs some design... We are too away from the theme of this PR. Now I know what you want and I'll see how to implement it ;) |
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
struct opt file_ops { .read = file_read, .write = file_write, }; The parser extracts "read" and "write" with "initialized" role of "member" kind. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
struct opt file_ops { .read = file_read, .write = file_write, }; The parser with this change extracts "file_read" and "file_write" with "value" role of "unknown" kind. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
struct opt file_ops { .read = file_read, .write = file_write, }; The parser with this change extracts "opt" with "defvar" role of "unknown" kind. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
#include <stdio.h> int main(void) { return puts("hello, world\n"); } The parser with this change extracts "puts" with "applied" role of "unknown" kind. TODO: consider sub parsers. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
21ddab6
to
ef7e809
Compare
See also #569.
Signed-off-by: Masatake YAMATO yamato@redhat.com
TODO: