typeToString can now show (recursively) resolved type aliases; fixes #8569 #8083 #8570

[timotheecour]

• fix [typetraits] echo A[B] prints differently depending on unrelated code #8569
• fix typetraits.name behaves unexpected #8083
• fix [typetraits] type names should resolve to name of resolved type; currently, not consistent #8570
• fixed typename case: fixed CString => cstring and Char=>char, openarray=>openArray (more consistent with all other types, see typeToStr)
  (also related to [typetraits] Tuple type name confusion #7976)

details

typeToString gets 2 new options (and typeToString gets exposed as a magic), which in future PRs could replace all existing TPreferedDesc options:

• preferResolved to show (recursively) resolved type aliases (tuple[a: MyInt] shows as tuple[a: int]) (note that preferDesc doesn't do that reliably)
• preferMixed to show (recursively) resolved type aliases + their aliases when they differ (at the place where they differ): (tuple[a: MyInt] shows as tuple[a: MyInt{int}])
  this fixes above mentioned bugs and also makes it clear to user what a type resolves to, while also showing original type if using preferMixed (eg cint), in a way more compact than current (unreliable) way of showing both preferName+preferDesc; it helps notably in type mismatch/sigmatch errors.

See unittest in tests/metatype/ttypetraits2.nim for detailed behavior; here's a snippet:

 template name3(T): string = typeToString(T, "preferMixed")
  doAssert name3(tuple[a: MyInt, b: float]) == "tuple[a: MyInt{int}, b: float]"
  doAssert name3(tuple[a: C2b[MyInt, C4[cstring]], b: cint, c: float]) ==
    "tuple[a: C2b{C}[MyInt{int}, C4[cstring]], b: cint{int32}, c: float]"

Existing code is unaffected except for the fixed typename case (such as CString => cstring)

in future PR we can use the preferMixed (eg to replace preferDesc and expose it in typetraits.typeToString)

I kept proc typeToString*(t: typedesc, prefer = "preferTypeName"): string {.magic: "TypeTrait".} out of typetraits.nim for now until we're sure of API; as for the public name for the new proc, using typeToString as I did instead of overloading name seems like a good choice (named just like the proc in compiler/types.nim), because name is such a common word it keeps causing issues (as noted by @kaushalmodi here #7975 (comment))

• could be adapted to also fix [TODO] type outType = type(10) prints as int literal(10) instead of int #8704 by printing int literal(10) instead of int with the option preferResolved
• could be used for sigmatch errors, to avoid confusing error messages where signatures don't match, leaving the user clueless as to why they don't
• should probably replace the existing preferDesc (in which case i can just remove the newly added preferResolved and make preferDesc use its implementation); but I'd rather do this in a separate PR

implementation notes

maybe easier to view the diff in a terminal with git diff -w to view the diff without getting confused by re-indentation; the 1st commit doesn't change semantics but just re-indents typeToString (hence seemingly large diff), adding a nested typeToString(typ: PType) inside top-level proc typeToString(typ: PType, prefer: TPreferedDesc = preferName): string ; this makes implementation much easier.

the remaining commits do the actual semantic changes

note:

CI failure seems unrelated (caused by #11708)

[narimiran]

@timotheecour marked this pull request as ready for review on Jul 11

Can you fix the remaining failing tests on Travis?

[timotheecour]

@narimiran done

[Araq]

Thank you!