During the implementation of modules I added myself a note to
implement nested_udt handling. It wasn't obvious to me what they were
for and nothing seemed to be broken in ignoring them. I figured
something would eventually pop up and I'd add support. Nothing popped up.
Investigating on trunk discovered 3 places where we look at the
nested-udts. I couldn't figure how the one in lookup_field_r was
needed -- surely the regular lookup would find the type. It turned
out that code was unreachable. So we can delete it.
Next in do_type_instantiation, we walk the nested-utd table
instantiating types. But those types are also on the TYPE_FIELDS
list, which we've just iterated over. So I can move the handling into
that loop.
The final use is in handling structs that have a typedef name for
linkage purposes. Again, we can just iterate over TYPE_FIELDS. (As
commented, we probably don't need to do even that, as a DR, whose
number I forget, requires such structs to only have C-like things in
them. But I didn't go that far.
Having removed all the uses of nested-udts, I can remove their
creation from name-lookup, and as the only instance of a binding_table
object, we can remove all that code too.