summary refs log tree commit diff stats
path: root/compiler/patterns.nim
diff options
context:
space:
mode:
authorAdam Strzelecki <ono@java.pl>2015-10-29 22:10:09 +0100
committerAdam Strzelecki <ono@java.pl>2015-10-29 23:10:45 +0100
commit47e45dee7e9157212995c5769b93713f5a4dd14b (patch)
treee7b39e8add8198f0e11b08bec3604548223f395c /compiler/patterns.nim
parent8e4b5e10ba2945f880a857872862bcb28f625594 (diff)
downloadNim-47e45dee7e9157212995c5769b93713f5a4dd14b.tar.gz
fixes #3496
The problem comes from the fact that macroOrTmpl[...] is transformed by
semSubscript which is trying to evaluate macroOrTmpl identifier in place. This
is okay for non-generic macros or templates, but wrong for generic ones, that
do not have a chance to receive their generic arguments explicitly specified in
brackets.

Solution:

1. macroOrTmpl[...] where macroOrTmpl is non-generic macro or template, then
   macroOrTmpl is evaluated before applying brackets. (as before)

2. macroOrTmpl[...] where macroOrTmpl is generic macro or template, then if:

   a. It comes from macroOrTmpl[...](...) call expr (efInCall), then macroOrTmpl
      is turned into a symbol (efNoEvaluate) rather than evaluating it in place,
      then whole bracket expr is returned to semIndirectOp which transforms it
      to proper generic macro or template call with explicit generic arguments.

   b. macroOrTmpl[...] does not come from call expr, as above macroOrTmpl is
      transformed to symbol, then it is transformed into proper generic macro or
      template call with explicit generic arguments and no normal arguments.
Diffstat (limited to 'compiler/patterns.nim')
0 files changed, 0 insertions, 0 deletions