Sync our ctags to the latest tag version (p6.1.20240421.0) #3859
Conversation
The file name has been changed and we cannot use the script for the update.
Geany compiles fine after this step, it just doesn't run because of incorrect mappings.
The parser isn't used by Geany itself but is started from within the cxx parser and the asm parser which don't run correctly without it.
All extra kinds are mapped to undef_t. Geany starts after this step.
Without it we might not get proper hierarchy in the sidebar because of missing parent tags.
Note: in C and other languages function arguments contain braces but it doesn't seem to be the case here. So instead of mymacro(args) we get mymacroargs in the pretty-printer script. Not sure if it's our problem or if the asm parser should be updated upstream.
When role kinds are enabled, they report tags also for checks like #ifdef MY_MACRO in which we are not interested.
There are lots of differences because of universal-ctags/ctags@6d85089 Also universal-ctags/ctags@b1870b8 seems to confuse the parser in simple.js so it doesn't generate my_global_var2. Finally, Geany reports (geany:820768): Tagmanager-WARNING **: 20:38:28.755: ignoring null tag in /home/parallels/projects/geany/doc/reference/jquery.js(line: 2, language: JavaScript)
Even though the output isn't perfect, I'd prefer not to maintain our own version of the parser (with different kinds which makes ctags files incompatible with our version).
|
I also added a commit updating the matlab parser to the upstream regex-based one. I'd like to avoid the situation that we have to maintain our (non-regex) version of the parser like in: Also, the kinds generated by the upstream parser are different than those we parse using our parser so the ctags file are incompatible. |
|
I'll look into this Soon™, but the JS changes might have an issue (might be what you see, might be something else), see this which doesn't look right to me. In any case, thanks for doing this :) |
|
Regarding JS:
Yeah, all this look OK. Some can be viewed as implementor's choice, but it's fair so I'm fine with it.
Despite what's in the test file, this is not valid JS (AFAICT, or as far as SpiderMonkey tells me), so it's understandable the parser doesn't get along very well with it. If you add a semicolon after it it fixes it, as it then consider it the end of the construct and "resets" itself.
Is this actually anything new? I just fixed a few upstream in universal-ctags/ctags#3993, but I believe we already had this before. Also, there's one instance in that jQuery code where it's somewhat expected, as there is indeed a zero-length property. For that remaining one, I'm not sure what the parser should do, as it can't really emit an empty name (format would probably not accept it, and anyway consumers are unlikely to like it), yet there is one in the input…
Yeah, the JS changes look (almost) fine. I raised a couple issues upstream, but it's nothing serious nor that actually affect us much (see e.g. universal-ctags/ctags#3995 and universal-ctags/ctags#3997). Two things:
|
|
BTW:
Tags |
|
@b4n Thanks for having a look at the javascript parser.
Can do that. Should it be part of this PR or a separate one after this one is merged?
Could do it myself but better someone who at least remotely knows what the correct syntax is :-).
OK, I didn't notice the release tags. But since these are just about once a year, I guess we want the latest thing and "risk" the consequences, right? |
tests/ctags/matlab_test.m.tags
Outdated
There was a problem hiding this comment.
that's a bit sad… I'll see if I can get those fixed upstream (it's easy enough to patch actually -- yet, I don't have a clue about matlab 😁 )
Whichever you prefer. I'd have said this one given it'll introduce yet another set of changes that are probably best diffed from current master, but I don't really mind either way in practice, so if it's easier for you just do another one afterwards.
Yeah, I think we can "risk it" 🙂 |
I just wanted to avoid rebasing this PR on top of another ctags version so I'd prefer a separate PR (which will be much smaller and easier to review). |
Remove invalid code (despite what the code says) that now confuses the parser, leading to missing tags after it.
|
@techee I just added 2 more commits -- feel free to comment and reject them :) |
Yes, that's what I'm gonna do, just to enjoy the power :-). Anyway, great, I've merged this PR. If you plan to do some more ctags changes, just ping me when you are done and the changes are merged upstream and I'll prepare another sync PR with them. |
|
Once this is dealt with that'd be fine: |
|
@techee FWIW, the PRs I wanted merged now are, so it's whenever you like :) |
|
Great, I think I'll just wait for the next ctags tag and will use that one. |
There were mostly expected "problems" like new source files that had to be added, rename of
perl6.ctoraku.c, update of kind mappings, etc.The only unexpected thing is the behavior of the javascript parser - this is from the javascript commit message:
There are lots of differences because of
universal-ctags/ctags@6d85089
Also
universal-ctags/ctags@b1870b8
seems to confuse the parser in simple.js so it doesn't generate
my_global_var2.Finally, Geany reports
@b4n Does the PR in general and the javascript parser in particular look good to you? I didn't investigate the javascript parser differences much as I'm not a javascript user myself. At least the NULL warning should be fixed though.