typRel and sumGeneric adjustments

[Graveflo]

Filling in some more logic in typeRel that I came across when poking the compiler in another PR. Some of the cases where typeRel returns an "incorrect" result are actually common, but sumGeneric ends up breaking the tie correctly. There isn't anything wrong with that necessarily, but I assume that it's preferred these functions behave just as well in isolation as they do when integrated.

I will be following up this description with specific examples.

[Graveflo]

These examples do not actually translate to bugs in the current version of the compiler! This is just to demonstrate the output of the relevant functions.

Ptr and Ref

type A[T] = ref object
proc p(M: ref object): bool = false
proc p(M: A): bool = true
var s = new(A[int])
discard p(s)

OK:

f	a	output
tyCompositeTypeClass(A)	tyRef(ref object)	isNone
tyRef(A)	tyRef(ref object)	isNone
tyObject(A:ObjectType)	tyBuiltInTypeClass(object)	isNone

not OK:

f	a	output
tyRef(ref object)	tyCompositeTypeClass(A)	isNone

ref object should have a generic relationship with A. Adjustment in getObjectType and in the tyPtr, tyRef branch of typeRel

Array

type IntArray[N: static[int]] = array[N, int]
proc p(a: IntArray): bool= true
proc p[T;N](a: array[N,T]): bool= false

var s: IntArray[5]
discard s.p()

not OK:

f	a	output
tyArray(array[N, T])	tyCompositeTypeClass(IntArray)	isNone

OK:

f	a	output
tyCompositeTypeClass(IntArray)	tyArray(array[N, T])	isNone
tyArray(IntArray)	tyArray(array[N, T])	isNone
tyInt(int)	tyGenericParam(T)	isNone

Same idea as above

Need to devalue isInferred

proc foo[T](x: proc(): T): bool = return true
proc foo(x: proc(): int): bool = return false
discard foo(proc (): auto {.nimcall.} = 88)

f	a	output
tyProc(proc (): int{.closure.})	tyProc(proc (): T{.closure.})	isInferred
tyGenericParam(T)	tyInt(int)	isGeneric

f	a	output
tyProc(proc (): T{.closure.})	tyProc(proc (): int{.closure.})	isGeneric
tyGenericParam(T)	tyInt(int)	isGeneric

Both of these are okay, but one of them ultimately returns isInferred and the other isGeneric. In this situation the generic match should be preferred to the inferred one. Adjustment in checkGeneric

Obscured base class

type
X = ref object
Z[T] = X

proc p[H](x:Z[H]):bool = false
proc p(x: ref object): bool = true
echo p(new(Z[int]))

not OK:

f	a	output
tyRef(ref object)	tyGenericInvocation(Z[p.H])	isNone

OK:

f	a	output
tyGenericInvocation(Z[p.H])	tyRef(ref object)	isNone
tyGenericBody(Z)	tyRef(ref object)	isNone
tyRef(Z)	tyRef(ref object)	isNone
tyObject(X:ObjectType)	tyBuiltInTypeClass(object)	isNone

Changing in getObjectType:

of tyGenericInvocation:
  result = getObjectType(f.baseClass)

Edit: I should also mention #22143 for organizational purposes, since that is the PR that lead to finding these

[github-actions]

Thanks for your hard work on this PR!
The lines below are statistics of the Nim compiler built from ccc7c45

Hint: mm: orc; opt: speed; options: -d:release
177580 lines; 7.500s; 767.785MiB peakmem