| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| | |
merge/2.11.x-to-2.12.x-20150501
|
| | |\
| | |
| | | |
Fix many typos
|
| | | |
| | |
| | |
| | |
| | | |
This commit corrects many typos found in scaladocs and comments.
There's also fixed the name of a private method in ICodeCheckers.
|
| | |\ \
| | |/
| |/| |
Don't crash GenBCode for value classes with a self declaration
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If a value class has a self declaration
class V(x: Long) extends AnyVal { self => /* ... */ }
`vClassSymbol.typeOfThis.typeSymbol` is `class Long` in the backend.
The InlineInfo for traits contains a field for the self type of the
trait. This is required for re-writing calls to final trait methods
to the static implementation method: the self type appears in the
impl method signature.
By mistake, the backend was recording the self type of all classes,
not only of traits. In the case of a value class with a self
declaration, this broke the assumption that the self type is always
a class type (not a primitive type).
The simple fix: only record the self type for traits.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When parsing a Java generic signature that references an inner
class `A$B`, we were tripping an assertion if the enclosing class
`A` was absent.
This commit creates a stub symbol for `B` when this happens, rather
than continuing on with `NoSymbol`.
The enclosed test shows that we can instantiate a class containing
a method referring to such an inner class with only a warning
about the absent classfile, and that an error is issued only upon
a subsequent attempt to call the method.
|
| | | | |
|
| |\| | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Under -Ydelambdafy:method (the basis of the upcoming "indylambda"
translation for -target:jvm-1.8), an anonymous function is currently
encoded as:
1. a private method containing the lambda's code
2. a public, static accessor method that allows access to 1 from
other classes, namely:
3. an anonymous class capturing free variables and implementing
the suitable FunctionN interface.
In our prototypes of indylambda, we do away with 3, instead deferring
creating of this class to JDK8's LambdaMetafactory by way of an
invokedynamic instruction at the point of lambda capture. This
facility can use a private method as the lambda target; access is
mediated by the runtime-provided instance of
`java.lang.invoke.MethodHandles.Lookup` that confers the privelages
of the lambda capture call site to the generated implementation class.
Indeed, The java compiler uses this to emit private lambda body
methods.
However, there are two Scala specific factors that make this
a little troublesome.
First, Scala's optimizer may want to inline the lambda capture
call site into a new enclosing class. In general, this isn't a
safe optimization, as `invokedynamic` instructions have call-site
specific semantics. But we will rely the ability to inline like
this in order to eliminate closures altogether where possible.
Second, to support lambda deserialization, the Java compiler creates
a synthetic method `$dersializeLamda$` in each class that captures
them, just to be able to get the suitable access to spin up an
anoymous class with access to the private method. It only needs
to do this for functional interfaces that extends Serializable,
which is the exception rather than the rule. But in Scala, *every*
function must support serialization, so blindly copying the Java
approach will lead to some code bloat.
I have prototyped a hybrid approach to these challenges: use the
private method directly where it is allowed, but fall back to
using the accessor method in a generic lambda deserializer or
in call sites that have been inlined into a new enclosing class.
However, the most straight forward approach is to simply emit the
lambda bodies as public (with an mangled name and with the SYHTNETIC
flag) and use them in all cases. That is what is done in this commit.
This does moves us one step backwards from the goals of SI-7085,
but it doesn't seem sensible to incur the inconvenience from locking
down one small part of our house when we don't have a plan or the
budget to complete that job.
The REPL has some fancy logic to decompile the bodys of lambdas
(`:javap -fun C#m`) which needed tweaking to accomodate this change.
I haven't tried to make this backwards compatible with the old
encoding as `-Ydelambdafy:method` is still experimental.
|
| | |\ \
| | |/
| |/| |
SI-3368 Default to coalescing for 2.11
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Preserve current behavior (no PCData nodes, only Text)
for 2.11.
The coalescing flag is on if enabled or if source level
is not 2.12 and no flag was supplied.
The subtle change is that adjacent Text nodes are thereby
coalesced. This happens in the presence of CData sections,
but this is at the discretion of the parser anyway.
Also, no PCData nodes are emitted under coalescing, even
if there were no sibling text nodes. That is the correct
behavior: the general idea is that coalescing mode says,
I only want to deal with text.
|
| | |\ \
| | |/
| |/| |
Disable -Ydelambdafy:method for specialized FunctionN
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The Delambdafy phase generates its `FunctionN` subclasses after
the specialization phase. As such, `((x: Int) => x).apply(42)` incurs
boxing.
This commit falls back to the `-Ydelambdafy:inline` in this case.
This is done by running the specialization type map over the
type of the function, and seeing if anything changes. To make this
work robustly, we first need to ensure that the specialization info
transformer has processed all the function types.
This is not a fundamental limitation; we could in principle generate
the specialized code.
A followup change will use `-Ydelambdafy:method` as the basis for
invokedymnamic lambdas. As part of that stream of
work, we will synthesize specialization-aware lambdas, and remove
the fallback to `-Ydelambdafy:inline`.
I have updated some tests that intend to test the delambdafy transform
to avoid use of specialized function types.
|
| | |\ \
| | | |
| | | | |
SI-3368 CDATA gets a Node
|
| | | | |
| | | |
| | | |
| | | | |
Verbose option help and test tweak.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As long as Scala does XML literals, there is probably parsing
behavior worth configuring.
Therefore, the umbrella option is promoted to `-Xxml`.
It was tempting to make it `-XML`, but we resisted.
|
| | | | |
| | | |
| | | |
| | | | |
Update the test slightly to use the rig it inspired.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
XML Parser uses `scala.xml.PCData`.
A compiler flag `-Yxml:coalescing`, analogous to
`DocumentBuilderFactory.setCoalescing`, turns `PCData`
nodes into `Text` nodes and coalesces sibling text nodes.
This change also fixes parse errors such as rejecting a
sequence of CDATA sections.
A sequence of "top level" nodes are not coalesced.
```
scala> <a><b/>start<![CDATA[hi & bye]]><c/>world<d/>stuff<![CDATA[red & black]]></a>
res0: scala.xml.Elem = <a><b/>start<![CDATA[hi & bye]]><c/>world<d/>stuff<![CDATA[red & black]]></a>
scala> :replay -Yxml:coalescing
Replaying: <a><b/>start<![CDATA[hi & bye]]><c/>world<d/>stuff<![CDATA[red & black]]></a>
res0: scala.xml.Elem = <a><b/>starthi & bye<c/>world<d/>stuffred & black</a>
```
|
| | |\ \ \
| | | | |
| | | | | |
SI-7741: Be more tolerant of absent inner classfiles and non-Scala interface members
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
1. Avoid forcing info of non-Scala interface members
This avoids parsing the ostensibly malformed class definitions that
correspond to a Groovy lambda defined in an interface.
2. Be more tolerant of absent inner classfiles
Taking a leaf out of javac's book (see transcript below),
we can use stub symbols for InnerClass entries that don't
have corresponding class files on the compilation classpath.
This will limit failures to code that directly refers to the
inner class, rather than any code that simply refers to the
enclosing class.
It seems that groovyc has a habit of emitting incongrous
bytecode in this regard. But this change seems generally
useful.
```
% cat sandbox/{Test,Client}.java
public class Test {
public class Inner {}
}
public class Client {
public Test.Inner x() { return null; }
}
% javac -d . sandbox/Test.java && javac -classpath . sandbox/Client.java
% javac -d . sandbox/Test.java && rm 'Test$Inner.class' && javac -classpath . sandbox/Client.java
sandbox/Client.java:2: error: cannot access Inner
public Test.Inner x() { return null; }
^
class file for Test$Inner not found
1 error
% cat sandbox/{Test,Client}.java
public class Test {
public class Inner {}
}
public class Client {
public Test.NeverExisted x() { return null; }
}
% javac -classpath . sandbox/Client.java
sandbox/Client.java:2: error: cannot find symbol
public Test.NeverExisted x() { return null; }
^
symbol: class NeverExisted
location: class Test
1 error
% cat sandbox/{Test,Client}.java
public class Test {
public class Inner {}
}
public class Client {
public Test x() { return null; }
}
topic/groovy-interop ~/code/scala2 javac -d . sandbox/Test.java && rm 'Test$Inner.class' && javac -classpath . sandbox/Client.java # allowed
```
|
| |\| | | | |
|
| | |\ \ \ \
| | |_|/ /
| |/| | | |
SI-9252 gets rid of custom logic for jArrayClass in runtime reflection
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Apparently, I've already fixed a very similar issue two years ago.
That was a fun surprise! (https://issues.scala-lang.org/browse/SI-5680)
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | | |
This behavior is confusing and also problematic for writing partest
tests: CI passes -optimize, which negates the -Ybackend:GenBCode entry
in a flags file.
|
| |\| | | |
|
| | |\ \ \
| | | | |
| | | | | |
SI-9182 Fix runtime reflection with package object, overloads
|
| | | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Eponymous modules and methods should be allowed to live in the
same package scope. This can happen when using a module and
and implicit class, or when defining the overloads manually.
This commit tones back an assertion that was added for sanity checking
runtime reflection thread safety to only fire when we are sure that
neither the existing and current symbol of the given name are methods.
|
| | |\ \ \
| | | | |
| | | | | |
SI-9170 More flexible SessionTest
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
SessionTest session text can include line continuations
and pasted text. Pasted script (which looks like a
double prompt) probably doesn't work.
This commit includes @retronym's SI-9170 one-liner.
|
| |\| | | | |
|
| | |\ \ \ \
| | | | | |
| | | | | | |
SI-9102: Reflect method invoke with mixed args
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Cover the second use case reported on the ML (ctors).
Improve formatting per the review. And it really does look
a lot better.
|
| | | | |/ /
| | |/| |
| | | | |
| | | | |
| | | | |
| | | | | |
A missing default branch when a method had value class
or by-name params caused other args to present as null
under reflective invocation.
|
| | |\ \ \ \
| | | | | |
| | | | | | |
SI-9219 Stream toString returns unexpected result
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- Cursor was not advanced before appending the second element
when only the first two elements of the stream were known.
- When there is no cycle in the stream, the "scout" (and
"cursor") ends up pointing to a stream where tailDefined
is false. This means that cursor is either empty, or
cursor.tail is not yet evaluated. The former case is handled
properly, but in the latter case, one more element
(cursor.head) needs to be appended.
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
Inliner for GenBCode
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Issue precise warnings when the inliner fails to inline or analyze a
callsite. Inline failures may have various causes, for example because
some class cannot be found on the classpath when building the call
graph. So we need to store problems that happen early in the optimizer
(when building the necessary data structures, call graph, ClassBTypes)
to be able to report them later in case the inliner accesses the
related data.
We use Either to store these warning messages. The commit introduces
an implicit class `RightBiasedEither` to make Either easier to use for
error propagation. This would be subsumed by a biased either in the
standard library (or could use a Validation).
The `info` of each ClassBType is now an Either. There are two cases
where the info is not available:
- The type info should be parsed from a classfile, but the class
cannot be found on the classpath
- SI-9111, the type of a Java source originating class symbol cannot
be completed
This means that the operations on ClassBType that query the info now
return an Either, too.
Each Callsite in the call graph now stores the source position of the
call instruction. Since the call graph is built after code generation,
we build a map from invocation nodes to positions during code gen and
query it when building the call graph.
The new inliner can report a large number of precise warnings when a
callsite cannot be inlined, or if the inlining metadata cannot be
computed precisely, for example due to a missing classfile.
The new -Yopt-warnings multi-choice option allows configuring inliner
warnings.
By default (no option provided), a one-line summary is issued in case
there were callsites annotated @inline that could not be inlined.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
In mixed compilation, the bytecode of Java classes is not availalbe:
the Scala compiler does not produce any, and there are no classfiles
yet.
When inlining a (Scala defined) method that contains an invocation to
a Java method, we need the Java method's bytecode in order to check
whether that invocation can be transplanted to the new location
without causing an IllegalAccessError. If the bytecode cannot be
found, inlining won't be allowed.
|
| | | |/ / / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Usually, the compiler tries avoids creating a field in a subclass
for a constructor parameter that is known to be stored in a field
in one of its superclasses.
However, in the enclosed test `run/t9223.scala`, this mechanism
confuses `=> A` with `A`, which results in a runtime
`ClassCastException`.
This commit avoids using param aliases for by-name parameters.
I have also added a test for something close the opposite case, where
the subclass has a strict parameter and the superclass has a by-name
parameter. This was working correctly before this patch.
|
| | |\| | | |
| | |/ / /
| |/| | | |
Emit the ScalaInlineInfo attribute under GenASM
|
| | | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The goal of this commit is to allow the new inliner (in GenBCode,
coming soon) to inline methods generated by the GenASM backend of
2.11.6.
The ScalaInlineInfo attribute is added to every classfile generated
by GenASM. It contains metadata about the class and its methods that
will be used by the new inliner.
Storing this metadata to the classfile prevents the need to look up a
class symbol for a certain class file name, a process that is known to
be brittle due to name mangling. Also, some symbols are not exactly
the same when originating in a class being compiled or an unpickled
one. For example, method symbols for mixed-in members are only added
to classes being compiled.
The classfile attribute is relatively small, because all strings it
references (class internal names, method names, method descriptors)
would exist anyway in the constant pool. It just adds a few references
and bits for each method in the classfile.
Jar sizes before:
480142 scala-actors.jar
15531408 scala-compiler.jar
5543249 scala-library.jar
4663078 scala-reflect.jar
785953 scalap.jar
After:
490491 scala-actors.jar (102.1%)
15865500 scala-compiler.jar (102.1%)
5722504 scala-library.jar (103.2%)
4788370 scala-reflect.jar (102.7%)
805890 scalap.jar (102.5%)
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Initial implementation of pluginsEnterStats was incorrect, because I got
the foldLeft wrong, making it perpetuate the initial value of stats.
This worked fine if zero or one macro plugins were active at a time,
but broke down if there were multiple of such plugins (concretely,
I discovered this issue when trying to marry macro paradise with scalahost).
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
Now both of the overloaded variants have a parameter list.
This seems to make type inference happier. Or it makes someone
happier.
The user is unaware whether `subsets()` takes a default arg.
But happily, empty application still kicks in.
|
| | |\
| | |
| | | |
SI-9097 Remove spurious warning about conflicting filenames
|
| | | |
| | |
| | |
| | | |
`pos` test is subsumed by `run`.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When using delambdafy:method, closure classes are generated late.
The class is added to a map and integrated into the PackageDef in
transformStats.
When declaring a package object, there are potentially multiple
PackageDefs for the same package. In this case, the closure class
was added to all of them. As a result, GenASM / GenBCode would run
multiple times on the closure class. In GenBCode this would trigger
a warning about conflicting filenames.
|
| | |\ \
| | | |
| | | | |
SI-6502 More robust REPL :require
|
| | | | |
| | | |
| | | |
| | | | |
This saves a check file in the crowded test directory.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- handle missing files gracefully (rather than NPE)
- read the class name with ASM, rather than with a dummy
classloader. The dummy classloader is prone to throwing
`LinkageError`s, as reported in the comments of SI-6502.
Manual test of the original report:
```
% qscala
Welcome to Scala version 2.11.5-20150115-183424-155dbf3fdf (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_25).
Type in expressions to have them evaluated.
Type :help for more information.
scala> :require does/not/exist
Cannot read: does/not/exist
scala> classOf[org.junit.Test]
<console>:8: error: object junit is not a member of package org
classOf[org.junit.Test]
^
scala> :require /Users/jason/.m2/repository/junit/junit/4.11/junit-4.11.jar
Added '/Users/jason/.m2/repository/junit/junit/4.11/junit-4.11.jar' to classpath.
scala> classOf[org.junit.Test]
res1: Class[org.junit.Test] = interface org.junit.Test
```
I have commited an automated test that is a minimization of this one.
|
| | |\ \ \
| | |_|/
| |/| | |
SI-7770 mutable.BitSet.toImmutable isn't immutable
|
