I don't know vala at all but it seems to work here. I have the same 74 warnings but no error. The warning don't seems to be related to this issue.

I have used vala version 0.36 though perhaps it's an issue in vala 0.38.

Indeed, with Vala 0.36 it seems fine but GNOME 3.26 will ship with Vala 0.38

Hmm, not sure why I didn't get https://mail.gnome.org/archives/vala-list/2017-August/msg00020.html directly. I just found that message through the web interface.

Simply the CCode and Codegen modules have been made internal to libvala with this commit: https://git.gnome.org/browse/vala/commit/?id=c9aa4716b2645af40080bd6523065e78fceba3b4

On the Anjuta side the use of get_ccode_lower_case_prefix () is in the on_drop () method in plugins/language-support-vala/plugin.vala. The method signature is:

public void on_drop (IAnjuta.EditorGladeSignal editor, IAnjuta.Iterable position, string signal_data) { ... }

So it looks like it could be part of automatically connecting signals from Glade with Vala code. The section in on_drop seems to check handler_name against a generated handler_cname and if they are different it will add [CCode(cname="...")] to the Vala signal handler.

It would be nice to have some examples to get a fuller understanding. Maybe for now the line with get_ccode_lower_case_prefix () should be commented out with a warning added such as "Signal cname generation from ui file in Vala plugin may not be as expected - please comment at https://bugzilla.gnome.org/show_bug.cgi?id=786973".

Long term it would be good to have Vala support the language server protocol. So understanding use cases like this is useful.

Created attachment 359243 [details] [review]
possible fix

I don't use Vala but I have tried to write a fix.

The CCodeBaseModule is used only to find the prefix used by vala compiler when dragging a signal from Glade panel into the code editor. As far as I have understood, it's used only to get a shorter name if the name defined in glade match the prefix used by vala compiler.

A better fix would be possible but it could needs some changed inside vala project and is anyway too complex for me.

Could you try if it works with vala 0.38 before I commit it in master? Or you can propose a better idea to fix that.

Review of attachment 359243 [details] [review]:

The patch builds with 0.38. Using the PKG_CONFIG_PATH and VALAC environment variables allowed for the build system to find Vala in an alternative directory:
PKG_CONFIG_PATH=/home/vala_source/installed/lib/pkgconfig/ VALAC=/home/vala_source/installed/bin/valac ./autogen.sh --prefix /srv/vala_builds/anjuta-installed/
The libvala-0.38.vapi did have to be copied from local-install-dir/share/vala/vapi to local-install-dir/share/vala-0.38/vapi

There is no need to amend the build system, Vala provides pre-parser defines for the Vala version - see http://www.vala-project.org/doc/vala/Preprocessor.html
#if VALA_0_38
#else
#endif

Created attachment 359445 [details] [review]
Updated patch using Vala pre-processor instead of build system

For Vala 0.38+ this sets handler_cname = "" in all cases, so it is different to handler_name in presumably all cases and a [CCode (cname="...")] attribute is then always generated. There may be a better solution, but I don't have enough information on how this fits in with Abjuta.

For Vala pre-0.38 is uses the original code. The pre-0.38 or 0.38+ code path is determined at compile time by the Vala compiler.

Review of attachment 359445 [details] [review]:

Thank you for your patch. This is better like this. I have just committed it before the release.

This should be fixed in Anjuta 3.26.0.