From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129585 invoked by alias); 1 Oct 2018 14:09:31 -0000 Mailing-List: contact libabigail-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Id: List-Subscribe: Sender: libabigail-owner@sourceware.org Received: (qmail 129530 invoked by uid 48); 1 Oct 2018 14:09:26 -0000 From: "dodji at redhat dot com" To: libabigail@sourceware.org Subject: [Bug default/23700] Wrong propagation of private type suppression category Date: Mon, 01 Jan 2018 00:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dodji at redhat dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: dodji at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on short_desc everconfirmed Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2018-q4/txt/msg00000.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23700 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 suppr= ess 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 t= ype is suppressed, a (changed) typedef to that class is considered to be suppre= ssed too. But then that is not true if the class type was changed because it's privat= e.=20 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/. --=20 You are receiving this mail because: You are on the CC list for the bug.