| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ \ \ \
| | | | |
| | | | |
| | | | | |
'axel22/feature/pc-execution-contexts', 'VladUreche/issue/5527-noPos' and 'retronym/topic/tolerant-interpolator' into develop
|
| | | | | |
| | | | |
| | | | |
| | | | | |
f"${foo}" is treated like f"${foo}%s".
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
By making the comment tree node transparent. Reverts previous change
in cfb04ef065. Will mark the bug 5527 as WONTFIX, because the effort
of fixing leaking comments is too great.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
During shutdown, other threads can still post work items on the work queue. They will never be serviced,
leading to clients waiting forever.
The fix is to replace the implementation of the queue with a 'always fail' implementation during shutdown.
Review by @odersky.
|
| | |_|/ /
|/| | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Has to be somewhere more directly tied to structural
refinements. See run/lub-visibility.scala before/after
output for motivation. Closes SI-5534.
|
| |/ / /
| | |
| | |
| | |
| | |
| | | |
I think this fixes SI-2296, the inability to access java protected
members from a trait which extends a java class. Counterexamples
appreciated. Closes SI-2296. Review by @dragos.
|
| | |/
|/|
| |
| | |
Simplifies the implementation a bit.
|
| | |
| |
| |
| | |
Closes SI-5537.
|
| | | | |
| | \ | |
| | \ | |
| | \ | |
| |\ \ \ \
| | | |/
| | |/|
| | | | |
'axel22/feature/pc-execution-contexts' and 'TiarkRompf/SI-5538'; commit 'd92bcb5302be04104abe2db6cf92620c4cd7255e' into develop
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Parallel collections now get the execution context task support
which by default picks the execution context from the scala concurrent
package. This execution context task support forwards calls to
either a fork join task support or the thread pool task support.
Additionally, the default execution context now uses either a fork join pool
or a thread pool executor, depending on the JVM vendor and version.
|
| | | |\|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/library/scala/collection/parallel/Combiner.scala
src/library/scala/collection/parallel/ParIterableLike.scala
src/library/scala/collection/parallel/mutable/ParCtrie.scala
|
| | | | | |
|
| | | | | |
|
| | | | |\ |
|
| | | | | |\ \
| | | | | | |
| | | | | | |
| | | | | | | |
'szabolcsberecz/SI-5380' and 'scalamacros/ticket/5532' into develop
|
| | | | | | | | |
|
| | | | | | |/ |
|
| | | | | |\ \
| | | | | |/
| | | | |/|
| | | | | |
| | | | | | |
Conflicts:
src/compiler/scala/tools/nsc/transform/UnCurry.scala
|
| | | | | | | |
|
| | | | | | | |
|
| | | | |/ /
| | | | |
| | | | |
| | | | | |
It's unfortunate the things one must do to see @inline go through.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This required a bit of refactoring in the tasks objects and implementations
of various operations. Combiners now hold a reference to a tasksupport
object and pass it on to their result if `resultWithTaskSupport` is called.
Additionally, several bugs that have to do with CanBuildFrom and combiner
resolution have been fixed.
|
| | | |/ /
| |/| | |
|
| |/ / / |
|
| | | |
| | |
| | |
| | | |
into develop
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Removed all the trailing whitespace to make eugene happier.
Will try to keep it that way by protecting at the merge level.
Left the tabs in place because they can't be uniformly changed
to spaces, some are 2, some are 4, some are 8, whee.
|
| | | |
| | |
| | |
| | | |
Eliminated annotation and custom phase. Kept SYNCHRONIZED flag.
|
| |\ \ \
| |_|/
|/| | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The following:
def f = synchronized { ... }
will be rewritten to:
<synchronized> def f = ...
which is then emitted to the classfile with the synchronized flag set.
Inlining of such transformed methods are disabled for now
This transformation is not done on methods defined in a trait.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Since there is no useful information in such a message.
|
| | | |
| | |
| | |
| | |
| | | |
An object in a pattern should have type "Foo.type" just as
objects not in patterns do. Closes SI-5406. Review by @moors.
|
| | | |
| | |
| | |
| | |
| | | |
Hacked filename into message to alleviate meaningless
"_$1 defined twice" error condition. References SI-4893.
|
| | | |
| | |
| | |
| | | |
From the extempore archive of already implemented things.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Have to pass an empty classpath to java if we put the boot libs
on the classpath, otherwise it puts the default "." on there.
Closes SI-5528.
|
| |\ \ \
| | | |
| | | | |
Fixed deploy script for nightly
|
| | | | | |
|
| |\ \ \ \ |
|
| | | |_|/
| |/| |
| | | |
| | | | |
range positions
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Quieting things down. Fixed some things revealed by quieter
logs, like forwarders being generated for superaccessors.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I guess these are self-explanatory.
@inline final def afterErasure[T](op: => T): T = afterPhase(currentRun.erasurePhase)(op)
@inline final def afterExplicitOuter[T](op: => T): T = afterPhase(currentRun.explicitouterPhase)(op)
...
@inline final def beforeTyper[T](op: => T): T = beforePhase(currentRun.typerPhase)(op)
@inline final def beforeUncurry[T](op: => T): T = beforePhase(currentRun.uncurryPhase)(op)
This commit is basically pure substitution. To get anywhere interesting
with all the phase-related bugs we have to determine why we use atPhase
and capture that reasoning directly. With the exception of erasure, most
phases don't have much meaning outside of the compiler. How can anyone
know why a block of code which says atPhase(explicitouter.prev) { ... }
needs to run there? Too much cargo cult, and it should stop. Every usage
of atPhase should be commented as to intention.
It's easy to find bugs like
atPhase(uncurryPhase.prev)
which was probably intended to run before uncurry, but actually runs
before whatever happens to be before uncurry - which, luckily enough, is
non-deterministic because the continuations plugin inserts phases
between refchecks and uncurry.
% scalac -Xplugin-disable:continuations -Xshow-phases
refchecks 7 reference/override checking, translate nested objects
uncurry 8 uncurry, translate function values to anonymous classes
% scalac -Xshow-phases
selectivecps 9
uncurry 10 uncurry, translate function values to anonymous classes
Expressions like atPhase(somePhase.prev) are never right or are at best
highly suboptimal, because most of the time you have no guarantees about
what phase precedes you. Anyway, I think most or all atPhases expressed
that way only wanted to run before somePhase, and because one can never
be too sure without searching for documentation whether "atPhase" means
before or after, people err on the side of caution and overshoot by a
phase. Unfortunately, this usually works. (I prefer bugs which never work.)
|
| | | | | | |
| | \ \ \ | |
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
'heathermiller/issue/5523' into develop
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This commit includes Doug Lea's updates to ForkJoinPool, as of January
25th, 2012. Details of the changes and performance improvements
available at: http://markmail.org/message/323vxzn6irkk5yrg.
The ForkJoinPool used in this commit comes from the most recent JSR166y.
Additionally, also included are minimal changes to parts of the Scala
Actors library which interface with the ForkJoinPool, as the
ForkJoinPool's interface has changed (prior to the release of Java 7)
since we last updated it for the Scala 2.8 release.
Of note- this is part of the planned overhaul of scala.concurrent,
and corresponds to ticket SI-5523.
For testing this was built on JDK 1.6, and passes all tests on both
JDK 1.5 and 1.6.
A new forkjoin.jar is necessary prior to applying these changes.
Using this source, the new jar can be built by running:
ant newforkjoin forkjoin.done
This creates a new forkjoin.jar in build/libs/. It must replace
lib/forkjoin.jar.
|
| | |/ / / / |
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As I peer into various longstanding crashes involving specialization,
mixin composition, and super calls, I find a very common reason for
logic to go wrong is ignoring or misusing atPhase. This is hardly
surprising given how much of a secret black art the whole process of
atPhase-ing is. I predict with some confidence that at least half the
calls to atPhase in the compiler are at best unnecessary and more likely
wrong; similarly, we are missing at least as many calls in other places.
Herein we find the following:
1) log messages now include not only the current "at" phase, which
in isolation was very confusing because it means what is logged is
dependent on the arbitrary jumps performed by atPhase, but the entire
"phase stack", anchored by the "global phase".
The leftmost phase is the global phase, the one set in Global which
proceeds in a predictable fashion from parser to terminal. That's the
one we usually mean when we talk about during which phase something
happens. The others (prefixed with an arrow) are calls to atPhase which
have not yet returned.
// example, assuming we've given -Ylog:expl
scala> atPhase(currentRun.explicitouterPhase)(log("hi mom"))
[log terminal(->typer ->explicitouter)] hi mom
2) A message will be logged if either the globalPhase matches,
or the current "at" phase does. So -Ylog:erasure will log all the
messages from the phase we think of as erasure, and also all those
from any phase run inside of atPhase(erasurePhase) { ... }
(except for times when that block uses atPhase to alter the
phase yet again - it only looks at the top of the atPhase stack.)
// example
% scalac -Ydebug -Ylog:refchecks foo.scala
[log refchecks] overriding-pairs? method size in trait TraversableOnce ...
[log mixin(->refchecks)] rebindsuper trait GenTraversable <none> <notype> false
3) A number of debug/power oriented functions. All of these
limit their results to phase transitions during which some change took
place, as measured by the result of `op`, compared with ==.
def afterEachPhase[T](op: => T): List[(Phase, T)]
def changesAfterEachPhase[T](op: => List[T]): List[ChangeAfterPhase[T]]
def logAfterEveryPhase[T](msg: String)(op: => T)
def describeAfterEachPhase[T](op: => T): List[String]
def describeAfterEveryPhase[T](op: => T): String
def printAfterEachPhase[T](op: => T): Unit
Some examples:
scala> printAfterEachPhase(ListClass.info.members.size)
[after 1/parser ] 219
[after 11/tailcalls ] 220
[after 12/specialize ] 322
[after 14/erasure ] 361
[after 18/flatten ] 357
scala> printAfterEachPhase(termMember(PredefModule, "implicitly").defString)
[after 1/parser ] def implicitly[T](implicit e: T): T
[after 10/uncurry ] def implicitly[T](e: T): T
[after 14/erasure ] def implicitly(e: Object): Object
Try this at home:
scala> changesAfterEachPhase(ListClass.info.nonPrivateMembers map (_.defString)) foreach println
|
| | | | |
| | | |
| | | |
| | | | |
perRunCaches and call clearAll from the presentation compiler
|
| | |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
contains whitespaces.
Assume -Xplugin is given the value
C:\Programs Files\plugins\Aplugin.jar C:\Programs Files\plugins\Bplugin.jar
Calling ``tryToSetFromPropertyValue`` with the above value will always result
in a total mess, no matter what, because it will split the string at
whitespaces.
The proposed solution is to change the implementation of
``tryToSetFromPropertyValue`` to use `,` (comma) as the splitting character
Further, I'm quite convinced that the current implementation of
``MultiStringSetting.tryToSetFromPropertyValue`` has never worked, that is why I
did not create an overload of ``tryToSetFromPropertyValue`` where the splitting
character (or string) can be passed as argument.
There is also an Eclipse Scala IDE associated to this issue:
http://scala-ide-portfolio.assembla.com/spaces/scala-ide/tickets/1000917
|
