1e01aa904Sopenharmony_ci2.1 version
2e01aa904Sopenharmony_ci===========
3e01aa904Sopenharmony_ci
4e01aa904Sopenharmony_ciThis occurred in libabigail 2.1.  The IR doesn't contain no-op
5e01aa904Sopenharmony_ciqualified types anymore.  These were the ancient way to represent
6e01aa904Sopenharmony_ciqualified type that were edited by libabigail to avoid spurious
7e01aa904Sopenharmony_cidiagnostics. E.g, const references or const void type.  In those
8e01aa904Sopenharmony_cicases, we were replacing these by qualified types that were no-ops.
9e01aa904Sopenharmony_ciThose no-ops qualified types further needed to be stripped off in the
10e01aa904Sopenharmony_cidiff IR to avoid emitting spurious changes.  It turned out stripping
11e01aa904Sopenharmony_ciout those no-op qualified types was causing some difficulties in the
12e01aa904Sopenharmony_cialgorithms that propagate type diff node categorization.
13e01aa904Sopenharmony_ci
14e01aa904Sopenharmony_ciFor instance, variable diff type node would have the categorization of
15e01aa904Sopenharmony_ciits diff->type_diff() be different from what we could see from the
16e01aa904Sopenharmony_cichange observed between its diff->first_subject()->get_type() and
17e01aa904Sopenharmony_cidiff->second_subject()->get_type().  This is because diff->type_diff()
18e01aa904Sopenharmony_cistrips the no-op qualified types to create a new diff IR node, whereas
19e01aa904Sopenharmony_cilooking at the difference between diff->first_subject->get_type() and
20e01aa904Sopenharmony_cidiff->second_subject()->get_type() gives a different perspective.
21e01aa904Sopenharmony_ci
22e01aa904Sopenharmony_ciSo looking at the "changes" carried by 'diff' could yield a result
23e01aa904Sopenharmony_cisuggesting that there was a change to be diagnosed, carried by the
24e01aa904Sopenharmony_cidifference between diff->first_subject()->get_type() and
25e01aa904Sopenharmony_cidiff->second_subject()->get_type() -- a difference between two no-ops
26e01aa904Sopenharmony_ciqualified types -- whereas actually looking at diff->type_diff() (that
27e01aa904Sopenharmony_cishould be equivalent) yields a different information because it's
28e01aa904Sopenharmony_cistripped off of the no-op qualified type.
29e01aa904Sopenharmony_ci
30e01aa904Sopenharmony_ciJust removing the no-op qualified types removed all those issues
31e01aa904Sopenharmony_cialtogether.  So in concrete terms, when we see a const reference, it's
32e01aa904Sopenharmony_cireplaced by a reference (because a reference is always const) and
33e01aa904Sopenharmony_ciwhen we see a const void, it's replaced by void.  As simple as that.
34e01aa904Sopenharmony_ci
35e01aa904Sopenharmony_ciBut then the emitted ABIXML won't carry any no-op qualified type
36e01aa904Sopenharmony_cianymore. Older versions of ABIXML might still carry those, and so
37e01aa904Sopenharmony_ciabidiff-ing those against their original binary might yield some
38e01aa904Sopenharmony_cispurious diagnostics.  Hence the minor version bump.
39e01aa904Sopenharmony_ci
40e01aa904Sopenharmony_cirelevant commit:
41e01aa904Sopenharmony_ci----------------
42e01aa904Sopenharmony_cicommit 8a4f72005bc96fecf63414784cf94857eddbd124
43e01aa904Sopenharmony_ciAuthor: Dodji Seketeli <dodji@redhat.com>
44e01aa904Sopenharmony_ciDate:   Thu Nov 4 10:59:32 2021 +0100
45e01aa904Sopenharmony_ci
46e01aa904Sopenharmony_ci    Bug 28450 - Fix cloned member function handling in DWARF
47e01aa904Sopenharmony_ci2.0 version
48e01aa904Sopenharmony_ci===========
49e01aa904Sopenharmony_ci
50e01aa904Sopenharmony_ciThis occured in libabigail 2.0.  The interpretation of
51e01aa904Sopenharmony_ciDW_AT_bit_offset (DWARF 5) changed so the value of the
52e01aa904Sopenharmony_ci'layout-offset-in-bits' property of the 'data-member' element might
53e01aa904Sopenharmony_cinow have changed in an incompatible way.
54e01aa904Sopenharmony_ci
55e01aa904Sopenharmony_cirelevant commit:
56e01aa904Sopenharmony_ci----------------
57e01aa904Sopenharmony_cicommit 23046152e0843bc2f141e37dcce047305c3f4379
58e01aa904Sopenharmony_ciAuthor: Dodji Seketeli <dodji@redhat.com>
59e01aa904Sopenharmony_ciDate:   Thu Oct 22 16:04:08 2020 +0200
60e01aa904Sopenharmony_ci
61e01aa904Sopenharmony_ci    Bump ABIXML format version to 2.0
62e01aa904Sopenharmony_ci
63e01aa904Sopenharmony_ci
64e01aa904Sopenharmony_ci1.0 version
65e01aa904Sopenharmony_ci===========
66e01aa904Sopenharmony_ci
67e01aa904Sopenharmony_ciThis was the initial version of abixml.
68