-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(sem): crash on unmatched immediate
routines
#929
fix(sem): crash on unmatched immediate
routines
#929
Conversation
Unmatched `immediate` `macro`s and `template`s 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)
In terms of an improved implementation, I'm currently considering a "match" proc of some sort and then if that passes call |
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()
With 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. |
@zerbina, thanks for looking at this. I didn't cut the bug's trigger down enough, it's the Also you're correct, it would be an arity check, basically doing what |
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 |
thanks for the explanation. :) |
revised the test and creating a mismatch procedure is pretty expensive, it'd double up the analysis of |
/merge |
Merge requested by: @saem Contents after the first section break of the PR description has been removed and preserved below:
|
Summary
Unmatched
immediate
macro
s andtemplate
s within a generic contextno longer result in a compiler error.
Details
Immediate macros and templates are not dispatched via
sigmatch
andinstead
semgnrc
directly callsevaltempl.evalTemplate
, in turnevalTemplateArgs
is called which can produce an error if an incorrectnumber of arguments are provided.
evalTemplateArgs
is also used bysemMacroExpr
, so similar issues would also exist for macros.Now the error from
evalTemplateArgs
is immediately returned byevalTemplate
and treated as a mismatch insemgnrc.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)