Fix documentation stutters. #35
Merged
Conversation
This file contains 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
gkossakowski
added a commit
to gkossakowski/scala
that referenced
this pull request
Jan 11, 2012
Scala IDE support
densh
pushed a commit
to densh/scala
that referenced
this pull request
Mar 15, 2013
Fixes tests which were broken by previous commit
som-snytt
added a commit
to som-snytt/scala
that referenced
this pull request
Jul 16, 2013
The REPL :java -app command is a convenience to locate
the body of DelayedInit code. Now it will look for
new style delayedEndpoints on the class before it
falls back to showing the apply method of the
delayedInit$body closure.
```
apm@mara:~/tmp$ skala
Welcome to Scala version 2.11.0-20130711-153246-eb1c3137f5 (OpenJDK 64-Bit Server VM, Java 1.7.0_21).
Type in expressions to have them evaluated.
Type :help for more information.
scala> :javap -pv -app delayed.C
public final void delayedEndpoint$delayed$C$1();
flags: ACC_PUBLIC, ACC_FINAL
Code:
stack=2, locals=1, args_size=1
0: getstatic scala#29 // Field scala/Predef$.MODULE$:Lscala/Predef$;
3: ldc scala#31 // String this is the initialization code of C
5: invokevirtual scala#35 // Method scala/Predef$.println:(Ljava/lang/Object;)V
8: return
LocalVariableTable:
Start Length Slot Name Signature
0 9 0 this Ldelayed/C;
LineNumberTable:
line 11: 0
scala> :q
apm@mara:~/tmp$ rm delayed/*.class
apm@mara:~/tmp$ scalac delayed.scala
apm@mara:~/tmp$ skala
Welcome to Scala version 2.11.0-20130711-153246-eb1c3137f5 (OpenJDK 64-Bit Server VM, Java 1.7.0_21).
Type in expressions to have them evaluated.
Type :help for more information.
scala> :javap -pv -app delayed.C
public final java.lang.Object apply();
flags: ACC_PUBLIC, ACC_FINAL
Code:
stack=2, locals=1, args_size=1
0: getstatic scala#13 // Field scala/Predef$.MODULE$:Lscala/Predef$;
3: ldc scala#15 // String this is the initialization code of C
5: invokevirtual scala#19 // Method scala/Predef$.println:(Ljava/lang/Object;)V
8: getstatic scala#25 // Field scala/runtime/BoxedUnit.UNIT:Lscala/runtime/BoxedUnit;
11: areturn
LocalVariableTable:
Start Length Slot Name Signature
0 12 0 this Ldelayed/C$delayedInit$body;
LineNumberTable:
line 11: 0
line 10: 8
```
retronym
referenced
this pull request
in retronym/scala
Aug 8, 2016
Dmitry learned that we've been relying on a bug in the
verifier that will be fixed in JDK 9 under the new
classfile format.
Assignment to a static final must occur lexically
within the <clinit>. We were performing this assignment
from the constructor of the module class.
I'd like to move the assignment to <clinit> but that would
change behaviour of "benign" cyclic references between modules.
Example:
```
package p1; class CC { def foo = O.bar}; object O {new CC().foo; def bar = println(1)};
// Exiting paste mode, now interpreting.
scala> p1.O
1
```
We currently assign the MODULE$ field after the super class constructors are finished,
but before the rest of the module constructor is called.
```
private p1.O$();
Code:
0: aload_0
1: invokespecial #30 // Method java/lang/Object."<init>":()V
4: aload_0
5: putstatic #32 // Field MODULE$:Lp1/O$;
8: new #34 // class p1/CC
11: dup
12: invokespecial #35 // Method p1/CC."<init>":()V
15: invokevirtual #38 // Method p1/CC.foo:()V
18: return
```
This commit removes the ACC_FINAL bit from the field. It actually wasn't
behaving as final at all, precisely the issue that the stricter verifier
now alerts us to.
```
scala> :paste -raw
// Entering paste mode (ctrl-D to finish)
package p1; object O
// Exiting paste mode, now interpreting.
scala> val O1 = p1.O
O1: p1.O.type = p1.O$@ee7d9f1
scala> scala.reflect.ensureAccessible(p1.O.getClass.getDeclaredConstructor()).newInstance()
res0: p1.O.type = p1.O$@64cee07
scala> O1 eq p1.O
res1: Boolean = false
```
retronym
referenced
this pull request
in retronym/scala
Aug 8, 2016
Dmitry learned that we've been relying on a bug in the
verifier that will be fixed in JDK 9 under the new
classfile format.
Assignment to a static final must occur lexically
within the <clinit>. We were performing this assignment
from the constructor of the module class.
I'd like to move the assignment to <clinit> but that would
change behaviour of "benign" cyclic references between modules.
Example:
```
package p1; class CC { def foo = O.bar}; object O {new CC().foo; def bar = println(1)};
// Exiting paste mode, now interpreting.
scala> p1.O
1
```
We currently assign the MODULE$ field after the super class constructors are finished,
but before the rest of the module constructor is called.
```
private p1.O$();
Code:
0: aload_0
1: invokespecial #30 // Method java/lang/Object."<init>":()V
4: aload_0
5: putstatic #32 // Field MODULE$:Lp1/O$;
8: new #34 // class p1/CC
11: dup
12: invokespecial #35 // Method p1/CC."<init>":()V
15: invokevirtual #38 // Method p1/CC.foo:()V
18: return
```
This commit removes the ACC_FINAL bit from the field. It actually wasn't
behaving as final at all, precisely the issue that the stricter verifier
now alerts us to.
```
scala> :paste -raw
// Entering paste mode (ctrl-D to finish)
package p1; object O
// Exiting paste mode, now interpreting.
scala> val O1 = p1.O
O1: p1.O.type = p1.O$@ee7d9f1
scala> scala.reflect.ensureAccessible(p1.O.getClass.getDeclaredConstructor()).newInstance()
res0: p1.O.type = p1.O$@64cee07
scala> O1 eq p1.O
res1: Boolean = false
```
Fixes scala/scala-dev#SD-194
retronym
referenced
this pull request
in retronym/scala
Aug 8, 2016
Dmitry learned that we've been relying on a bug in the
verifier that will be fixed in JDK 9 under the new
classfile format.
Assignment to a static final must occur lexically
within the <clinit>. We were performing this assignment
from the constructor of the module class.
I'd like to move the assignment to <clinit> but that would
change behaviour of "benign" cyclic references between modules.
Example:
```
package p1; class CC { def foo = O.bar}; object O {new CC().foo; def bar = println(1)};
// Exiting paste mode, now interpreting.
scala> p1.O
1
```
We currently assign the MODULE$ field after the super class constructors are finished,
but before the rest of the module constructor is called.
```
private p1.O$();
Code:
0: aload_0
1: invokespecial #30 // Method java/lang/Object."<init>":()V
4: aload_0
5: putstatic #32 // Field MODULE$:Lp1/O$;
8: new #34 // class p1/CC
11: dup
12: invokespecial #35 // Method p1/CC."<init>":()V
15: invokevirtual #38 // Method p1/CC.foo:()V
18: return
```
This commit removes the ACC_FINAL bit from the field. It actually wasn't
behaving as final at all, precisely the issue that the stricter verifier
now alerts us to.
```
scala> :paste -raw
// Entering paste mode (ctrl-D to finish)
package p1; object O
// Exiting paste mode, now interpreting.
scala> val O1 = p1.O
O1: p1.O.type = p1.O$@ee7d9f1
scala> scala.reflect.ensureAccessible(p1.O.getClass.getDeclaredConstructor()).newInstance()
res0: p1.O.type = p1.O$@64cee07
scala> O1 eq p1.O
res1: Boolean = false
```
Fixes scala/scala-dev#SD-194
retronym
referenced
this pull request
in retronym/scala
Aug 13, 2016
Dmitry learned that we've been relying on a bug in the
verifier that will be fixed in JDK 9 under the new
classfile format.
Assignment to a static final must occur lexically
within the <clinit>. We were performing this assignment
from the constructor of the module class.
I'd like to move the assignment to <clinit> but that would
change behaviour of "benign" cyclic references between modules.
Example:
```
package p1; class CC { def foo = O.bar}; object O {new CC().foo; def bar = println(1)};
// Exiting paste mode, now interpreting.
scala> p1.O
1
```
We currently assign the MODULE$ field after the super class constructors are finished,
but before the rest of the module constructor is called.
```
private p1.O$();
Code:
0: aload_0
1: invokespecial #30 // Method java/lang/Object."<init>":()V
4: aload_0
5: putstatic #32 // Field MODULE$:Lp1/O$;
8: new #34 // class p1/CC
11: dup
12: invokespecial #35 // Method p1/CC."<init>":()V
15: invokevirtual #38 // Method p1/CC.foo:()V
18: return
```
This commit removes the ACC_FINAL bit from the field. It actually wasn't
behaving as final at all, precisely the issue that the stricter verifier
now alerts us to.
```
scala> :paste -raw
// Entering paste mode (ctrl-D to finish)
package p1; object O
// Exiting paste mode, now interpreting.
scala> val O1 = p1.O
O1: p1.O.type = p1.O$@ee7d9f1
scala> scala.reflect.ensureAccessible(p1.O.getClass.getDeclaredConstructor()).newInstance()
res0: p1.O.type = p1.O$@64cee07
scala> O1 eq p1.O
res1: Boolean = false
```
Fixes scala/scala-dev#SD-194
retronym
referenced
this pull request
in retronym/scala
Aug 19, 2016
- Avoid boxing the {Object, Int, ...}Ref itself by storing it in
a val, not a var
- Avoid box/unbox of primitive lazy expressions due which are added
to "adapt" it to the erased type of the fictional syncronized
method, by using a `return`. We have to add a dummy throw after
the synchronized block, but this is elimnated by the always-on
DCE in the code generator.
```
⚡ qscalac -Xprint:mixin $(f "class C { def foo = { lazy val x = 42; x }}"); javap -private -c -cp . C
[[syntax trees at end of mixin]] // a.scala
package <empty> {
class C extends Object {
def foo(): Int = {
lazy <artifact> val x$lzy: scala.runtime.LazyInt = new scala.runtime.LazyInt();
C.this.x$1(x$lzy)
};
final private[this] def x$1(x$lzy$1: scala.runtime.LazyInt): Int = {
x$lzy$1.synchronized({
if (x$lzy$1.initialized().unary_!())
{
x$lzy$1.initialized_=(true);
x$lzy$1.value_=(42)
};
return x$lzy$1.value()
});
throw null
};
def <init>(): C = {
C.super.<init>();
()
}
}
}
Compiled from "a.scala"
public class C {
public int foo();
Code:
0: new #12 // class scala/runtime/LazyInt
3: dup
4: invokespecial #16 // Method scala/runtime/LazyInt."<init>":()V
7: astore_1
8: aload_1
9: invokestatic #20 // Method x$1:(Lscala/runtime/LazyInt;)I
12: ireturn
private static final int x$1(scala.runtime.LazyInt);
Code:
0: aload_0
1: dup
2: astore_1
3: monitorenter
4: aload_0
5: invokevirtual #31 // Method scala/runtime/LazyInt.initialized:()Z
8: ifne 22
11: aload_0
12: iconst_1
13: invokevirtual #35 // Method scala/runtime/LazyInt.initialized_$eq:(Z)V
16: aload_0
17: bipush 42
19: invokevirtual #39 // Method scala/runtime/LazyInt.value_$eq:(I)V
22: aload_0
23: invokevirtual #42 // Method scala/runtime/LazyInt.value:()I
26: istore_2
27: goto 33
30: aload_1
31: monitorexit
32: athrow
33: aload_1
34: monitorexit
35: iload_2
36: ireturn
Exception table:
from to target type
4 30 30 Class java/lang/Throwable
public C();
Code:
0: aload_0
1: invokespecial #43 // Method java/lang/Object."<init>":()V
4: return
}
```
sjrd
pushed a commit
to sjrd/scala
that referenced
this pull request
Aug 19, 2018
Add isExpanded method
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.