removed unnecessary zero that was added to all matches...
providing runOrElse's type args explicitly: speeds up compilation, removes hacks needed to bootstrap
a bit of clean up to keep a list of list of treemakers, which encodes the match, until the last possible moment
this list of list is going to be the subject of the analyses coming next
no review
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26070 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
Was enjoying watching adriaan go for the record for redundant
implementations of repackExistential, but eventually everyone has to
join Club Code Reuse. Trimmed 2/3 of the implementations and put the
remaining third somewhere it can be enjoyed by all. Continued by tearing
apart and reassembling TypeVar. Review by moors.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26068 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
Another case where I tried to get into the performance party
but ended up playing dungeons and dragons next door. However I
did come away with an attractive tablecloth, which I draped over
Implicits.scala before waving my magic wand.
TRANSLATION: it's probably not faster but it's still better.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26067 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
Keep seeing what might be our single use of Tuple3#zipped so high in
the profiling output. I don't think it's zipped3's fault, more that it
figures prominently in a major consumer of compile time, but it's not
going to hurt to send it on its merry way.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26066 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
Trying to make hashcodes faster. Didn't achieve much on that front, so
redirected into structural/consistency issues. The latter was lacking
in terms of how/where "def seq" was defined. The documentation I can
find doesn't give me much hint that the sequential form of my sequential
collection might be a single-use iterator! (As in StringOps, ArrayOps.)
If that's intentional it should be in huge letters. I'm assuming for now
that it wasn't.
Also, there was this:
GenMapLike: def seq: Map[A, B]
GenSetLike: def seq: Set[A]
GenSeqLike: // nothing, returns Traversable
So I added some def seqs where I needed the more specific types for
my hashcode work. Hashcodewise, I broke the MurmurHash3 object into
a reusable class and a collections-specific object, and I deprecated
the methods which took GenTraversableOnce in favor of ones taking
TraversableOnce, because there's no reason the hashcode library should
have to know about things like "make sure to call seq before you
traverse or you'll be sorry." Exclude things by their type and you can
never make a mistake. End transmission.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26065 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
And kept carrying me until I was carried away. The changes are
mostly of the janitorial variety, just doing my part to make the
interesting logic visible without being buried in low level
compiler plumbing.
Added at least one seriously convenient convenience method:
tree modifyType fn
// equivalent to if (tree.tpe == null) tree else tree setType fn(tree.tpe)
This is the analogue to the recently added:
symbol modifyInfo fn
// same idea
It's like having our carpets steam cleaned when we can keep pushing
until machinery stays in the machine and the relevant logic stands
gloriously on top. You'll eventually exclaim, "I didn't even know these
carpets were that color!"
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26064 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
Took a more ambitious swing based on input from martin.
Eliminated the external map and gave annotations a more
useful inheritance hierarchy. Eliminated AnnotationInfoBase
and made LazyAnnotationInfo an AnnotationInfo (just like
LazyType is a Type.) Review by odersky.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26056 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
If use cases are present, the original member disappears from the list. References SI-5054, but needs more work on the html part.
If use cases are present along with links, scaladoc doesn't crash anymore. Closes SI-4898.
Review by kzys.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26048 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
- The 'partest' ant task gets a new 'compilerargs' element for scalac options (like in scalacfork and javac).
- Fixed argument list handling in partest task.
- Further improvements to argument list handling for all ant tasks.
- Fixed argument list handling in DirectTest (used by partest shell scripts)
- Fixed path handling in several test cases.
Closes SI-622. Review by phaller.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26047 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
"According to the spec this code should not be legal. Disabling for now." Need to come back and either make it work or (more likely) make nsc reject the test)
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26046 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
I noticed a long time ago that calls to def annotations in Symbols
figured way, way too high in profiling output, but my earlier efforts to
modify it failed because I didn't understand the "accidental" service
it was supplying. Here is the key piece of the former implementation of
annotations:
- val annots1 = initialize.rawannots map {
- case x: LazyAnnotationInfo => x.annot()
- case x: AnnotationInfo => x
- } filterNot (_.atp.isError)
The first thing you might notice is that because it calls initialize,
any call to either annotations or (more frequently) a method like
"hasAnnotation" causes a symbol to be initialized. The upshot is that
taking away tens of thousands of calls to initialize means a certain
amount of "free lunch" is over.
The second thing is that this implementation lead to the allocation of
a new list on every call to annotations. 99.999% of the time it's the
same elements in the list. The fact that rawannots is typed as a list of
"AnnotationInfoBase" which may as well be AnyRef means you can't even
use mapConserve, but even mapConserve would be an abuse of the garbage
collector given how infrequently there is any change.
So here's what we have now:
1) Annotations are delivered from trees to symbols by way of an
externally positioned map, not a field on the symbol. It's done once.
The only overhead on a call to annotations now is a null check.
2) I added a small sprinkling of calls to initialize in sensible
locations.
3) The profiler impact is hard to believe, but this is reproducible.
For whatever reason the non-profiler wall clock time impact is not
as impressive.
My profiling target was the compilation of these 15 files:
src/library/scala/collection/generic/G*.scala
Before this patch, heap usage peaked at 60MB. After, 35MB. 40% drop in
profiler measured time elapsed. (Again, it's not like that outside the
profiler.) About a 55% drop in number of allocations. About a 40% drop
in total size of allocations.
+----------------------+------------------+-----------------+-----------------+
| Name | Time Diff (ms) | Old Time (ms) | New Time (ms) |
+----------------------+------------------+-----------------+-----------------+
| +---<All threads> | -19,569 | 52,496 | 32,926 |
+----------------------+------------------+-----------------+-----------------+
+----------------------------+--------------------+-----------------------+
| Packages and Classes | Objects (+/-) | Size (+/-) |
+----------------------------+--------------------+-----------------------+
| +---<Objects by classes> | -877,387 -56 % | -26,425,512 -37 % |
| | | | |
| +---char[] | -43,308 -2 % | -2,756,744 -3 % |
| | | | |
| +---java | -67,064 -3 % | -2,027,264 -2 % |
| | | | |
| +---scala | -745,099 -48 % | -19,021,760 -26 % |
+----------------------------+--------------------+-----------------------+
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26042 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
If you run a jar directly, like
scala foo.jar
Then if a Class-Path attribute is present in the jar manifest, the
classpath will be constructed from that instead of the arguments. Some
things remain to be determined, like whether it's supposed to replace
a classpath given on the command line or supplement it, and whether
the master jar should be on the classpath or only and exactly the jars
listed in the manifest.
There's a really nice test case, which won't be run of course, but I
can't stand going any further without tests for these hard to test on
all platforms things. The faux .check file shows what I see.
Closes SI-4355, review by harrah.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26041 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
Closes SI-1510 which is actually caused by a bad command line string when the path to Java contains a space, and not by long path names per se. References SI-622 since this commit fixes the specific error described there (not closing because follow-up bugs remain).
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26040 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
The complete histogram of results for "commonOwner" until this
patch, when building quick.lib and quick.comp:
Calculated common owner Occurrences
----------------------- -----------
NoSymbol 299,242
Everything Else 0
Since I'm always paranoid somebody will think I'm the one who
broke such things in the first place, I got in the gitmobile and
fingered the responsible party.
Looks OK when it was checked in: r3930, Feb 4 2005. And it was smooth
sailing until... r4026, Mar 22 2005. So 6 1/2 weeks of goodness for poor
commonOwnerMap, to be followed by 6 1/2 years of endless NoSymboldom. In
2005 I was still making a living grifting strangers in seedy gambling
halls, so I think I'm in the clear. Here's the exact spot.
ae0da87d1a (L12L991)
I found this while trying to figure out why we are generating so many
refinements. This doesn't fix any of that, but maybe takes us a notch
closer. Review by odersky.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26038 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
providing a richer TreeMakers interface in hopes of performing analyses and optimizations on TreeMakers rather than the trees they generate
not sure yet, though: on the one hand, working on raw trees removes the unsoundness potential due to the extra indirection layer
on the other hand, indirection is nice, and recovering the meaning lost in translation from richer treemakers to raw trees is such a drag
no review
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26036 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
farewell ProtoTreeMaker, we hardly knew ye
needed one more repeatedToSeq for pos/annotDepMethType when compiling under -Xexperimental and -Yvirtpatmat... I wonder why this hadn't failed before
outer check for extractor type test: definitely need it for case classes, and probably makes sense for user-defined extractors as well
no review
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26034 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
There's every hint that it's a requirement that a TypeApply have
non-empty typeArgs, but testing for and handling the empty condition
is done irregularly. Made a mkTypeApply which handles the isEmpty case
(returning "fun" unchanged.) Also unified most of the variations of
casts under one umbrella. Review by moors.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26033 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
Painstakingly winnowed out the most frequently duplicated code
sequences related to symbol cloning and substitution. Created
canonical methods to perform these actions and documented them.
Key methods include:
def createFromClonedSymbols[T](syms: List[Symbol], tpe: Type)(creator: (List[Symbol], Type) => T): T
def deriveSymbols(syms: List[Symbol], symFn: Symbol => Symbol): List[Symbol]
def deriveType(syms: List[Symbol], symFn: Symbol => Symbol)(tpe: Type): Type
Many example usages enclosed with commit.
I did lots of timing tests, I find no material difference before and
after. Actually I won by four seconds in this incarnation:
Before - Total time: 7 minutes 55 seconds
After - Total time: 7 minutes 51 seconds
Review by moors.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26032 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
Many thanks to Jordi Salvat i Alabart for catching this.
Universal equality is a formidable foe when it comes to avoiding
this kind of mistake. Closes SI-5206, no review.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26031 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
(The original commit in r26026, reverted in r26027, used the new compilerargs
element in the Scala build -- we cannot do this until it's in starr.)
- Revert r25995 which was fixing it only partly and in the wrong place.
- Properly encode argument files for scalac in scalac ant task.
- Allow 'compilerarg' elements in scalac ant task (like in ant's built-in
javac task) to allow passing extra parameters like plugindir path with
proper encoding of spaces and file names.
- Fix space handling in get-scala-revision.bat.
Closes SI-3047.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26030 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
This reverts the previous commit due to failure to build:
BUILD FAILED
/scratch/trunk1/build.xml:639: scalacfork doesn't support the nested "compilerarg" element.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26027 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
Revert r25995 which was fixing it only partly and in the wrong place.
Properly encode argument files for scalac in scalac ant task.
Allow 'compilerarg' elements in scalac ant task (like in ant's built-in
javac task) to allow passing extra parameters like plugindir path with
proper encoding of spaces and file names, and use it in the Scala build.
Fix space handling in get-scala-revision.bat.
(Patch by Stefan Zeiger.) Closes SI-3047.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26026 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
scalac (ant.Scalac)
- added attributes `dependencyfile`, `explaintypes`, `nobootcp`,
`nowarn` and `usejavacp`
- added support for nested element `compilerarg` (see Ant manual)
in order to pass prefix settings (eg. -J-Xbootclasspath, -Ddebug=true)
to nsc.CompileClient
- updated list of permissible values for compiler phases
fsc (ant.FastScalac)
- added attributes `ip4` and `maxIdle` in addition to `reset`, `server`
and `shutdown` (and forwards them to nsc.CompileClient)
- also forwards prefix settings `jvmargs` and `defines`, and
boolean settings `explaintypes`, `nospecialization`, `nowarn`,
`optimise`, `unchecked` and `usejavacp` to nsc.CompileClient
- fixed CompileClient.process if-test
Nota Bene
I added the following element to partest.PartestTask (commit is pending)
in order to automatically test the Scala Ant tasks:
<anttests dir="${partest.dir}/${partest.srcdir}/ant" includes="*build.xml"/>
Here is the output:
[user@localhost scala]$ ant test.ant
Buildfile: /home/user/workspace/scala/build.xml
[echo] Forking with JVM opts: -Xms1536M [...]
init:
[echo] Build number is '2.10.0.r26022-b20111116212958'
[echo] Built 16 November 2011, 21:29:58 [...]
[...]
test.ant:
[partest] Running ant task tests
[partest] testing: [...]/files/ant/fsc-build.xml [ OK ]
[partest] testing: [...]/files/ant/scaladoc-build.xml [ OK ]
[partest] testing: [...]/files/ant/scalac-build.xml [ OK ]
[partest] Test suite finished with no failures.
BUILD SUCCESSFUL
Total time: 12 seconds
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26023 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
i think it couldn't find javac, since it was hardwired to JAVAHOME/bin/javac, but that didn't exist in the windows jre/ directory structure
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26020 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
moors