diff options
author | Tom Tromey <tom@tromey.com> | 2023-11-19 21:09:57 -0700 |
---|---|---|
committer | Tom Tromey <tom@tromey.com> | 2024-01-28 10:58:16 -0700 |
commit | 790948cb0933c835e76ada717ab857852813e04f (patch) | |
tree | 6df7ccac367e4ccd6988082c07ae33233196e214 /gdb/f-lang.c | |
parent | 13eade6a108d3c07aec165d867099a0d9d4325fe (diff) | |
download | binutils-790948cb0933c835e76ada717ab857852813e04f.zip binutils-790948cb0933c835e76ada717ab857852813e04f.tar.gz binutils-790948cb0933c835e76ada717ab857852813e04f.tar.bz2 |
Give names to unspecified types
A patch later in this series will change check_typedef to also look in
the type domain. This change by itself caused a regression, but one
that revealed some peculiar behavior.
The regression is in nullptr_t.exp, where examining a std::nullptr_t
will change from the correct:
typedef decltype(nullptr) std::nullptr_t;
to
typedef void std::nullptr_t;
Right now, the DWARF reader marks all unspecified types as stub types.
However, this interacts weirdly with check_typedef, which currently
does not try to resolve types -- only struct-domain objects.
My first attempt here was to fix this by changing void types not to be
stub types, as I didn't see what value that provided. However, this
caused another regression, because call_function_by_hand_dummy checks
for stub-ness:
if (values_type == NULL || values_type->is_stub ())
values_type = default_return_type;
I'm not really sure why it does this rather than check for
TYPE_CODE_VOID.
While looking into this, I found another oddity: the DWARF reader
correctly creates a type named 'decltype(nullptr)' when it seems a
DW_TAG_unspecified_type -- but it creates a symbol named "void"
instead.
This patch changes the DWARF reader to give the symbol the correct
name. This avoids the regression.
Diffstat (limited to 'gdb/f-lang.c')
0 files changed, 0 insertions, 0 deletions