[Bug default/23700] New: Surprising abidiff report on IBus

[Bug default/23700] New: Surprising abidiff report on IBus

[bochecha at daitauha dot fr]

https://sourceware.org/bugzilla/show_bug.cgi?id=23700

            Bug ID: 23700
           Summary: Surprising abidiff report on IBus
           Product: libabigail
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: bochecha at daitauha dot fr
                CC: libabigail at sourceware dot org
  Target Milestone: ---

Created attachment 11270
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11270&action=edit
Trees containing built/installed ibus 1.5.18and ibus 1.5.19

Running abidiff on the latest IBus release gives a surprising report:

Functions changes summary: 0 Removed, 2 Changed, 0 Added (11 filtered out)
functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

2 functions with some indirect sub-type change:

  [C]'function const gchar* ibus_key_event_to_string(guint, guint)' at
ibuskeynames.c:128:1 has some indirect sub-type changes:
    return type changed:
      in pointed to type 'const gchar' at gtypes.h:46:1:
        entity changed from 'const gchar' to 'typedef gchar' at gtypes.h:46:1
        type size hasn't changed

  [C]'function void ibus_panel_service_panel_extension(IBusPanelService*,
GVariant*)' at ibuspanelservice.c:1578:1 has some indirect sub-type changes:
    parameter 2 of type 'GVariant*' changed:

It is really cut there. That second change is surprising because it tells me
"it changed", but then doesn't say what changed at all.

As for the first one, that doesn't seem like an actual ABI break?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/23700] Surprising abidiff report on IBus

[bochecha at daitauha dot fr]

https://sourceware.org/bugzilla/show_bug.cgi?id=23700

--- Comment #2 from Mathieu Bridon <bochecha at daitauha dot fr> ---
Here's a tarball containing the two stripped libraries, debuginfos and headers:
https://www.daitauha.fr/static/abigail/gtk3-reproducer.tar.xz

It's too big to be added to Bugzilla unfortunately.

In a libabigail clone, where I just built:

$ tar xf gtk3-reproducer.tar.xz 
$ ./tools/abidiff --no-added-syms --drop-private-types --headers-dir1
1/usr/include --headers-dir2 2/usr/include --debug-info-dir1 1/usr/lib/debug
--debug-info-dir2 2/usr/lib/debug
1/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30
2/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2400.0
Functions changes summary: 0 Removed, 1 Changed (37 filtered out), 0 Added (31
filtered out) functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

1 function with some indirect sub-type change:

  [C]'function void gtk_enumerate_printers(GtkPrinterFunc, gpointer,
GDestroyNotify, gboolean)' at gtkprinter.c:1248:1 has some indirect sub-type
changes:
    parameter 1 of type 'typedef GtkPrinterFunc' has sub-type changes:
      underlying type 'typedef gboolean (GtkPrinter*, typedef gpointer)*'
changed:
        in pointed to type 'function type typedef gboolean (GtkPrinter*,
typedef gpointer)':
          parameter 1 of type 'GtkPrinter*' has sub-type changes:
            in pointed to type 'typedef GtkPrinter' at gtkprinter.h:81:1:
              underlying type 'struct _GtkPrinter' at gtkprinter.h:88:1
changed:
                type size hasn't changed
                1 data member insertion:
                  'GtkPrinterPrivate* _GtkPrinter::priv', at offset 192 (in
bits) at gtkprinter.h:93:1

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/23700] Wrong propagation of private type suppression category

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23700

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from dodji at redhat dot com ---
The categorizing issue should now be fixed by commit
https://sourceware.org/git/gitweb.cgi?p=libabigail.git;a=commit;h=a16e97596b2c1395b5cac2f8c98e243c6e4eebcd
in the master git branch.

The private type change category propagation rule issue should now be fixed by
commit
https://sourceware.org/git/gitweb.cgi?p=libabigail.git;a=commit;h=60daf958ae092c1bb00f6bc8eeab00b2b29ec1be
in the master git branch.

Together, these two commits should allow us to close this bug.

Thank you for taking time to report this issue!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/23700] Surprising abidiff report on IBus

[bochecha at daitauha dot fr]

https://sourceware.org/bugzilla/show_bug.cgi?id=23700

--- Comment #1 from Mathieu Bridon <bochecha at daitauha dot fr> ---
To reproduce the problem:

$ tar xf ibus-reproducer.tar.xz
$ abidiff --no-added-syms --drop-private-types --headers-dir1
ibus-1.5.18/usr/include/ --headers-dir2 ibus-1.5.19/usr/include/
ibus-1.5.18/usr/lib64/libibus-1.0.so.5.0.518
ibus-1.5.19/usr/lib64/libibus-1.0.so.5.0.519 

Both libabigail 1.4 and master lead to the same result.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/23700] Surprising abidiff report on IBus

[bochecha at daitauha dot fr]

https://sourceware.org/bugzilla/show_bug.cgi?id=23700

--- Comment #3 from Mathieu Bridon <bochecha at daitauha dot fr> ---
Oops, comment 2 was for bug 23641. Too many tabs open… >_<

Please ignore comments 2 and 3.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/23700] Wrong propagation of private type suppression category

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23700

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2018-10-01
            Summary|Surprising abidiff report   |Wrong propagation of
                   |on IBus                     |private type suppression
                   |                            |category
     Ever confirmed|0                           |1

--- Comment #4 from dodji at redhat dot com ---
Here is my analysis of the second part of the issue reported here.

Conceptually, there are two kinds of type suppression specifications:

1/ a generic user-provided suppression specification that is meant to suppress
changes on types specified by the user

2/ a private type suppression specification that is automatically generated
from the path to public header files provided by the user.

Technically, one difference between 1 and 2 lays in the way we propagate
categories of changes matched by those suppression specifications.

If a class type change of category SUPPRESSED_CATEGORY is referenced in a
typedef change, then the typedef change is also considered to be of category
SUPPRESSED_CATEGORY.  In other words, the SUPPRESSED_CATEGORY category is
propagated to the typedef change.  That means that if a change to a class type
is suppressed, a (changed) typedef to that class is considered to be suppressed
too.

But then that is not true if the class type was changed because it's private. 
In that, a typedef to that class can be *public*, because the said typedef is
defined in a public header.  In that case the typedef change should *NOT* be
considered suppressed just because the class type change was suppressed.

The problem we have here is that we don't make any difference between 1/ and
2/.  So we need to introduce different propagation rules for 1/ and 2/.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/23700] Wrong propagation of private type suppression category

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23700

--- Comment #5 from dodji at redhat dot com ---
(In reply to Mathieu Bridon from comment #0)
> Created attachment 11270 [details]
> 2 functions with some indirect sub-type change:
> 
>   [C]'function const gchar* ibus_key_event_to_string(guint, guint)' at
> ibuskeynames.c:128:1 has some indirect sub-type changes:
>     return type changed:
>       in pointed to type 'const gchar' at gtypes.h:46:1:
>         entity changed from 'const gchar' to 'typedef gchar' at gtypes.h:46:1
>         type size hasn't changed

[...]

> As for the first one, that doesn't seem like an actual ABI break?

Yes, it's true that change is an actual change, but not an incompatible one. 
So we ought to classify it as harmless change.

-- 
You are receiving this mail because:
You are on the CC list for the bug.