Add new variant part code

This patch adds the infrastructure for the new variant part code.  At
this point, nothing uses this code.  This is done in a separate patch
to make it simpler to review.

I examined a few possible approaches to handling variant parts.  In
particular, I considered having a DWARF variant part be a union
(similar to how the Rust code works now); and I considered having type
fields have a flag indicating that they are variants.

Having separate types seemed bad conceptually, because these variants
aren't truly separate -- they rely on the "parent" type.  And,
changing how fields worked seemed excessively invasive.

So, in the end I thought the approach taken in this patch was both
simple to implement and understand, without losing generality.  The
idea in this patch is that all the fields of a type with variant parts
will be stored in a single field array, just as if they'd all been
listed directly.  Then, the variants are attached as a dynamic
property.  These control which fields end up in the type that's
constructed during dynamic type resolution.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tromey@adacore.com>

	* gdbtypes.c (is_dynamic_type_internal): Check for variant parts.
	(variant::matches, compute_variant_fields_recurse)
	(compute_variant_fields_inner, compute_variant_fields): New
	functions.
	(resolve_dynamic_struct): Check for DYN_PROP_VARIANT_PARTS.
	Use resolved_type after type is made.
	(operator==): Add new cases.
	* gdbtypes.h (TYPE_HAS_VARIANT_PARTS): New macro.
	(struct discriminant_range, struct variant, struct variant_part):
	New.
	(union dynamic_prop_data) <variant_parts, original_type>: New
	members.
	(enum dynamic_prop_node_kind) <DYN_PROP_VARIANT_PARTS>: New constant.
	(enum dynamic_prop_kind) <PROP_TYPE, PROP_VARIANT_PARTS>: New
	constants.
	* value.c (unpack_bits_as_long): Now public.
	* value.h (unpack_bits_as_long): Declare.

0 files changed, 0 insertions, 0 deletions