| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Seven weeks is a good amount of time between starrs,
and I'm going nutso for -Xdev during locker.
|
| |
|
|
|
| |
Contains the extension method naming change, in the
interests of unbreaking the sbt build for a while.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Deployed a new starr that does not depend on `@static` annotation.
The next step will be deleting `@static` from the library
altogether.
|
| |
|
|
|
| |
Updates the starr with the changes introduced by the previous commit.
Cleans up obsolete symbols required by the previous starr.
|
| |
|
|
| |
for those who use locker as their main development platform
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
That doesn't require Context.reify anymore.
|
| |
|
|
| |
Requires a new starr.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
More details here:
http://groups.google.com/group/scala-internals/browse_thread/thread/fbd6d9f923f1cc89
|
| |
|
|
|
| |
Review by @dragos, @jsuereth. Required bootstrapping because the starr was
ant tasks were invoking locker with -Ysourcepath instead of -sourcepath.
|
| |
|
|
|
| |
This protects everyone from the confusion caused by stuff like this:
https://issues.scala-lang.org/browse/SI-5884
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
