summaryrefslogtreecommitdiff
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* A remedy for Illegal class modifiers in lockerEugene Burmako2012-06-083-3/+3
| | | | | More details here: http://groups.google.com/group/scala-internals/browse_thread/thread/fbd6d9f923f1cc89
* Reverting 22c8dec5 and preventing bootstapping in scaladocVlad Ureche2012-06-083-3/+3
| | | | | Review by @dragos, @jsuereth. Required bootstrapping because the starr was ant tasks were invoking locker with -Ysourcepath instead of -sourcepath.
* TypeTag => AbsTypeTag, ConcreteTypeTag => TypeTagEugene Burmako2012-06-083-3/+3
| | | | | This protects everyone from the confusion caused by stuff like this: https://issues.scala-lang.org/browse/SI-5884
* removes array tagsEugene Burmako2012-06-083-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before 2.10 we had a notion of ClassManifest that could be used to retain erasures of abstract types (type parameters, abstract type members) for being used at runtime. With the advent of ClassManifest (and its subtype Manifest) it became possible to write: def mkGenericArray[T: Manifest] = Array[T]() When compiling array instantiation, scalac would use a ClassManifest implicit parameter from scope (in this case, provided by a context bound) to remember Ts that have been passed to invoke mkGenericArray and use that information to instantiate arrays at runtime (via Java reflection). When redesigning manifests into what is now known as type tags, we decided to explore a notion of ArrayTags that would stand for abstract and pure array creators. Sure, ClassManifests were perfectly fine for this job, but they did too much - technically speaking, one doesn't necessarily need a java.lang.Class to create an array. Depending on a platform, e.g. within JavaScript runtime, one would want to use a different mechanism. As tempting as this idea was, it has also proven to be problematic. First, it created an extra abstraction inside the compiler. Along with class tags and type tags, we had a third flavor of tags - array tags. This has threaded the additional complexity though implicits and typers. Second, consequently, when redesigning tags multiple times over the course of Scala 2.10.0 development, we had to carry this extra abstraction with us, which exacerbated the overall feeling towards array tags. Finally, array tags didn't fit into the naming scheme we had for tags. Both class tags and type tags sound logical, because, they are descriptors for the things they are supposed to tag, according to their names. However array tags are the odd ones, because they don't actually tag any arrays. As funny as it might sound, the naming problem was the last straw that made us do away with the array tags. Hence this commit.
* Introduces scala-reflect.jarEugene Burmako2012-06-083-2/+3
|
* The new reflectionEugene Burmako2012-06-082-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A must read: "SIP: Scala Reflection": https://docs.google.com/document/d/1Z1VhhNPplbUpaZPIYdc0_EUv5RiGQ2X4oqp0i-vz1qw/edit Highlights: * Architecture has undergone a dramatic rehash. * Universes and mirrors are now separate entities: universes host reflection artifacts (trees, symbols, types, etc), mirrors abstract loading of those artifacts (e.g. JavaMirror loads stuff using a classloader and annotation unpickler, while GlobalMirror uses internal compiler classreader to achieve the same goal). * No static reflection mirror is imposed on the user. One is free to choose between lightweight mirrors and full-blown classloader-based mirror (read below). * Public reflection API is split into scala.reflect.base and scala.reflect.api. The former represents a minimalistic snapshot that is exactly enough to build reified trees and types. To build, but not to analyze - everything smart (for example, getting a type signature) is implemented in scala.reflect.api. * Both reflection domains have their own universe: scala.reflect.basis and scala.reflect.runtime.universe. The former is super lightweight and doesn't involve any classloaders, while the latter represents a stripped down compiler. * Classloader problems from 2.10.0-M3 are solved. * Exprs and type tags are now bound to a mirror upon creation. * However there is an easy way to migrate exprs and type tags between mirrors and even between universes. * This means that no classloader is imposed on the user of type tags and exprs. If one doesn't like a classloader that's there (associated with tag's mirror), one can create a custom mirror and migrate the tag or the expr to it. * There is a shortcut that works in most cases. Requesting a type tag from a full-blown universe will create that tag in a mirror that corresponds to the callsite classloader aka `getClass.getClassLoader`. This imposes no obligations on the programmer, since Type construction is lazy, so one can always migrate a tag into a different mirror. Migration notes for 2.10.0-M3 users: * Incantations in Predef are gone, some of them have moved to scala.reflect. * Everything path-dependent requires implicit prefix (for example, to refer to a type tag, you need to explicitly specify the universe it belongs to, e.g. reflect.basis.TypeTag or reflect.runtime.universe.TypeTag). * ArrayTags have been removed, ConcreteTypeTag have been renamed to TypeTags, TypeTags have been renamed to AbsTypeTags. Look for the reasoning in the nearby children of this commit. Why not in this commit? Scroll this message to the very bottom to find out the reason. * Some of the functions have been renamed or moved around. The rule of thumb is to look for anything non-trivial in scala.reflect.api. Some of tree build utils have been moved to Universe.build. * staticModule and staticClass have been moved from universes to mirrors * ClassTag.erasure => ClassTag.runtimeClass * For the sake of purity, type tags no longer have erasures. Use multiple context bounds (e.g. def foo[T: ru.TypeTag : ClassTag](...) = ...) if you're interested in having both erasures and types for type parameters. * reify now rolls back macro applications. * Runtime evaluation is now explicit, requires import scala.tools.reflect.Eval and scala-compiler.jar on the classpath. * Macro context now has separate universe and mirror fields. * Most of the useful stuff is declared in c.universe, so be sure to change your "import c.universe._" to "import c.mirror._". * Due to the changes in expressions and type tags, their regular factories are now really difficult to use. We acknowledge that macro users need to frequently create exprs and tags, so we added old-style factories to context. Bottom line: almost always prepend Expr(...)/TypeTag(...) with "c.". * Expr.eval has been renamed to Expr.splice. * Expr.value no longer splices (it can still be used to express cross-stage path-dependent types as specified in SIP-16). * c.reifyTree now has a mirror parameter that lets one customize the initial mirror the resulting Expr will be bound to. If you provide EmptyTree, then the reifier will automatically pick a reasonable mirror (callsite classloader mirror for a full-blown universe and rootMirror for a basis universe). Bottom line: this parameter should be EmptyTree in 99% of cases. * c.reifyErasure => c.reifyRuntimeClass. Known issues: * API is really raw, need your feedback. * All reflection artifacts are now represented by abstract types. This means that pattern matching against them will emit unchecked warnings. Adriaan is working on a patch that will fix that. WARNING, FELLOW CODE EXPLORER! You have entered a turbulence zone. For this commit and its nearby parents and children tests are not guaranteed to work. Things get back to normal only after the "repairs the tests after the refactoring spree" commit. Why so weird? These twentish changesets were once parts of a humongous blob, which spanned 1200 files and 15 kLOC. I did my best to split up the blob, so that the individual parts of the code compile and make sense in isolation. However doing the same for tests would be too much work.
* macros: refactoring of fast track infrastructureEugene Burmako2012-06-082-2/+2
| | | | | | | | | As a result, hardwired macros don't need implementation stubs. This is very important, because in a few commits scala.reflect.makro.Context will move out from scala-library.jar. Also adding fast track entries doesn't require jumping through hoops with PDTs. It's as simple as defining PartialFunction[Tree, Any].
* New starr with adriaan's fix from 1b198fadd1 .Paul Phillips2012-05-143-3/+3
| | | | Since we still fail in locker.comp.
* cherry-picking important macro fixes from topic/reflectionEugene Burmako2012-05-122-2/+2
|
* rethinks tagsEugene Burmako2012-04-232-2/+2
| | | | | * introduces ArrayTag and ErasureTag * all type tags now feature erasure
* fixes SI-5680Eugene Burmako2012-04-202-2/+2
|
* Updates forkjoin.jar sha1Heather Miller2012-04-151-1/+1
|
* New starr with implicit classes and macros.Paul Phillips2012-04-123-3/+3
|
* GroundTypeTag => ConcreteTypeTagEugene Burmako2012-04-122-2/+2
|
* Next generation of macrosEugene Burmako2012-04-122-2/+2
| | | | | | | | | | | | | | | | | | | | | | Implements SIP 16: Self-cleaning macros: http://bit.ly/wjjXTZ Features: * Macro defs * Reification * Type tags * Manifests aliased to type tags * Extended reflection API * Several hundred tests * 1111 changed files Not yet implemented: * Reification of refined types * Expr.value splicing * Named and default macro expansions * Intricacies of interaction between macros and implicits * Emission of debug information for macros (compliant with JSR-45) Dedicated to Yuri Alekseyevich Gagarin
* The rest of the inline classes.Paul Phillips2012-03-1410-10/+5
| | | | | | | | | Have you often thought that programming is just like the movie 'Hackers', only with less rollerblading? Now that we have @inline skates, that last caveat can be retired. It's just like the movie 'Hackers'. Signed-off-by: Zero Cool
* Merge remote-tracking branch 'odersky/topic/inline' into merge-inlinePaul Phillips2012-03-145-0/+5
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: lib/scala-compiler.jar.desired.sha1 lib/scala-library-src.jar.desired.sha1 lib/scala-library.jar.desired.sha1 src/compiler/scala/reflect/internal/Definitions.scala src/compiler/scala/reflect/internal/Symbols.scala src/compiler/scala/tools/nsc/Global.scala src/compiler/scala/tools/nsc/transform/Constructors.scala src/compiler/scala/tools/nsc/transform/Erasure.scala src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala src/compiler/scala/tools/nsc/typechecker/Contexts.scala src/compiler/scala/tools/nsc/typechecker/RefChecks.scala src/compiler/scala/tools/nsc/typechecker/SyntheticMethods.scala src/library/scala/Function0.scala src/library/scala/Function1.scala src/library/scala/Function10.scala src/library/scala/Function11.scala src/library/scala/Function12.scala src/library/scala/Function13.scala src/library/scala/Function14.scala src/library/scala/Function15.scala src/library/scala/Function16.scala src/library/scala/Function17.scala src/library/scala/Function18.scala src/library/scala/Function19.scala src/library/scala/Function2.scala src/library/scala/Function20.scala src/library/scala/Function21.scala src/library/scala/Function22.scala src/library/scala/Function3.scala src/library/scala/Function4.scala src/library/scala/Function5.scala src/library/scala/Function6.scala src/library/scala/Function7.scala src/library/scala/Function8.scala src/library/scala/Function9.scala test/files/codelib/code.jar.desired.sha1 test/files/neg/anyval-children-2.check test/files/run/programmatic-main.check
| * New starr which has java.io.Serializable as a universal traitMartin Odersky2012-03-067-7/+7
| |
| * New binaries to support value classes in standard library (the ones two ↵Martin Odersky2012-02-228-3/+8
| | | | | | | | commits ago were a mistake).
* | New starr to support new fundamental laws of reality.Paul Phillips2012-03-143-3/+3
| | | | | | | | | | | | | | | | | | | | And grueling recovery from branch drift. Merges a portion (and only a portion) of topic/inline into master. The major changes which come with this merge are: AnyVal is unsealed, can be extended directly. ScalaObject is no longer with us.
* | Merge branch 'master' into merge-inlinePaul Phillips2012-03-141-1/+1
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: lib/scala-compiler.jar.desired.sha1 lib/scala-library-src.jar.desired.sha1 lib/scala-library.jar.desired.sha1 src/compiler/scala/reflect/internal/Definitions.scala src/compiler/scala/reflect/internal/Importers.scala src/compiler/scala/reflect/internal/Symbols.scala src/compiler/scala/reflect/internal/Trees.scala src/compiler/scala/reflect/internal/Types.scala src/compiler/scala/tools/nsc/Global.scala src/compiler/scala/tools/nsc/transform/Erasure.scala src/compiler/scala/tools/nsc/transform/LiftCode.scala src/compiler/scala/tools/nsc/transform/UnCurry.scala src/compiler/scala/tools/nsc/typechecker/RefChecks.scala src/compiler/scala/tools/nsc/typechecker/Typers.scala test/files/run/programmatic-main.check test/files/speclib/instrumented.jar.desired.sha1
| * New forkjoin jar as described in 76e9da2ca4 .Paul Phillips2012-02-251-1/+1
| |
| * Specialization action.Paul Phillips2012-02-143-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The crickets at http://www.scala-lang.org/node/11901 were in unanimous agreement that I should proceed as suggested. - No arguments to @specialize gets you 10/10, not 9/10 - Fixed bugs in AnyRef specialization revealed by trying to use it - Specialized Function1 on AnyRef. - Changed AnyRef specialization to use OBJECT_TAG, not TVAR_TAG. - Deprecated SpecializableCompanion in favor of Specializable, which has the virtue of being public so it can be referenced from outside the library. - Cooked up mechanism to group specializable types so we don't have to repeat ourselves quite so much, and create a few groups for illustrative purposes. I'm not too serious about those names but I used up all my name-thinking-up brain for the day. - Updated genprod and friends since I had to regenerate Function1. - Put tests for a bunch of remaining specialization bugs in pending. Closes SI-4740, SI-4770, SI-5267.
| * new starr based on v2.10.0-M1-167-g0ccd295a78Paul Phillips2012-02-063-3/+3
| |
* | Restored msil.Paul Phillips2012-02-041-1/+1
| |
* | Making AnyVal into a class instead of a trait.Paul Phillips2012-02-043-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -- traits can extend Any, AnyRef, or AnyVal -- classes can extend AnyRef or AnyVal but not Any. This breaks reflection for the moment as it smuggles AnyVal so far downstream that it's reflecting its way into bytecode (or something) but the following test case goes five for six as anticipated. trait Foo1 extends Any trait Foo2 extends AnyVal trait Foo3 extends AnyRef class Bar1 extends Any // fail @inline class Bar2 extends AnyVal class Bar3 extends AnyRef Eliminated various hijinx from definitions.
* | Guard List_apply from premature forcitude.Paul Phillips2012-02-043-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Solved the annotation cycle puzzle. Was being burned again by the hack which preferentially treats List() as Nil to avoid List's extractor. This commit includes a new starr which fully bootstraps. Also at this point traits can extend Any and will not be given an AnyRef parent (until erasure.) This is the case for AnyVal and NotNull.
* | New shas for bootstrap libs.Paul Phillips2012-02-033-3/+3
| | | | | | | | | | Free at last, free at last, of ScalaObject we're free at last. (With apologies to the Reverend, but the man had a way with words.)
* | Merge branch 'master' into topic/inlinePaul Phillips2012-02-031-1/+1
|\|
| * Fixed handling of empty keys in emitSWITCH.Grzegorz Kossakowski2012-02-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem of emitSWITCH not handling empty keys popped up when I tried to implement unfolding of pattern alternatives in genicode instead of in typers/explicitouter. This change makes perfect sense in isolation as bytecode allows LOOKUPSWITCHes that have only default case. I actually verified that this kind of bytecode is generated by javac when one has switch statement with only default case defined. Review by @paulp or @dragos.
* | Pushed new starr and updated desired shas.Paul Phillips2012-01-303-3/+3
|/
* Fix for erroneous bytecode generation.Paul Phillips2011-11-281-1/+1
| | | | | | | | | | | | | | | | | | | A remedy for an IllegalAccessError where generated bytecode referred to an inaccessible type. Closes SI-1430. Bonus materials: - tore out all the invokedynamic support. The shipped jdk7 implementation shows limited resemblance to the one this was written against; the code mostly serves to distract. (I think I could get invokedynamic working pretty quickly, except that it would mean having a codebase for java7 and one for 5-6, which is not a yak I wish to shave today.) - gave NullClass and NothingClass objects of their own, which allowed a nice polymorphic simplification of isSubClass, plus a couple other streamlinings.
* New starr based on r26060.Paul Phillips2011-11-233-3/+3
|
* New starr based on r26049.Paul Phillips2011-11-233-3/+3
|
* Moved meta annotations to annotation.meta, plus.Paul Phillips2011-10-103-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It took me a long time to find a trivial error while adjusting the annotation packages, so I spent even longer trying to make sure next time it would take me less time. It's the usual business of eliminating duplication and unnecessary indirection. Behavioral note: there was no consistency or deducible reasoning regarding when annotation checks would be performed against the typeSymbol directly (thus excluding annotation subclasses) or when they would do a subclass check. I saw no reason it shouldn't always be a subclass check; if the annotation isn't supposed to be subclassed it should be final, and if it is, then the subclasses had probably better not stop exhibiting the behavior of the base class. Example: this now draws deprecated warnings, but did not before. class bippy extends deprecated("hi mom", "burma shave") @bippy def f = 5 (The deprecation message isn't printed so we're not there yet, but closer.) There is some new internal documentation on annotations, sadly lacking in my famous ascii diagrams, and some new conveniences. Review by rytz.
* Shuffling classes around.Paul Phillips2011-10-013-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Old Man Reflection is coming home and he's not going to like finding out a bunch of beans have moved into his reflecting room. We had better evict those guys before he blows his stack. scala.reflect.*Bean* --> scala.beans.* scala.beans, that's kind of a fancy package name for some beans. I figure it's time to start fishing or cutting bait on this kind of thing. I don't even know what beans are, but if we're going to have them in the mainline, the least surprising place to find them is scala.beans. If we don't want to put them in scala.beans for whatever reason, then I say they don't belong in trunk at all. Bonus round: scala.annotation.target --> scala.beans.meta I don't know if there is any more unfortunate name for a package possible than "target". Maybe ".svn" or ".git" if you could have dots in package names. Package CVS wouldn't hit too hard these days. Package lib_managed? I'll try to come up with something. In any case this golden opportunity could not be squandered. There is a new starr included, because GenJVM contains all kinds of shooting-from-the-hip Bean-related name hardcoding. (Yes, still. I ran out of stones. So a few birds escape with their lives... this time.)
* Fixing the optimized build.Paul Phillips2011-09-101-1/+1
| | | | | | Continuations suddenly needs fjbg.jar on its classpath due to transitive dependency, no review.
* Discovered through jsuereth's work that a file ...Paul Phillips2011-07-291-1/+0
| | | | | | | Discovered through jsuereth's work that a file I should have removed way back in r17897 slipped the noose. Your free ride ends here, midpapi10.jar. No review.
* New starr based on r25394 to make the starr lib...Paul Phillips2011-07-283-3/+3
| | | | | | New starr based on r25394 to make the starr liberator's job easier, no review.
* Upgraded jline to use jansi 1.6 in the belief i...Paul Phillips2011-06-191-1/+1
| | | | | | Upgraded jline to use jansi 1.6 in the belief it will cure SI-4703. No review.
* Updated jline build to use xsbt 0.9.9 and rebui...Paul Phillips2011-05-291-1/+1
| | | | | Updated jline build to use xsbt 0.9.9 and rebuilt, no review.
* Rebuilt jline with some navigation improvements...Paul Phillips2011-05-261-1/+1
| | | | | | | | | | | | | | | | | Rebuilt jline with some navigation improvements (ctrl-T jumps forward a word, ctrl-X deletes the word in front of the cursor), thanks to Kenji Matsuoka for portions of this patch. Note to OSX users: TIL learned that ctrl-O is swallowed by the terminal and that unless you have some need for weird flow-control over serial connection control chars, you can recover it with stty discard undef And then you have ctrl-O for previous word and ctrl-T for next word. No review.
* Error reporting when the generated code size ex...Iulian Dragos2011-05-171-1/+1
| | | | | | Error reporting when the generated code size exceeds JVM limits (65,535 bytes per method). Closed #4573. review by extempore.
* New starr based on r24814, no review.Paul Phillips2011-04-243-3/+3
|
* Reverted a jline commit which had broken histor...Paul Phillips2011-04-231-1/+1
| | | | | Reverted a jline commit which had broken history search, no review.
* New starr based on r24804, no review.Paul Phillips2011-04-223-3/+3
|
* [MSIL] finer-grain debugging (steps one sub-exp...Miguel Garcia2011-04-201-1/+1
| | | | | [MSIL] finer-grain debugging (steps one sub-expression at time).
* Some patches to jline, and new jar.Paul Phillips2011-04-141-1/+1
| | | | | for improving the keybindings. No review.
* New starr based on r24749. No review.Paul Phillips2011-04-133-3/+3
|
* [MSIL] handling of volatile fields.Miguel Garcia2011-04-081-1/+1
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-27 21:16:55 +0000