GNOME Bugzilla – Bug 657751
gmmproc: Some parameters in a _WRAP_METHOD may affect a later _WRAP_METHOD
Last modified: 2011-10-20 14:59:42 UTC
Overview: The following code is generated for the non-const version of Gtk::Dialog::get_content_area(), i.e. this function calls itself: Box* Dialog::get_content_area() { return const_cast<Dialog*>(this)->get_content_area(); } The relevant part of dialog.hg is: _WRAP_METHOD(Box* get_vbox(), gtk_dialog_get_content_area, deprecated "Use get_content_area() instead.") _WRAP_METHOD(const Box* get_vbox() const, gtk_dialog_get_content_area, constversion, deprecated "Use get_content_area() instead.") _WRAP_METHOD(Box* get_content_area(), gtk_dialog_get_content_area) _WRAP_METHOD(const Box* get_content_area() const, gtk_dialog_get_content_area, constversion) gmmproc gets confused here because both get_vbox() and get_content_area() wrap gtk_dialog_get_content_area(). Steps to reproduce: Compile gtkmm-documentation/examples/book/scrolledwindow and run it under gdb. Abort the program (Ctrl-C) after a while. Actual results: The program is executing Gtk::Dialog::get_content_area(). Expected results: A window should be shown fairly quickly, before you abort the program. Build date and platform: Ubuntu 11.04, source code of gtkmm, gtk+, etc. built with jhbuild on 2011-08-30 Additional information: The reason for this behaviour of gmmproc can be found in glibmm/tools/pm/WrapParser.pm, function on_wrap_method(). $$objCfunc{rettype_needs_ref}, $$objCfunc{throw_any_errors}, and $$objCfunc{constversion} are set to 1 if refreturn, errthrow, and constversion, respectively, are specified in _WRAP_METHOD in the .hg file, but they are not set to 0, if these parameters are not specified. Therefore constversion in _WRAP_METHOD(const Box* get_vbox() const, gtk_dialog_get_content_area, constversion, deprecated "Use get_content_area() instead.") makes gmmproc behave as if _WRAP_METHOD(Box* get_content_area(), gtk_dialog_get_content_area) also contains constversion. $$objCfunc{deprecated} is cleared if deprecated is not specified in the .hg file, so gmmproc does not mark get_content_area() as deprecated. Of course this is an error in glibmm (gmmproc), but I've filed the bug on gtkmm, because I wonder what will happen if gmmproc is corrected now. Many modules use gmmproc. Is it possible that any module actually depends on this strange behaviour? Perhaps inadvertently? Do we dare to correct this bug in gmmproc except when glibmm's API/ABI can be broken? One way to avoid the problem in Gtk::Dialog is to remove 'constversion' in _WRAP_METHOD(const Box* get_vbox() const, gtk_dialog_get_content_area, constversion, deprecated "Use get_content_area() instead.") The generated code will be longer, but not much.
I can make a patch, but first I'd like to know which alternative to choose. 1. Change gmmproc to make _WRAP_METHOD behave reasonably, i.e. the parameters refreturn, errthrow, and constversion shall apply only to the instance of _WRAP_METHOD where they exist. Now those parameters apply also to all following instances wrapping the same C function. This is also true of parameter errthrow in _WRAP_METHOD_DOCS_ONLY. 2. Change gtkmm/gtk/src/dialog.hg as a workaround for the present behaviour of _WRAP_METHOD. I prefer alternative 1. But it's not backwards compatible, and it may affect any module that uses gmmproc.
(In reply to comment #0) > Of course this is an error in glibmm (gmmproc), but I've filed the bug on > gtkmm, because I wonder what will happen if gmmproc is corrected now. Many > modules use gmmproc. Is it possible that any module actually depends on this > strange behaviour? Perhaps inadvertently? Do we dare to correct this bug in > gmmproc except when glibmm's API/ABI can be broken? Yes, how could this wrong behavior ever be useful? > > One way to avoid the problem in Gtk::Dialog is to remove 'constversion' in > _WRAP_METHOD(const Box* get_vbox() const, gtk_dialog_get_content_area, > constversion, deprecated "Use get_content_area() instead.") > The generated code will be longer, but not much. Sounds fine for now, but please leave this open as a glibmm gmmproc bug.
Created attachment 195469 [details] [review] patch: Avoid infinite loop in Gtk::Dialog::get_content_area(). (gtkmm) This is a patch for alternative 2 in comment 1, i.e. 'constversion' is removed from from get_vbox() const in dialog.hg.
I have pushed the gtkmm patch in comment 3, and moved this bug from gtkmm to glibmm, and changed its title.
Created attachment 195509 [details] [review] patch: Correct handling of constversion etc. in _WRAP_METHOD. (glibmm, gmmproc) Here's a glibmm patch that fixes the bug in gmmproc. Can it be pushed soon, or does it have to wait until the ABI/API of glibmm can be broken? I've tested it on the following modules: glibmm, gtkmm, atkmm, pangomm, goocanvasmm If I remove the gtkmm patch in dialog.hg (comment 3) the generated code for get_vbox() and get_content_area() is correct, as expected. Apart from that the only case where the gmmproc patch makes a difference in the generated code is Gtk::PrintUnixDialog::get_selected_printer(). This is what printunixdialog.hg contains: _WRAP_METHOD(Glib::RefPtr<Printer> get_selected_printer(), gtk_print_unix_dialog_get_selected_printer, refreturn) _WRAP_METHOD(Glib::RefPtr<const Printer> get_selected_printer() const, gtk_print_unix_dialog_get_selected_printer, refreturn. constversion) Note the period instead of a comma after the second refreturn. gmmproc ignores 'refreturn. constversion' without even the slightest warning! With the present version of gmmproc, the second _WRAP_METHOD inherits refreturn from the first one, and the generated code is correct but not optimal. With the gmmproc patch applied, the code generated from the second _WRAP_METHOD is as if it had read _WRAP_METHOD(Glib::RefPtr<const Printer> get_selected_printer() const, gtk_print_unix_dialog_get_selected_printer) which is not correct.
Thanks. Please push. And please fix that . in get_selected_printer().
Pushed. And I have also fixed get_selected_printer().
Created attachment 199336 [details] [review] patch: Undo removal of 'constversion' in Gtk::Dialog::get_vbox(). (gtkmm) gtkmm in the master branch now requires giomm-2.4 >= 2.30.0 (and then also glibmm-2.4 >= 2.30.0). The bug in gmmproc that gave rise to the gtkmm patch in comment 3, is fixed in glibmm-2.4 >= 2.29.13. The gtkmm patch is therefore unnecessary and can be undone. That's what this new patch does. Isn't that a good idea?
I have pushed the patch in comment 8.