This is an alternative attempt to fix issue #2841 in a way that does not
rely on non-standard C compiler behavior.
The underlying problem is that the typeinfo module includes
system/hti.nim, but system/hti.nim is also included by system.nim. The
result is that the compiler at any given point has two instances of
TNimType with the same external name and will generate code either for
one or both of them. Code generation for the second version is normally
suppressed by using {.importc.}, but that results in a missing type
declaration for modules that only use the second version. This happens
for modules that import typeinfo, because the the second component of
typeinfo.Any has type PNimType = ptr TNimType, which generates a
"TNimType *" struct member.
The previous solution was to have a typedef for TNimType in nimbase.h;
however, this results in duplicate typedefs (specifically, but not only
for the code generated for typeinfo.nim). Duplicate typedefs with the
same type name are allowed in C++ and C11, but are explicitly forbidden
in C89 and C99. Modern versions of gcc and clang accept them anyway, but
this is not standard-compliant and may break for other C compilers or
older versions of gcc and clang.
This patch attempts to fix the issue by making the second component of
typeinfo.Nim a pointer instead of a PNimType and casting back and forth
as needed. Thus, the second version of TNimType occurs only within the
code for typeinfo.nim, where it can be safely omitted.
The struct NimException still referred to the old exception type
E_Base, which has since been renamed to Exception. This made the
C++ backend fail on any code that used exceptions.
Lines from the original source are outputted as comments next to line directives.
Hopefully, this will make debugging codegen problems easier.
Other changes:
The frame setup code now uses a single-line C macro. My motivation was to reduce
the noise in the generated output and make it easier to step over the boiler-plate
code, but counter-intuitively this also improved the overall compilation speed a
little bit so I applied the same treatment to line tracking too (this reduces the size of
the generated files and the explanation is that probably the I/O overhead dominates
the macro expansion costs).
