| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make sure that methods annotated with varargs are properly mixed-in. This commit
splits the transformation into an info transformer (that works on all symbols, whether
they come from source or binary) and a tree transformer.
The gist of this is that the symbol-creation part of the code was moved to the UnCurry
info transformer, while tree operations remained in the tree transformer. The newly
created symbol is attached to the original method so that the tree transformer can still
retrieve the symbol.
A few fall outs:
- I removed a local map that was identical to TypeParamsVarargsAttachment
- moved the said attachment to StdAttachments so it’s visible between reflect.internal
and nsc.transform
- a couple more comments in UnCurry to honour the boy-scout rule
|
| |
|
|
|
|
| |
Rather than putting the code of a trait method body into a static method,
leave it in the default method. The static method (needed as the target
of the super calls) now uses `invokespecial` to exactly call that method.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An existing optimization in `Constructors` elides the outer
field in member and local classes, if the class doesn't use
the outer reference. (Member classes also need to be final,
which is a secret handshake to say we're also happy to weaken
prefix matching in the pattern matcher.)
That optimization leaves the constructor signature as is: the
constructor still accepts the outer instance, but does not store
it. For member classes, this means that we can separately compile
code that calls the constructor.
Local classes need not be hampered by this constraint, we could
remove the outer instance from the constructor call too.
Why would we want to do this?
Let's look at the case before and after this commit.
Before:
```
class C extends Object {
def foo(): Function1 = $anonfun();
final <static> <artifact> def $anonfun$foo$1($this: C, x: Object): Object = new <$anon: Object>($this);
def <init>(): C = {
C.super.<init>();
()
}
};
final class anon$1 extends Object {
def <init>($outer: C): <$anon: Object> = {
anon$1.super.<init>();
()
}
}
```
After:
```
class C extends Object {
def foo(): Function1 = $anonfun();
final <static> <artifact> def $anonfun$foo$1(x: Object): Object = new <$anon: Object>(null);
def <init>(): C = {
C.super.<init>();
()
}
};
final class anon$1 extends Object {
def <init>($outer: C): <$anon: Object> = {
anon$1.super.<init>();
()
}
}
```
However, the status quo means that a lambda that
This in turn makes lambdas that refer to such classes serializable
even when the outer class is not itself serialiable.
I have not attempted to extend this to calls to secondary constructors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The body of lambdas is compiled into a synthetic method
in the enclosing class. Previously, this method was a public
virtual method named `fully$qualified$Class$$anonfun$n`.
For lambdas that didn't capture a `this` reference, a static
method was used.
This commit changes two aspects.
Firstly, all lambda impl methods are now emitted static.
An extra parameter is added to those that require a this
reference.
This is an improvement as it:
- allows, shorter, more readable names for the lambda impl method
- avoids pollution of the vtable of the class. Note that javac uses
private instance methods, rather than public static methods. If
we followed its lead, we would be unable to support important use
cases in our inliner
Secondly, the name of the enclosing method has been included in
the name of the lambda impl method to improve debuggability and
to improve serialization compatibility. The serialization improvement
comes from the way that fresh names for the impl methods are
allocated: adding or removing lambdas in methods not named "foo" won't
change the numbering of the `anonfun$foo$n` impl methods from methods
named "foo". This is in line with user expectations about anonymous
class and lambda serialization stability. Brian Goetz has described
this tricky area well in:
http://cr.openjdk.java.net/~briangoetz/eg-attachments/lambda-serialization.html
This commit doesn't go as far a Javac, we don't use the hash of the
lambda type info, param names, etc to map to a lambda impl method name.
As such, we are more prone to the type-1 and -2 failures described there.
However, our Scala 2.11.8 has similar characteristics, so we aren't going
backwards.
Special case in the naming: Use "new" rather than "<init>" for constructor enclosed
lambdas, as javac does.
I have also changed the way that "delambdafy target" methods are identifed.
Rather than relying on the naming convention, I have switched to using a
symbol attachment. The assumption is that we only need to identify them
from within the same compilation unit.
This means we can distinguish impl metbods for expanded functions
(ones called from an `apply` method of an ahead-of-time expanded
anonfun class), from those that truly end up as targets for lambda
metafactory. Only the latter are translated to static methods in
this patch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We cannot use the expected type to track whether a Function node
targets a SAM type, as the expected type may be erased (see test
for an example).
Thus, the type checker attaches a SAMFunction attachment to a
Function node when SAM conversion is performed in adapt. Ideally,
we'd move to Dotty's Closure AST, but that will need a
deprecation cycle.
Thanks to Jason for catching my mistake, suggesting the fix and
providing the test.
Both the sam method symbol and sam target type must be tracked,
as their relationship can be complicated (due to inheritance).
For example, the sam method could be defined in a superclass (T)
of the Function's target type (U).
```
trait T { def foo(a: Any): Any }
trait U extends T { def apply = ??? }
(((x: Any) => x) : U).foo("")
```
This removes some of the duplication in deriving the sam method
from the expected type, but some grossness (see TODO) remains.
|
| |
|
|
|
|
|
| |
Allow annotating individual callsites @inline / @noinline using an
annotation ascription
c.foo(): @inline
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit corrects many typos found in scaladocs, comments and
documentation. It should reduce a bit number of PRs which fix one
typo.
There are no changes in the 'real' code except one corrected name of
a JUnit test method and some error messages in exceptions. In the case
of typos in other method or field names etc., I just skipped them.
Obviously this commit doesn't fix all existing typos. I just generated
in IntelliJ the list of potential typos and looked through it quickly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reflection API exhibits a tension inherent to experimental things:
on the one hand we want it to grow into a beautiful and robust API,
but on the other hand we have to deal with immaturity of underlying mechanisms
by providing not very pretty solutions to enable important use cases.
In Scala 2.10, which was our first stab at reflection API, we didn't
have a systematic approach to dealing with this tension, sometimes exposing
too much of internals (e.g. Symbol.deSkolemize) and sometimes exposing
too little (e.g. there's still no facility to change owners, to do typing
transformations, etc). This resulted in certain confusion with some internal
APIs living among public ones, scaring the newcomers, and some internal APIs
only available via casting, which requires intimate knowledge of the
compiler and breaks compatibility guarantees.
This led to creation of the `internal` API module for the reflection API,
which provides advanced APIs necessary for macros that push boundaries
of the state of the art, clearly demarcating them from the more or less
straightforward rest and providing compatibility guarantees on par with
the rest of the reflection API.
This commit does break source compatibility with reflection API in 2.10,
but the next commit is going to introduce a strategy of dealing with that.
|
| | |
|
| |
|
|
|
|
|
|
| |
This makes it easy to differentiate unit inserted by a compiler vs unit
written by the user. Useful for quasiquotes and pretty printing.
Additionally SyntacticBlock extractor is changed to treat EmptyTree as
zero-element block.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces internal attachment that allows unapply macros to
be aware of their sub patterns and tweak their expansion depending
on that info.
At the moment this is not possible due to the way pattern macros are
expanded:
case MacroPat(inner1, inner2) => ...
During type checking this will expand as
MacroPat.unapply(<unapply-dummy>)
Meaning that macro can’t see inner1 and inner2 in it’s macroApplication.
To circumvent this we attach that info as an attachment to the dummy.
|
| | |
|
| |
|
|
|
|
| |
Encode values into real trees rather than non-tree case classes.
This is needed for re-usability of desugaring code between quasiquotes
and parser.
|
| |
|
|
|
|
|
| |
Previously attachments weren't imported by importTree. Now a new marker
trait has been added that lets attachments to import themselves to the
new universe together with all their innards. Additionally a simpler
subtrait is defined to mark attachments that can be imported as-is.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Confusing, now-it-happens now-it-doesn't mysteries lurk
in the darkness. When scala packages are declared like this:
package scala.collection.mutable
Then paths relative to scala can easily be broken via the unlucky
presence of an empty (or nonempty) directory. Example:
// a.scala
package scala.foo
class Bar { new util.Random }
% scalac ./a.scala
% mkdir util
% scalac ./a.scala
./a.scala:4: error: type Random is not a member of package util
new util.Random
^
one error found
There are two ways to play defense against this:
- don't use relative paths; okay sometimes, less so others
- don't "opt out" of the scala package
This commit mostly pursues the latter, with occasional doses
of the former.
I created a scratch directory containing these empty directories:
actors annotation ant api asm beans cmd collection compat
concurrent control convert docutil dtd duration event factory
forkjoin generic hashing immutable impl include internal io
logging macros man1 matching math meta model mutable nsc parallel
parsing partest persistent process pull ref reflect reify remote
runtime scalap scheduler script swing sys text threadpool tools
transform unchecked util xml
I stopped when I could compile the main src directories
even with all those empties on my classpath.
|
| |
|
|
|
|
|
|
|
| |
Changes macroExpand to accommodate expansion schemes different from the
currently supported one.
As a bonus, which follows clarification of the macro expansion logic,
this refactoring fixes suppression of macro expansions, which
previously didn't work with delayed expansion.
|
| |
|
|
|
| |
When transforming Idents to qualified Selects, typedIdent used to forget
about carrying original attachments to the resulting tree. Not anymore.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Eta expansions previously caused the typer to disable macros. That was
done in order to detect eta expansion of macro defs and show the user
an appropriate error message.
Macros were disabled because to find out whether we're expanding
a macro def, we need to get its symbol, and to get a symbol of something
we need to typecheck that something. However typechecking automatically
expands macros, so, unless we disable macros, after a typecheck we won't
be able to analyze macro occurrences anymore.
Unfortunately this solution has a fatal flaw. By disabling macros we
not only prevent the eta-expandee from macro expanding, but also all
the subtrees of that eta-expandee (see SI-6673).
This commit adds a mechanism for fine-grained control over macro
expansion. Now it's possible to prohibit only the node, but not its
children from macro expanding.
|
| |
|
|
|
|
| |
Because they are only available in macros.Universe, not in api.Universe,
therefore I'd argue that the confusion factor is stronger than the weirdness
of scala.reflect.api.Position extending scala.reflect.macros.Attachments.
|
| |
|
|
|
| |
As the experience has shown, there's no need for a separate layer of reflection
in scala-library.jar. Therefore I'm putting an end to it.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously Attachments allowed multiple attachments that
correspond to the same attachment type.
This created a potential for confusion, given that Attachments.get
only searched for the first attachment of a given type.
Hence I made Attachments.add overwrite previously existing attachments
of a given type and renamed it to Attachments.update, so that the name
suits the intention better.
|
| |
|
|
| |
Removes the two global hash maps in Namers, and the one in NamesDefaults. Also fixes SI-5975.
|
| |
|
