diff options
author | Tom Tromey <tromey@adacore.com> | 2024-08-26 12:54:17 -0600 |
---|---|---|
committer | Tom Tromey <tromey@adacore.com> | 2025-03-06 14:17:17 -0700 |
commit | 7eccd2e407890a554ffc64d015ba82b7fdf941c4 (patch) | |
tree | 6fd7a2114b8e65a0e5fa229143a89c922516b9f0 /gdb/cli | |
parent | a8551849716c2b29e59547212e3aa69b8f4e2ad8 (diff) | |
download | binutils-7eccd2e407890a554ffc64d015ba82b7fdf941c4.zip binutils-7eccd2e407890a554ffc64d015ba82b7fdf941c4.tar.gz binutils-7eccd2e407890a554ffc64d015ba82b7fdf941c4.tar.bz2 |
Compare unqualified names in ada_identical_enum_types_p
With the coming changes to GNAT, gdb must compare the unqualified
names of two enum types.
Currently, GNAT will fully-qualify enumeration constant names, so for
instance one might see "enum_with_gap__lit4" as the name.
GNAT also may emit a copy of an enumeration type when a newtype is
involved. E.g., in the arr_acc_idx_w_gap.exp test case, this can
occur for the base type of this subtype:
type Enum_Subrange is new Enum_With_Gaps range Lit1 .. Lit3;
(Note that the base type of this subrange is anonymous.)
With some forthcoming changes to GNAT, these names will no longer be
qualified -- and because the newtype is anonymous, they can't be
identically qualified. But, in gdb we still want "lit4" to resolve
without ambiguity in this scenario.
The fix is to change ada_identical_enum_types_p to compare unqualified
enum names. This will work correctly with both variants of the
compiler, and with -fgnat-encodings=all as well.
Diffstat (limited to 'gdb/cli')
0 files changed, 0 insertions, 0 deletions