aboutsummaryrefslogtreecommitdiff
path: root/gdb/ada-lang.c
diff options
context:
space:
mode:
authorTom Tromey <tromey@adacore.com>2023-08-15 11:04:17 -0600
committerTom Tromey <tromey@adacore.com>2023-08-16 11:43:40 -0600
commit94c5098e4d9d5b58a6db31064398fb4941ab5efb (patch)
treeacc0e32f8c4b0e2cca1e586a75b050d09f85c2ab /gdb/ada-lang.c
parent100dbc6de52e6d4bfaf4b330ee923267e56e936c (diff)
downloadbinutils-94c5098e4d9d5b58a6db31064398fb4941ab5efb.zip
binutils-94c5098e4d9d5b58a6db31064398fb4941ab5efb.tar.gz
binutils-94c5098e4d9d5b58a6db31064398fb4941ab5efb.tar.bz2
Fix obvious bug in aggregate expression
I found an obvious bug in Ada aggregate expression handling: if (vvo != nullptr) error (_("Invalid record component association.")); name = vvo->get_symbol ()->natural_name (); Here the code errors when vvo is not null -- and then proceeds to use vvo. This hasn't caused a crash because, I believe, there's currently no way to reach this code in the null case. However, I'm not really willing to assert this... Fixing this shows another bug, which is that due to the way the parser works, a field name in an aggregate expression might erroneously be fully qualified if some global variable with the same base name exists. The included test case triggers both bugs. Note that the test includes a confounding case for array aggregates as well, but as these are harder to fix, I've left it as kfail. As this is Ada-specific, and has already been tested internally at AdaCore, I am checking it in.
Diffstat (limited to 'gdb/ada-lang.c')
-rw-r--r--gdb/ada-lang.c9
1 files changed, 8 insertions, 1 deletions
diff --git a/gdb/ada-lang.c b/gdb/ada-lang.c
index 1261ee8..4a9a6e0 100644
--- a/gdb/ada-lang.c
+++ b/gdb/ada-lang.c
@@ -9575,9 +9575,16 @@ ada_name_association::assign (struct value *container,
{
ada_var_value_operation *vvo
= dynamic_cast<ada_var_value_operation *> (m_val.get ());
- if (vvo != nullptr)
+ if (vvo == nullptr)
error (_("Invalid record component association."));
name = vvo->get_symbol ()->natural_name ();
+ /* In this scenario, the user wrote (name => expr), but
+ write_name_assoc found some fully-qualified name and
+ substituted it. This happens because, at parse time, the
+ meaning of the expression isn't known; but here we know
+ that just the base name was supplied and it refers to the
+ name of a field. */
+ name = ada_unqualified_name (name);
}
index = 0;