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.
Previously introduced node comparison `==` was working somehow wrong on nodes
returned from getType(a), comparing just ids of the symbols.
Recently introduced `==` change 47dce26886
started comparing symbol nodes pointer-wise, thus strictly. Since getType(a)
always creates new symbol pointing to the type, comparing two such nodes using
`==` always returns false, even they point to the same type.
That is why we need a new sameType macro to be able to tell if these nodes
point to the same type.
