diff options
author | Eugene Burmako <xeno.by@gmail.com> | 2014-01-22 13:18:35 +0300 |
---|---|---|
committer | Eugene Burmako <xeno.by@gmail.com> | 2014-02-10 09:16:35 +0100 |
commit | a02e053a5dec134f7c7dc53a2c1091039218237d (patch) | |
tree | 13d71007d47b02b2dea80bcdc9d3609ad0aad9c6 /test/pending/run/macro-expand-default.flags | |
parent | d2a1dd59c264947137669f4dbda20d89b26743af (diff) | |
download | scala-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/pending/run/macro-expand-default.flags')
-rw-r--r-- | test/pending/run/macro-expand-default.flags | 1 |
1 files changed, 0 insertions, 1 deletions
diff --git a/test/pending/run/macro-expand-default.flags b/test/pending/run/macro-expand-default.flags deleted file mode 100644 index cd66464f2f..0000000000 --- a/test/pending/run/macro-expand-default.flags +++ /dev/null @@ -1 +0,0 @@ --language:experimental.macros
\ No newline at end of file |