From fe124ceadc887f0ae4aa09e9af4fe96b91df670a Mon Sep 17 00:00:00 2001 From: Zahary Karadjov Date: Sun, 2 Aug 2015 23:23:13 +0300 Subject: [PATCH] Disable the new generic params handling for immediate template and macros 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. --- compiler/evaltempl.nim | 12 +++++++++++- compiler/vm.nim | 9 +++++---- compiler/vmgen.nim | 6 +++++- 3 files changed, 21 insertions(+), 6 deletions(-) diff --git a/compiler/evaltempl.nim b/compiler/evaltempl.nim index 015c14ab5a..82c4e8f573 100644 --- a/compiler/evaltempl.nim +++ b/compiler/evaltempl.nim @@ -66,7 +66,16 @@ proc evalTemplateArgs(n: PNode, s: PSym): PNode = else: 0 var - genericParams = s.ast[genericParamsPos].len + # XXX: 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. + genericParams = if sfImmediate in s.flags: 0 + else: s.ast[genericParamsPos].len expectedRegularParams =