Vala parser (in progress)

[masatake]

• https://www.vala-project.org/doc/vala/
• https://www.vala-project.org/doc/manual.pdf

[coveralls]

Coverage increased (+0.02%) to 87.216% when pulling a8a03f2 on masatake:vala into 165f7e3 on universal-ctags:master.

[codecov]

Codecov Report

❌ Patch coverage is 92.15686% with 32 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.10%. Comparing base (0ae4783) to head (bb54fdb).
⚠️ Report is 1156 commits behind head on master.

Files with missing lines	Patch %	Lines
parsers/vala.c	93.49%	24 Missing ⚠️
main/tokeninfo.c	79.48%	8 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2677      +/-   ##
==========================================
+ Coverage   85.02%   85.10%   +0.07%     
==========================================
  Files         228      229       +1     
  Lines       53901    54345     +444     
==========================================
+ Hits        45832    46252     +420     
- Misses       8069     8093      +24     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[masatake]

@rrthomas, I need your help.

var x = 1;

For x in the input, which "kind" I should assign to it.

I tried anjuta-tags installed via Fedora's repository. However, it seems that it has no Vala parser.

The kinds set of the vala parser we are working on is based on anjuta-tags.
The kinds we have in the vala parser are:

#LETTER NAME        ENABLED REFONLY NROLES MASTER DESCRIPTION
E       errordomain yes     no      0      NONE   error domains
S       signal      yes     no      0      NONE   signals
c       class       yes     no      0      NONE   classes
d       delegate    yes     no      0      NONE   delegates
e       enum        yes     no      0      NONE   enumerations
f       field       yes     no      0      NONE   fields
i       interface   yes     no      0      NONE   interfaces
l       local       no      no      0      NONE   local variables
m       method      yes     no      0      NONE   methods
n       namespace   yes     no      0      NONE   namespace
p       property    yes     no      0      NONE   properties
r       errorcode   yes     no      0      NONE   error codes
s       struct      yes     no      0      NONE   structures
v       enumvalue   yes     no      0      NONE   enumeration Values

I cannot find variable kind. Should I add variable kind? or should I use the "field" kind instead?
In this case, how I should fill the "scope:" field?
Does vala have "main" or "top-level" something implicit namespace for dealing with a variable as a member?

[masatake]

/*
 * vala HelloWorld
 */
void main(string[] args) {
    print("Hello, World\n");
}

In this test case, main is tagged as a method.
So the x should be recorded as a field.

[rrthomas]

@masatake: anjuta-tags uses libvala's Vala parser.

Your analysis sounds right: it looks like it's a field.

[masatake]

# public domain
# This one is for https://gitlab.gnome.org/GNOME/vala/-/blob/master/doc/manual/manual.xml
--langdef=valaManualXML
--map-valaManualXML=+(manual.xml)
--kinddef-valaManualXML=r,rule,syntax rules
--regex-valaManualXML=/<para>([^:]+):<\/para>/\1/r/

[masatake]

@rrthomas, thank you.

anjuta-tags uses libvala's Vala parser.

It is the reason why anjuta-tags emits nothing for input.vala?
Can I use anjuta-tags for parsing vala input from the command line?

[rrthomas]

It is the reason why anjuta-tags emits nothing for input.vala?

Sorry, I'm not sure what you're referring to. Is input.vala a particular file?

Can I use anjuta-tags for parsing vala input from the command line?

I don't think so, I think anjuta-tags only supports the same options as whatever version of ctags it was forked from. I don't think it exposes the Vala parser directly to the user.

[masatake]

Sorry, I'm not sure what you're referring to. Is input.vala a particular file?

input.vala is u-ctags terminology. It means any input file written in Vala.

Can I use anjuta-tags for parsing vala input from the command line?
I don't think so, I think anjuta-tags only supports the same options as whatever version of ctags it was forked from. I don't think it exposes the Vala parser directly to the user.

I can't find "Vala" in "anjuta-tags --list-languages| grep -i vala".
I wonder the packager of the RPM package disables the parser when building.

[rrthomas]

Sorry, I'm not sure what you're referring to. Is input.vala a particular file?

input.vala is u-ctags terminology. It means any input file written in Vala.

Ah, thanks for explaining.

I can't find "Vala" in "anjuta-tags --list-languages| grep -i vala".

$ anjuta-tags --list-languages|grep -i vala
Vala

I wonder the packager of the RPM package disables the parser when building.

Looks like it.

[albfan]

I'm just using this building as:

./autogen.sh
./configure --prefix /usr
make
DESTDIR=foo make install
sudo cp foo/usr/bin/ctags /usr/bin/ctags-vala

Will provide feedback but looks to parse almost everything. Any known blocker to merge? I think I can contribute again if needed

[masatake]

Will provide feedback but looks to parse almost everything. Any known blocker to merge? I think I can contribute again if needed

Thank you, but I cannot remember why I didn't merge this.

I read test cases to find the incompleteness of the parser.

A. typeref fields for methods should be filled.

void main(string[] args) {
...

The tag entry for the main is:

main	input.vala	/^void main(string[] args) {$/;"	kind:method	line:8	language:Vala	signature:(string [] args)	roles:def	end:13

The return type void should be storin to its typeref field.
I am disappoinhat I didn't implement the code for filling the field.

B. Semantics?

namespace X {
}

public class X.MyObject {

For X.MyObject, which tags should we make "X.MyObject" or "MyObjecRegardingr as reading a test case (qnamed-class.d), I expected ctags makes a tag for "X.MyObject".
However, I cannot convince whether this is a good idea or not.
Users may want to jump the definition of MyObject with an input key "MyObject", not "X.MyObject". Making a tag "X.MyObject" doesn't help the users' wants.

C. kinds having only stubs
K_DELEGATE, K_SIGNAL, K_LOCAL are not implemented. We can remove K_LOCAL. However, the rest of two may be too important.

D. Generics and other language features

B. is the primary blocker.
This is not only about Vala.
I wonder how did we do in the other languages.

Maybe we should make a reference tag for X of X.MyObject.
Then we should make a tag for MyObject which has X as scope.
This is the technique I found and introduced during hacking the JavaScript parser.

This "indirection through a reference tag" technique is nice because it is possible to make a tag for X.MyObject with --extras=+q notion if you want.

It seems in the year 2020, I didn't get the idea.

[rrthomas]

Amazing work, @masatake!

[masatake]

I added lines to parseClassBody. However, it seems that I should add them to recurseValaTags. I have to restart from 8e16ea9. I extended the test cases that valac accepted. So restarting is not so hard.