sigmatch: simpler procedural type matching

[zerbina]

Summary

• simplify the logic for handling generic routines using auto as the
  return type
• reject un-instantiated routines earlier when used in branch and array
  constructor expressions, resulting in clearer error messages
  (has no concrete type instead of cannot instantiate)
• fix spurious cannot instantiate errors when passing generic routines
  as arguments to parameters that are also generic
• support lambda expressions coming from template expansions

Details

Introduced by nim-lang/Nim#3234, when both the
formal and actual type are unresolved meta types, the relation is
considered to be isBothMetaConvertible. The intention seems to have
been supporting passing auto-returning routines or lambda-expressions
to generic procedure-type parameters, but the logic introduced by the
aforementioned PR is not necessary for achieving that.

auto return types now use dedicated handling in procTypeRel, both
the formal and actual type being unresolved generics results in a
mismatch again, and typeRel is no longer applied repeatedly for
isBothMetaConvertible matches.

There was also the issue of generateTypeInstance being misused, which
could result in spurious cannot instantiate or internal compiler
errors. Until type instantiation properly supports the case where it's
not certain whether all used generic parameters have been inferred
already, the tryGenerateInstance routine is introduced as a temporary
solution.

Finally, both nkStmtListExpr and nkBlockExpr nodes are now
considered when instantiating a generic routine as part of parameter
matching, which allows for complex expressions yielding un-instantiated
generic routines (e.g.: call((discard x; genericRoutine))).

[zerbina]

Regarding the effect on overload quality, the only difference is for generic procedural types with an auto return type. If after instantiation, the concrete procedural type matches exactly, the match is now considered as 1 conversion + 1 generic instead of 1 conversion + 1 exact. Example case:

proc call(x: proc(x: int): int {.nimcall.}) = discard

proc generic[T](x: T): auto {.nimcall.} =
  result = x

call(generic) # after instantiation, the types match exactly

I'm unsure whether this is a good idea or not.

[saem]

This is far more sensible than before. 🎉

I made some doc suggestions and possibly discovered a case that needs covering (nkBlockExpr).

[saem]

(just thinking outloud; entirely ignorable)

This isn't a bug, just an observation, sigmatch has an assumption that all name lookups have been complete and we're dealing with symbols only (not counting untyped AST parameter values, but sigmatch just passes those around like opaque values). This is one of those invariants of the module that I'm figuring out how to capture in the long run (entirely outside this PR).

[saem]

Regarding the effect on overload quality, the only difference is for generic procedural types with an auto return type. If after instantiation, the concrete procedural type matches exactly, the match is now considered as 1 conversion + 1 generic instead of 1 conversion + 1 exact. Example case:

proc call(x: proc(x: int): int {.nimcall.}) = discard

proc generic[T](x: T): auto {.nimcall.} =
  result = x

call(generic) # after instantiation, the types match exactly

I'm unsure whether this is a good idea or not.

It's not ideal, but I'm not quite sure if +1 generic and exact is either. If it's cumbersome to fix right now I would note it in a comment as an issue and move on.

[zerbina]

I have reverted the effects an instantiated auto-returning generic has on an overloads quality back to how they were before this PR.

The change with prepareMetatypeForSigmatch was also not quite correct:

• it doesn't always produce proper instances (because the instance cache is partially disabled), which causes subtle issues and can lead to C compiler errors
• the isMetaType + containsGenericType check isn't able to detect generic phantom types like, for example, Type[T] = object, which would lead to compiler assertions (rightfully) failing

To more properly fix the misuse of generateTypeInstance for the time being, I introduced the tryGenerateInstance routine. It uses prepareMetatypeForSigmatch as a way to check if all referenced generic parameters have been inferred already, and only if that is the case creates a proper instance via generateTypeInstance. This is rather inefficient, but it's the most robust and low-impact temporary solution that I could come up with.

[zerbina]

That should fix the test failures. I had forgotten that the tfHasMeta flag is also not excluded properly, meaning that it cannot be relied on at all for types produced by replaceTypeVarsT when meta-types are allowed.

[saem]

/merge

[github-actions]

Merge requested by: @saem

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

---

To-do

• add a negative test for making sure that non-matching overloads are rejected properly
• decide what effect a generic routine with an auto return type should have on an overload's quality
• maybe rename isBothMetaConvertible

Notes for Reviewers

• split off from and a blocker for sem: simplify generic parameter symbol handling #644
• the PR is already ready for review

[saem]

This is a good step forward in making this bit of sem make more sense.