| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Creates MacroPlugin, a sister interface of AnalyzerPlugin in the namer/typer
extensibility interface.
Exposes `pluginsTypedMacroBody`, `pluginsMacroExpand`, `pluginsMacroArgs`
and `pluginsMacroRuntime` in the macro plugin interface. This will
make it easy to prototype changes to the macro engine without disturbing scala/scala.
|
| |
|
|
|
|
|
|
|
| |
This is the first commit in a pull request that makes macro engine
extensible by analyzer plugins.
Such helpers as `macroArgs` and `macroExpandWithRuntime` have proven
to be indispensable in macro paradise, so it’ll be important to have
them available to macro plugins.
|
| |
|
|
|
|
| |
Abstracts away the foldLeft-based iteration pattern behind CumulativeOp[T].
In order to avoid performance regressions, `pluginsPt` and `pluginsTyped`
are special-cased for empty lists of analyzer plugins.
|
| |
|
|
|
|
|
|
|
|
|
| |
I guess having `computeMacroDefType` is the remnant from the times when
we considered an immediate possibility of having non-defdef macros, for
instance type macros, which would be TypeDefs.
These happy early days are gone, type macros have been long buried,
and the perspectives of extensions to the existing def macro scheme are
unclear. Therefore let’s have maximally precise types right away and then
think of generalization later on, once/if we get there.
|
| |
|
|
|
|
|
|
|
|
| |
Back then, when we needed separate macro expanders for both applications
and unapplications, it made sense to have two different methods that
do macro expansions.
However, after @paulp’s upgrade of the pattern matching engine, we no longer
need a dedicated expander for unapply, so I’m removing it and renaming
`macroExpandApply` to just `macroExpand`.
|
| |\
| |
| | |
makes boxity of fast track macros configurable
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, all built-in macros were assumed to be whitebox, but that’s
actually not the case. Just quasiquote macros have to be whitebox, while
the rest can be blackbox.
This also fixes SI-8091, because blackbox macros are typechecked differently
and therefore the necessary implicit conversion kicks in. If `f”...”` were
to remain a whitebox macro, then due to the changes introduced in commit
https://github.com/scala/scala/commit/a3b33419b02cafb7e2c6fed6dd96151859fc7d77
we would have to explicitly ascribe its expansion as String to achieve the same effect.
After I made reify blackbox, several tests had to be changed, because
we now explicitly ascribe the expansion with `c.Expr[T]`, which changes `toString`.
Also, a number of less obvious corrections had to be applied, because
things like `reify(<constant>).splice` have stopped being optimized away
due to `reify(<constant>)` no longer having a narrow `c.Expr[<constant>.type]`,
making it ineligible for constant folding.
Moreover, this change forced me to adjust our approach to positioning
blackbox wrappings, because after being changed to blacbox and starting using
wrappings, f”...” interpolators used in the compiler started crashing
-Yrangepos builds. Now wrapping Typed nodes are assigned with transparent
positions.
|
| |\ \
| | |
| | | |
Added .ant-targets-build.xml to .gitignore.
|
| | | |
| | |
| | |
| | | |
Something generates this repo-dirtying file during ant replacestarr.
|
| |\ \ \
| | | |
| | | | |
Remove commented out code from HashSet and HashMap
|
| | |/ /
| | |
| | |
| | |
| | |
| | | |
Remove an ancient, commented out microbenchmark from HashSet and HashMap.
Also, fix indentation for while loop in HashSet.foreach and remove some
other commented out code that no longer serves any purpose.
|
| |\ \ \
| | | |
| | | | |
makes well-known packages and package classes consistent with each other
|
| | |/ /
| | |
| | |
| | |
| | |
| | | |
As discovered in https://groups.google.com/forum/#!topic/scala-user/RckXE90LoXo,
RootClass.sourceModule and EmptyPackageClass.sourceModule used to incorrectly
return NoSymbol instead of RootModule and EmptyPackage. This is now fixed.
|
| |\ \ \
| | | |
| | | | |
duplicates arguments to macro typer APIs
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit continues the tendency set by the parent commit to duplicate
as much as possible in order to avoid potential confusion that users
might run into when compiler internals start leaking.
Here we plumb another way that by-reference sharing of trees might bite
unsuspecting macro writers. Previously we have duplicated macro expansions,
macro arguments, c.macroApplication, and now it’s arguments to typeCheck
and resetAttrs.
There is still an unlikely situation when someone gets to c.enclosingXXX
and then starts typechecking around, but that’s left for future work,
as it’s yet unclear what to do with c.enclosingXXX APIs.
|
| |\ \ \ \
| | | | |
| | | | | |
<uptodate> Ant-ics
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This was recently refactored from build.xml. Changing either file
should invalidate caches.
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Changes to the compiler or library were not triggering recreation
of the OSGI JARs, which are used in the local maven deployment tasks.
Reason: this Ant-ipattern:
<fileset base="/foo">
<include name="/foo/bar.baz"/>
</fileset>
Instead, we should use a <filelist/>, which doesn't require
a base directory. This can be composed into a <srcresources/>
element in the <uptodate/>.
Phew!
|
| |\ \ \ \
| | | | |
| | | | | |
SI-7777 SI-8006 assorted fixes for dynamics
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Since mkInvoke, the applyDynamic/selectDynamic/etc desugarer, is disconnected
from typedNamedApply, the applyDynamicNamed argument rewriter, the latter
doesn’t know whether it needs to apply the rewriting because the application
has just been desugared or it needs to hold on because it’s already performed
a desugaring on this tree.
This commit introduces the attachment that links these translation facilities,
preventing infinite applyDynamicNamed desugarings.
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Interplay between the insertApply desugaring and the invokeDynamic desugarings
is already quite brittle, but the real fun begins when macros crash the party.
The proposed patch enriches the `isDesugaredApply` check performed in
`mkInvoke`, the invokeDynamic desugarer, and makes sure that everything
is safe and sound in the macroland.
|
| |\ \ \ \
| | | | |
| | | | | |
(master) codifies the state of the art wrt SI-8104
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As it was discovered in SI-8104, whiteboxity doesn’t apply equally to
type parameters and type members of materialized type classes.
During implicit search and subsequent type inference, whitebox type parameters
are consistently erased to wildcards, whereas whitebox type members sometimes
remain as is and get in the way of signature conformance checks.
|
| |\ \ \ \
| |/ / /
|/| | | |
SI-6355 SI-7059 it is possible to overload applyDynamic
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
As our discussion at https://issues.scala-lang.org/browse/SI-6355 shows,
it looks like it is possible to overload applyDynamic, even though a
straightforward way is closed. This commit codifies the pattern proposed
by @paulp and makes sure that it doesn’t break in the future.
|
| |\ \ \
| | | |
| | | | |
cosmetic changes to liftables
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Namely:
1) Moved definitions of Liftable and Unliftable into a separate file.
2) Inlined internal names that were only used in StandardLiftables.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-6120 Suppress extra warnings
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is a mere polish for the fix to allow multiple warnings.
Sensibility checks in refchecks were shown to be redundant.
This commit includes a mild refactor to reduce tabbage, and
uses a local var to flag that a warning has already been emitted.
It would be better to have the checks return true if warned,
to facilitate `nonSensically || unrelatedly`, etc., but that's
a lot of `else false`.
The check files that were updated with the redundant warnings
are reverted.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-8017 Value class awareness for -Ydelamdafy:method
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The delambdafy creates a bridge method which requires adaptation
of the result type to the generic `Object`, which is the erased
return type of FunctionN.
This bridge building reused some code from erasure, now refactored
into TypeAdaptingTransformer.
But, it was running into problems with:
class C(a: Int) extends AnyVal
(x: Any) => new C(0)
It created (forgive the pseudo quasiquote syntax):
class anonfun$ extends Function1[Any, C] {
def apply#1(a: Object): Int = 0
<bridge> def apply#2(a: Object): Object = {
val result: Int = apply#1(a)
${adapt(Ident("result"), ObjectType)}
}
}
This resulted in primitive boxing, rather than value class boxing.
Instead, we need the call to the main apply method to be typed
as `ErasedValueClass(C, Int)`, which `adapt` takes as a trigger
to perform value class boxing.
Finally, we have to run the post-erasure transformer over the adapted
tree to eliminate remnants of `ErasedValueClass` from the types of
trees.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Fix crasher with private[this] in nested traits
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The previous commit means we no longer have a test that
gets to this point.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Currently, accessors for private local trait fields are added
very late in the game when the `Mixin` tree transformer treats the
trait. By contrast, fields with weaker access have accessors created
eagerly in `Namers`.
// Mixin#addLateInterfaceMembers
val getter = member.getter(clazz)
if (getter == NoSymbol) addMember(clazz, newGetter(member))
`addMember` mutates the type of the interface to add the getter.
(This seems like a pretty poor design: usually if a phase changes
types, it should do in an `InfoTransformer`.)
However, if an inner class or anonymous function of the trait
has been flattened to a spot where it precedes the trait in the
enclosing packages info, this code hasn't had a chance to run,
and the lookup of the getter crashes as mixins `postTransform`
runs over a selection of the not-yet-materialized getter.
// Mixin#postTransform
case Select(qual, name) if sym.owner.isImplClass && !isStaticOnly(sym) =>
val iface = toInterface(sym.owner.tpe).typeSymbol
val ifaceGetter = sym getter iface
This commit ensures that `Flatten` lifts inner classes to
a position *after* the enclosing class in the stats of the
enclosing package.
Bonus fix: SI-7012 (the followup ticket to SI-6231 / SI-2897)
|
| |\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | / /
| | |_|_|/ /
| |/| | | | |
(2.11.0-M8) duplicates macro arguments before expansion
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
As discussed with Jason, this is an important dimension of defenses that
we can build to ensure robustness of the macro engine.
This commit is important in the context of the upcoming patch to the
presentation compiler that will throw away expansions and keep original
macro applications (only when run in presentation compiler mode) so that
hyperlinking in macro arguments starts working in the IDE.
Duplication of macro arguments will make sure that macro arguments, which
are going to become exposed to the IDE, can’t become corrupted by possibly
misbehaving or misguided macros.
|
| |\ \ \ \ \ \
| |_|_|_|_|/
|/| | | | | |
SI-7971 Handle static field initializers correctly
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Before this fix, static fields where erroneously treated like instance
fields and the initialization was moved into the constructor.
With this fix, the static initializer statements go into the static
initializer of the class (called “<STATIC> def init” in Scala,
<clinit> in Java). The statements are added to an existing
static initializer method or, if no such method exists, a new static
initializer method is created and added to the class.
|
| |\ \ \ \ \ \
| |_|_|_|_|/
|/| | | | | |
(2.11.0-M8) whitebox macros are now first typechecked against outerPt
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
While fixing the problem with the order of typechecks for whitebox expansions,
I realized that we’re doing redundant work when expanding blackbox macros.
Concretely, typechecking blackbox expansions looked as follows:
val expanded1 = atPos(enclosingMacroPosition.focus)(Typed(expanded0, TypeTree(innerPt)))
val expanded2 = typecheck("blackbox typecheck #1", expanded1, innerPt)
typecheck("blackbox typecheck #2", expanded1, outerPt)
Or, if we reformulate it using quasiquotes (temporarily not taking
positions into account, since they aren’t important here):
val expanded2 = typed(q”$expanded: $innerPt”, innerPt)
typed(expanded2, outerPt)
In this formulation, it becomes apparent that the first typecheck is
redundant. If something is ascribed with some type, then typechecking
the ascription against that type does nothing useful.
This is also highlights one of the reasons why it would be really nice
to have quasiquotes used in the compiler. With them, it’s easy to notice
things that would otherwise remain buried behind swaths of boilerplate.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Even though whitebox macros are supposed to be used to produce expansions
that refine advertised return types of their macro definitions, sometimes
those more precise types aren’t picked up by the typechecker.
It all started with Travis generating structural types with macros
and noticing that typer needs an extra nudge in order to make generated
members accessible to the outside world. I didn’t understand the mechanism
of the phenomenon back then, and after some time I just gave up.
Afterwards, when this issue had been brought up again in a different
StackOverflow question, we discussed it at reflection meeting, figured out
that typedBlock provides some special treatment to anonymous classes,
and it became clear that the first macro typecheck (the one that types
the expansion against the return type of the corresponding macro def)
is at fault here.
The thing is that if we have a block that stands for a desugard anonymous
class instantiation, and we typecheck it with expected type different from
WildcardType, then typer isn’t going to include decls of the anonymous class
in the resulting structural type: https://github.com/scala/scala/blob/master/src/compiler/scala/tools/nsc/typechecker/Typers.scala#L2350.
I tried to figure it out at https://groups.google.com/forum/#!topic/scala-internals/eXQt-BPm4i8,
but couldn’t dispel the mystery, so again I just gave up.
But today I had a profound WAT experience that finally tipped the scales.
It turns out that if we typecheck an if, providing a suitable pt, then
the resulting type of an if is going to be that pt, even though the lub
of the branch types might be more precise. I’m sure that reasons for this
behavior are also beyond my understanding, so I decided to sidestep this problem.
upd. Here’s Jason’s clarification: Doing thing differently would require
us to believe that "'Tis better to have lubbed and lost than never to have
lubbed at all." But the desire for efficiency trumps such sentimentality.
Now expansions of whitebox macros are first typechecked against outerPt,
the expected type that comes from the enclosing context, before being
typechecked against innerPt, the expected type that comes from the return
type of the macro def. This means that now outerPt provides the correct
expected type for the initial, most important typecheck, which makes
types more precise.
|
| | | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Moves some code around to clearly define the concepts that the method
operates on: 1) `innerPt`, which is expected type provided by the macro
def return type, 2) `outerPt`, which is expected type provided by the
enclosing context.
Once everything is clearly defined, the gist of the expander fits in
a few lines in its end. If blackbox, do this. If whitebox, do that.
Note that unlike the subsequent commit, this commit doesn’t change
the way how macro expansion works. It just clears everything out, so that
the upcoming changes can be applied in a concise and comprehensible manner.
|
| |\ \ \ \ \
| |_|_|_|/
|/| | | | |
Improvements to partest-ack, plus partest-paths.
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I noticed partest-ack was not finding all matching tests, and
fixed that. Also cleaned up the ack options so they're understood
by the latest version of ack.
Along the way I broke the canonicalization functionality out into its
own script so it can easily be used from other places.
|
| |\ \ \ \
| | | | |
| | | | | |
Fix osgi bundle name for continuations.
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | | |
Final library modularization for 2.11
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The Scala Swing library will still ship with 2.11 (albeit unsupported).
It now resides at https://github.com/scala/scala-swing.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The continuations plugin and library will still ship with 2.11 (albeit unsupported).
They now reside at https://github.com/scala/scala-continuations.
|
| |\ \ \ \ \
| |/ / / /
|/| | | | |
SI-7546 Use likely monotonic clock source for durations
|
