* new .gensym implementation
* make astspec test green again
* introduce a --useVersion switch to group compatibility switches
* fixes#10180
* fixes#11494
* fixes#11483
* object constructor fields and named parameters are also not gensym'ed
* disabled broken package
This allows you to pass a template or a macro to another macro
which can then inspect the implementation of the former template/macro
using `getImpl`.
Since templates can be freely redefined, this allows you to treat
their symbols as compile-time variables that have lexical scope.
A motivating PoC example for a logging library taking advantage of
this will be provided in the next commit.
Implementation details:
* The name of a template or a macro will be consider a symbol if
the template/macro requires parameters
* For parameterless templates/macros, you can use `bindSym`, which
was extended to also work outside of compile-time procs.
This commit returns to a bit less strict checking of the number
of macro arguments, because some old immediate macros rely on a
behavior where even the arity of the macro is not being checked.
It may be better if such macros are just declared to use varargs[expr],
but this remains for another day.
Previously it was not possible to use template arguments in template body as
the symbols were not resolved correctly leading to Error: undeclared
identifier: 'XX', eg.:
template defaultOf[T](t: T): expr = (var d: T; d)
echo defaultOf(1) #<- invalid identifier, but should output 0
Since immediate templates are not subjected to the standard sigmatching
algorithm, they will have a number of deficiencies when it comes to generic
params: Type dependencies between the parameters won't be honoured
and the bound generic symbols won't be resolvable within their bodies.
We could try to fix this, but it may be wiser to just deprecate immediate
templates and macros now that we have working untyped parameters.
Disabling the new features is admittedly not the greatest way to handle
this situations as it introduces inconsistency in the language, but at least
it makes the code backwards-compatible with the previous version of the
compiler instead of triggering more serious problems.
Implementation notes:
Just after overload resolution, the resolved generic params will be added to the
call expression to be later processed in evalTemplate and evalMacroCall. These
procs have been modified to handle the increased number of parameters, but one
remaining issue is that immediate templates and macros don't go through the same
process. The next commit will outlaw the use of generic parameters with such macros.
