typerel: rework tyGenericInvocation handling

[zerbina]

Summary

Make the type relationship computation (typeRel) for instantiated
generic types (tyGenericInst) and unresolved type applications
(tyGenericInvocation) more consistent with each other, which, apart
from removing another dependency on semtypinst's "meta-types allowed"
mode, is also a preparation for fixing the handling of phantom types.

Fixes:

• invocations of types like Body[T] = T.param and
  Body[N] = range[0..(N+1)] with generic parameters in routine
  signatures now work properly during parameter matching
• for the procedure with the signature proc f[T](x: Type[Type[T]])
  and Type[A] = (A,), inferring T as X now works when passing
  a (Type[X],)

A temporary regression is that constraints of generic parameters are now
ignored when a non-generic-instance is matched against the invocation of
a generic type.

Details

Key changes:

• typeRel doesn't directly use prepareMetatypeForSigmatch anymore,
  which is another step towards removing semtypinst's "meta-types
  allowed" mode
• the replaceTypeVarsInType procedure is added, which replaces type
  variables without also resolving tyGenericInvocations
• tyGenericInvocation handling in typeRel is now much more similar
  to that of tyGenericInst

When computing the relationship with a tyGenericInvocation (e.g., a
Type[T] in a routine signature where T is a generic parameter) and:

• the argument type is an array type or an instantiated generic type
  (i.e., tyGenericInst)
• typeRel happens in the context of routine signature parameter type
  matching

the invocation was first resolved via prepareMetatypeForSigmatch and
the argument type then matched against the instantiated type. The reason
for this seems to have been being able to consistently handle generic
aliases (by skipping them) and, in the case of arrays, that static
parameter inference works.

What prepareMetatypeForSigmatch does is create a fully instantiated
tyGenericInst for a tyGenericInvocation, using the "meta-types
allowed" mode of semtypinst. For example, the instance produced for
Body[A] = (A, A) with an invocation like Body[T] would be a (T, T)
type.

Reworked handling

In order to not having to rely on the "meta-types allowed" mode, the
handling of tyGenericInvocation is reworked to be the following (f
is the formal type and a the argument type after generic alias are
skipped):

1. if a is a tyGenericInvocation, the behaviour is the same as
   previously
2. if a is a tyGenericInst and it's an instance of the generic type
   that the invocation invokes, their relation is that of their
   arguments (the comparison works the same as for two tyGenericInst)
3. if the formal invocation is of an object type (including ref and
   ptr versions), f and a have a sub-type relationship if a is a
   sub-type of f, otherwise there's no relation
4. if f is an invocation of a and|or type or of another
   invocation and a is a tyGenericInst, there is no relationship
   (this mirrors the tyGenericInst-against-tyGenericInst handling)
5. otherwise (i.e., none of the above were true), the type parameters in
   f's body are replaced with the types passed to the invocation, and
   a is matched against the resulting type

The replacing in step 5. is implemented by the new
replaceTypeParamsInType procedure, which is similar to
replaceTypeVarsT, but with the important difference that:

• it doesn't instantiate tyGenericInvocations
• it properly handles tyFromExpr, by also replacing the type
  parameters in the attached AST
• the attached AST for object, tuple, and proc types is not modified, as
  this is not needed for typeRel to work with the types

For the case where a is not a tyGenericInst or tyArray, the
important difference is that a is now not matched against the body of
f first, with the inferred parameters of f then being matched
against its arguments. This leads to inference working in more complex
cases, but it also means that the parameter constraints of the invoked
types are ignored. For example:

type Type[A: object] = (A,)
proc f[T](x: Type[T]) = discard

f((1,))

doesn't fail now, while it previously (correctly) did.

Related changes:

• move the logic for comparing the arguments of two tyGenericInst
  types into a standalone procedure and adjust it to also work with
  tyGenericInvocations
• change skipToObject to not skip over tyGenericBody, as doing
  so is almost never what is wanted
• adjust isSubtypeOfGenericInstance to support f being a
  tyGenericInvocation
• remove the now-obsolete isGenericSubtype
• add a known-issue test for a pre-existing issue with generic range
  types

[saem]

I agree the temporary regression is acceptable.

Found a non-blocking very minor typo, I wouldn't bother fixing it -- could easily be done in a future PR, and since it's in 'known issue' text might be removed entirely.

[saem]

It shouldn't, pretty sure it should be an error where Generic[int] is expected, but received a Generic.

Specifying the type parameter on the procedure should affect the formal parameter's type definition and interpretation of any argument (the instantiated procedure's declaration), but not the actual argument.

[saem]

It's a temporary regression because, it's not unreasonable to do the check as part of the replace in the future?

[zerbina]

Yep, my current plan goes into that direction. In short, the idea is to, should the typeRel against the patched body return a match, perform a typeRel for all type arguments against their passed-to parameter's constraint. For that to work, typeRel is going to need some more improvements, which is why I haven't implemented it as part of this PR.

---

A complementary improvement could be leveraging the tyInferred mechanism (or an improved/extended version thereof) to infer the constraints for a generic parameter on definition:

type Generic[A: object] = (A, A)

proc f[T](x: Generic[T]) = ...

here T would be inferred to be constrained to an object type. This would make it possible to detect conflicting constraints on definition of a generic type/routine (instead of during parameter type matching).

[saem]

Suggested change

	type variables
	type variable

[saem]

these are super valuable, nice!

[zerbina]

/merge

[github-actions]

Merge requested by: @zerbina

Contents after the first section break of the PR description has been removed and preserved below:

---

Notes for Reviewers

• the regression is unfortunate, although I personally think it's acceptable for the time being