GNOME Bugzilla – Bug 792998
vala 0.36.9 generates incorrect vte-2.91.vapi for vte 0.48.3
Last modified: 2018-01-29 23:28:52 UTC
Versions 0.36.8 and 0.36.9 of vala generate vte-2.91.vapi incorrectly for vte 0.48.3. Vala 0.36.7 and earlier generate vte-2.91.vapi properly. The vte API has an interface for getting and setting the encoding which is of type gchar * and can be directly accessed by the application. In Vte-2.91.gir it looks like: <property name="encoding" writable="1" transfer-ownership="none"> <doc xml:space="preserve">Controls the encoding the terminal will expect data from the child to be encoded with. For certain terminal types, applications executing in the terminal can change the encoding. The default is defined by the application's locale settings.</doc> <type name="utf8" c:type="gchar*"/> </property> When generating vte-2.91.vapi, older versions of vala generate the following: [NoAccessorMethod] public string encoding { owned get; set; } Vala versions 0.36.8 and 0.36.9 generate: public string encoding { get; set; } When a consumer of this interface (in this case altyo 0.4_rc19) uses vala to generate code to set the encoding, the generated code attempts to use a non-existent two-argument vte_terminal_set_encoding() function and the compile fails if vala 0.36.8 or newer was used to generate the .vapi file. If the .vapi file is generated by vala 0.36.7 or earlier, vala versions 0.36.8 and 0.36.9 will generate working code.
The vapi should be "more" correct than before. Although the problem is this special setter which may throw an error. gboolean vte_terminal_set_encoding (VteTerminal *terminal, const char *codeset, GError **error); bound as: bool set_encoding (string? codeset) throws GLib.Error; So we need to handle this by adding an additional NULL argument like it is done in vte_terminal_set_property().
I think that is the legacy vte 2.90 API which is still present for compatibility. The altyo source contains a file named altyo_terminal.vala that contains this fragment of code: var s = my_conf.get_string("terminal_default_encoding","default"); if(s!="default"){ #if ! VTE_2_91 this.vte_term.set_encoding (s); #else this.vte_term.encoding=s; #endif }else #if ! VTE_2_91 this.vte_term.set_encoding (null);//reset to default #else this.vte_term.encoding=null; #endif } Since VTE_2_91 is defined, the direct assignment versions of the code will be used: this.vte_term.encoding=s; and this.vte_term.encoding=null; This all works fine with vala 0.36.7 and earlier. With vala 0.36.8 and newer the generated C code looks like it attempts to call: vte_terminal_set_encoding (VteTerminal *terminal, const char *codeset) which is a fatal compile error since the only the three argument version of the setter function is defined. The actual compile errors are: /wrkdirs/usr/ports/x11/altyo/work/AltYo-debian-0.4_rc19-linvinus1/altyo_terminal .vala.c:5638:62: error: too few arguments to function call, expected 3, have 2 vte_terminal_set_encoding ((VteTerminal*) _tmp44_, _tmp4 5_); ~~~~~~~~~~~~~~~~~~~~~~~~~ ^ /usr/local/include/vte-2.91/vte/vteterminal.h:399:1: note: 'vte_terminal_set_enc oding' declared here _VTE_PUBLIC ^ /usr/local/include/vte-2.91/vte/vtemacros.h:42:21: note: expanded from macro '_V TE_PUBLIC' #define _VTE_PUBLIC __attribute__((__visibility__("default"))) extern ^ /wrkdirs/usr/ports/x11/altyo/work/AltYo-debian-0.4_rc19-linvinus1/altyo_terminal .vala.c:5642:59: error: too few arguments to function call, expected 3, have 2 vte_terminal_set_encoding ((VteTerminal*) _tmp46_, NULL) ; ~~~~~~~~~~~~~~~~~~~~~~~~~ ^ /usr/local/include/vte-2.91/vte/vteterminal.h:399:1: note: 'vte_terminal_set_enc oding' declared here
Direct access to the encoding variable is mentioned in the Vte docs here: https://developer.gnome.org/vte/unstable/VteTerminal.html#VteTerminal--encoding
vte-2.91.vapi *does* also contain the legacy setter: public bool set_encoding (string? codeset) throws GLib.Error;
I understood the problem with your initial report. I don't see an indication that the "set_encoding()" method is meant to be deprecated/obsolete in any way by upstream. So the explicit accessor-methods for the "encoding" property can still be used, which is still done in vte itself. Of course this an unfortunate regression in vala. To fix this fast, you can simply drop the paths with the property-set ("direct access", as you call it).
Created attachment 367588 [details] [review] girparser: Don't accept methods as property-accessor which throw errors This should be considered a temporary fix.
Attachment 367588 [details] pushed as ff8a6d1 - girparser: Don't accept methods as property-accessor which throw errors