summaryrefslogtreecommitdiff
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* SI-7442 Update bundled Fork/Join pool (JSR166y)Philipp Haller2013-05-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Updates ForkJoinPool and dependent classes to the latest jsr166y revisions: ForkJoinPool.java: Revision 1.185 Sat Feb 16 20:50:29 2013 UTC (2 months, 2 weeks ago) by jsr166 ForkJoinTask.java: Revision 1.100 Tue Feb 5 17:09:54 2013 UTC (3 months ago) by jsr166 ForkJoinWorkerThread.java: Revision 1.73 Wed Nov 21 19:54:39 2012 UTC (5 months, 2 weeks ago) by dl - Includes Akka-contributed `sun.misc.Unsafe` detection to support Android. See changeset 06d685c1bbd8a0d058ee8a3f374569f8097f2acc - Adds private `CountedCompleter` class. This class is only visible and used in `ForkJoinPool.java`. - Updates desired.sha1 for updated forkjoin.jar. - Updates binary compatibility whitelists to exclude package-private methods in the `forkjoin` package. - Also fixes SI-7438.
* SI-6363 deploys the updated starrEugene Burmako2012-09-196-6/+6
|
* prepping for the refactoringEugene Burmako2012-09-196-6/+6
| | | | | | | | | | Reification (both tree-based and type-based) should be avoided before we release 2.10.0-final, since it impairs reflection refactorings like the upcoming one. Also the upcoming refactoring moves tag materialization anchors, and we have to add them to fast track in advance, so that they are treated as macros later.
* New starr that does not depend on `@static`.Grzegorz Kossakowski2012-09-186-6/+6
| | | | | | Deployed a new starr that does not depend on `@static` annotation. The next step will be deleting `@static` from the library altogether.
* SI-6310 redeploys the starrEugene Burmako2012-09-146-6/+6
| | | | | Updates the starr with the changes introduced by the previous commit. Cleans up obsolete symbols required by the previous starr.
* rebuilt the starr after performance optimizationsEugene Burmako2012-08-206-6/+6
| | | | for those who use locker as their main development platform
* deploys a new starr that knows reify is a macroEugene Burmako2012-08-026-6/+6
| | | | | | | | | | | | | | | reify has just been moved to base.Universe from api.Universe, so the fast track in the old starr doesn't know about its existence. Therefore locker is built without reify having the MACRO flag, thus it won't be able to expand reify. Strictly speaking we don't need a new starr, because reify isn't used in scalac so, even though locker won't recognize reify, quick will be fine. However you don't know where a little sloppiness is going to bite you, so I took time to rebuild and push the new starr. It was as simple as "ant build starr.done" of the parent commit. No file mingling was required.
* reflect.makro => reflect.macros (Step I)Eugene Burmako2012-08-026-6/+6
| | | | | | | | | Builds a starr that uses stuff from scala.reflect.macros for macro activities. Crucial makro thingies (such as makro.Context or makro.internal.macroImpl) are temporarily left in place, because they are necessary for previous starr. Macro tests will be fixed in a dedicated commit, so that they don't pollute meaningful commits, making the life easy for reviewers and spelunkers.
* prepares our macro defs for refactoring (Step I)Eugene Burmako2012-08-026-6/+6
| | | | | | | | | | | | | | | | | | | | | | | In our codebase we have a bunch of macros, and some of those macros (namely, tag materialization macros and string context "f" formatter) are used inside the compiler itself. The logic of those macros is hardwired into starr's fast track, so it doesn't rely on any of the subsystems of the macro engine to be located, bound and executed. But to trigger this logic we need to color these macros as macros, i.e. as term symbols having the MACRO flag. Currently this works automatically, because fast track macros (the same as regular macros) have their rhs in the "macro ???" form. Having seen the "macro" keyword, the compiler knows that the corresponding def declares a macro and sets the MACRO flag. As the latest refactoring attempt has shown, the "macro" in "macro ???" is unnecessary and might stand in the way of macro refactorings. After all if some symbol is in the fast track registry, then it's definitely a macro. Hence I'm changing the compiler to not need the "macro" keyword in declarations of fast track macros anymore.
* SI-5999 deploys a new starrEugene Burmako2012-07-206-6/+6
| | | | That doesn't require Context.reify anymore.
* Moved cloneable class to package `scala.annotation`.Lukas Rytz2012-07-116-4/+6
| | | | Requires a new starr.
* adds the sha1 files of the new starr / stringContext.fDominik Gruntz2012-07-0613-13/+13
| | | | | | | | This commit provides the new sha1 codes of the new STARR. Moreover, it replaces the implementation of StringContext.f to `macro ???`. The implementation is magically hardwired into `scala.tools.reflect.MacroImplementations.macro_StringInterpolation_f` by the new STARR.
* removes ClassTag.String and TypeTag.StringEugene Burmako2012-07-023-3/+3
| | | | | | | | | | TypeTag.String is removed because it's unclear whether it should point to scala.Predef.String or to java.lang.String. ClassTag.String is removed to be consistent with TypeTag.String. This requires re-bootstrapping, because Definitions.scala in locker expects classTag[String] being automatically generated, whereas starr disagrees with locker on how to generate that class tag.
* Improves backward compatibility of manifestsEugene Burmako2012-07-023-3/+3
| | | | | | | | | | | | | | | | 1) type ClassManifest[T] = ClassTag[T] (solves a problem with toArray[T: ClassManifest] defined on most of the collections; if these types weren't aliases, then we won't be able to change the signature of that method to toArray[T: ClassTag], because that would break source compatibility for those who override toArray in their custom collections) 2) Compiler-generated manifests no longer trigger deprecation warnings (this is implemented by using ClassManifestFactory instead of ClassManifest and ManifestFactory instead of Manifest) 3) Deprecation messages got improved to reflect the changes that were introduced in 2.10.0-M4.
* 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.)
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-31 21:18:51 +0000