| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some extra synthetic code generated under this mode failed to escape
input before adding it to a literal string. It used to get away with
this most of the time by triple quoting the literal.
This commit reuses Scala string escaping logic buried in `Constant`
to do this properly. Actually, the proper approach would be to build
the synthetic code with trees and quasiquotes, and avoid the mess
of stringly-genererated code.
I threw in some defensive hygiene for the reference to `Nil` while
I was in the neighbourhood.
|
|
|
|
| |
Since it's a private method, it's safe to just rename it.
|
| |
|
|\
| |
| | |
Revert "SI-8346 Rebuild invariant sets in #toSet, avoiding CCE"
|
| | |
|
|\ \
| | |
| | | |
Fix documentation of Stream.filter introduced in 13f30c
|
| |/ |
|
|/ |
|
|\
| |
| | |
Improved error message for "filename too long" build errors
|
| |
| |
| |
| |
| |
| |
| |
| | |
When building on ecryptfs filenames can be limited to ~142 characters.
This limit doesn't take long to hit and can leave the the user with a
hard to diagnosis error message. Some legacy file systems will have
similarly small limits. This just adds a hint that the error might
be related to the underlying fs.
|
|\ \
| | |
| | | |
Fix tracing of implicit search under -Ytyper-debug
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The log messages intented to chronicle implicit search were
always being filtered out by virtue of the fact that the the tree
passed to `printTyping` was already typed, (e.g. with an implicit
MethodType.)
This commit enabled printing in this case, although it still
filters out trees that are deemed unfit for typer tracing,
such as `()`. In the context of implicit search, this happens
to filter out the noise of:
```
| | | [search #2] start `()`, searching for adaptation to pt=Unit => Foo[Int,Int] (silent: value <local Test> in Test) implicits disabled
| | | [search #3] start `()`, searching for adaptation to pt=(=> Unit) => Foo[Int,Int] (silent: value <local Test> in Test) implicits disabled
| | | \-> <error>
```
... which I think is desirable.
The motivation for this fix was to better display the interaction
between implicit search and type inference. For instance:
```
class Foo[A, B]
class Test {
implicit val f: Foo[Int, String] = ???
def t[A, B](a: A)(implicit f: Foo[A, B]) = ???
t(1)
}
```
````
% scalac -Ytyper-debug sandbox/instantiate.scala
...
| |-- t(1) BYVALmode-EXPRmode (site: value <local Test> in Test)
| | |-- t BYVALmode-EXPRmode-FUNmode-POLYmode (silent: value <local Test> in Test)
| | | [adapt] [A, B](a: A)(implicit f: Foo[A,B])Nothing adapted to [A, B](a: A)(implicit f: Foo[A,B])Nothing
| | | \-> (a: A)(implicit f: Foo[A,B])Nothing
| | |-- 1 BYVALmode-EXPRmode-POLYmode (site: value <local Test> in Test)
| | | \-> Int(1)
| | solving for (A: ?A, B: ?B)
| | solving for (B: ?B)
| | [search #1] start `[A, B](a: A)(implicit f: Foo[A,B])Nothing` inferring type B, searching for adaptation to pt=Foo[Int,B] (silent: value <local Test> in Test) implicits disabled
| | [search #1] considering f
| | [adapt] f adapted to => Foo[Int,String] based on pt Foo[Int,B]
| | [search #1] solve tvars=?B, tvars.constr= >: String <: String
| | solving for (B: ?B)
| | [search #1] success inferred value of type Foo[Int,=?String] is SearchResult(Test.this.f, TreeTypeSubstituter(List(type B),List(String)))
| | |-- [A, B](a: A)(implicit f: Foo[A,B])Nothing BYVALmode-EXPRmode (site: value <local Test> in Test)
| | | \-> Nothing
| | [adapt] [A, B](a: A)(implicit f: Foo[A,B])Nothing adapted to [A, B](a: A)(implicit f: Foo[A,B])Nothing
| | \-> Nothing
```
|
|\ \ \
| | | |
| | | | |
Fix the bug in the example in scala.sys.process
|
| | | | |
|
| | | |
| | | |
| | | | |
There's no `!` method with argument type `ProcessIO`. I suppose this is intended to be `run`.
|
|\ \ \ \
| | | | |
| | | | | |
SI-8362: AbstractPromise extends AtomicReference, avoids sun.misc.Unsafe
|
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
To avoid `sun.misc.Unsafe`, which is not supported on Google App Engine.
Deprecate `AbstractPromise` --> extend `j.u.c.atomic.AtomicReference` directly.
`AtomicReference.compareAndSet()` should also provide better performance on
HotSpot, which compiles it down to the machine's CAS instruction.
The binary incompatible change is ok because it's in an internal package.
I can't think of any real issue with adding a superclass (which contributes
only final methods) to a class in an implementation package (as long as
those methods were not introduced in any illicit subclasses of said class).
Instead of changing `DefaultPromise`'s super class, let's be more
conservative, and do it closest to the source. This is both clearer and more
focussed, leaving those subclasses of AbstractPromise we never heard of
unaffected.
Genesis of the commit: since the work on `Future` performance, `AbstractPromise`
is using `Unsafe`, breaking the ability for `Future` to be executed on GAE. At
that time, viktorklang suggested to implement a fallback in case `Unsafe` is
not available. carey proposed an implementation, and mchv submitted a patch,
which was refined by adriaanm.
|
|\ \ \ \
| | | | |
| | | | | |
SI-1931 Hide Predef.any2stringadd in REPL
|
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
User imports that reference Predef are relocated to the top of
the wrapping template so that they can hide implicits defined
in Predef.
Only one import from Predef is retained for special treatment.
This is simple and sane. The test shows that `import Predef._`
restores Predef implicits even if a user-defined term would
normally be in scope.
A smart `:import` command to turn off or quarantine imports explicitly
would allow fine-grained control.
|
|\ \ \ \
| | | | |
| | | | | |
ScalaDoc fixes for compiler
|
| | |/ /
| |/| | |
|
|\ \ \ \
| | | | |
| | | | | |
SI-9425 Leave Companion.apply if constructor is less accessible
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Calls to synthetic case class apply methods are inlined to the
underlying constructor invocation in refchecks.
However, this can lead to accessibility errors if the constructor
is private.
This commit ensures that the constructor is at least as accessible
as the apply method before performing this tranform.
I've manually checked that other the optimization still works in other
cases:
scala> class CaseApply { Some(42) }
defined class CaseApply
scala> :javap -c CaseApply
Compiled from "<console>"
public class CaseApply {
public CaseApply();
Code:
0: aload_0
1: invokespecial #9 // Method java/lang/Object."<init>":()V
4: new #11 // class scala/Some
7: dup
8: bipush 42
10: invokestatic #17 // Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
13: invokespecial #20 // Method scala/Some."<init>":(Ljava/lang/Object;)V
16: pop
17: return
}
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Stop mapping to Unit when executing finally code.
|
| | |_|_|/
| |/| | |
| | | | |
| | | | | |
Finally.invoke has result type Unit so foreach is sufficient here.
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Using length instead of size on String to avoid a conversion call.
This dump confirms there is a conversion to StringOps when using size.
object StringSize {
val s = "hi"
println(s.size)
}
$ scalac -Xprint:typer StringSize.scala
[[syntax trees at end of typer]] // StringSize.scala
package <empty> {
object StringSize extends scala.AnyRef {
def <init>(): StringSize.type = {
StringSize.super.<init>();
()
};
private[this] val s: String = "hi";
<stable> <accessor> def s: String = StringSize.this.s;
scala.this.Predef.println(scala.this.Predef.augmentString(StringSize.this.s).size)
}
}
|
| |/ /
|/| |
| | |
| | |
| | | |
Option(null) is None while Option(v) is Some(v) which makes the null
test redundant.
|
|\ \ \
| |/ /
|/| | |
SI-9422 Fix incorrect constant propagation
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The ConstantOptimization phase uses abstract interpretation
to track what is known about values, and then to use this information
to optimize away tests with a statically known result.
Constant propagation was added under -optimize in Scala 2.11.0-M3, in
PR #2214.
For example, we might know that a variable must hold one of a set
of values (`Possible`). Or, we could track that it must *not*
be of of a set of value (`Impossible`).
The test case in the bug report was enough to create comparison:
v1 == v2 // where V1 = Possible(Set(true, false))
// V2 = Possible(Set(true, false))
This test was considered to be always true, due to a bug in
`Possible#mightNotEqual`. The only time we can be sure that
`Possible(p1) mightNotEquals Possible(p2)` is if
`p1` and `p2` are the same singleton set. This commit changes
this method to implement this logic.
The starting assumption for all values is currently
`Impossible(Set())`, although it would also be reasonable to represent
an unknown boolean variable as `Possible(Set(true, false))`, given
the finite and small domain.
I tried to change the starting assumption for boolean locals in
exactly this manner, and that brings the bug into sharp focus.
Under this patch:
https://github.com/retronym/scala/commit/e564fe522d
This code:
def test(a: Boolean, b: Boolean) = a == b
Compiles to:
public boolean test(boolean, boolean);
Code:
0: iconst_1
1: ireturn
Note: the enclosed test case does not list `-optimize` in a `.flags`
file, I'm relying on that being passed in by the validation build.
I've tested locally with that option, though.
|
|\ \ \
| | | |
| | | | |
ScalaDoc fixes for reflect
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | | |
ScalaDoc fixes for library and library-aux
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
SI-9365 Don't null out dependencies of transient lazy vals
|
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As per Iulian's analysis:
> When lazy vals are transient, the optimization in SI-720 is invalid,
> leading to NPEs.
These NPEs appear when recomputing the lazy val when deserializaing
the object.
This commit disables the field nulling if the lazy val is marked
transient.
The post-mixin tree in the enclosed test changes as follows:
```
--- sandbox/old.log 2015-07-27 15:48:03.000000000 +1000
+++ sandbox/new.log 2015-07-27 15:47:56.000000000 +1000
@@ -1,61 +1,54 @@
[[syntax trees at end of mixin]] // t9365.scala
package <empty> {
class Test extends Object with Serializable {
@transient @volatile private[this] var bitmap$trans$0: Boolean = false;
private def foo$lzycompute(): Object = {
{
Test.this.synchronized({
if (Test.this.bitmap$trans$0.unary_!())
{
Test.this.foo = Test.this.x.apply();
Test.this.bitmap$trans$0 = true;
()
};
scala.runtime.BoxedUnit.UNIT
});
- Test.this.x = null
+ ()
};
Test.this.foo
};
```
In addition to the test from the ticket, I've added a reflection
based test that directly tests the nulling. This complements the
test added in 449f2a7473, the fix for SI-720, which passes by
virtue of not exhausting the heap.
|
| |/ /
|/| | |
|
|\ \ \
| | | |
| | | | |
SI-9403 fix ICodeReader for negative BIPUSH / SIPUSH values
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The byte value of a BIPUSH instruction and the (byte1 << 8) | byte2
value of a SIPUSH instruction are signed, see [1] and [2].
Similar for the increment value of IINC [3].
[1] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.bipush
[2] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.sipush
[3] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.iinc
|
| | |
| | |
| | |
| | |
| | | |
Similar to the new JAVA_ANNOTATION flag, be more explicit about flags
for java entities.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The Scala classfile and java source parsers make Java annotation
classes (which are actually interfaces at the classfile level) look
like Scala annotation classes:
- the INTERFACE / ABSTRACT flags are not added
- scala.annotation.Annotation is added as superclass
- scala.annotation.ClassfileAnnotation is added as interface
This makes type-checking @Annot uniform, whether it is defined in Java
or Scala.
This is a hack that leads to various bugs (SI-9393, SI-9400). Instead
the type-checking should be special-cased for Java annotations.
This commit fixes SI-9393 and a part of SI-9400, but it's still easy
to generate invalid classfiles. Restores the assertions that were
disabled in #4621. I'd like to leave these assertions in: they
are valuable and helped uncovering the issue being fixed here.
A new flag JAVA_ANNOTATION is introduced for Java annotation
ClassSymbols, similar to the existing ENUM flag. When building
ClassBTypes for Java annotations, the flags, superclass and interfaces
are recovered to represent the situation in the classfile.
Cleans up and documents the flags space in the area of "late" and
"anti" flags.
The test for SI-9393 is extended to test both the classfile and the
java source parser.
|
| | |
| | |
| | |
| | | |
Fixes the stability regression introduced by #4619.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A macro in shapeless was generating a tree of the form:
```
{
class C#2
new C#2
}.setType(C#1)
```
This happened due to an error in the macro; it used untypecheck
to try to fix the owner-chain consistency problem, but kept a
reference to the previous version of the block-local class symbol
`C` and used this in the resulting tree.
This commit detects the particular situation we encountered, and
avoids the crash by not creating the `NestedInfo` for the
`BType` corresponding to `C#1`. The code comment discusses why I
think this is safe, and suggests a refactoring that would mean
we only ever try to construct `NestedInfo` when we are going to
need them.
|
| | |
| | |
| | |
| | |
| | |
| | | |
These cause a crash in the build of Play. We should try to bring
these back once we have suitable annotation awareness. Perhaps
they should only be `devWarning`-s, though.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Refactor and clean up the ClosureOptimzier. The goal of this change
is to run the ProdCons analyzer only once per method, instead of
once per closure instantiation.
Bootstrapping scala with `-Yopt-inline-heuristics:everything` revealed
that ProdCons can take a very long time on large methods, for example
```
[quick.compiler] scala/tools/nsc/backend/jvm/BCodeBodyBuilder$PlainBodyBuilder#genArithmeticOp - analysis: 1 spans, 17755ms
[quick.compiler] scala/tools/nsc/typechecker/SuperAccessors$SuperAccTransformer#transform - analysis: 1 spans, 28024ms
[quick.compiler] scala/tools/nsc/backend/jvm/BCodeBodyBuilder$PlainBodyBuilder#genInvokeDynamicLambda - analysis: 1 spans, 22100ms
```
With this change and enough time and space (-Xmx6000m), bootstrapping
scala succeeds in this test mode.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As with regular `Apply`-s, we should compute the generated type
based on the function's type, rather than the expected type.
In the test case, the expected type was void. Now, we correctly
use the generated type of `scala/Function1`, which is enough
to generate a subsequent POP instruction.
The tree shape involved was:
```
arg0 = {
{
$anonfun()
};
scala.runtime.BoxedUnit.UNIT
}
```
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Introduces an extractor `LMFInvokeDynamic` that matches InvokeDynamic
instructions that are LambdaMetaFactory calls.
The case class `LambdaMetaFactoryCall` holds such an InvokeDynamic
instruction. It also holds the bootstrap arguments (samMethodType,
implMethod, instantiatedMethodType) so that they can be accessed
without casting the indy.bsmArgs.
The `closureInstantiations` map in the call graph now stores
ClosureInstantiation objects instead of a tuple.
This simplifies some code and gets rid of a few casts.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Implements the necessary tests to check if a method with an
InvokeDynamic instruction can be inlined into a destination class.
Only InvokeDynamic instructions with LambdaMetaFactory as bootstrap
methods can be inlined. The accessibility checks cannot be implemented
generically, because it depends on what the bootstrap method is doing.
In particular, the bootstrap method receives a Lookup object as
argument which can be used to access private methods of the class
where the InvokeDynamic method is located.
A comment in the inliner explains the details.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When there are multiple closure allocations and invocations in the
same method, ensure that the callsites are re-written to the body
methods in a consistent order. Otherwsie the bytecode is not stable
(the local variable indices depend on the order in which the calls
are re-written)
|