summaryrefslogtreecommitdiff
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* Remove further references to forkjoinJason Zaugg2015-07-151-1/+0
| | | | | | | | | | | | | | | | | Use j.u.c.Forkjoin directly in active and disabled tests Remove bitrotted benchmarks code I was going to update these to use `java.util.concurrent.ForkJoin` directly, instead of our deprecated stubs. But most of them don't compile anymore (e.g. scala.testing.Benchmark has been removed, ClassTag imports missing). While I'm all for benchmarks, we should have large swathes of code checked in that isn't at compiled and run automatically. I'm happy to help someone resurrect these in a suitable form.
* No longer support unreleased STARR.Adriaan Moors2013-11-256-6/+0
| | | | | | | | | | | | | | | | | | | | | | | The STARR ("stable reference") compiler is used to bootstrap the compiler. It is now always resolved from maven, based on the `starr.version` property (stored in `versions.properties`). Before, we used the `.desired.sha1` mechanism to pull a set of jars that define the compiler used to build locker ("local reference"), which then builds quick. From now on, we only support officially released versions of STARR. Milestones are allowed of course, which means that, instead of breaking change, STARR evolution must support old and new behavior for at least one milestone cycle. For local development, use the `replacestarr` target as before. It builds quick (core only) and publishes it to your local maven repo with a generated version number, which is saved as `starr.version` in `build.properties` for convenience (overriding `versions.properties`), so that your next build will use this version of the compiler for STARR. You may now think of STARR as STAble Reference Release -- if you will.
* Merge pull request #2743 from retronym/topic/gitignore-in-repoAdriaan Moors2013-07-181-15/+0
|\ | | | | Commit .gitignore directly
| * Commit .gitignore directlyJason Zaugg2013-07-171-15/+0
| | | | | | | | | | | | | | | | | | | | | | | | Rather than relying on the cloner to copy the provided gitignore.SAMPLE files. This finishes the job started in c48509598, mostly by reverting that commit and moving the two existing SAMPLE files to the final destinations. Use `.git/info/exclude` to augment the list of patterns with entries specific to your workflow.
* | STARR: use 2.11.0-M4, built with 2.11.0-M3Adriaan Moors2013-07-166-6/+6
|/ | | | | | | | | | | | | | | | | | | | | | | | Replaced starr jars with 2.11.0-M4, built with Scala 2.11.0-M3. I used `ant replacestarr-opt -Dstarr.use.released=1`, with `starr.number`: ``` starr.version=2.11.0-M3 ``` Then pushed the jars to artifactory after moving `lib/jline.jar` out of the way, as it's no longer "desired" (i.e., not pulled from artifactory). Its presence seemed to break `./push-binary-libs.sh $ARTIFACTORY_USER $ARTIFACTORY_PASS`. You can by-pass the custom starr artifact download and use a (released) version of Scala by changing your `build.properties` to include ``` starr.use.released=1 ``` You may optionally change `starr.version` in `starr.number` to whichever version that maven can resolve for you.
* Unfork jline: use vanilla jline 2.11 as a dependency.Adriaan Moors2013-07-051-1/+0
| | | | | | | | Notes: - no longer specifying terminal by class name in scripts (using 'unix') - jline doesn't need a separate jansi dependency; it includes its own version according to: http://mvnrepository.com/artifact/jline/jline/2.11
* Updates .gitignore files.Lex Spoon2013-06-261-0/+15
|
* new starr that supports macro ???Eugene Burmako2013-05-276-6/+6
|
* Merge v2.10.1-326-g4f8c306' into merge/v2.10.1-326-g4f8c306-to-masterJason Zaugg2013-05-179-9/+7
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ================================================================ Merge commit 'v2.10.1-326-g4f8c306' into merge/v2.10.1-326-g4f8c306-to-master Conflicts: src/compiler/scala/tools/nsc/typechecker/SuperAccessors.scala src/reflect/scala/reflect/runtime/JavaMirrors.scala ================================================================ Merge -s ours 4e64a27 ([nomaster commit range]) ================================================================ Merge commit '0ae7e55' into merge/v2.10.1-326-g4f8c306-to-master Conflicts: src/compiler/scala/tools/nsc/typechecker/Macros.scala
| * Updated jline and rebuilt.Paul Phillips2013-04-241-1/+1
| | | | | | | | | | Two years of atrophy. Now using sbt 0.12.3 and latest versions of jansi, etc.
| * New starr based on b7840d6b41.Paul Phillips2012-12-286-6/+6
| | | | | | | | | | Seven weeks is a good amount of time between starrs, and I'm going nutso for -Xdev during locker.
| * Merge commit 'refs/pull/1718/head' into merge-msil-genjvm-deletePaul Phillips2012-12-061-1/+0
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * commit 'refs/pull/1718/head': Expunged the .net backend. Conflicts: build.detach.xml build.examples.xml build.xml project/Build.scala src/compiler/scala/tools/ant/Scalac.scala src/compiler/scala/tools/nsc/Global.scala src/compiler/scala/tools/nsc/settings/StandardScalaSettings.scala src/compiler/scala/tools/nsc/symtab/clr/TypeParser.scala src/compiler/scala/tools/nsc/transform/Mixin.scala src/intellij/compiler.iml.SAMPLE tools/buildcp
| | * Expunged the .net backend.Paul Phillips2012-12-051-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | It lives on in a branch born from this commit's parent. It's abrupt; no attempt is made to offer a "smooth transition" for the serious msil userbase, population zero. If anyone feels very strongly that such a transition is necessary, I will be happy to talk you into feeling differently.
| * | SI-6769 Removes GenJVM backendJames Iry2012-12-051-1/+0
| |/ | | | | | | | | Get rid of GenJVM and everything that refers to it. Also get rid of GenAndroid since it's dead code that refers to GenJVM.
| * New starr based on 4f98d50bc2 .Paul Phillips2012-11-086-6/+6
| | | | | | | | | | Contains the extension method naming change, in the interests of unbreaking the sbt build for a while.
* | 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-07 12:01:21 +0000