aboutsummaryrefslogtreecommitdiff
path: root/gdb/cli
diff options
context:
space:
mode:
authorTom Tromey <tromey@adacore.com>2024-08-26 12:54:17 -0600
committerTom Tromey <tromey@adacore.com>2025-03-06 14:17:17 -0700
commit7eccd2e407890a554ffc64d015ba82b7fdf941c4 (patch)
tree6fd7a2114b8e65a0e5fa229143a89c922516b9f0 /gdb/cli
parenta8551849716c2b29e59547212e3aa69b8f4e2ad8 (diff)
downloadbinutils-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