summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Explicit type application in cps plugin.Paul Phillips2012-09-261-1/+1
| | | | -Xlint revealed a strange type was being inferred here.
* Don't overload implicit methods.Paul Phillips2012-09-262-3/+3
| | | | It is the cause of much unhappiness, and it is not necessary.
* Don't write public methods with non-public parameters.Paul Phillips2012-09-263-7/+6
| | | | | | | | | If the parameter types of a method have lower visibility than the method itself, then the method cannot be overridden because the parameter types cannot be expressed. This is a confusing and frustrating situation to expose via public API. Such methods should either have access as strong as their parameter types, or be made final.
* Don't write side-effecting nullary methods.Paul Phillips2012-09-266-26/+25
| | | | | | | | | | | | Style says never write methods like this: def foo: Unit If it is Unit, then it is side-effecting, and should be def foo(): Unit Since -Xlint warns about this, we must adhere to its dictate.
* Avoid relying on auto-tupling.Paul Phillips2012-09-265-14/+14
| | | | | | | | | | | | | | | When you call Some(a, b, c) The compiler does eventually figure out that you meant Some((a, b, c)) However the compiler finds this inordinately taxing, and because this auto-tupling is dangerous, -Xlint warns about it. In the interests of being able to hear -Xlint's important points, we write Some((a, b, c)) to give it less to warn about.
* Merge pull request #1380 from scalamacros/ticket/6277Eugene Burmako2012-09-2615-49/+145
|\ | | | | SI-6277 fix for isXXX methods in reflection
| * SI-6277 fixes flags, annotations & privateWithinEugene Burmako2012-09-264-28/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `Symbol.getFlag`, 'Symbol.hasFlag`, `Symbol.hasAllFlags`, `Symbol.annotations` and `Symbol.privateWithin` now trigger automatic initialization of symbols if they are used in a runtime reflection universe and some other conditions are met (see `Symbol.needsInitialize` for details). As the performance testing in https://github.com/scala/scala/pull/1380 shows, this commit introduces a ~2% performance regression of compilation speed. Unfortunately all known solutions to the bug at hand (A, B & C - all of those) introduce perf regressions (see the pull request linked above for details). However we're under severe time pressure, so there's no more time to explore. Therefore I suggest this is reasonable to accept this performance hit, because we've just gained 6% from removing scala.reflect.base, and even before that we were well within our performance goal for 2.10.0-final.
| * distinguishes flag-agnostic completersEugene Burmako2012-09-2410-18/+30
| | | | | | | | | | | | | | | | | | At times it's useful to know whether a lazy type can change the flags of the underlying symbol or not. If the completer is flag-agnostic, this means that we can safely use flag-inspection facilities such as hasFlag and isXXX tests without fear of looking into not yet initialized data.
| * minor cleanup for reflectionEugene Burmako2012-09-223-5/+5
| |
* | Merge pull request #1397 from jsuereth/fix/SI-6409Grzegorz Kossakowski2012-09-261-0/+3
|\ \ | | | | | | Improves SI-6409 - Add note to string flatMap about evaluation.
| * | Improves SI-6409 - Add note to string flatMap about evaluation.Josh Suereth2012-09-251-0/+3
| | | | | | | | | | | | | | | | | | Note: flatMap has to evaluate the stream until it finds a head for the new stream. This is a limitation that will exist for 2.10.0, but the bug will remain open.
* | | Merge pull request #1405 from heathermiller/topic/scaladoc-interface-fixesGrzegorz Kossakowski2012-09-263-5440/+187
|\ \ \ | | | | | | | | Scaladoc interface fixes, js/css-only
| * | | Automatically highlight and scroll to linked-to membersHeather Miller2012-08-241-0/+16
| | | |
| * | | SI-4857 fixes showall/hideall Scaladoc interface bugHeather Miller2012-08-231-0/+11
| | | |
| * | | SI-6170 Revert #456 "Upgrade jQuery from 1.4.2 to 1.7.2"Heather Miller2012-08-232-5440/+160
| | | | | | | | | | | | | | | | | | | | This reverts commit b6c0e4478616a1252d65754a40c5dcbfc6554b36 because it caused SI-6170, after this revert, the left "search" panel of scaladoc should be resizable again.
* | | | Merge pull request #1388 from odersky/topic/instrumenterGrzegorz Kossakowski2012-09-261-6/+7
|\ \ \ \ | | | | | | | | | | Fixed instrumentation code so that it can deal with:
| * | | | Fixed instrumentation code so that it can deal with:Martin Odersky2012-09-251-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. leading imports: object sheet { import math; … } 2. trailing objects: object sheet { … } object other { … } Review by @dragos
* | | | | Merge pull request #1394 from vjovanov/amk/ActorRefGrzegorz Kossakowski2012-09-266-18/+31
|\ \ \ \ \ | | | | | | | | | | | | Moving ActorRef API to scala.concurrent.
| * | | | | Moving actor migration to separate dir.Vojin Jovanovic2012-09-255-0/+0
| | | | | |
| * | | | | Support for scala.concurrent for the ActorRef.Vojin Jovanovic2012-09-252-11/+18
| | | | | | | | | | | | | | | | | | | | | | | | Review by @phaller
| * | | | | SI-6305 fix.Vojin Jovanovic2012-09-255-7/+13
| | | | | |
* | | | | | Generate links to external projects in scaladoc.Eugene Vigdorchik2012-09-2610-108/+186
| |_|_|/ / |/| | | | | | | | | | | | | | Review by @VladUreche.
* | | | | Merge pull request #1345 from paulp/issue/6344Grzegorz Kossakowski2012-09-251-18/+32
|\ \ \ \ \ | | | | | | | | | | | | Possible fix for SI-6344, value class generic signatures.
| * | | | | Fix for SI-6344, value class generic signatures.Paul Phillips2012-09-201-18/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Value classes mostly erase to the erasure of the underlying type. Not everything in the checkfile looks correct, but I know from experience I can spend the rest of my life poking at erasures, so let's try to book some progress.
* | | | | | Revert "SI-6412 alleviates leaks in toolboxes"Grzegorz Kossakowski2012-09-253-107/+82
| |/ / / / |/| | | | | | | | | | | | | | This reverts commit b403c1d7524ccdfc3455b5bc5d5363fdd9c82bec.
* | | | | Merge pull request #1385 from scalamacros/ticket/6412Paul Phillips2012-09-247-96/+180
|\ \ \ \ \ | | | | | | | | | | | | SI-6412 some fixes for reflection leaks
| * | | | | fixes mirrorThatLoaded in JavaMirrorsEugene Burmako2012-09-242-13/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `mirrorThatLoaded(sym: Symbol): Mirror` in JavaMirrors used to iterate over `lazy val mirrors = new WeakHashMap[ClassLoader, WeakReference[JavaMirror]]()` to find out what mirror has loaded a certain symbol. It worked okay until yesterday when I noticed failing tests, which crashed when weak references in mirrors were dereferenced with get.get. Apparently some mirrors were collected, and the logic in JavaMirror didn't account for that possibility. When fixing this bug, I noticed that mirrors can become unreachable even if there are still reachable symbols created by those mirrors. That doesn't make sense, therefore I fixed this bug as well by introducing a strong ref from root symbols to the enclosing mirror. Therefore, any active symbol will have a strong reference to the enclosing mirror by the virtue of the owner chain.
| * | | | | SI-6412 alleviates leaks in toolboxesEugene Burmako2012-09-243-82/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Turns importer caches into fully weak hash maps, and also applies manual cleanup to toolboxes every time they are used. It's not enough, because reflection-mem-typecheck test is still leaking at a rate of ~100kb per typecheck, but it's much better than it was before. We'll fix the rest later, after 2.10.0-final. For more information, see https://issues.scala-lang.org/browse/SI-6412 and http://groups.google.com/group/scala-internals/browse_thread/thread/eabcf3d406dab8b2
| * | | | | SI-6412 fixes leaks in Types.uniquesEugene Burmako2012-09-242-1/+61
| | |/ / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the most blatant leak in reflection. There are others, but their impact is much smaller, therefore we'll fix them later, after 2.10.0-final. For more information, see https://issues.scala-lang.org/browse/SI-6412 and http://groups.google.com/group/scala-internals/browse_thread/thread/eabcf3d406dab8b2
* | | | | Merge pull request #1373 from smessmer/2.10.xGrzegorz Kossakowski2012-09-244-4/+4
|\ \ \ \ \ | |/ / / / |/| | | | Changed implementation comments from /** */ to /* */ for ScalaDoc
| * | | | Changed implementation comments from /** */ to /* */, so ScalaDoc remains ↵smessmer2012-09-214-4/+4
| | | | | | | | | | | | | | | | | | | | reasonable
* | | | | Merge pull request #1378 from scalamacros/ticket/5918Eugene Burmako2012-09-233-44/+11
|\ \ \ \ \ | | | | | | | | | | | | SI-5918 fixes the ConstantType ugliness
| * | | | | SI-5918 fixes the ConstantType uglinessEugene Burmako2012-09-233-44/+11
| | |_|_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Java enum values are represented with constants wrapping corresponding Symbols. To find out the underlying type of such a constant one needs to calculate sym.owner.linkedClassOfClass.tpe (where sym represents the wrapped symbol). To quote the source code, given (in java): class A { enum E { VAL1 } } - sym: the symbol of the actual enumeration value (VAL1) - .owner: the ModuleClassSymbol of the enumeration (object E) - .linkedClassOfClass: the ClassSymbol of the enumeration (class E) Back then, as far as I can guess, linkedClassOfClass was flaky and didn't work well late in the compilation pipeline. Therefore a fix to SI-1329 introduced a caching facility. Once a ConstantType representing the type of Constant(sym) was created (I guess, during typer, when linkedClassOfClass was still working), it cached the underlying type and used it in subsequent phases. *** Unfortunately this solution, being fine for enum values, broke another flavor of constants - type wrapping constants that represent classOf (for example, Constant(IntTpe) represents the classOf[Int] constant). Type-wrapping constants are special, because their type (e.g. Class[Int] in the example from the previous paragraph) changes as the compilation progresses. Before erasure it's Class[something], and after erasure it's just Class. Therefore caching types of such constants might lead to incorrect types flying around after erasure, as described in this scala-internals thread: http://groups.google.com/group/scala-internals/browse_thread/thread/45185b341aeb6a30. *** Now when the problem is clear, the question is why didn't it happen before? That's all because of another peculiarity of the compiler. Before erasure package references (e.g. in TypeRef prefixes) are represented as ThisType(sym), where sym stands for a package class symbol. After erasure such references are represented differently, e.g. java.lang package looks like TypeRef(TypeRef(TypeRef(NoPrefix, root, Nil), java, Nil), java.lang, Nil). As described in the aforementioned thread, the incorrect caching strategy employed in UniqueConstantType mixed with other caching mechanisms in compiler effectively established a non-clearable cache that goes from Type instances to types that represent their classOfs, e.g. from String to Class[String]. So if anyone tried to typecheck a classOf after erasure, he/she would get Class[String] instead of the correct Class, and compiler would crash. Right? Nope. Before erasure String is TypeRef(ThisType(java.lang), StringSymbol, Nil), and after erasure it's TypeRef(TypeRef(...), StringSymbol, Nil), as explained above. Therefore the foul cache would contain two String types: one pre-erasure going to a pre-erasure Class[String], and another one post-erasure going to a post-erasure Class. *** This shaky balance was broken when I tried to implement class tag generation with shiny Type.erasure method that Martin just exposed in the reflection API. The erasure method partially invoked the Erasure phase, and for a String it returned its post-erasure representation (with java.lang prefix represented as TypeRef, not as ThisType). And after that I used the result of erasure to build a classOf for a class tag. Since I did it in a macro, it was typer, a pre-erasure phase. Now you understand why things broke. That classOf created a Constant wrapping a post-erasure representation of String, which cached the incorrect non-erased Class[String] type for a post-erasure type, and things exploded. You can imagine my panic! The ScalaDays deadline was near, I still had to do finishing touches to implicit macros (which I actually never had time to do), and such a fundamental thing exploded. Actually I figured out the hashing problem, but in the limited time I had I failed to understand why exactly it's happening, so I introduced the dirty workaround praised in SI-5918 and moved on. *** The story doesn't end here. Some time has passed, and I learned a lot about the compiler. I independently discovered the ThisType -> TypeRef transform that erasure applies to package references and patched Type.erasure to undo it. After all, Type.erasure is a user-facing API, and users don't need to know about post-typer implementation details. You can read more about this here: http://groups.google.com/group/scala-internals/browse_thread/thread/6d3277ae21b6d581 From what we've learned above, we can see that this Type.erasure fix made the UniqueConstantType workaround unnecessary. But I didn't know that. So imagine my surprise when I tried to remove that workaround and ran the tests only to see that nothing fails. I went back in time to April when the problem first manifested, extracted a minimized crasher and tried to use it on trunk. Again, nothing crashed. And only with the help of showRaw, I finally understood that types printed as "String" can be wildly different. The rest was a piece of cake. *** The irony is that the original reason for ConstantType caching is no longer valid. linkedClassOfClass now works fine (and files/jvm/outerEnum.scala agrees with me), so we can remove the cache altogether. So why all this story about erasure and package references? Well, I don't know. I enjoyed uncovering this mystery, so I wanted to share it with you :)
* | | | | Merge pull request #1377 from scalamacros/topic/partest-always-lfPaul Phillips2012-09-222-4/+23
|\ \ \ \ \ | | | | | | | | | | | | partest now always produces log files with LFs
| * | | | | partest now always produces log files with LFsEugene Burmako2012-09-222-4/+23
| |/ / / /
* | | | | Merge pull request #1379 from retronym/topic/boxing-conversionsPaul Phillips2012-09-221-5/+0
|\ \ \ \ \ | |/ / / / |/| | | | Remove BoxingConversions from the scala package.
| * | | | Remove BoxingConversions from the scala package.Jason Zaugg2012-09-221-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | And add it to two test cases that rely on it. It is a remnant of the now-removed FlatArray (8cc7de74d).
* | | | | Merge pull request #1370 from pavelpavlov/SI-5767Grzegorz Kossakowski2012-09-211-2/+0
|\ \ \ \ \ | | | | | | | | | | | | LinkedHashSet scaladoc fix after FlatHashTable->HashTable transiton
| * | | | | LinkedHashSet scaladoc fix after FlatHashTable->HashTable transitonPavel Pavlov2012-09-211-2/+0
| | | | | |
* | | | | | fix scala.collection.TraversableLike scaladocxuwei-k2012-09-211-1/+1
| | | | | |
* | | | | | fix Subscriber scaladocxuwei-k2012-09-211-1/+1
| | | | | |
* | | | | | Merge remote-tracking branch 'paulp/treecheckers' into 2.10.xPaul Phillips2012-09-201-1/+1
|\ \ \ \ \ \
| * | | | | | Fix for loud test.Paul Phillips2012-09-201-1/+1
| | |_|_|/ / | |/| | | |
* | | | | | Merge remote-tracking branch 'paulp/topic/gitattributes' into 2.10.xPaul Phillips2012-09-201-91/+91
|\ \ \ \ \ \ | |_|_|/ / / |/| | | | |
| * | | | | Normalized line endings.Paul Phillips2012-09-201-91/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This brings all the files into line with the .gitattributes settings, which should henceforth be automatically maintained by git.
* | | | | | Merge pull request #1348 from scalamacros/ticket/6394Grzegorz Kossakowski2012-09-201-1/+1
|\ \ \ \ \ \ | | | | | | | | | | | | | | SI-6394 fixes macros.Context.enclosingClass
| * | | | | | SI-6394 fixes macros.Context.enclosingClassEugene Burmako2012-09-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously I used typer.context.enclClass, but it seems to do something completely unexpected, so I switched to manual context traversal.
* | | | | | | Merge pull request #1325 from odersky/ticket/6337Paul Phillips2012-09-202-2/+6
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | Fixes SI-6337 by disallowing nested value classes.
| * | | | | | | Fixed comment.Martin Odersky2012-09-171-0/+1
| | | | | | | |
| * | | | | | | Fixes SI-6337 by disallowing nested value classes.Martin Odersky2012-09-172-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems for the moment too hard to allow this, and the functionality to have value classes wrap other value classes does not seem essential.