Type inlining was a feature that allowed type definitions of
structs/unions/enums to be printed in C directly inside the definition
of another parent struct/union, if the inner type was only used once in
the parent type.
This kind of reasoning is inherently global: a type definition of the
subtype can be inlined in the parent type one only if *globally* the
subtype it isn't referred anywhere else.
This caused issues with type inlining inside definitions of stack types
in the body of functions. Indeed, for a given function, due to type
inlining, it was necessary to do global reasoning about what other types
could be inlined in the definition of the function's stack frame type.
This, in turn, had heavy consequences on invalidation, because any
change to any type (even if it wasn't referred in a given function's
body) was causing invalidation of all functions' bodies.
For this reason it was decided to drop the type inlining feature.
This data structure is used to bind together a pair of pointers to
TypeDependencyNode, one referring to a declaration of a type and the
other referring to a definition of the same type.
The definition can be null if the type referred to is a type without an
explicit definition (e.g. typedefs), while it's never null for types
for which have forward declaration that is separate from the definition
(e.g. structs and unions).
This commit bans from the model array types in as argument or return
types in CABIFunctionDefinition.
CABIFunctionDefinition implies we're decompiling towards C, and C does
not support array arguments (passed by copy) nor array return types.
Banning these from the model reduces the number of situations where we
have to emit artificial array wrappers (not present in the model) around
types when printing C code, simplifying the handling of such situations
when translating to clift and in general in the decompilation pipeline.
Before this, commenting is only possible on specific names, with this
the entire supported line is active (unless there are more grannular
comment contexts, for example, in the function prototype).
For example (commentable parts are marked with `^`):
```
// struct whatever {
// ...
// before this
const my_type_name *my_field_name[10];
// ^^^^^^^^^^^^^
// after this
const my_type_name *my_field_name[10];
//^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
// ...
// };
```
It's the same for all the others, like segments, arguments, and so on.
This reworks NameBuilder to ease the transition to the system where
the model will be guaranteed to never contain any name collisions, both
between user-specified names and the automatic ones.
Alessandro Di Federico