| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pick the first excessive positional arg for the caret.
Note that erroring on named args doesn't do the obvious thing
in this regard.
If `k` was removed from the signature, then `f(k=1, i=2, j=3)`
doesn't tell us much about the wrong arg, because naming takes
the `k=1` as an assignment, `i` as duplicate naming. No arg is
deemed extra, though further inspection of the conflicting args
might get there. Since assignment syntax in parens is more|less
deprecated (?), no more effort is done here.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Use removeNames to help diagnose the application.
Supplement the error message with how many extra
args and any other residual assignments that the
user might have thought was a properly named arg.
The error message is gradual: succinct for short
arg lists, more verbose for longer applications.
Very long arg lists are probably generated, so
that message is the least colloquial.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tryNamesDefaults branch of application typechecking contains the
checkNotMacro check, which errors out when we try to do named/default arguments
for macros (that's not supported yet, see SI-5920 for discussion).
Unfortunately, the check activates too early, because it turns out that
we can also enter tryNamesDefaults when the user just provides insufficient
number of arguments to a method by mistake, without expecting any default
arguments at all.
This leads to really confusing errors, which can luckily be fixed in a
very simple way by moving the checkNotMacro check down the happy path
of named/default typechecking.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit a02e053a5dec134f7c7dc53a2c1091039218237d.
That commit lead to an error compiling Specs2:
[info] [warn] /localhome/jenkinsdbuild/workspace/Community-2.11.x-retronym/dbuild-0.7.1-M1/target-0.7.1-M1/project-builds/specs2-aaa8091b47a34817ca90134ace8b09a9e0f854e9/core/src/test/scala/org/specs2/text/EditDistanceSpec.scala:6: Unused import
[info] [warn] import DiffShortener._
[info] [warn] ^
[info] [error] /localhome/jenkinsdbuild/workspace/Community-2.11.x-retronym/dbuild-0.7.1-M1/target-0.7.1-M1/project-builds/specs2-aaa8091b47a34817ca90134ace8b09a9e0f854e9/core/src/test/scala/org/specs2/text/LinesContentDifferenceSpec.scala:7: exception during macro expansion:
[info] [error] java.lang.UnsupportedOperationException: Position.point on NoPosition
[info] [error] at scala.reflect.internal.util.Position.fail(Position.scala:53)
[info] [error] at scala.reflect.internal.util.UndefinedPosition.point(Position.scala:131)
[info] [error] at scala.reflect.internal.util.UndefinedPosition.point(Position.scala:126)
[info] [error] at org.specs2.reflect.Macros$.sourceOf(Macros.scala:25)
[info] [error] at org.specs2.reflect.Macros$.stringExpr(Macros.scala:19)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
Macro impl bindings now store more information in signatures.
Previously it was a flattened List[Int] corresponding to flattened paramss,
now it's List[List[Int]] to preserve the lengths of parameter lists.
Also now we distinguish between c.Expr parameters and others.
Previously actual and reference macro signatures were represented as
tuples of vparamss, rets, and sometimes tparams. Now they are all
abstracted behind MacroImplSig.
Finally this patch provides better error messages in cases of
argsc <-> paramsc and argc <-> paramc mismatches.
|
