summaryrefslogtreecommitdiff
path: root/src/reflect
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #1202 from scalamacros/topic/reflectionPaul Phillips2012-09-0210-40/+59
|\ | | | | further polishing of reflection
| * definitive way to learn if a symbol is a val/varEugene Burmako2012-08-272-4/+6
| | | | | | | | | | I think `isVal` and `isVar` are the right names, because they exactly map on Scala syntax.
| * Exposes Symbol.sourceModuleEugene Burmako2012-08-272-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As discussed, this is not the best API to expose, because this is an implementation detail that might change. However the ship has sailed. We're already imposing the moduleClass <-> sourceModule quirk to the users of our API: Evidence: http://stackoverflow.com/questions/12128783. There are reflection tasks that cannot be pulled without the knowledge of this implementation detail, so we shouldn't pretend that we can change it on a whim and not break anything. Hence I propose to add sourceModule to the public contract and bear the potential consequences.
| * rehash of source file information for SymbolEugene Burmako2012-08-272-2/+7
| | | | | | | | | | | | | | | | Symbol.pos is moved to macros.Universe, because it's empty at runtime. Also added Symbol.associatedFile, because it has valid usages during runtime. When reflecting one might want to get to a classfile of the symbol and then analyze it to e.g. decompile the bytecode or find out the associated src file.
| * removes AbstractFileApiEugene Burmako2012-08-278-34/+17
| | | | | | | | | | no longer necessary, since scala.tools.nsc.io.AbstractFile has been long moved to scala-reflect.jar
| * exposes MethodSymbol.isPrimaryConstructorEugene Burmako2012-08-271-0/+3
| | | | | | | | Doesn't seem to be inferrable from the API we expose right now
| * Exposes Symbol.deSkolemize to macrosEugene Burmako2012-08-271-0/+2
| |
| * adds Symbol.isJavaEugene Burmako2012-08-272-0/+5
| | | | | | | | Doesn't seem to be inferrable from the API we expose right now
| * adds ClassSymbol.baseClassesEugene Burmako2012-08-272-0/+7
| | | | | | | | | | | | | | | | | | Sure this stuff is also declared in Type.baseClasses, but this is one of the hot paths in reflection (e.g. like ClassSymbol.typeParams), so I think it's justified to have it as a dedicated method. Unfortunately we cannot remove Type.baseClasses, because it includes ridiculously involved calculation of base classes for compound types.
| * exposes Symbol.childrenEugene Burmako2012-08-272-0/+6
| | | | | | | | As requested in http://stackoverflow.com/questions/12078366/
* | Better errors for Any/AnyRef issues.Paul Phillips2012-09-012-8/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an error occurs because some type does not conform to AnyRef (and an AnyRef-derived type would have sufficed) try to say something useful about the situation. This commit also initializes scope members before printing error messages because the + version seems more useful than the - version (taken from one of the checkfile diffs.) - def <init>: <?> - def methodIntIntInt: <?> + def <init>(): X + def methodIntIntInt(x: scala.Int,y: scala.Int): scala.Int
* | Fix for SI-6034, covariant value classes.Paul Phillips2012-08-312-2/+8
| | | | | | | | | | | | | | | | My summary in the ticket was incorrect. The problem was that the class type parameters were being cloned for the method and being allowed to keep their variance. I threw in an assertion for anyone attempting to create a method type with variant type parameters, because hey, why should we allow such madness.
* | Reflection tuningDominik Gruntz2012-08-303-3/+3
| | | | | | | | | | | | | | | | | | This pull request applies some tuning changes to the reflection library: 1) the traits scala.reflect.api.FlagSets, scala.reflect.api.Mirrors and scala.reflect.internal.Importers extend their corresponding trait in the base layer of the cake. 2) method isType and asType in trait TypeSymbolBase is declared final 3) small changes in the docs.
* | removes Symbol.kind and Type.kindEugene Burmako2012-08-264-8/+1
|/ | | | | | | | | | | | | use Universe.showRaw instead: scala> import scala.reflect.runtime.{universe => ru} import scala.reflect.runtime.{universe=>ru} scala> ru.showRaw(typeOf[Int]) res0: String = TypeRef(ThisType(scala), scala.Int, List()) scala> ru.showRaw(typeOf[Int].typeSymbol, printKinds = true) res1: String = scala.Int#CLS
* Merge pull request #1178 from scalamacros/topic/weak-subtypePaul Phillips2012-08-231-0/+4
|\ | | | | adds weak_<:< to the API
| * adds weak_<:< to the APIEugene Burmako2012-08-211-0/+4
| | | | | | | | | | quite a fundamental method to be left to be implemented manually by the users of the reflection API
* | Merge pull request #1170 from scalamacros/topic/overridenPaul Phillips2012-08-231-0/+3
|\ \ | | | | | | exposes overridenSymbol/overridingSymbol in API
| * | exposes the notion on overriding in the APIEugene Burmako2012-08-211-0/+3
| |/ | | | | | | it seems like we completely overlooked this functionality
* / exposes absTypeTag and absTypeOfEugene Burmako2012-08-211-0/+2
|/ | | | | | | to be symmetric with typeTag and typeOf. this is especially important for macro development, since only c.AbsTypeTag context bounds can be used on macro implementations
* Slightly less drastic disabling of statistics.Martin Odersky2012-08-201-12/+12
| | | | All statistics code is now subject to a switch at each use site, as opposed to a compile-time constant before. We should veryfy that this does not affect performance. Statistics is a useful ability to have for trouble-shooting compile time speeds on specific code bases. But we should not pay a lot for having it on normal runs.
* Reverted closure hoisting except for functions returning a Boolean resultMartin Odersky2012-08-205-35/+23
| | | | | | If our theory wrt map is correct (i.e. that it gets inlined by JVM), then closure hoisting is counter-productive because it migh well prevent the closure from being inlined. This commit removes all hoisted closures that are passed to map and leaves only those boolean closures that are passed to exists and forall. I should have split the early optimizations including closures into separate commits. As that train has left, I am now reverting some bits to see whether the reverts affect performance at all, and in what direction.
* Some more closure hositing/eliminationMartin Odersky2012-08-202-7/+15
|
* Made all statistic code disappear unless built with Statistics.canEnable = trueMartin Odersky2012-08-205-47/+62
|
* Partial revert of itransform commit.Martin Odersky2012-08-201-52/+43
| | | | Profile data actually showed a small slowdown in steady state. We keep the reordering but merge all submethods into one.
* Manaul inling of `UndoLog.undoUnless`.Grzegorz Kossakowski2012-08-202-25/+71
| | | | | | | | | | | | | Inline `UndoLog.undoUnless` into `isSubType` and `isSameType` methods. They are responsible for 20% of all Function0 allocations. I had to do manual inlining because inlier doesn't cope with exception handlers well. Let it be noted that I almost cried while doing this ugly change. I'll want to see inliner being fixed so we can revert this change ASAP.
* Optimizations to SymTree and transformMartin Odersky2012-08-201-84/+96
| | | | | | | Two optimizations: (1) Make SymTree a class rather than a trait to allow faster access to symbol (2) Split itransform into several smaller methods and order cases according to expected frequency.
* Specialize hashCode in TypeRef from the generic MurmurHashCode3 implementation.Martin Odersky2012-08-201-1/+15
|
* Rework synchronization scheme of `UndoLog` for performance.Grzegorz Kossakowski2012-08-202-21/+42
| | | | | | | | | Introduced explicit locking mechanism that allows us to make public methods of `UndoLog` that take thunks as arguments final and thus `@inline`. Once inliner is able to cope with inlining methods with exception handlers we'll be able to get rid of significant (around 5%) number of thunk allocation.
* Mark logging methods in `SymbolTable` with `@inline`.Grzegorz Kossakowski2012-08-201-2/+4
| | | | | Those two methods contribute 2% of Function0 allocation when compiling `Vector.scala`.
* Optimizations to cut down on #closures createdMartin Odersky2012-08-206-28/+78
| | | | Driven by profile data.
* Made hashCode a method on Type to avoid megamorphic dispatchMartin Odersky2012-08-204-90/+79
| | | | | | | | | profiling data shows that accessing the hashCode field has a cost of about 10% of fully hot running times. We speculate that it's megamorphic dispatch which is costing us this much. Rewrote code so that UniqueType is not an abstract base class with the hashCode field. Also removed fingerPrinting bloom filter on findMember because it caused complexity and did not gain us anything accdoring to the tests. Made TypeVar an abstract case class to avoid extractor calls in TypeMap.
* No longer uses generic hashCode in UniqueType, since case class hashCode is ↵Martin Odersky2012-08-201-1/+1
| | | | now the same and faster.
* Replaced isTrivial lazy vals by custom scheme to save space.Martin Odersky2012-08-202-10/+43
|
* Optimizations of isTrivial fields and methodsMartin Odersky2012-08-201-8/+19
|
* More method hoisting.Martin Odersky2012-08-206-46/+72
| | | | | Also avoided systematically to map (_.tpe) on parameters in favor of lazy val paramTypes.
* Compilespeed improvements: Exists arguments and othersMartin Odersky2012-08-202-35/+78
| | | | | | | | | | | | It turns out that exists is not inlinable, even if put into List. We try to eliminate or hoist most closures passed to exists in Types. There are some other small improvements as well. -- (@gkossakowski): This commit contains also a fix to crasher prepared by @paulp. I squashed that commit and kept the test-case that came with it.
* pull request feedbackEugene Burmako2012-08-192-10/+4
|
* cleanup for macroExpandEugene Burmako2012-08-182-5/+12
| | | | | | | | | | | | | Error reporting is moved to ContextErrors to disentangle stuff in Macros.scala. With logics and error reporting intertwined it was an awful mess. Exceptions are used for the same reason. Instead of threading failures through the code polluting it with options/ifs, I outline the success path. It worked much better for typedMacroBody, but I'm also happy with the resulting code of macroExpand. To me a major factor towards applicability of exceptions was that they are short-lived and that there might be max one error per domain, after which we unconditionally bail.
* Merge pull request #1151 from scalamacros/topic/cleanupEugene Burmako2012-08-172-1/+21
|\ | | | | more cleanup in Macros.scala
| * more cleanup for typedMacroBodyEugene Burmako2012-08-172-8/+11
| |
| * shaves more than 150 lines off typedMacroBodyEugene Burmako2012-08-172-1/+18
| |
* | Merge pull request #1149 from paulp/topic/substmap210Grzegorz Kossakowski2012-08-171-6/+10
|\ \ | | | | | | Topic/substmap210
| * | Optimization in SubstMap.Paul Phillips2012-08-161-6/+10
| |/ | | | | | | | | | | | | | | Don't create a new type with the same symbol. This modification avoids the creation of 30K types and a similar number of symbols in a compile of trunk. Also cleaned up / deprecated a couple other type mappers.
* / Hunting down eliminable :: allocations.Paul Phillips2012-08-177-35/+41
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | With this commit, the number of :: allocations logged in total after individually compiling each scala file in src/compiler drops from 190,766,642 to 170,679,925. Twenty million fewer colon-colons in the world, it's a start. For some heavily used lists like List(List()) I made vals so we can reuse the same one every time, e.g. val ListOfNil = List(Nil) The modifications in this patch were informed by logging call frequency to List.apply and examining the heaviest users. >> Origins tag 'listApply' logged 3041128 calls from 318 distinguished sources. 1497759 scala.reflect.internal.Definitions$ValueClassDefinitions$class.ScalaValueClasses(Definitions.scala:149) 173737 scala.reflect.internal.Symbols$Symbol.alternatives(Symbols.scala:1525) 148642 scala.tools.nsc.typechecker.SuperAccessors$SuperAccTransformer.transform(SuperAccessors.scala:306) 141676 scala.tools.nsc.transform.SpecializeTypes$$anonfun$scala$tools$nsc$transform$SpecializeTypes$$specializedOn$3.apply(SpecializeTypes.scala:114) 69049 scala.tools.nsc.transform.LazyVals$LazyValues$$anonfun$1.apply(LazyVals.scala:79) 62854 scala.tools.nsc.transform.SpecializeTypes.specializedTypeVars(SpecializeTypes.scala:427) 54781 scala.tools.nsc.typechecker.SuperAccessors$SuperAccTransformer.transform(SuperAccessors.scala:293) 54486 scala.reflect.internal.Symbols$Symbol.newSyntheticValueParams(Symbols.scala:334) 53843 scala.tools.nsc.backend.icode.Opcodes$opcodes$CZJUMP.<init>(Opcodes.scala:562) ... etc.
* Merge pull request #1145 from scalamacros/topic/cleanupEugene Burmako2012-08-1624-193/+64
|\ | | | | cleanup of reflection and macros
| * Dominik's comments on api.MirrorsEugene Burmako2012-08-151-3/+3
| |
| * cleanup of reflection- and macro-related stuffEugene Burmako2012-08-1524-190/+61
| | | | | | | | | | | | mostly removes [Eugene] marks that I left back then and reviews related code some of those tokens got left in place, because I don't know to how fix them without imposing risks on 2.10.0
* | Merge pull request #1114 from scalamacros/topic/is-artifactPaul Phillips2012-08-154-17/+23
|\ \ | |/ |/| Introduces the `isArtifact` test for symbols
| * HIDDEN => ARTIFACTEugene Burmako2012-08-134-17/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This test is necessary in the API to tell apart useful synthetic symbols (such as accessors) and low-level compilation artifacts (such as $outer). However `isHidden` (as it's currently named in the compiler) is too generic. Hence I renamed it along with the corresponding flag. Now the test says `isArtifact` and the flag is named ARTIFACT. Despite being an improvement over the first version, `isArtifact` is still a bit unlucky. The name I like is `isImplementationArtifact`, but that's a mouthful to be used in compiler hacking. Moreover, IMPLEMENTATION_ARTIFACT looks weird. For a discussion about related stuff see: http://groups.google.com/group/scala-internals/browse_thread/thread/d04e762127737968 https://github.com/scala/scala/pull/1114
* | Merge pull request #1101 from scalamacros/ticket/5940Josh Suereth2012-08-141-0/+7
|\ \ | | | | | | SI-5940 impls are no longer in macro def pickles
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-21 05:56:25 +0000