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