[typetraits] type names should resolve to name of resolved type; currently, not consistent

[timotheecour]

import typetraits
import timn/util

type
  A = object
  B = object
  C[T] = object

type MyInt = int
type C2=C

type A2=A
echo A2 # A; (case_A2)

type MyInt2 = int
echo MyInt2 # MyInt2 # case_MyInt2 BUG=> should be int (otherwise inconsistent with case_A2)

type MyInt3 = MyInt2
echo MyInt3 # MyInt2 ; mixing rules case_A2 and case_MyInt2...

type MyInt_distinct = distinct int
echo MyInt_distinct # MyInt_distinct: ok, it's a distinct type

echo C2 # C2 BUG=> should be C (otherwise inconsistent with case_A2)
echo C2[MyInt] # C2[t01_resolveTypeName.MyInt]

NOTE: related but not identical to #8569 ; although if this bug gets fixed by resolving type names to name of resolved type, then #8569 would automatically get fixed

proposal:

• use something a bit similar to [superseded] new macro for generic reflection: extractGeneric(Foo2[float, string], 0) is float #8554 to have a proc that resolves a type to a concrete type => typeResolved
  C2[MyInt] | C2[float] => C[int] | C[float]
• introduce a new typedesc.nameResolved that use that typeResolved
• not sure what should be the behavior of typedesc.name ; it may be useful to keep aliased name around (eg BiggestInt, UnsignedInteger etc) as they may carry semantic info in their name, but some adjustments are needed as current behavior is definitely buggy (eg [typetraits] echo A[B] prints differently depending on unrelated code #8569 + some inconsistencies above)
• then, in error messages, show type T.name aka T.nameResolved (as done in clang)

[kaushalmodi]

Is this the same bug: #7976?

[timotheecour]

actually no, but definitely #7976 is instead very related to #8569 (continuing #7976 related discussion there)

[ghost]

I think it's the same or at least related to #8083