scala:2.12.x #20
Closed
scala:2.12.x #20
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
SI-8575 Fix subtyping transitivity with aliases, compound types
SI-8922 REPL load -v
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 #16 // Field scala/Symbol$.MODULE$:Lscala/Symbol$;
3: ldc #18 // String a
5: invokevirtual #22 // Method scala/Symbol$.apply:(Ljava/lang/String;)Lscala/Symbol;
8: putstatic #26 // Field symbol$1:Lscala/Symbol;
11: getstatic #16 // Field scala/Symbol$.MODULE$:Lscala/Symbol$;
14: ldc scala#28 // String b
16: invokevirtual #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 #26 // Field symbol$1:Lscala/Symbol;
7: pop
8: getstatic scala#31 // Field symbol$2:Lscala/Symbol;
11: pop
12: return
}
fixup
A classic mistake of discarding a non-trivial qualifier. We actually should have fixed this before merging scala#3149, as it was raised in review, but I suppose we got too caught up in the difficulty of resolving the right overload of `Symbol_apply` that we forgot.
This option has been allowed by the command line compiler since ee706b8. This commit allows use of this via Ant. Note: we still don't exploit the features of classfile version 52, but watch this space as we roll out method handle based closures soon!
Sealed abstract classes (like `List`) have a primary constructor, public by default. It can never be called by external code but it shows up in the scaladoc as a nice `new List()` construtor... If a class is only abstract, the constructor is still useful because people can subclass and call it. If it is only sealed (i.e. effectively final), then it is the normal constructor of a final class. But sealed *and* abstract makes documenting the constructor useless. This should remove the misleading constructors of `List`, `Double`, `Option` and others from the scaladoc.
'&' isn't a prefix operator, perhaps to the chagrin of the C crowd.
In 2.11.0-M8, the enclosed test issued the following feature
warning:
sandbox/t7750.scala:7: warning: the existential type LazyCombiner[_$1,_$2,_$3] forSome { type _$1; type _$2; type _$3 <: Growable[_$1] with Sizing }, which cannot be expressed by wildcards,
This went way in 2.11.0-RC1 after we turned off the problematic
attempt to infer existential bounds based on the bounds of the
corresponding type parameters.
The test case passes since Scala 2.9.2. Prior, it failed with: ~/scala/2.9.1/bin/scalac sandbox/t1994.scala sandbox/t1994.scala:9: error: method y overrides nothing override def y = 1 ^ one error found
Don't naively derive types for the single method's signature from the provided function's type, as it may be a subtype of the method's MethodType. Instead, once the sam class type is fully defined, determine the sam's info as seen from the class's type, and use those to generate the correct override. ``` scala> Arrays.stream(Array(1, 2, 3)).map(n => 2 * n + 1).average.ifPresent(println) 5.0 scala> IntStream.range(1, 4).forEach(println) 1 2 3 ``` Also, minimal error reporting Can't figure out how to do it properly, but some reporting is better than crashing. Right? Test case that illustrates necessity of the clumsy stop gap `if (block exists (_.isErroneous))` enclosed as `sammy_error_exist_no_crash` added TODO for repeated and by-name params
When using delambdafy:method, anonymous function classes are not currently specialized, as noted here: https://github.com/scala/scala/blob/f08e96571479552b103b15cc2d40ea5454999546/src/compiler/scala/tools/nsc/transform/Delambdafy.scala#L26
It's okay for the two types to LUB to something above `Object` if they both individially were its supertype.
…led-ctor SI-5730 hide constructors of sealed abstract classes in scaladoc
Generate correct trees to refer to repeated params using `gen.paramToArg`. Based on retronym's review feedback.
That's all we ship in that directory, but it seems that some
JVMs freak out with a core dump if something else ends up
in that directory and we add it to the boot classpath.
Testing on unix:
% rm ./build/pack/bin.complete; ant
% touch /Users/jason/code/scala/build/pack/lib/foo.txt
% mkdir /Users/jason/code/scala/build/pack/lib/dir
% bash -x ./build/pack/bin/scala -version
...
/Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home/bin/java -Xmx256M -Xms32M -Xbootclasspath/a:/Users/jason/code/scala/build/pack/lib/dir:/Users/jason/code/scala/build/pack/lib/jline.jar:/Users/jason/code/scala/build/pack/lib/scala-actors.jar:/Users/jason/code/scala/build/pack/lib/scala-compiler.jar:/Users/jason/code/scala/build/pack/lib/scala-continuations-library_2.11-1.0.2.jar:/Users/jason/code/scala/build/pack/lib/scala-continuations-plugin_2.11.2-1.0.2.jar:/Users/jason/code/scala/build/pack/lib/scala-library.jar:/Users/jason/code/scala/build/pack/lib/scala-parser-combinators_2.11-1.0.2.jar:/Users/jason/code/scala/build/pack/lib/scala-partest-extras.jar:/Users/jason/code/scala/build/pack/lib/scala-partest-javaagent.jar:/Users/jason/code/scala/build/pack/lib/scala-reflect.jar:/Users/jason/code/scala/build/pack/lib/scala-swing_2.11-1.0.1.jar:/Users/jason/code/scala/build/pack/lib/scala-xml_2.11-1.0.2.jar:/Users/jason/code/scala/build/pack/lib/scalap.jar -classpath '""' -Dscala.home=/Users/jason/code/scala/build/pack -Dscala.usejavacp=true -Denv.emacs= scala.tools.nsc.MainGenericRunner -version
The boot classpath contains `build/pack/lib/dir` but not `foo.txt`.
I will seek a Windows test of the same during PR review.
PR scala#2374 changed the behaviour of `typedSingletonTypeTree` in the presence of an error typed reference tree. It incorrectly returns the reference tree in case on an error. However, this is a term tree, which is an inconsistent result with the input type tree. Consequently, a `typedSelectInternal` later fails when using this as the qualifier of a `SelectFromTypeTree`. Both test cases enclosed show this symptom. This commit: - Returns `tree` rather than `refTyped` when `refTyped` is error typed or when it isn't suitable as a stable prefix. - Avoids issuing a cascading "not a stable prefix" error if the `refTyped` is error typed. - Adds an extra layer of defense in `typedSelectFromTypeTree` to bail out quickly if the qualifier is error typed. The last measure is not necessary to fix this bug.
The spec says that `case _: List[Int]` should be always issue
an unchecked warning:
> Types which are not of one of the forms described above are
> also accepted as type patterns. However, such type patterns
> will be translated to their erasure (§3.7). The Scala compiler
> will issue an “unchecked” warning for these patterns to flag
> the possible loss of type-safety.
But the implementation goes a little further to omit warnings
based on the static type of the scrutinee. As a trivial example:
def foo(s: Seq[Int]) = s match { case _: List[Int] => }
need not issue this warning.
These discriminating unchecked warnings are domain of
`CheckabilityChecker`.
Let's deconstruct the reported bug:
def nowarn[T] = (null: Any) match { case _: Some[T] => }
We used to determine that if the first case matched, the scrutinee
type would be `Some[Any]` (`Some` is covariant). If this statically
matches `Some[T]` in a pattern context, we don't need to issue an
unchecked warning. But, our blanket use of `existentialAbstraction`
in `matchesPattern` loosened the pattern type to `Some[Any]`, and
the scrutinee type was deemed compatible.
I've added a new method, `scrutConformsToPatternType` which replaces
pattern type variables by wildcards, but leaves other abstract
types intact in the pattern type. We have to use this inside
`CheckabilityChecker` only. If we were to make `matchesPattern`
stricter in the same way, tests like `pos/t2486.scala` would fail.
I have introduced a new symbol test to (try to) identify pattern
type variables introduced by `typedBind`. Its not pretty, and it
might be cleaner to reserve a new flag for these.
I've also included a test variation exercising with nested matches.
The pattern type of the inner case can't, syntactically, refer to the
pattern type variable of the enclosing case. If it could, we would
have to be more selective in our wildcarding in `ptMatchesPatternType`
by restricting ourselves to type variables associated with the closest
enclosing `CaseDef`.
As some further validation of the correctness of this patch,
four stray warnings have been teased out of
neg/unchecked-abstract.scala
I also had to changes `typeArgsInTopLevelType` to extract the type
arguments of `Array[T]` if `T` is an abstract type. This avoids the
"Checkability checker says 'Uncheckable', but uncheckable type
cannot be found" warning and consequent overly lenient analysis.
Without this change, the warning was suppressed for:
def warnArray[T] = (null: Any) match { case _: Array[T] => }
Fixed in SI-8111 / 2.10.4.
When the Scala typechecker typechecks signatures in Java sources, it must enable use of a type constructor without applied type arguments (a raw type). However, the check in `adaptType::properTypeRequired` was too restricive: it only allows raw types given a) we are typechecking a Java source file and b) the type constructor itself is Java defined. The second check does not make sense; it is perfectly legal to define a Java raw type for over a Scala defined type constructor. This commit removes it. The bug was noticed in the Scaladoc context, as it explores the signatures of all Java sources so it can document them. But the enclosed test demonstrates the underlying bug under normal compilation.
In Scala fa0cdc7 (just before 2.9.0), a regression in implicit search, SI-2866, was discovered by Lift and fixed. The nature of the regression was that an in-scope, non-implicit symbol failed to shadow an eponymous implicit import. The fix for this introduced `isQualifyingImplicit` which discards in-scope implicits when the current `Context`'s scope contains a name-clashing entry. Incidentally, this proved to be a shallow solution, and we later improved shadowing detection in SI-4270 / 9129cfe. That picked up cases where a locally defined symbol in an intervening scope shadowed an implicit. This commit includes the test case from the comments of SI-2866. Part of it is tested as a neg test (to test reporting of ambiguities), and the rest is tested in a run test (to test which implicits are picked.) However, in the test case of SI-5639, we see that the scope lookup performend by `isQualifyingImplicit` is fooled by a "ghost" module symbol. The apparition I'm referring to is entered when `initializeFromClassPath` / `enterClassAndModule` encounters a class file named 'Baz.class', and speculatively enters _both_ a class and module symbol. AFAIK, this is done to defer parsing the class file to determine what inside. If it happens to be a Java compiled class, the module symbol is needed to house the static members. This commit adds a condition that `Symbol#exists` which shines a torch (forces the info) in the direction of the ghost module symbol. In our test, this causes it to vanish, as we only need a class symbol for the Scala defined `class Baz`. The existing `pos` test for this actually did not exercise the bug, separate compilation is required. It was originally checked in to `pending` with this error, and then later moved to `pos` when someone noticed it was not failing.
Fixed in SI-5508 / cca4d51.
Under resident compilation, we were getting multiple copies of static forwarders created for mixed in methods. It seems like the bug was fixed as a by-product of scala#4040. This commit adds a test to show this. I've confirmed that the test fails appropriately with 2.11.4. For future reference, before I figured out how to write the test for this one (test/resident doesn't seem to let you run the code after compiling it), I was using bash to test as follows: (export V=2.11.x; (scalac-hash $V sandbox/t5938_1.scala; (for i in 1 2; do echo sandbox/t5938.scala; done; printf '\n') | scalac-hash $V -Xresident); stty echo; scala-hash $V X ; echo ':javap -public X' | scala-hash $V);
The spliced application was placed in the `attrMap` in
`SymbolicXMLBuilder` and later incorrectly matched by a pattern
intended only to match:
xml.Text(s)
That attribute value is generated by parsing:
<elem xmlns='a'/>
So the net effect was that the two fragments of XML were identical!
This commit sharpens up the match to really look for a syntactic
`_root_.scala.xml.Text("...")`.
The test just prints the parse trees of a variety of cases, as we
we should not test the modularized XML library in scala/scala.
`Erasure.boxingErasure` exists to ensure that we use boxed primitives to represent the value, if the value class has type parameters referred to by its element type. However, this is implenented with a type map that runs deeply across the type. In the enclosed test case, we have `Repr=Array[Int]`, which should be erased to `Array[Int]`, _not_ to `Array[Integer]`. This commit ensures that the `boxingErasure` map only applies boxing at the top level, and not within array arguments. (Other type arguments will be erased, so we don't have to deal with them.)
GenBCode: cleanup optimizations
Fix problems in Symbol Literal static caching
SI-8954 Make @deprecated{Overriding,Inheritance} aware of @deprecated.
[sammy] eta-expansion, overloading, existentials
SI-8965 Account for corner case in "unrelated types" warning
SI-8966 Allow use of jvm-1.8 via the Ant scalac task
As diagnosed by the reporter, we needed additional overrides
due to the way these orderings are implemented.
I've added tests to show other methods and other orderings
are working correctly.
After writing that, I found a scalacheck test related to
NaN handling that also covers `Ordering`. I had to correct
the assertion in the tests of `reverse.{min,max}`.
2.11.5 bump
SI-9087 Fix min/max of reversed Double/Float orderings
SI-8519 collection.immutable.Map.apply is inefficient
SI-9030 make BoxesRunTime.equalsNumChar public
SI-5817: Add header to language.scala and languageFeature.scala
SI-5154 Parse leading literal brace in XML pattern
SI-7128 copyToArray(xs, 0, 0) should not fail
IMPORTANT: Base your PR on this one --> New PR validation <--
We can now edit these in IntelliJ, as per the regular JUnit tests.
We use the PAX Exam framework to integration test that the OSGi metadata we add to our JARs allows them to be loaded into the Felix and Equinox containers. However, we had to disable this test under Java 8 due to an incompatibility between that framework and the modern Java version. I have found a combination that works in Java 6, 7, and 8, so the test is now run under all Java versions. I have left a `skip` property to disable them, following the established convention. Tip of the hat to: - @soc / @rkrzewski for the work in scala#4066 that paved the way for this small change - Harald Wellman, for sharing [1] the Java 8 compatible combination of PAX and Felix . Testing: ``` for V in 1.6 1.7 1.8; do java_use $V; ant -q test.osgi; 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) ... [echo] Running OSGi JUnit tests. Output in /Users/jason/code/scala3/build/osgi [echo] Test pass 1 of 2 using Apache Felix 4.4.0 [echo] Test pass 2 of 2 using Eclipse Equinox 3.7.1 BUILD SUCCESSFUL Total time: 31 seconds 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) ... [echo] Running OSGi JUnit tests. Output in /Users/jason/code/scala3/build/osgi [echo] Test pass 1 of 2 using Apache Felix 4.4.0 [echo] Test pass 2 of 2 using Eclipse Equinox 3.7.1 BUILD SUCCESSFUL Total time: 22 seconds 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) ... [echo] Running OSGi JUnit tests. Output in /Users/jason/code/scala3/build/osgi [echo] Test pass 1 of 2 using Apache Felix 4.4.0 [echo] Test pass 2 of 2 using Eclipse Equinox 3.7.1 BUILD SUCCESSFUL Total time: 16 seconds ``` [1] https://groups.google.com/d/msg/ops4j/TN0sZFf6wLs/vUP0GML6-TQJ
SI-8642 Enable OSGi tests under Java 8
Conflicts: build.number src/compiler/scala/tools/nsc/transform/ExtensionMethods.scala src/library/scala/collection/Iterator.scala versions.properties
…2.x-20150129 Conflicts: build.number src/library/scala/concurrent/Future.scala versions.properties
…150129 Merge 2.11.x to 2.12.x
... until scala-ide/uber-build#48 is fixed.
adriaanm
force-pushed
the
ci-2.12-ide-nop
branch
from
1047f68 to
77ee308
Compare
adriaanm
pushed a commit
that referenced
this pull request
Aug 24, 2015
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
}
adriaanm
pushed a commit
that referenced
this pull request
Jun 7, 2016
This corrects an error in the change to the trait encoding in scala#5003: getters in traits should have empty bodies and be emitted as abstract. ``` % ~/scala/2.12.0-M4/bin/scalac sandbox/test.scala && javap -c T Compiled from "test.scala" public interface T { public abstract void T$_setter_$x_$eq(int); public int x(); Code: 0: aload_0 1: invokeinterface #15, 1 // InterfaceMethod x:()I 6: ireturn public int y(); Code: 0: aload_0 1: invokeinterface #20, 1 // InterfaceMethod y:()I 6: ireturn public void y_$eq(int); Code: 0: aload_0 1: iload_1 2: invokeinterface #24, 2 // InterfaceMethod y_$eq:(I)V 7: return public void $init$(); Code: 0: aload_0 1: bipush 42 3: invokeinterface scala#29, 2 // InterfaceMethod T$_setter_$x_$eq:(I)V 8: aload_0 9: bipush 24 11: invokeinterface #24, 2 // InterfaceMethod y_$eq:(I)V 16: return } % qscalac sandbox/test.scala && javap -c T Compiled from "test.scala" public interface T { public abstract void T$_setter_$x_$eq(int); public abstract int x(); public abstract int y(); public abstract void y_$eq(int); public static void $init$(T); Code: 0: aload_0 1: bipush 42 3: invokeinterface #21, 2 // InterfaceMethod T$_setter_$x_$eq:(I)V 8: aload_0 9: bipush 24 11: invokeinterface #23, 2 // InterfaceMethod y_$eq:(I)V 16: return public void $init$(); Code: 0: aload_0 1: invokestatic scala#27 // Method $init$:(LT;)V 4: return } ```
adriaanm
pushed a commit
that referenced
this pull request
Jun 28, 2016
This corrects an error in the change to the trait encoding in scala#5003: getters in traits should have empty bodies and be emitted as abstract. ``` % ~/scala/2.12.0-M4/bin/scalac sandbox/test.scala && javap -c T Compiled from "test.scala" public interface T { public abstract void T$_setter_$x_$eq(int); public int x(); Code: 0: aload_0 1: invokeinterface #15, 1 // InterfaceMethod x:()I 6: ireturn public int y(); Code: 0: aload_0 1: invokeinterface #20, 1 // InterfaceMethod y:()I 6: ireturn public void y_$eq(int); Code: 0: aload_0 1: iload_1 2: invokeinterface #24, 2 // InterfaceMethod y_$eq:(I)V 7: return public void $init$(); Code: 0: aload_0 1: bipush 42 3: invokeinterface scala#29, 2 // InterfaceMethod T$_setter_$x_$eq:(I)V 8: aload_0 9: bipush 24 11: invokeinterface #24, 2 // InterfaceMethod y_$eq:(I)V 16: return } % qscalac sandbox/test.scala && javap -c T Compiled from "test.scala" public interface T { public abstract void T$_setter_$x_$eq(int); public abstract int x(); public abstract int y(); public abstract void y_$eq(int); public static void $init$(T); Code: 0: aload_0 1: bipush 42 3: invokeinterface #21, 2 // InterfaceMethod T$_setter_$x_$eq:(I)V 8: aload_0 9: bipush 24 11: invokeinterface #23, 2 // InterfaceMethod y_$eq:(I)V 16: return public void $init$(); Code: 0: aload_0 1: invokestatic scala#27 // Method $init$:(LT;)V 4: return } ```
adriaanm
pushed a commit
that referenced
this pull request
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 scala#31 // Method scala/runtime/LazyInt.initialized:()Z
8: ifne 22
11: aload_0
12: iconst_1
13: invokevirtual scala#35 // Method scala/runtime/LazyInt.initialized_$eq:(Z)V
16: aload_0
17: bipush 42
19: invokevirtual scala#39 // Method scala/runtime/LazyInt.value_$eq:(I)V
22: aload_0
23: invokevirtual scala#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 scala#43 // Method java/lang/Object."<init>":()V
4: return
}
```
SethTisue
pushed a commit
that referenced
this pull request
Apr 25, 2018
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.