[typetraits] echo A[B] prints differently depending on unrelated code

[timotheecour]

import typetraits

type
  C[T] = object

type MyInt = int
type C2=C

when defined(case1):
  echo C2[int]   # C2[system.int]
  echo C2[MyInt] # C2[system.int]

when defined(case2):
  echo C2[MyInt]  # C2[t01_resolveTypeName2.MyInt]
  echo C2[int]    # C2[t01_resolveTypeName2.MyInt]

# EDIT: using `name` instead of `$` doesn't make a difference, unlike test case for related issue https://github.com/nim-lang/Nim/issues/7976#issuecomment-395246665
when defined(case3):
  echo C2[MyInt].name #C2[t01_resolveTypeName2.MyInt]
  echo C2[int].name #C2[t01_resolveTypeName2.MyInt]

when defined(case4):
  echo C2[int].name #C2[system.int]
  echo C2[MyInt].name #C2[system.int]

NOTE: related to, but probably not identical, to #8570, see note there

[andreaferretti]

(you don't have to prefix all issues with BUG, that's kind of the point of an issue tracker :-D)

[timotheecour]

Note: #7976 seems super related to this [EDIT] ; it's not an actual duplicate because:

• this issue is for generics, whereas other one for tuple
• in this issue, using name vs $ makes no difference, but for other one it makes the bug disappear

[jangko]

looks like both of this issue and #7976 have something in common:

• [typetraits] Tuple type name confusion #7976 happened because of generic proc instantiation cache mechanism.
• this bug occurs because of generic type instantiation cache mechanism.

and I think it might also plaguing macros.getTypeXXX family.

[Araq]

@jangko Well the compiler is allowed to cache generic instantiations ignoring type aliases. I don't think it's that bad, macro code that uses getType and friends needs to be written in a robust way.

[mratsim]

I find it quite hard to just write getType macro code, see https://github.com/nim-lang/Nim/issues/7719 / nim-lang/RFCs#44, making it robust is very hard, see for example this stress test: #8531 (comment).