summaryrefslogtreecommitdiff
path: root/src/compiler
Commit message (Collapse)AuthorAgeFilesLines
* SD-225 Use a "lzycompute" method for module initializationJason Zaugg2016-09-141-2/+4
| | | | | | | | | | | | | | | | | | | | | The monitors and module instantation were inliuned into the module accessor method in b2e0911. However, this seems to have had a detrimental impact on performance. This might be because the module accessors are now above the "always inline" HotSpot threshold of 35 bytes, or perhaps because they contain monitor-entry/exit and exception handlers. This commit returns to the the 2.11.8 appraoch of factoring the the second check of the doublecheck locking into a method. I've done this by declaring a nested method within the accessor; this will be lifted out to the class level by lambdalift. This represents a slight deviation from the implementation strategy used for lazy accessors, which create a symbol for the slowpath method in the info transform and generate the corresponding DefDef as a class member. I don't believe this deviation is particular worrisome, though. I have bootstrapped the compiler through this commit and found that the drastic regression in compiling the shapeless test suite is solved.
* SD-143 allow super calls to methods defined in indirect super classesJason Zaugg2016-09-051-1/+7
| | | | | | | | The restriction for super calls to methods defined in indirect super classes introduced in a980fde was over-restrictive. In particular, it ruled out a valid code pattern to select a method from a superclass when an unqualified `super` would resolve to an override defined in a trait (example in the commit as a test).
* More elegant holders for local lazy vals.Adriaan Moors2016-09-021-24/+18
|
* Merge pull request #5369 from lrytz/sd210Lukas Rytz2016-09-029-65/+122
|\ | | | | Fixes to mixin forwarders
| * Add a -Xmixin-force-forwarders ChoiceSettingLukas Rytz2016-09-023-5/+18
| |
| * Allow per-choice help in ChoiceSettingLukas Rytz2016-09-023-13/+28
| |
| * Allow all settings to be helpingLukas Rytz2016-09-014-5/+11
| |
| * Emit mixin forwarders for JUnit-annotated trait methods by defaultLukas Rytz2016-09-012-4/+8
| | | | | | | | | | | | | | | | | | | | | | JUnit 4 does not support default methods. For better user experience, this commit makes the compiler generate mixin forwarders for inherited trait methods that carry a JUnit annotation. The -Yjunit-trait-methods-no-forwarders flag disables this behavior. This supersedes the scala-js/scala-2.12-junit-mixin-plugin compiler plugin.
| * SD-143 error for super calls that cannot be implemented correctlyLukas Rytz2016-09-012-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a call super[T].m resolves to a method A.m where A is a class, but not the direct superclass of the current class, there is no way to emit an invocation of A.m: `invokespecial A.m` will resolve to B.m where B is the superclass of the current class. This commit adds an error message in this case. Note that this is similar to an existing error message for qualified super calls to a non-direct superclass: class A { def m = 1 } class B extends A { override def m = 2 } class C extends B { override def m = super[A].m } Gives "error: A does not name a parent class of class C". If the user means to call method m in the superclass, he can write an unqualified `super.m`. An similar error message is introduced if A is a Java-defined interface (and m is a default method), and A is not a direct parent of the current class. In this case `invokespecial A.m` is invalid bytecode. The solution is to add A as a direct parent of the current class.
| * SD-210 don't generate invalid forwarders under -Xgen-mixin-forwardersLukas Rytz2016-09-011-42/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With -Xgen-mixin-forwarders the compiler eagerly creates mixin forwarders for methods inherited from traits, even if the JVM method resolution would pick the correct default method. When generating a such a forwarder for a Java-defined default method, the mixin forwarder invokes the default method directly using `invokespecial` (for Scala-defined trait methods, the forwarder uses the static `m$` method that is generated for every trait method). An `invokespecial` call is only legal if the named interface is a direct parent of the current class. If this is not the case, we don't generate the mixin forwarder and emit a warning. In the tests there's also an example where a mixin forwarder is required for correctness, but cannot be added because the corresponding `invokespecial` call would be invalid. In this case we emit an error. This is similar to what we already do for other super calls to Java- defined default methods. The difference is that the super call is not written by the user but generated by the mixin forwarder. The solution is the same: add the interface as a direct parent.
* | Merge pull request #5294 from adriaanm/fields-laziesAdriaan Moors2016-09-0122-1401/+1113
|\ \ | |/ |/| Fields: expand lazy vals during fields, like modules
| * Lazy val without local.Adriaan Moors2016-09-011-10/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now `synchronized` is erased specially to avoid boxing, we can drop that work around. Note that this does add an extra cast and getter call on the slow path, but that likely doesn't matter. ``` class C { def foo = {lazy val x = {println("a"); "A" }; x } } ``` becomes ``` def foo(): String = { lazy <artifact> val x$lzy: scala.runtime.LazyRef[String] = new scala.runtime.LazyRef[String](); <artifact> private def x$lzycompute(): String = x$lzy.synchronized[String]{ if (x$lzy.initialized()) x$lzy.value() // NOTE: gets an `.asInstanceOf[String]` after erasure else { x$lzy.value_=({ scala.Predef.println("a"); "A" }); x$lzy.initialized_=(true); x$lzy.value() // NOTE: gets an `.asInstanceOf[String]` after erasure } } lazy def x(): String = if (x$lzy.initialized()) x$lzy.value() // NOTE: gets an `.asInstanceOf[String]` after erasure else x$lzycompute(); x() } ```
| * Cleanups after integrating lazyvals into fields.Adriaan Moors2016-09-012-67/+76
| | | | | | | | | | | | | | | | | | | | Mostly refactorings and catching up with doc updates. Some changes to flag handling, removing some redundancy, and making lazy fields and modules a bit more consistent in their flags. They now uniformly carry LAZY or MODULEVAR. Before, LAZY was dropped because mixin had some lazy val logic. No longer.
| * Specialize erasure of `synchronized` primitive methodAdriaan Moors2016-08-302-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal is to avoid emitting unneeded `BoxedUnit` values, which are the result of adapting a `Unit`-typed expression inside a `synchronized(...)` to the erased type of `synchronized`'s argument -- `Object`. The proposed solution gives `synchronized` a polymorphic type (the info of the type param is still erased so that bounds checking works in the erased type system), so that an application `synchronized(println("boo"))` erases to `synchronized[Unit])(println("boo"))`, and no boxing is performed on the `println("boo")` argument, whose expected type is now `Unit` instead of `Object`.
| * Local lazy vals: avoid boxing and mutable captureAdriaan Moors2016-08-291-13/+32
| |
| * Double-checked locking for local lazy vals.Adriaan Moors2016-08-291-27/+36
| |
| * Double-checked locking for modules.Adriaan Moors2016-08-293-36/+33
| | | | | | | | Inline `mkSynchronizedCheck`, whose abstraction obscured rather than clarified.
| * Ensure access from subclass to trait lazy valAdriaan Moors2016-08-291-0/+5
| | | | | | | | | | | | | | | | | | | | | | Since we need to refer to a trait lazy val's accessor using a super call in a subclass (when the field and bitmap are added), we must ensure that access is allowed. If the lazy val has an access boundary (e.g., `private[somePkg]`), make sure the `PROTECTED` flag is set, which widens access to `protected[somePkg]`. (As `member.hasAccessBoundary` implies `!member.hasFlag(PRIVATE)`, we don't have to `resetFlag PRIVATE`.)
| * Move AccessorSynthesis out to its own fileAdriaan Moors2016-08-292-455/+466
| |
| * Fields does bitmaps & synch for lazy vals & modulesAdriaan Moors2016-08-298-719/+444
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Essentially, we fuse mixin and lazyvals into the fields phase. With fields mixing in trait members into subclasses, we have all info needed to compute bitmaps, and thus we can synthesize the synchronisation logic as well. By doing this before erasure we get better signatures, and before specialized means specialized lazy vals work now. Mixins is now almost reduced to its essence: implementing super accessors and forwarders. It still synthesizes accessors for param accessors and early init trait vals. Concretely, trait lazy vals are mixed into subclasses with the needed synchronization logic in place, as do lazy vals in classes and methods. Similarly, modules are initialized using double checked locking. Since the code to initialize a module is short, we do not emit compute methods for modules (anymore). For simplicity, local lazy vals do not get a compute method either. The strange corner case of constant-typed final lazy vals is resolved in favor of laziness, by no longer assigning a constant type to a lazy val (see widenIfNecessary in namers). If you explicitly ask for something lazy, you get laziness; with the constant-typedness implicit, it yields to the conflicting `lazy` modifier because it is explicit. Co-Authored-By: Lukas Rytz <lukas@lightbend.com> Fixes scala/scala-dev#133 Inspired by dotc, desugar a local `lazy val x = rhs` into ``` val x$lzy = new scala.runtime.LazyInt() def x(): Int = { x$lzy.synchronized { if (!x$lzy.initialized) { x$lzy.initialized = true x$lzy.value = rhs } x$lzy.value } } ``` Note that the 2.11 decoding (into a local variable and a bitmap) also creates boxes for local lazy vals, in fact two for each lazy val: ``` def f = { lazy val x = 0 x } ``` desugars to ``` public int f() { IntRef x$lzy = IntRef.zero(); VolatileByteRef bitmap$0 = VolatileByteRef.create((byte)0); return this.x$1(x$lzy, bitmap$0); } private final int x$lzycompute$1(IntRef x$lzy$1, VolatileByteRef bitmap$0$1) { C c = this; synchronized (c) { if ((byte)(bitmap$0$1.elem & 1) == 0) { x$lzy$1.elem = 0; bitmap$0$1.elem = (byte)(bitmap$0$1.elem | 1); } return x$lzy$1.elem; } } private final int x$1(IntRef x$lzy$1, VolatileByteRef bitmap$0$1) { return (byte)(bitmap$0$1.elem & 1) == 0 ? this.x$lzycompute$1(x$lzy$1, bitmap$0$1) : x$lzy$1.elem; } ``` An additional problem with the above encoding is that the `lzycompute` method synchronizes on `this`. In connection with the new lambda encoding that no longer generates anonymous classes, captured lazy vals no longer synchronize on the lambda object. The new encoding solves this problem (scala/scala-dev#133) by synchronizing on the lazy holder. Currently, we don't exploit the fact that the initialized field is `@volatile`, because it's not clear the performance is needed for local lazy vals (as they are not contended, and as soon as the VM warms up, biased locking should deal with that) Note, be very very careful when moving to double-checked locking, as this needs a different variation than the one we use for class-member lazy vals. A read of a volatile field of a class does not necessarily impart any knowledge about a "subsequent" read of another non-volatile field of the same object. A pair of volatile reads and write can be used to implement a lock, but it's not clear if the complexity is worth an unproven performance gain. (Once the performance gain is proven, let's change the encoding.) - don't explicitly init bitmap in bytecode - must apply method to () explicitly after uncurry
| * Precompute bitmap info for lazy/init-checked valsAdriaan Moors2016-08-291-255/+256
| | | | | | | | | | | | Instead of doing this lazily, rework the logic to make it suitable for operating first on symbols (during the info transform), then on trees (tree transform).
| * [refactor] strictly reorder definitionsAdriaan Moors2016-08-291-456/+448
| |
| * [refactor] corral init bits some moreAdriaan Moors2016-08-291-355/+410
| | | | | | | | More code motion.
| * [refactor] corral checkinit logicAdriaan Moors2016-08-291-57/+51
| | | | | | | | Just moving some code around to make it comprehensible.
| * [refactor] lazy val expansion in mixins/lazyvalsAdriaan Moors2016-08-293-103/+68
| | | | | | | | Towards expanding lazy vals and modules during fields phase.
| * SI-8873 don't propagate primary ctor arg to case class's applyAdriaan Moors2016-08-292-0/+12
| | | | | | | | Final implementation based on feedback by Jason
| * Fields phase expands lazy vals like modulesAdriaan Moors2016-08-2911-439/+337
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They remain ValDefs until then. - remove lazy accessor logic now that we have a single ValDef for lazy vals, with the underlying machinery being hidden until the fields phase leave a `@deprecated def lazyAccessor` for scala-refactoring - don't skolemize in purely synthetic getters, but *do* skolemize in lazy accessor during typers Lazy accessors have arbitrary user code, so have to skolemize. We exempt the purely synthetic accessors (`isSyntheticAccessor`) for strict vals, and lazy accessors emitted by the fields phase to avoid spurious type mismatches due to issues with existentials (That bug is tracked as https://github.com/scala/scala-dev/issues/165) When we're past typer, lazy accessors are synthetic, but before they are user-defined to make this hack less hacky, we could rework our flag usage to allow for requiring both the ACCESSOR and the SYNTHETIC bits to identify synthetic accessors and trigger the exemption. see also https://github.com/scala/scala-dev/issues/165 ok 7 - pos/existentials-harmful.scala ok 8 - pos/t2435.scala ok 9 - pos/existentials.scala previous attempt: skolemize type of val inside the private[this] val because its type is only observed from inside the accessor methods (inside the method scope its existentials are skolemized) - bean accessors have regular method types, not nullary method types - must re-infer type for param accessor some weirdness with scoping of param accessor vals and defs? - tailcalls detect lazy vals, which are defdefs after fields - can inline constant lazy val from trait - don't mix in fields etc for an overridden lazy val - need try-lift in lazy vals: the assign is not seen in uncurry because fields does the transform (see run/t2333.scala) - ensure field members end up final in bytecode - implicit class companion method: annot filter in completer - update check: previous error message was tangled up with unrelated field definitions (`var s` and `val s_scope`), now it behaves consistently whether those are val/vars or defs - analyzer plugin check update seems benign, but no way to know... - error message gen: there is no underlying symbol for a deferred var look for missing getter/setter instead - avoid retypechecking valdefs while duplicating for specialize see pos/spec-private - Scaladoc uniformly looks to field/accessor symbol - test updates to innerClassAttribute by Lukas
| * asmutilsAdriaan Moors2016-08-291-13/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | decompile classfiles in parallel to aid in diffing bytecode between quick & strap ``` mkdir class-repo cd class-repo git init . ( cd .. ; sbt publishLocal ) v="2.12.0-local-$(g rev-parse --short HEAD)" ( cd ~/git/scala-2 ; sbt -Dstarr.version=$v compile ) for i in compiler interactive junit library partest-extras partest-javaagent reflect repl repl-jline repl-jline-embedded scaladoc scalap do cp -a ~/git/scala/build/quick/classes/$i . ~/git/scala/build/quick/bin/scala scala.tools.nsc.backend.jvm.AsmUtils $(find $i -name "*.class" ) g add $(find $i -name "*.asm" ) done g commit -m"quick" for i in compiler interactive junit library partest-extras partest-javaagent reflect repl repl-jline repl-jline-embedded scaladoc scalap do cp -a ~/git/scala-2/build/quick/classes/$i/* $i/ ~/git/scala/build/quick/bin/scala scala.tools.nsc.backend.jvm.AsmUtils $(find $i -name "*.class" ) done git --no-pager diff | mate ```
* | Ensure trait var accessor type is widenedAdriaan Moors2016-08-291-1/+2
|/ | | | | | | | | | If we don't widen, we'll fail to find the setter when typing `x = 42`, because `x` is constant-folded to `0`, as its type is `=> Int(0)`. After widening, `x` is type checked to `x` and its symbol is the getter in the trait, which can then be rewritten to the setter. Regression spotted and test case by szeiger.
* Merge pull request #5263 from retronym/review/5041Jason Zaugg2016-08-293-9/+35
|\ | | | | SI-5294 SI-6161 Hard graft in asSeenFrom, refinements, and existentials [ci: last-only]
| * Minor changes after reviewJason Zaugg2016-08-231-1/+1
| |
| * Improved refinement type and existential type handlingJason Zaugg2016-08-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lazy base type seq elements are encoded as a refined type with an empty scope and a list of type refs over some common type symbol that will be merged when `BaseTypeSeq#apply` is called. The first change in this commit is to mark the creation and consumption of such elements with calls to `[is]IntersectionTypeForBaseTypeSeq`. They are distinguished by using the actual type symbol rather than a refinement class symbol, which in turn simplifies the code in `BaseTypeSeq#typeSymbol`. I have also made `lub` aware of this encoding: it is now able to "see through" to the parents of such refined types and merge them with other base types of the same class symbol (even other refined types representing lazy BTS elements.) To make this fix work, I also had to fix a bug in LUBs of multiple with existential types. Because of the way the recursion was structured in `mergePrefixAndArgs`, the order of list of types being merged changed behaviour: quantified varialbles of existential types were being rewrapped around the resultting type, but only if we hadn't encountered the first regular `TypeRef`. This can be seen with the following before/after shot: ``` // 2.11.8 scala> val ts = typeOf[Set[Any]] :: typeOf[Set[X] forSome { type X <: Y; type Y <: Int}] :: Nil; def merge(ts: List[Type]) = mergePrefixAndArgs(ts, Variance.Contravariant, lubDepth(ts)); val merged1 = merge(ts); val merged2 = merge(ts.reverse); (ts.forall(_ <:< merged1), ts.forall(_ <:< merged2)) ts: List[$r.intp.global.Type] = List(Set[Any], Set[_ <: Int]) merge: (ts: List[$r.intp.global.Type])$r.intp.global.Type merged1: $r.intp.global.Type = scala.collection.immutable.Set[_ >: Int] merged2: $r.intp.global.Type = scala.collection.immutable.Set[_53] forSome { type X <: Int; type _53 >: X } res0: (Boolean, Boolean) = (false,true) // HEAD ... merged1: $r.intp.global.Type = scala.collection.immutable.Set[_10] forSome { type X <: Int; type _10 >: X } merged2: $r.intp.global.Type = scala.collection.immutable.Set[_11] forSome { type X <: Int; type _11 >: X } res0: (Boolean, Boolean) = (true,true) ``` Furthermore, I have fixed the computation of the base type sequences of existential types over refinement types, in order to maintain the invariant that each slot of the base type sequence of a existential has the same type symbol as that of its underlying type. Before, what I've now called a `RefinementTypeRef` was transformed into a `RefinedType` during rewrapping in the existential, which led to it being wrongly considered as a lazy element of the base type sequence. The first change above should also be sufficient to avoid the bug, but I felt it was worth cleaning up `maybeRewrap` as an extra line of defence. Finally, I have added another special case to `BaseTypeSeq#apply` to be able to lazily compute elements that have been wrapped in an existential. The unit test cases in `TypesTest` rely on these changes. A subsequent commit will build on this foundation to make a fix to `asSeenFrom`.
| * Type#contains should peer into RefinementTypeRef-sJason Zaugg2016-08-191-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Usually, `contains` should not look into class symbol infos. For instance, we expect that: ``` scala> trait C { def foo: Int }; typeOf[C].contains(IntClass) defined trait C res1: Boolean = false ``` We do, however, look at the decls of a `RefinedType` in contains: ``` scala> typeOf[{ def foo: Int }].contains(IntClass) res2: Boolean = true ``` Things get a little vague, however, when we consider a type ref to the refinement class symbol of a refined type. ``` scala> TypeRef(NoPrefix, typeOf[{ def foo: Int }].typeSymbol, Nil) res3: $r.intp.global.Type = AnyRef{def foo: Int} scala> .contains(IntClass) res4: Boolean = false ``` These show up in the first element of the base type seq of a refined type, e.g: ``` scala> typeOf[{ def foo: Int }].typeSymbol.tpe_* res5: $r.intp.global.Type = AnyRef{def foo: Int} scala> typeOf[{ def foo: Int }].baseTypeSeq(0).getClass res7: Class[_ <: $r.intp.global.Type] = class scala.reflect.internal.Types$RefinementTypeRef scala> typeOf[{ def foo: Int }].typeSymbol.tpe_*.getClass res6: Class[_ <: $r.intp.global.Type] = class scala.reflect.internal.Types$RefinementTypeRef ``` This commit takes the opinion that a `RefinementTypeRef` should be transparent with respect to `contains`. This paves the way for fixing the base type sequences of existential types over refinement types. The implementation of `ContainsCollector` was already calling `normalize`, which goes from `RefinementTypeRef` to `RefinedType`. This commit maps over the result, which looks in the parents and decls.
| * Determistically enter classes from directory into package scopeJason Zaugg2016-08-191-3/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Linux, the directory listing is not automatically sorted on Mac. This leads to non-determistic ids of Symbols of the classes in a directory, which in turn leads to instability of the ordering of parents within inferred refinement types. Notable, with this patch, we will stably infer: ``` scala> case class C(); case class D(); List(C(), D()).head defined class C defined class D res0: Product with Serializable = C() ``` rather than sometimes getting `Serializable with Product` on Linux. As such, I've removed the workarounds for this instability in two test cases.
* | SAM for subtypes of FunctionNLukas Rytz2016-08-261-1/+1
| | | | | | | | | | | | | | | | | | | | only exclude FunctionN types themselves from SAM, don't exclude their subtypes; we want e.g. trait T extends Function1[String, String] (x => x) : T to compile reference: https://github.com/scala/scala-dev/issues/206
* | Merge pull request #5322 from retronym/topic/SD-194Adriaan Moors2016-08-221-1/+8
|\ \ | |/ |/| SD-194 Tweak module initialization to comply with JVM spec
| * SD-194 Tweak module initialization to comply with JVM specJason Zaugg2016-08-181-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Top level modules in Scala currently desugar as: ``` class C; object O extends C { toString } ``` ``` public final class O$ extends C { public static final O$ MODULE$; public static {}; Code: 0: new #2 // class O$ 3: invokespecial #12 // Method "<init>":()V 6: return private O$(); Code: 0: aload_0 1: invokespecial #13 // Method C."<init>":()V 4: aload_0 5: putstatic #15 // Field MODULE$:LO$; 8: aload_0 9: invokevirtual #21 // Method java/lang/Object.toString:()Ljava/lang/String; 12: pop 13: return } ``` The static initalizer `<clinit>` calls the constructor `<init>`, which invokes superclass constructor, assigns `MODULE$= this`, and then runs the remainder of the object's constructor (`toString` in the example above.) It turns out that this relies on a bug in the JVM's verifier: assignment to a static final must occur lexically within the <clinit>, not from within `<init>` (even if the latter is happens to be called by the former). 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 ``` This relies on the way that we assign MODULE$ field after the super class constructors are finished, but before the rest of the module constructor is called. Instead, 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 ``` We will still achieve safe publication of the assignment to other threads by virtue of the fact that `<clinit>` is executed within the scope of an initlization lock, as specified by: https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.5 Fixes scala/scala-dev#SD-194
* | Merge pull request #5317 from retronym/ticket/SD-192Lukas Rytz2016-08-154-17/+26
|\ \ | | | | | | SD-192 Change scheme for trait super accessors
| * | SD-192 Change scheme for trait super accessorsJason Zaugg2016-08-154-17/+26
| |/ | | | | | | | | | | Rather than putting the code of a trait method body into a static method, leave it in the default method. The static method (needed as the target of the super calls) now uses `invokespecial` to exactly call that method.
* | Merge pull request #5266 from som-snytt/issue/9847Adriaan Moors2016-08-141-8/+33
|\ \ | | | | | | SI-9847 Nuance pure expr statement warning
| * | SI-9847 Nuance pure expr statement warningSom Snytt2016-07-081-8/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clarify the current warning, which means that an expression split over multiple lines may not be parsed as naively expected. When typing a block, attempt minor nuance. For instance, a single expression is not in need of parens. Try to avoid duplicate warnings for expressions that were adapted away from result position.
* | | Merge pull request #5283 from lrytz/sd182Jason Zaugg2016-08-152-35/+44
|\ \ \ | |_|/ |/| | SD-182 compiler option -Xgen-mixin-forwarders
| * | SD-182 compiler option -Xgen-mixin-forwardersLukas Rytz2016-07-152-35/+44
| | | | | | | | | | | | | | | Introduce a compiler option -Xgen-mixin-forwarders to always generate mixin forwarder methods.
* | | Merge pull request #5307 from adriaanm/issue-157Adriaan Moors2016-08-132-28/+61
|\ \ \ | | | | | | | | Propagate overloaded function type to expected arg type
| * | | Propagate overloaded function type to expected arg typeAdriaan Moors2016-08-122-28/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Infer missing parameter types for function literals passed to higher-order overloaded methods by deriving the expected argument type from the function types in the overloaded method type's argument types. This eases the pain caused by methods becoming overloaded because SAM types and function types are compatible, which used to disable parameter type inference because for overload resolution arguments are typed without expected type, while typedFunction needs the expected type to infer missing parameter types for function literals. It also aligns us with dotty. The special case for function literals seems reasonable, as it has precedent, and it just enables the special case in typing function literals (derive the param types from the expected type). Since this does change type inference, you can opt out using the Scala 2.11 source level. Fix scala/scala-dev#157
* | | | Merge pull request #5332 from retronym/review/5304Adriaan Moors2016-08-135-31/+44
|\ \ \ \ | | | | | | | | | | Fixes to Java source support in Scaladoc
| * | | | Javadoc: fix problems in community buildJakob Odersky2016-08-133-9/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - fix initialization NPE in doc headers - fix assertion errors for java fields - ignore comments when deciding where to put interface methods - consider DocDefs when checking for constructors
| * | | | Javadoc: java static name resolutionAdriaan Moors2016-08-133-22/+23
| | | | | | | | | | | | | | | | | | | | [Jakob Odersky <jodersky@gmail.com>: remove obsolete comments and fix tests]
* | | | | Merge pull request #5331 from adriaanm/pr5282-rewordAdriaan Moors2016-08-121-2/+2
|\ \ \ \ \ | |/ / / / |/| | | | SD-128 fix override checks for default methods
| * | | | SD-128 fix override checks for default methodsLukas Rytz2016-08-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The check for inheriting two conflicting members was wrong for default methods, leading to a missing error message. We were also not issuing "needs `override' modifier" when overriding a default method. Removes two methods: - `isDeferredOrJavaDefault` had a single use that is removed in this commit. - `isDeferredNotJavaDefault` is redundant with `isDeferred`, because no default method has the `DEFERRED` flag: - For symbols originating in the classfile parser this was the case from day one: default methods don't receive the `DEFERRED` flag. Only abstract interface methods do, as they have the `JAVA_ACC_ABSTRACT` flag in bytecode, which the classfile parser translates to `DEFERRED`. - For symbols created by the Java source parser, we don't add the `DEFERRED` to default methods anymore since 373db1e. Fixes scala/scala-dev#128
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-27 09:06:06 +0000