summaryrefslogtreecommitdiff
path: root/test/files/run/macro-invalidusage-partialapplication-with-tparams.check
diff options
context:
space:
mode:
authorEugene Burmako <xeno.by@gmail.com>2014-01-22 13:18:35 +0300
committerEugene Burmako <xeno.by@gmail.com>2014-02-10 09:16:35 +0100
commita02e053a5dec134f7c7dc53a2c1091039218237d (patch)
tree13d71007d47b02b2dea80bcdc9d3609ad0aad9c6 /test/files/run/macro-invalidusage-partialapplication-with-tparams.check
parentd2a1dd59c264947137669f4dbda20d89b26743af (diff)
downloadscala-a02e053a5dec134f7c7dc53a2c1091039218237d.tar.gz
scala-a02e053a5dec134f7c7dc53a2c1091039218237d.tar.bz2
scala-a02e053a5dec134f7c7dc53a2c1091039218237d.zip
SI-5920 enables default and named args in macros
When producing an initial spec for macros two years ago, we sort of glossed over named/default arguments in macro applications, leaving them for future work. Once the aforementioned future has come, I’ve made several attempts at making things operational (e.g. last summer), but it’s always been unclear how to marry the quite complex desugaring that tryNamesDefaults performs with the expectations of macro programmers to see unsugared trees in macro impl parameters. Here’s the list of problems that arise when trying to encode named/default arguments of macro applications: 1) When inside macro impls we don’t really care about synthetic vals that are typically introduced to preserve evaluation order in non-positional method applications. When we inline those synthetics, we lose information about evaluation order, which is something that we wouldn’t like to lose in the general case. 2) More importantly, it’s also not very exciting to see invocations of default getters that stand for unspecified default arguments. Ideally, we would like to provide macro programmers with right-hand sides of those default getters, but that is: a) impossible in the current implementation of default parameters, b) would anyway bring scoping problems that we’re not ready to deal with just yet. Being constantly unhappy with potential solutions to the aforementioned problems, I’ve been unable to nail this down until the last weekend, when I realized that: 1) even though we can’t express potential twists in evaluation order within linearly ordered macro impl params, we can use c.macroApplication to store all the named arguments we want, 2) even though we can’t get exactly what we want for default arguments, we can represent them with EmptyTree’s, which is not ideal, but pretty workable. That’s what has been put into life in this commit. As a pleasant side-effect, now the macro engine doesn’t have to reinvent the wheel wrt reporting errors about insufficient arg or arglist count. Since this logic is intertwined with the tryNamesDefaults desugaring, we previously couldn’t make use of it and had to roll our own logic that checked that the number of arguments and parameters of macro applications correspond to each other. Now it’s all deduplicated and consistent.
Diffstat (limited to 'test/files/run/macro-invalidusage-partialapplication-with-tparams.check')
-rw-r--r--test/files/run/macro-invalidusage-partialapplication-with-tparams.check2
1 files changed, 1 insertions, 1 deletions
diff --git a/test/files/run/macro-invalidusage-partialapplication-with-tparams.check b/test/files/run/macro-invalidusage-partialapplication-with-tparams.check
index 6cbcb9e5af..f1061e00f7 100644
--- a/test/files/run/macro-invalidusage-partialapplication-with-tparams.check
+++ b/test/files/run/macro-invalidusage-partialapplication-with-tparams.check
@@ -1,3 +1,3 @@
reflective compilation has failed:
-too few argument lists for macro invocation
+missing arguments for macro method foo in object Macros