New ci #18
Closed
New ci #18
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The enclosed test case stopped working in 2.11.5 on the back of scala#4040. The key change was that we ran all post-typer info transformers on each run of the compiler, rather than trying to reuse the results of the previous run. In that patch, I noticed one place [1] in specialization that aggressively entered specialized members into the owning scope, rather than relying on `transformInfo` to place the new members in the scope of the newly created element of the info history. I made that change after noticing that this code could actually mutated scopes of specializaed types at the parser phase, which led to fairly obscure failures. This bug is another one of these obscure failures, and has the same root cause. We effectively "double specialiaze" Function0, which trips an assertion when `method apply$mcI$sp` is found twice in a scope. I have found another spot that was directly manipulating the scope, and removed the offending code. [1] scala#4040 (comment)
SI-9089 Another REPL/FSC + specialization bug fix
Each ClassBType is identified by its internalName, the fully qualified JVM class name. Before this change, the name was stored in the `chrs` array of the compiler name table (hash consed), with the idea to avoid materializing the string. However, we materialize the string anyway, because each ClassBType is stored in the classBTypeFromInternalNameMap, indexed by the string. If string equality turns out to be too slow we can use interning. For the inliner, we read classes from bytecode and create ClassBTypes for them. The names of these classes would not yet exist in the name table, so the backend would need to be able to create new names. Using Strings removes this dependency.
There's already the map classBTypeFromInternalNameMap in BTypes which stores all ClassBTypes.
Introduces methods for textifying classes, methods, InsnLists and individual AbstractInsnNodes.
This infrastructure is required for the inliner: when inlining code
from a classfile, the corresponding ClassBType is needed for various
things (eg access checks, InnerClass attribute).
The test creates two ClassBTypes for the same class: once using the
(unpickled) Symbol, once using the parsed ASM ClassNode, and verifies
that the two are the same.
There's a cleanup to the InnerClass attribute:
object T { class Member; def foo = { class Local } }
class T
For Java compatibility the InnerClass entry for Member says the class
is nested in T (not in the module class T$). We now make sure to add
that entry only to T, not to T$ (unless Member is actually referenced
in the classfile T$, in that case it will be added, as required).
- Rename CodeRepository to ByteCodeRepository - Scaladoc on OptimizerReporting - Scaladoc on ByteCodeRepository
Construct ClassBTypes from parsed classfiles
2.11.5 bump
SI-9087 Fix min/max of reversed Double/Float orderings
|
PLS SYNCH |
cunei
pushed a commit
to cunei/scala
that referenced
this pull request
May 19, 2015
In Scala 2.8.2, an optimization was added to create a static
cache for Symbol literals (ie, the results of `Symbol.apply("foo"))`.
This saves the map lookup on the second pass through code.
This actually was broken somewhere during the Scala 2.10 series,
after the addition of an overloaded `apply` method to `Symbol`.
The cache synthesis code was made aware of the overload and brought
back to working condition recently, in scala#3149.
However, this has uncovered a latent bug when the Symbol literals are
defined with traits.
One of the enclosed tests failed with:
jvm > t8933b-run.log
java.lang.IllegalAccessError: tried to access field MotherClass.symbol$1 from class MixinWithSymbol$class
at MixinWithSymbol$class.symbolFromTrait(A.scala:3)
at MotherClass.symbolFromTrait(Test.scala:1)
This commit simply disables the optimization if we are in a trait.
Alternative fixes might be: a) make the static Symbol cache field
public / b) "mixin" the static symbol cache. Neither of these
seem worth the effort and risk for an already fairly situational
optimization.
Here's how the optimization looks in a class:
% cat sandbox/test.scala; qscalac sandbox/test.scala && echo ":javap C" | qscala;
class C {
'a; 'b
}
Welcome to Scala version 2.11.5-20141106-145558-aa558dce6d (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_20).
Type in expressions to have them evaluated.
Type :help for more information.
scala> :javap C
Size 722 bytes
MD5 checksum 6bb00189166917254e8d40499ee7c887
Compiled from "test.scala"
public class C
{
public static {};
descriptor: ()V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=0, args_size=0
0: getstatic adriaanm#16 // Field scala/Symbol$.MODULE$:Lscala/Symbol$;
3: ldc adriaanm#18 // String a
5: invokevirtual adriaanm#22 // Method scala/Symbol$.apply:(Ljava/lang/String;)Lscala/Symbol;
8: putstatic adriaanm#26 // Field symbol$1:Lscala/Symbol;
11: getstatic adriaanm#16 // Field scala/Symbol$.MODULE$:Lscala/Symbol$;
14: ldc scala#28 // String b
16: invokevirtual adriaanm#22 // Method scala/Symbol$.apply:(Ljava/lang/String;)Lscala/Symbol;
19: putstatic scala#31 // Field symbol$2:Lscala/Symbol;
22: return
public C();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokespecial scala#34 // Method java/lang/Object."<init>":()V
4: getstatic adriaanm#26 // Field symbol$1:Lscala/Symbol;
7: pop
8: getstatic scala#31 // Field symbol$2:Lscala/Symbol;
11: pop
12: return
}
fixup
cunei
pushed a commit
to cunei/scala
that referenced
this pull request
May 19, 2015
These methods are "signature polymorphic", which means that compiler
should not:
1. adapt the arguments to `Object`
2. wrap the repeated parameters in an array
3. adapt the result type to `Object`, but instead treat it as it
it already conforms to the expected type.
Dispiritingly, my initial attempt to implement this touched the type
checker, uncurry, erasure, and the backend.
However, I realized we could centralize handling of this in the typer
if at each application we substituted the signature polymorphic
symbol with a clone that carried its implied signature, which is
derived from the types of the arguments (typechecked without an
expected type) and position within and enclosing cast or block.
The test case requires Java 7+ to compile so is currently embedded
in a conditionally compiled block of code in a run test.
We ought to create a partest category for modern JVMs so we can
write such tests in a more natural style.
Here's how this looks in bytecode. Note the `bipush` / `istore`
before/after the invocation of `invokeExact`, and the descriptor
`(LO$;I)I`.
```
% cat sandbox/poly-sig.scala && qscala Test && echo ':javap Test$#main' | qscala
import java.lang.invoke._
object O {
def bar(x: Int): Int = -x
}
object Test {
def main(args: Array[String]): Unit = {
def lookup(name: String, params: Array[Class[_]], ret: Class[_]) = {
val lookup = java.lang.invoke.MethodHandles.lookup
val mt = MethodType.methodType(ret, params)
lookup.findVirtual(O.getClass, name, mt)
}
def lookupBar = lookup("bar", Array(classOf[Int]), classOf[Int])
val barResult: Int = lookupBar.invokeExact(O, 42)
()
}
}
scala> :javap Test$#main
public void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC
Code:
stack=3, locals=3, args_size=2
0: aload_0
1: invokespecial adriaanm#18 // Method lookupBar$1:()Ljava/lang/invoke/MethodHandle;
4: getstatic adriaanm#23 // Field O$.MODULE$:LO$;
7: bipush 42
9: invokevirtual scala#29 // Method java/lang/invoke/MethodHandle.invokeExact:(LO$;I)I
12: istore_2
13: return
LocalVariableTable:
Start Length Slot Name Signature
0 14 0 this LTest$;
0 14 1 args [Ljava/lang/String;
13 0 2 barResult I
LineNumberTable:
line 16: 0
}
```
I've run this test across our active JVMs:
```
% for v in 1.6 1.7 1.8; do java_use $v; pt --terse test/files/run/t7965.scala || break; done
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)
Selected 1 tests drawn from specified tests
.
1/1 passed (elapsed time: 00:00:02)
Test Run PASSED
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
Selected 1 tests drawn from specified tests
.
1/1 passed (elapsed time: 00:00:07)
Test Run PASSED
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
Selected 1 tests drawn from specified tests
.
1/1 passed (elapsed time: 00:00:05)
Test Run PASSED
```
adriaanm
pushed a commit
that referenced
this pull request
Aug 3, 2015
And do the same for the specialized variants.
Tested by a Java source file that uses lambda syntax to create
instances of generic and specialized `Function{0,1}`.
Here's how the interfaces look now:
```
% javap -c -classpath /tmp/function 'scala.Function1'
Compiled from "Function1.scala"
public interface scala.Function1<T1, R> {
public abstract R apply(T1);
public <A> scala.Function1<A, R> compose(scala.Function1<A, T1>);
Code:
0: aload_0
1: aload_1
2: invokestatic #18 // Method scala/Function1$class.compose:(Lscala/Function1;Lscala/Function1;)Lscala/Function1;
5: areturn
public <A> scala.Function1<T1, A> andThen(scala.Function1<R, A>);
Code:
0: aload_0
1: aload_1
2: invokestatic #24 // Method scala/Function1$class.andThen:(Lscala/Function1;Lscala/Function1;)Lscala/Function1;
5: areturn
public abstract java.lang.String toString();
public int apply$mcII$sp(int);
Code:
0: aload_0
1: iload_1
2: invokestatic scala#110 // Method scala/Function1$class.apply$mcII$sp:(Lscala/Function1;I)I
5: ireturn
public long apply$mcJI$sp(int);
Code:
0: aload_0
1: iload_1
2: invokestatic scala#115 // Method scala/Function1$class.apply$mcJI$sp:(Lscala/Function1;I)J
5: lreturn
...
}
% javap -c -classpath /tmp/function 'scala.Function1$mcII$sp'
Compiled from "Function1.scala"
public interface scala.Function1$mcII$sp extends scala.Function1<java.lang.Object, java.lang.Object> {
public java.lang.Object apply(java.lang.Object);
Code:
0: aload_0
1: aload_1
2: invokestatic #16 // Method scala/runtime/BoxesRunTime.unboxToInt:(Ljava/lang/Object;)I
5: invokeinterface #19, 2 // InterfaceMethod apply:(I)I
10: invokestatic #23 // Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
13: areturn
public abstract int apply$mcII$sp(int);
public int apply(int);
Code:
0: aload_0
1: iload_1
2: invokeinterface scala#30, 2 // InterfaceMethod apply$mcII$sp:(I)I
7: ireturn
}
```
adriaanm
pushed a commit
that referenced
this pull request
Aug 8, 2015
And do the same for the specialized variants.
Tested by a Java source file that uses lambda syntax to create
instances of generic and specialized `Function{0,1}`.
Here's how the interfaces look now:
```
% javap -c -classpath /tmp/function 'scala.Function1'
Compiled from "Function1.scala"
public interface scala.Function1<T1, R> {
public abstract R apply(T1);
public <A> scala.Function1<A, R> compose(scala.Function1<A, T1>);
Code:
0: aload_0
1: aload_1
2: invokestatic #18 // Method scala/Function1$class.compose:(Lscala/Function1;Lscala/Function1;)Lscala/Function1;
5: areturn
public <A> scala.Function1<T1, A> andThen(scala.Function1<R, A>);
Code:
0: aload_0
1: aload_1
2: invokestatic #24 // Method scala/Function1$class.andThen:(Lscala/Function1;Lscala/Function1;)Lscala/Function1;
5: areturn
public abstract java.lang.String toString();
public int apply$mcII$sp(int);
Code:
0: aload_0
1: iload_1
2: invokestatic scala#110 // Method scala/Function1$class.apply$mcII$sp:(Lscala/Function1;I)I
5: ireturn
public long apply$mcJI$sp(int);
Code:
0: aload_0
1: iload_1
2: invokestatic scala#115 // Method scala/Function1$class.apply$mcJI$sp:(Lscala/Function1;I)J
5: lreturn
...
}
% javap -c -classpath /tmp/function 'scala.Function1$mcII$sp'
Compiled from "Function1.scala"
public interface scala.Function1$mcII$sp extends scala.Function1<java.lang.Object, java.lang.Object> {
public java.lang.Object apply(java.lang.Object);
Code:
0: aload_0
1: aload_1
2: invokestatic #16 // Method scala/runtime/BoxesRunTime.unboxToInt:(Ljava/lang/Object;)I
5: invokeinterface #19, 2 // InterfaceMethod apply:(I)I
10: invokestatic #23 // Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
13: areturn
public abstract int apply$mcII$sp(int);
public int apply(int);
Code:
0: aload_0
1: iload_1
2: invokeinterface scala#30, 2 // InterfaceMethod apply$mcII$sp:(I)I
7: ireturn
}
```
adriaanm
pushed a commit
that referenced
this pull request
Sep 2, 2015
And do the same for the specialized variants.
Tested by a Java source file that uses lambda syntax to create
instances of generic and specialized `Function{0,1}`.
Here's how the interfaces look now:
```
% javap -c -classpath /tmp/function 'scala.Function1'
Compiled from "Function1.scala"
public interface scala.Function1<T1, R> {
public abstract R apply(T1);
public <A> scala.Function1<A, R> compose(scala.Function1<A, T1>);
Code:
0: aload_0
1: aload_1
2: invokestatic #18 // Method scala/Function1$class.compose:(Lscala/Function1;Lscala/Function1;)Lscala/Function1;
5: areturn
public <A> scala.Function1<T1, A> andThen(scala.Function1<R, A>);
Code:
0: aload_0
1: aload_1
2: invokestatic #24 // Method scala/Function1$class.andThen:(Lscala/Function1;Lscala/Function1;)Lscala/Function1;
5: areturn
public abstract java.lang.String toString();
public int apply$mcII$sp(int);
Code:
0: aload_0
1: iload_1
2: invokestatic scala#110 // Method scala/Function1$class.apply$mcII$sp:(Lscala/Function1;I)I
5: ireturn
public long apply$mcJI$sp(int);
Code:
0: aload_0
1: iload_1
2: invokestatic scala#115 // Method scala/Function1$class.apply$mcJI$sp:(Lscala/Function1;I)J
5: lreturn
...
}
% javap -c -classpath /tmp/function 'scala.Function1$mcII$sp'
Compiled from "Function1.scala"
public interface scala.Function1$mcII$sp extends scala.Function1<java.lang.Object, java.lang.Object> {
public java.lang.Object apply(java.lang.Object);
Code:
0: aload_0
1: aload_1
2: invokestatic #16 // Method scala/runtime/BoxesRunTime.unboxToInt:(Ljava/lang/Object;)I
5: invokeinterface #19, 2 // InterfaceMethod apply:(I)I
10: invokestatic #23 // Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
13: areturn
public abstract int apply$mcII$sp(int);
public int apply(int);
Code:
0: aload_0
1: iload_1
2: invokeinterface scala#30, 2 // InterfaceMethod apply$mcII$sp:(I)I
7: ireturn
}
```
SethTisue
pushed a commit
that referenced
this pull request
Apr 25, 2018
Add base traits of collection hierarchy
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.