fix(sem): crash on unmatched immediate routines

[saem]

Summary

Unmatched immediate macros and templates within a generic context
no longer result in a compiler error.

Details

Immediate macros and templates are not dispatched via sigmatch and
instead semgnrc directly calls evaltempl.evalTemplate, in turn
evalTemplateArgs is called which can produce an error if an incorrect
number of arguments are provided. evalTemplateArgs is also used by
semMacroExpr, so similar issues would also exist for macros.

Now the error from evalTemplateArgs is immediately returned by
evalTemplate and treated as a mismatch in semgnrc.semGenericStmt.
Doing so prevents a compiler crash, attempt to access the sons of an
error
node. A test has been added as part of this change, which was
originally
from: zevv/npeg#68 (comment)

[saem]

In terms of an improved implementation, I'm currently considering a "match" proc of some sort and then if that passes call evalTemplate.

[zerbina]

A more minimal test case:

template unique(x, y: untyped) =
  ## A template (macro would work too) that is not overloaded. 
  # it's important that `y` is actually used within the template. The
  # error wouldn't occur otherwise
  y

proc test[T]() =
  unique("test")

test()

In terms of an improved implementation, I'm currently considering a "match" proc of some sort and then if that passes call evalTemplate.

With match, do you mean a procedure that performs an arity check? If yes, then I think that's the way go.

At a later point (i.e., not something that I think has to happen as part of this PR), this could be extended to test each overload in the symbol choice, so that overloaded immediate macros/templates are resolved during the generic pre-pass.

[saem]

@zerbina, thanks for looking at this.

I didn't cut the bug's trigger down enough, it's the > being treated as a prefix and based on the definition inside system that's failing to match in the original. There evalTemplateArgs returned an nkError due to argument count mismatch, evalTemplateAux attempted to index into the error node, thinking it was an nkArgList, leading to a variant field access violation on sons crash. The part I'll have to try is the reduced example you provided because I can't explain why y must appear in the template body to force the error.

Also you're correct, it would be an arity check, basically doing what evalTemplateArgs is doing now.

[zerbina]

You're welcome :)

Sorry for the confusion, the wording in the test snippet I provided put the focus on the wrong part: the only important part is that a template parameter is used within the body, otherwise actual (the template arguments) is never indexed into in evalTemplateAux. Both the snippet I provided and the test case with > trigger the same error.

[saem]

thanks for the explanation. :)

[saem]

revised the test and creating a mismatch procedure is pretty expensive, it'd double up the analysis of evalTemplateArgs, it should be revisited after nkArgList wrapping is introduced.

[saem]

/merge

[github-actions]

Merge requested by: @saem

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

---

Notes for Reviewers

• this is an immediate fix; creating a mismatch detection procedure would have
  resulted in analyses the args twice among other issues
• longer term:
  • nkCall and friends should wrap their args in nkArgList
  • this can then be semantically analysed and better returned with error nodes
  • more legacy report removal (i.e. localReport) to clean-up the error messages