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 is due to the fact that type inlining currently is broken in some
corner cases involving recursive types.
The bugs are caused by the fact that TypeInlineHelper uses its own
custom graph instead of using the DependencyGraph used by ModelToHeader,
causing different decisions about the order of emission of types.
As a result, the generated C types are not valid C, and they fail to
compile because a field of a struct has a type that is defined later
than its use.
After refactoring TypeInlineHelper to use DependencyGraph like
ModelToHeader, this can be reverted.
Ivan Krysak