[Bug default/25998] New: Support incomplete enum types

["gprocida+abigail at google dot com" <sourceware-bugzilla@sourceware.org>]

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

            Bug ID: 25998
           Summary: Support incomplete enum types
           Product: libabigail
           Version: unspecified
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: gprocida+abigail at google dot com
                CC: libabigail at sourceware dot org
  Target Milestone: ---

Incomplete enum types are a GCC and Clang extension for C and are widely used
in the (AOSP at least) Linux kernel code.

C++ now supports "opaque" enums which are essentially forward-declared types
*of known size*.

If would good to have support in libabigail for the C case as this lack is
affecting AOSP kernel ABI monitoring.

I posted an RFC patch series demonstrating feasibility as:

https://sourceware.org/pipermail/libabigail/2020q2/001994.html

I followed up with a simplification of WIP types in the DWARF reader to reduce
some of the code duplication in the initial series:

https://sourceware.org/pipermail/libabigail/2020q2/002262.html

However, this only tackles a fraction of the duplication. There are two
possible approaches in general: templating over the relevant types or factoring
the common features into or otherwise using a type hierarchy.

libabigail already has a type hierarchy. There are at least two issues:

* the functionality for dealing with incomplete types exists at the
class_or_union level which is quite far down the hierarchy
* the common ancestors (plural, multiple inheritance) of class_or_union and
enum_decl_type are quite high up in hierarchy

Essentially, if we're going to try inheritance to avoid duplication, the
hierarchy will have to change.

Inheritance may not be a perfect fit, for example, there are separate
hierarchies of type types and diff types (and the diff types have to have
specialised methods like first_num) and things like
get_definition_of_declaration whose return value will need to be downcast if
it's made a base class method.

Templating comes with its own concerns. The main reason not to use it here is
that the combination of both inheritance and templating may impose a high
cognitive load on the poor developers.

Any detailed proposal should include full support for the newer C++ enum types
(scoped and opaque) and the should cover DWARF reader TODOs about supporting
incomplete union types.

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