Document resolve_dynamic_type oddity
authorTom Tromey <tromey@adacore.com>
Tue, 19 Oct 2021 20:42:04 +0000 (14:42 -0600)
committerTom Tromey <tromey@adacore.com>
Fri, 29 Oct 2021 13:33:13 +0000 (07:33 -0600)
commit52429bbd71af5f14f8f3f5a962a2457a93c6d171
tree54e0b8221ba779cef213accb1b3cd5d2d9cb71e4
parent9e6978753df24726a73667b293ac7f0cc94a2fcb
Document resolve_dynamic_type oddity

Today I re-learned that resolve_dynamic_type can return a type for
which is_dynamic_type returns true.  This can happen for an array
whose elements have dynamic type -- the array is reported as dynamic,
but resolving the elements would be incorrect, because each element
might have a different type after resolution.

You can see the special case in resolve_dynamic_array_or_string:

  if (ary_dim != NULL && ary_dim->code () == TYPE_CODE_ARRAY)
...
  else
...

I looked into having the TYPE_CODE_ARRAY case in
is_dynamic_type_internal follow this same logic, but that breaks down
on the gdb.fortran/dynamic-ptype-whatis.exp test case.  In particular
this code in fortran_undetermined::evaluate:

  value *callee = std::get<0> (m_storage)->evaluate (nullptr, exp, noside);
  if (noside == EVAL_AVOID_SIDE_EFFECTS
      && is_dynamic_type (value_type (callee)))
    callee = std::get<0> (m_storage)->evaluate (nullptr, exp, EVAL_NORMAL);

... relies on is_dynamic_type returning true for such an array.

I wasn't really sure of the best way to fix this, so in the meantime I
wrote this patch, which documents the oddity so that I might have a
chance of remembering this in the future.
gdb/gdbtypes.h