diff options
author | Eugene Burmako <xeno.by@gmail.com> | 2013-10-02 16:34:59 +0200 |
---|---|---|
committer | Eugene Burmako <xeno.by@gmail.com> | 2013-10-02 22:45:58 +0200 |
commit | d627672ec4a10861a659bfaacfaf86aa4b5b4e6e (patch) | |
tree | fd8e9af80295bac892e9e684ef4945d9761a3352 /test/long-running | |
parent | 8aae23ed47c4e38a465ff3373392484ca82473d1 (diff) | |
download | scala-d627672ec4a10861a659bfaacfaf86aa4b5b4e6e.tar.gz scala-d627672ec4a10861a659bfaacfaf86aa4b5b4e6e.tar.bz2 scala-d627672ec4a10861a659bfaacfaf86aa4b5b4e6e.zip |
clearly establishes what macro bundles are
Previously it was enough to just extend scala.reflect.macros.Macro, which
created some loopholes, but now scalac enforces that bundles:
1) Are static (not necessarily top-level, but just static)
2) Are traits (objects shouldn't be bundles anyway, and classes bring
complications with their ctors which require special treatment in
generated classes, so why support them if they don't bring anything
new to the table?)
3) Are monomorphic (again, this brings unnecessary complications wrt
auxiliary code generation, so I don't see merit in supporting
polymorphic bundles, whatever that a polymorphic bundle could mean)
4) Don't provide concrete implementation for Macro.c (if they do then
what is the point?)
Diffstat (limited to 'test/long-running')
0 files changed, 0 insertions, 0 deletions