Adding varType TagEntryInfo field from Geany

[techee]

I'd like to start syncing Geany's ctags with universal-ctags and there are a few things we'd need in universal-ctags in order to have all the functionality we need. One of the things we need is a

const char *varType;

field in sTagEntryInfo. As the name suggests, it contains a string corresponding to a variable type or a return type of a function. For instance for

char *foo;

int bar() {
    return 0;
}

it contains "char *" for the variable and "int" for the function. We need this info to be able to perform scope-based autocompletion and also the return value of functions for tooltips. This value is non-NULL only for statically typed languages - the currently supported ones in Geany are the languages from c.c and then Pascal, Rust, Go (c.c implementation in Geany diverges quite a lot and I haven't checked how hard it would be to port it to universal-ctags - the other languages should be easy to port).

Is it OK to add a new field to ctags with this information? I'd prepare a patch doing this. I've also noticed #857 - one possibility would be to use custom extension field for this info (though the type info should be available for all statically typed languages so quite a big portion so one field defined for all of them might be better).

cc @b4n

[masatake]

I'm working hard to generalize field manipulation based on the idea proposed in #857 by @pragmaware.
Could you wait for awhile?

[techee]

@masatake Sure, no problem. From the Geany perspective it's just important that we have some kind of access to the field definitions to map them to Geany's internal types. I did this in the last commit of

geany/geany#957

by accessing LanguageTable. If you are interested what we need from ctags you can have a look at tm_ctags_wrappers.h/c in the pull request.

[masatake]

@techee, did you see typeref:typename introduced by @pragmaware ?

[yamato@x201]~/var/ctags-github% cat /tmp/foo.c
cat /tmp/foo.c
char *foo;

int bar() {
    return 0;
}
[yamato@x201]~/var/ctags-github% ./ctags -o - /tmp/foo.c
./ctags -o - /tmp/foo.c
bar /tmp/foo.c  /^int bar() {$/;"   f   typeref:typename:int
foo /tmp/foo.c  /^char *foo;$/;"    v   typeref:typename:char *

This is not enough?
@pragmaware solved two things.

1. the way to use typeRef[2] field of extensionFields of tagEntryInfo.
   As @b4n speicified before, ctags main part expects typeRef [0] and typeRef[1] are filled.
   e.g. "struct" and "foo". for char *foo, typeRef[0] cannot be filled.
   @pragmaware 's hack is that "typename" is used for filling typeRef[0].
   See docs/cxx.rst.
2. field in tags file.
   Surprisingly he didn't introduce new filed in tags file. He reused typeref field.
   In other word his change about tags file format is very small.

However, @pragmaware digs more. Finally he wants a new filed both in data structured and
tags file.

@techee, could you look at #872. I made a prototype for allowing a parser defining new field.
If you like the prototype, I will work on the area more.

[techee]

@pragmaware solved two things.

the way to use typeRef[2] field of extensionFields of tagEntryInfo.
As @b4n speicified before, ctags main part expects typeRef [0] and typeRef[1] are filled.
e.g. "struct" and "foo". for char *foo, typeRef[0] cannot be filled.
@pragmaware 's hack is that "typename" is used for filling typeRef[0].
See docs/cxx.rst.

field in tags file.
Surprisingly he didn't introduce new filed in tags file. He reused typeref field.
In other word his change about tags file format is very small.

This is actually almost all we'd need - in Geany we could concatenate typeRef[0] and typeRef[1] to get what we now have in varType. It would just be nicer if typeRef[0] was allowed to be NULL and "typename" was generated when creating the tag in entry.c. The problem is that the cxx parser uses "typename" both for this case but also when it's really a true typename and we won't be able to distinguish this in Geany. In addition, the PHP parser uses "unknown" for the same so in Geany we'd need some per-language table defining what word is used here.

What I'd suggest is #880 . That is, having typeRef[0] == NULL in this case and generating "unknown" for it when writing out the tag. I find the name "unknown" better here because it doesn't refer any existing tag type which then leads to ambiguity between e.g. real "typename" and "typename that's not really a typename".

@pragmaware @masatake What do you think?

[techee]

@masatake Regarding #872 - it looks nice but as typeRef already exists, it would be better to reuse this one and not to have another field doing almost the same. Moreover, it would add some complications to Geany because each parser could have a different set of the extended fields and we'd need to somehow know which of the fields corresponds to the varType field (and this could be different for every language).