summaryrefslogtreecommitdiff
path: root/src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala
Commit message (Collapse)AuthorAgeFilesLines
* Fix typos in compiler and reflectJanek Bogucki2017-02-131-1/+1
| | | | | | | | | | | | Miscellania: Miscellania is a small island off the northernmost part of the Fremennik Isles - RunScape Wiki Miscellanea: A collection of miscellaneous objects or writings - Merriam-Webster
* SI-9814 Fix synchronized in specialized overridesJason Zaugg2016-11-251-1/+2
| | | | | | | | | | | | | | | | Specialization creates a subclasses of a specializd class for each type parameter combination. These contains copies of the methods from the superclass. However, before this transform, the pattern of self-synchronization in a method body had been replace by flag Flag.SYNCHRONIZED on the method symbol. This was not being propagated to the override, and hence no locking occured. This commit modifies the creation of the specialized overload symbol to copy the SYNCHRONIZED flag, as was already done for ASBOVERRIDE. I have also done the same for the `@strictfp` annotation.
* Fields does bitmaps & synch for lazy vals & modulesAdriaan Moors2016-08-291-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Reduce flag fiddlingAdriaan Moors2016-08-111-1/+1
| | | | | | | | | | | | | | | There isn't much point to the late* flags in a world where we're mutating flags left and right in tree and info transformers... So, lets get rid of the indirection until we can include flags in a symbol's type history, like we do for its info. This retires lateDEFERRED (redundant with SYNTHESIZE_IMPL_IN_SUBCLASS). Since it's introduced so late, it makes little sense to have these synthetic members go back to DEFERRED. Instead, just set DEFERRED directly. Also remove unused late* and not* flags. notPRIVATE subsumes lateFINAL for effective finality (scala/scala-dev#126)
* Lambda impl methods static and more stably namedJason Zaugg2016-06-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The body of lambdas is compiled into a synthetic method in the enclosing class. Previously, this method was a public virtual method named `fully$qualified$Class$$anonfun$n`. For lambdas that didn't capture a `this` reference, a static method was used. This commit changes two aspects. Firstly, all lambda impl methods are now emitted static. An extra parameter is added to those that require a this reference. This is an improvement as it: - allows, shorter, more readable names for the lambda impl method - avoids pollution of the vtable of the class. Note that javac uses private instance methods, rather than public static methods. If we followed its lead, we would be unable to support important use cases in our inliner Secondly, the name of the enclosing method has been included in the name of the lambda impl method to improve debuggability and to improve serialization compatibility. The serialization improvement comes from the way that fresh names for the impl methods are allocated: adding or removing lambdas in methods not named "foo" won't change the numbering of the `anonfun$foo$n` impl methods from methods named "foo". This is in line with user expectations about anonymous class and lambda serialization stability. Brian Goetz has described this tricky area well in: http://cr.openjdk.java.net/~briangoetz/eg-attachments/lambda-serialization.html This commit doesn't go as far a Javac, we don't use the hash of the lambda type info, param names, etc to map to a lambda impl method name. As such, we are more prone to the type-1 and -2 failures described there. However, our Scala 2.11.8 has similar characteristics, so we aren't going backwards. Special case in the naming: Use "new" rather than "<init>" for constructor enclosed lambdas, as javac does. I have also changed the way that "delambdafy target" methods are identifed. Rather than relying on the naming convention, I have switched to using a symbol attachment. The assumption is that we only need to identify them from within the same compilation unit. This means we can distinguish impl metbods for expanded functions (ones called from an `apply` method of an ahead-of-time expanded anonfun class), from those that truly end up as targets for lambda metafactory. Only the latter are translated to static methods in this patch.
* SI-9671, SI-7397 fix null.asInstanceOf[Int] when pt erases to ObjectLukas Rytz2016-05-181-5/+16
| | | | | | | | | | | | | | Erasure first replaces null.asInstanceOf[Int] by unbox(null). If the expected type erases to object, erasure then introduces a box operation, yielding box(unbox(null)). Note that this value is a box of zero, not null. Erasure has an optimization to replace box(unbox(x)) in case x is of primitive type. 60f1b4b extended this to the case when x is null, which is incorrect in general. The reason was to prevent creating a primitive box to be stored in the unused generic field when creating an instance of a specialized class. A special case ensures that this optimization is still performed.
* General cleanups and less warnings during a Scala buildsoc2016-04-041-23/+21
|
* Specialization precludes use of LambdaMetaFactory for SAMAdriaan Moors2016-03-291-0/+13
| | | | | | | | | | | | | When a SAM type is specialized (i.e., a specialized type parameter receives a specialized type argument), do not use LambdaMetaFactory (expand during Uncurry instead). This is an implementation restriction -- the current specialization scheme is not amenable to using LambdaMetaFactory to spin up subclasses. Since the generic method is abstract, and the specialized ones are concrete, specialization is rendered moot because we cannot implement the specialized method with the lambda using LMF.
* Don't generate specialized overrides in traitsJason Zaugg2015-08-111-3/+3
| | | | | | | | | | | | | | The term "specialized override" is used to describe a method in a synthetic specialized subclass that generically substitutes the specialized type args into the siganture of a generic method. For example, `trait T[@spec A] { def t(a: A) }` gives rise to `def t(a: Int)` under the type environment `A=Int`. This commit avoids doing this for specialized traits, only classes have these overrides now. The motivation is to make it simpler to use specialized interfaces (like `T$mcI$sp` from the example above) as Java functional interfaces.
* Merge pull request #4463 from retronym/topic/indylambda-emit-indyLukas Rytz2015-05-041-1/+16
|\ | | | | Use LambdaMetafactory where possible for lambda creation.
| * Support specialized method-handle based lambdasJason Zaugg2015-04-211-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ``` scala> (x: Int) => {??? : Int} res2: Int => Int = $$Lambda$1371/1961176822@6ed3ccb2 scala> res2(42) scala.NotImplementedError: an implementation is missing at scala.Predef$.$qmark$qmark$qmark(Predef.scala:225) at .$anonfun$1(<console>:8) at $$Lambda$1371/1961176822.apply$mcII$sp(Unknown Source) ... 33 elided scala> (x: Int, y: Long) => {??? : Int} res4: (Int, Long) => Int = $$Lambda$1382/1796047085@6f8e8894 scala> res4(0, 0L) scala.NotImplementedError: an implementation is missing at scala.Predef$.$qmark$qmark$qmark(Predef.scala:225) at .$anonfun$1(<console>:8) at $$Lambda$1382/1796047085.apply$mcIIJ$sp(Unknown Source) ... 33 elided ```
* | Fix many typosMichał Pociecha2015-04-211-2/+2
|/ | | | | This commit corrects many typos found in scaladocs and comments. There's also fixed the name of a private method in ICodeCheckers.
* Deprecations: Use of isPackage, hasSymbol, getter, setter...Simon Ochsenreither2015-03-261-4/+4
| | | | ... replaced by hasPackageFlag, hasSymbolIn, getterIn, setterIn.
* Merge pull request #4249 from retronym/ticket/9089Vlad Ureche2015-01-161-1/+0
|\ | | | | SI-9089 Another REPL/FSC + specialization bug fix
| * SI-9089 Another REPL/FSC + specialization bug fixJason Zaugg2015-01-151-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The enclosed test case stopped working in 2.11.5 on the back of https://github.com/scala/scala/pull/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] https://github.com/scala/scala/pull/4040#commitcomment-8531516
* | Fix many typos in docs and commentsmpociecha2014-12-141-1/+1
|/ | | | | | | | | | | | | This commit corrects many typos found in scaladocs, comments and documentation. It should reduce a bit number of PRs which fix one typo. There are no changes in the 'real' code except one corrected name of a JUnit test method and some error messages in exceptions. In the case of typos in other method or field names etc., I just skipped them. Obviously this commit doesn't fix all existing typos. I just generated in IntelliJ the list of potential typos and looked through it quickly.
* SI-5583 Remove the workaround for specialization bugJason Zaugg2014-10-091-13/+6
| | | | | | 08505bd added a workaround for an undiagnosed interaction between resident compilation and specialzation. This is no longer needed after the previous commit.
* SI-8871 Fix specialization under REPL / FSCJason Zaugg2014-10-091-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The transformation of applications to specialized methods relies on the owner of said method having had the specialization info transform run which stashes a bunch of related data into per-run caches such as `SpecializeTypes#{typeEnv}`. Recently, we found that per-run caches didn't quite live up to there name, and in fact weren't being cleaned up before a new run. This was remedied in 00e11ff. However, no good deed goes unpunished, and this led to a regression in specialization in the REPL and FSC. This commit makes two changes: - change the specialization info tranformer to no longer directly enter specialized methods into the `info` of whatever the current phase happens to be. This stops them showing up `enteringTyper` of the following run. - change `adaptInfos` to simply discard all but the oldest entry in the type history when bringing a symbol from one run into the next. This generalizes the approach taken to fix SI-7801. The specialization info transformer will now execute in each run, and repopulate `typeEnv` and friends. I see that we have a seemingly related bandaid for this sort of problem since 08505bd4ec. In a followup, I'll try to revert that.
* SI-8574 Copy @SerialVersionUID, etc, to specialized subclassesJason Zaugg2014-05-161-0/+1
| | | | | | | | | | | | The test case demonstrates that this is important for serialization and for strictfp. (Although the latter is still pretty broken, see SI-7954.) Now that the synthetic subclass of `Tuple2[Int, Int]` also has the `@deprecatedInheritance` annotation, I had to change the spot that issues this warning to be silent after the typer phase. Otherwise, we get two warnings in `run/t3888.scala`. This also remedies double warnings that were incurred in `neg/t6162-inheritance`.
* fixes compat for tree and type extractorsEugene Burmako2014-02-151-5/+5
| | | | | | | | | | | | | | | | | | | | | When I removed XXXDef(...) and XXXType(...) methods from the public API, I put compatibility stubs in compat via implicit classes enriching XXXExtractor traits with apply methods. Unfortunately, this doesn't work, because if XXXDef or XXXType have any kind of an apply method left in the public API, then implicit classes won't even be considered when resolving calls to XXXDef(...) or XXXType(...). Therefore I had to put those removed methods back and adorn them with an implicit parameter that can only be resolved when "import compat._" is in place. Quite extravagant, yes, but goes along the lines with the design goals of the refactoring, which are: 1) Break source compatibility for users who are using methods that are now moved to internal in order to attract attention. 2) Provide an easy way to fix the breakage by importing compat._, which will pimp back all the missing APIs with deprecation warnings that are going to guide migration.
* disambiguates uses of “local” in internal symbol APIEugene Burmako2014-02-121-1/+0
| | | | | | | | | | | | | | | | | There’s been a conflation of two distinct meanings of the word “local” in the internal symbol API: the first meaning being “local to this” (as in has the LOCAL flag set), the second meaning being “local to block” (as in declared in a block, i.e. having owner being a term symbol). Especially confusing is the fact that sym.isLocal isn’t the same as sym.hasFlag(LOCAL), which has led to now fixed SI-6733. This commit fixes the semantic mess by deprecating both Symbol.isLocal and Symbol.hasLocalFlag (that we were forced to use, because Symbol.isLocal had already been taken), and replacing them with Symbol.isLocalToThis and Symbol.isLocalToBlock. Unfortunately, we can’t remove the deprecated methods right away, because they are used in SBT, so I had to take small steps.
* Merge pull request #3444 from retronym/topic/opt6Adriaan Moors2014-02-011-2/+2
|\ | | | | Avoid generic collections operations hot paths
| * Avoid generic collections operations hot pathsJason Zaugg2014-01-311-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - Use a specialized version of List#{map, collectFirst} These special case mapping over an empty list and avoid allocating. - Avoid nonEmpty in favor of `ne Nil` I see in the order of 2% speedup. Perhaps more useful is that these methods no longer dominate the YourKit profiles, even though profiler bias due to safepoints at allocation of the ListBuffer might have been overstating their significance.
* | Merge pull request #3425 from retronym/ticket/7700Jason Zaugg2014-01-311-9/+19
|\ \ | |/ |/| SI-7700 @unspecialized, Part Deux: Now Working.
| * SI-7700 @unspecialized, Part Deux: Now Working.Jason Zaugg2014-01-311-9/+19
| | | | | | | | | | | | | | | | | | This annotation was introduced to allow us to mark methods within a specialized trait as immune from specialization. In particular, this is desirable for `Function1.{andThen, compose}`. However, it seems we need to check for this in two places in the specialization code base. The feature is now backed with a test.
* | SI-8151 Remove -Yself-in-annots and associated implementationJason Zaugg2014-01-151-2/+2
|/ | | | | | | | | | | | | | | This experimental option typechecked arguments of annotations with an injected value in scope named `self`: @Foo(self.foo < 1) This has been slated for removal [1] for some time. This commit removes it in one fell swoop, without any attempt at source compatibility with code that constructs or pattern matches on AnnotatedType. [1] https://groups.google.com/d/msg/scala-internals/VdZ5UJwQFGI/C6tZ493Yxx4J
* SI-7406 crasher with specialized lazy valPaul Phillips2013-12-211-1/+1
| | | | | | | This reverts a tiny bit of f7d5f45aa7 where the crasher was introduced. The enclosed test case compiles and runs under 2.9, but prints the wrong answer. It crashes in 2.10 and until this patch. Now it compiles and prints the right answer.
* SI-7678 Don't cache member symbols of TypeTags in Definitions.Jason Zaugg2013-11-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | It we can only safely use vals in Definitions for top-level symbols. Otherwise, when the IDE switches to loading the symbol from source, we can hold on to a stale symbol, which in turn impedes implicit materialization of TypeTags. This commit moves (most) of the accessors for member symbols into RunDefinitions, and changes calling code accordingly. This is a win for presentation compiler correctness, and might even shave of a few cycles. In a few cases, I have had to leave a `def` to a member symbol in Definitions so we can get to it from the SymbolTable cake, which doesn't see RunDefinitions. The macro FastTrack facility now correctly recreates the mapping from Symbol to macro implementation each run, using a new facility in perRunCaches to create a run-indexed cache. The enclosed test recreates the situation reported in the ticket, in which TypeTags.scala is loaded from source.
* Make specialization aware of anonymous functions.James Iry2013-11-061-1/+7
| | | | | | | | During development of late delmabdafying there was a problem where specialization would undo some of the work done in uncurry if the body of the lambda had a constant type. That would result in a compiler crash as when the delambdafy phase got a tree shape it didn't understand. This commit has a fix and a test.
* SI-6762 rename emptyValDef to noSelfType.Paul Phillips2013-09-271-2/+2
| | | | | Looks like emptyValDef.isEmpty was already changed to return false, so now all that's left is a name which means something.
* Reducing variation of tree creation methods.Paul Phillips2013-09-131-6/+4
| | | | | | | | | | | | | | | | | | | | | | | TreeDSL has no future - it was always a temporary measure waiting for something like quasiquotes to come along. In this commit I cull as much of it as I can, especially the delicate matter of creating new DefDefs and ValDefs, which I completely turn over to the old style creators. I unified all the symbol-based DefDef and ValDef creators under a single method, since it was yet another place where ctrl-C and ctrl-V were being punched with glee. Was beaten to the punch on adding copyTypeDef to fill out the *Def creators. Eliminated as many redundant positioning calls as I could find. If you are creating a DefTree tree based on a symbol, it will always have an atPos(sym.pos) { ... } wrapped around it. You don't need another one. All of this is motivated by positions work: positions are assigned in so many places and in such an ad hoc fashion that it is impossible to bring consistency to that without first bringing some consistency to tree creation.
* Merge 2.10.x into masterAdriaan Moors2013-06-281-2/+30
|\ | | | | | | | | | | | | Conflicts: src/compiler/scala/tools/nsc/typechecker/Duplicators.scala src/library/scala/concurrent/Future.scala test/files/jvm/scala-concurrent-tck.scala
| * SI-7343 Fixed phase ordering in specializationVlad Ureche2013-06-121-2/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Specialization rewires class parents during info transformation, and the new info then guides the tree changes. But if a symbol is created during duplication, which runs after specialization, its info is not visited and thus the corresponding tree is not specialized. One manifestation is the following: ``` object Test { class Parent[@specialized(Int) T] def spec_method[@specialized(Int) T](t: T, expectedXSuper: String) = { class X extends Parent[T]() // even in the specialized variant, the local X class // doesn't extend Parent$mcI$sp, since its symbol has // been created after specialization and was not seen // by specialzation's info transformer. ... } } ``` We can fix this by forcing duplication to take place before specialization. Review by @dragos, @paulp or @axel22.
* | SI-7344 Specialize methods in private scopesVlad Ureche2013-06-281-23/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This performs method specialization inside a scope other than a {class, trait, object}: could be another method or a value. This specialization is much simpler, since there is no need to record the new members in the class signature, their signatures are only visible locally. It works according to the usual logic: - we use normalizeMember to create the specialized symbols - we leave DefDef stubs in the tree that are later filled in by tree duplication and adaptation The solution is limited by SI-7579: since the duplicator loses the sym annotations when duplicating, this expansion and rewiring can only take place in code that has not been subject to duplication. You can see the test case for an example. Review by @dragos, @paulp or @axel22.
* | SI-6308 Specialize methods that have some unspecialized paramsJason Zaugg2013-06-051-4/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a continuation of 1591c14e50, which didn't go far enough to handle method calls with a mix of specialized and unspecialized type parameters. This commit modifies `specSym` to calculate the residual type of the original method after specialized type parameters have been removed and the type environment of the candidate specialized variant has been subsituted. For example, here is trace of `specSym` when searcing for the specialized variant of `f4` in the enclosed test: tree = Main.this.f4[Nothing, Int] tree.tpe = (a: Int, b: List[(Int, Nothing)])String fun.tpe = [B, A](a: A, b: List[(A, B)])String residualTreeType = [B](a: Int, b: List[(Int, B)])String memberType = [B](a: Int, b: List[(Int, B)])String env = Map(type A -> Int) doesConform = true A few "todo" tests are included that highlight an endemic issue with the current specialization implementation: type parameters that show up after `uncurry` might be clones of the original symbols from typer, if they have been through a TypeMap (e.g. within a call to `uncurryTreeType`). So testing them for existence with the `typeEnv` map is fruitless. No amount of `atPhase` acrobatics can rescue us from this; we need to transport this information in a symbol-cloning resiliant manner. Maybe Symbol Attachments?
* | A couple additional simplifications.Paul Phillips2013-05-241-3/+3
| | | | | | | | As noted by reviewer.
* | Concision contribution.Paul Phillips2013-05-231-25/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have lots of core classes for which we need not go through the symbol to get the type: ObjectClass.tpe -> ObjectTpe AnyClass.tpe -> AnyTpe I updated everything to use the concise/direct version, and eliminated a bunch of noise where places were calling typeConstructor, erasedTypeRef, and other different-seeming methods only to always wind up with the same type they would have received from sym.tpe. There's only one Object type, before or after erasure, with or without type arguments. Calls to typeConstructor were especially damaging because (see previous commit) it had a tendency to cache a different type than the type one would find via other means. The two types would compare =:=, but possibly not == and definitely not eq. (I still don't understand what == is expected to do with types.)
* | Absolutized paths involving the scala package.Paul Phillips2013-05-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Confusing, now-it-happens now-it-doesn't mysteries lurk in the darkness. When scala packages are declared like this: package scala.collection.mutable Then paths relative to scala can easily be broken via the unlucky presence of an empty (or nonempty) directory. Example: // a.scala package scala.foo class Bar { new util.Random } % scalac ./a.scala % mkdir util % scalac ./a.scala ./a.scala:4: error: type Random is not a member of package util new util.Random ^ one error found There are two ways to play defense against this: - don't use relative paths; okay sometimes, less so others - don't "opt out" of the scala package This commit mostly pursues the latter, with occasional doses of the former. I created a scratch directory containing these empty directories: actors annotation ant api asm beans cmd collection compat concurrent control convert docutil dtd duration event factory forkjoin generic hashing immutable impl include internal io logging macros man1 matching math meta model mutable nsc parallel parsing partest persistent process pull ref reflect reify remote runtime scalap scheduler script swing sys text threadpool tools transform unchecked util xml I stopped when I could compile the main src directories even with all those empties on my classpath.
* | Merge pull request #2398 from huitseeker/silence_scaladoc_betterJason Zaugg2013-04-211-1/+1
|\ \ | | | | | | Change unrecognized scaladoc comments to C-style
| * | Change unrecognized scaladoc comments to C-styleFrançois Garillot2013-04-161-1/+1
| | |
* | | Merge remote-tracking branch 'origin/2.10.x' into ↵Jason Zaugg2013-04-201-1/+5
|\ \ \ | | |/ | |/| | | | | | | | | | | | | | | | merge/v2.10.1-245-g5147bb2-to-master Conflicts: src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala src/compiler/scala/tools/nsc/typechecker/Typers.scala
| * | Merge pull request #2364 from vigdorchik/ticket/si-7329Paul Phillips2013-04-191-1/+5
| |\ \ | | | | | | | | SI-7329 duplicate default getters for specialized parameters.
| | * | SI-7329 duplicate default getters for specialized parameters.Eugene Vigdorchik2013-04-071-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The default getter is generated with @specialized annotation if the type parameter corresponding to the type of the parameter is specialized. Consequently specialize pass tries to generate overloads. Rather than pruning overloads to exclude duplicates, let's notice that default getter specialization is not needed at all: - The dynamic scope of default getter doesn't include specialized method or class constructor. - generic default getter is called even when calling specialized method: object V { @specialized def foo[@specialized B](b: B = (??? : B)) = {} foo[Int]() } gives: invokevirtual Method V$.foo$default$1:()Ljava/lang/Object; invokestatic (unboxToInt) invokevirtual Method V$.foo$mIc$sp:(I)V
* | | | Merge remote-tracking branch 'origin/2.10.x' into ↵Jason Zaugg2013-04-151-22/+19
|\| | | | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | merge/v2.10.1-235-g4525e92-to-master Conflicts: bincompat-backward.whitelist.conf bincompat-forward.whitelist.conf src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala src/compiler/scala/tools/nsc/typechecker/Typers.scala src/reflect/scala/reflect/internal/Types.scala
| * | SI-6286 IllegalArgumentException handling specialized method.Eugene Vigdorchik2013-04-101-20/+17
| |/ | | | | | | | | | | Specialize assigns SpecialOverride info to a specialized method even when there is a further specialization that should be forwarded to.
* | Merge remote-tracking branch 'origin/2.10.x' into merge-2.10.xPaul Phillips2013-04-081-16/+12
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * origin/2.10.x: if starr.use.released fetch Scala ${starr.version} for STARR assume build.release when maven.version.suffix is set make quick.done depend on quick.bin again SI-7321 Memory leak in specialize on multiple compiler runs. Take the N^2 out of the compiler's TreeSet. SI-6900 Fix tailrec for dependent method types Simplify interplay between Uncurry Info- and Tree-Transformers Refactor existential related code out of types. Add a cautionary comment to TreeSymSubstitutor. SI-6715 Shouldn't return "" from TermNames.originalName Backport #2289's TermNames.unexpandedName as TermNames.originalName SI-7147 Diagnostic for unexplained assertion in presentation compiler. SI-6793 Don't use super param accessors if inaccessible. Correct sorting example for Ordering in scaladoc Conflicts: bincompat-backward.whitelist.conf bincompat-forward.whitelist.conf build.xml src/compiler/scala/tools/nsc/transform/UnCurry.scala src/reflect/scala/reflect/internal/StdNames.scala
| * SI-7321 Memory leak in specialize on multiple compiler runs.Eugene Vigdorchik2013-04-041-16/+12
| | | | | | | | | | | | | | | | Currently the map is declared LinkedHashMap, which doesn't align with other caching maps that are cleared on every run. Linkedness is only needed to ensure deterministic order on the generated specialized classes. The same can be accomplished by sorting generated classes a-posteriori.
| * [backport] SI-6301 / SI-6572 specialization regressionsJason Zaugg2013-01-291-51/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Squashed commit of the following: commit a3680be29ccd5314c5d027d473b37940eaecd530 Author: Paul Phillips <paulp@improving.org> Date: Fri Aug 31 10:20:16 2012 -0700 Actual fix for SI-6301, specialized crasher. This means the workaround in the previous commit is no longer reached, but it should remain where it is as a much needed layer of robustness/useful error reporting. Conflicts: src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala src/compiler/scala/tools/nsc/typechecker/Duplicators.scala commit f4c45ae204ce3ff3c16b19cab266d0b6515b6e0f Author: Paul Phillips <paulp@improving.org> Date: Fri Aug 31 10:49:24 2012 -0700 Rewrite of GenICode adapt. Started for debuggability, stayed for clarify/performance. Conflicts: src/compiler/scala/tools/nsc/backend/icode/GenICode.scala commit 74842f72a0af485e5def796f777f7003f969d75b Author: Paul Phillips <paulp@improving.org> Date: Fri Aug 31 08:45:34 2012 -0700 Workaround for SI-6301, @specialize crasher. SpecializeTypes is generating symbols with overloaded types which then proceed to crash in CleanUp or GenICode. Until I or someone works out why that is, take a look in case the overload is easily disambiguated by the argument list arity, in which case warn and proceed.
* | SI-7261 Implicit conversion of BooleanSetting to Boolean and BooleanFlagSom Snytt2013-03-271-2/+2
| | | | | | | | | | | | | | This commit shortens expressions of the form `if (settings.debug.value)` to `if (settings.debug)` for various settings. Rarely, the setting is supplied as a method argument. The conversion is not employed in simple definitions where the Boolean type would have to be specified.
* | Overhauled local/getter/setter name logic.Paul Phillips2013-03-251-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sifted through extraneous methods trying to find consistency, consolidating and deprecating as I went. The original motivation for all this was the restoration of LOCAL_SUFFIX to originalName, because: It looks like in an attempt to make originalName print consistently with decodedName, I went a little too far and stripped invisible trailing spaces from originalName. This meant outer fields would have an originalName of '$outer' instead of '$outer ', which in turn could have caused them to be mis-recognized as outer accessors, because the logic of outerSource hinges upon "originalName == nme.OUTER". I don't know if this affected anything - I noticed it by inspection, improbably enough. Deprecated originalName - original, compared to what? - in favor of unexpandedName, which has a more obvious complement. Introduced string_== for the many spots where people have given up and are comparing string representations of names. A light dusting of types is still better than nothing. Editoral note: LOCAL_SUFFIX is the worst. Significant trailing whitespace! It's a time bomb.
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-20 13:27:15 +0000