| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
viktorklang/wip-SI7383-EC-prepare-in-Future-apply-2.10-√
SI-7383 - call ExecutionContext.prepare in Future.apply
|
| |
| |
| |
| | |
capturing local context like ThreadLocals and then re-establishing them prior to execution, as per intention of EC.prepare
|
|\ \
| | |
| | | |
SI-7442 Update bundled Fork/Join pool (JSR166y)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- 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.
|
|\ \ \
| | | |
| | | | |
makes sense of implicit macros!
|
| | | |
| | | |
| | | |
| | | | |
Shame-driven development at its best.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Despite inferImplicit usually being nice and buffering errors, apparently
it can also throw DivergentImplicit exception. This patch catches it and
only reports it if silent is set to false.
NOTE: we no longer have the DivergentImplicit exception in master,
so this commit only makes sense in 2.10.x.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
silent = true now throws a TypecheckException even if we don't know why
an implicit search has failed (i.e. if context.hasErrors is false).
NOTE: this commit is a part of a pull request for 2.10.x, which makes sense of
implicit macros. Everything in that pull request is [nomaster] due to one
reason or another. This commit would work equally well in both 2.10.x and
master, but I'm marking it as [nomaster] as well, because I'm anyway going
to resubmit the whole pull request into master soon, so there's no reason
to introduce additional confusion.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Since we don't throw exceptions for normal errors it was a bit odd
that we don't do that for DivergingImplicit.
As SI-7291 shows, the logic behind catching/throwing exception
was broken for divergence. Instead of patching it, I rewrote
the mechanism so that we now another SearchFailure type related
to diverging expansion, similar to ambiguous implicit scenario.
The logic to prevent diverging expansion from stopping the search
had to be slightly adapted but works as usual.
The upside is that we don't have to catch diverging implicit
for example in the presentation compiler which was again showing
that something was utterly broken with the exception approach.
NOTE: This is a partial backport of https://github.com/scala/scala/pull/2428,
with a fix for SI-7291, but without removal of error kinds (the former is
absolutely necessary, while the latter is nice to have, but not a must,
therefore I'm not risking porting it to 2.10.x). Also, the fix for SI-7291
is hidden behind a flag named -Xdivergence211 in order not to occasionally
break the code, which relies on pre-fix behavior.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Imagine a macro writer which wants to synthesize a complex implicit
Complex[T] by making recursive calls to Complex[U] for its parts.
E.g. if we have `class Foo(val bar: Bar)` and `class Bar(val x: Int)`,
then it's quite reasonable for the macro writer to synthesize
Complex[Foo] by calling `inferImplicitValue(typeOf[Complex[Bar])`.
However if we didn't insert `info.sym.isMacro` check in `typedImplicit`,
then under some circumstances (e.g. as described in http://groups.google.com/group/scala-internals/browse_thread/thread/545462b377b0ac0a)
`dominates` might decide that `Bar` dominates `Foo` and therefore a
recursive implicit search should be prohibited.
Now when we yield control of divergent expansions to the macro writer,
what happens next? In the worst case, if the macro writer is careless,
we'll get a StackOverflowException from repeated macro calls. Otherwise,
the macro writer could check `c.openMacros` and `c.openImplicits` and
do `c.abort` when expansions are deemed to be divergent. Upon receiving
`c.abort` the typechecker will decide that the corresponding implicit
search has failed which will fail the entire stack of implicit searches,
producing a nice error message provided by the macro writer.
NOTE: the original commit from macro paradise also introduced a new
class, which encapsulates information about implicits in flight.
Unfortunately we cannot do that in 2.10.x, because of binary compatibility
concerns, therefore I'm marking this commit as [nomaster] and will be
resubmitting its full version in a separate pull request exclusively
targetting master.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
macroExpandAll is the key player in the mechanism of expanding macros after
their type arguments have been inferred. (Macro applications that contain
yet uninferred type arguments don't get expanded and are delayed until
the targs are inferred. Therefore later on we need to trigger those delayed
expansions manually, which is done by macroExpandAll).
Previously macroExpandAll was only called from a few selected places in
the typechecker, but that's quite risky, since typer evolves, and who knows
when this scheme breaks.
To make things more robust, I'm now calling macroExpandAll in the epilogue
of every single call to `typed`. Don't worry - this shouldn't impose
noticeable performance penalties, since the call is guarded by a branch
upon a plain boolean field.
NOTE: This patch is a second take on fixing implicit macros, with the first
one being a backport from macro paradise merged into master in January 2013:
https://github.com/scala/scala/commit/fe60284769.
The original fix had an unfortunate error, as described on scala-internals:
https://groups.google.com/forum/#!msg/scala-internals/7pA9CiiD3u8, so I had
to refine the approach here.
This means that it's not possible to directly merge this commit into master,
so I'm marking it as [nomaster] and will submit a separate pull request
targetting master later on.
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Amazingly enough, the fix for the "macro not expanded" problem was super
easy. (And I remember spending a day or two trying to find a quick fix
somewhen around Scala Days 2012!)
The problem was in the implementation of the macro expansion trigger,
which was buried in a chain of if-elif-elif in `adapt`. This meant that macro
expansion was mutually exclusive with a lot of important adaptations, e.g.
with `instantiate`.
More precisely, if an expandee contains an undetparam, its expansion
should be delayed until all its undetparams are inferred and then retried
later. Sometimes such inference can only happen upon a call to instantiate
in one of the elif's coming after the macro expansion elif. However this
elif would never be called for expandees, because control flow would always
enter the macro expansion branch preceding the inference branch.
Therefore `macroExpand` now takes the matters in its own hands,
calling `instantiate` if the expansion has been delayed and we're not in
POLYmode (see a detailed explanation in a comment to `macroExpand`).
Consequences of this fix are vast. First of all, we can get rid of the
"type parameter must be specified" hack. Secondly and most importantly,
we can now remove the `materializeImplicit` method from Implicits and
rely on implicit macros to materialize tags for us. (This is a tricky
change, and I'll do it later after we merge as much of my pending work
as possible). Finally, we learn that the current scheme of interaction
between macros, type inference and implicits is, in principle, sound!
NOTE: This patch is a second take on fixing implicit macros, with the first
one being a backport from macro paradise merged into master in January 2013:
https://github.com/scala/scala/commit/fe60284769.
The original fix had an unfortunate error, as described on scala-internals:
https://groups.google.com/forum/#!msg/scala-internals/7pA9CiiD3u8, so I had
to refine the approach here.
This means that it's not possible to directly merge this commit into master,
so I'm marking it as [nomaster] and will submit a separate pull request
targetting master later on.
|
|\ \ \
| | | |
| | | | |
Scaladoc: fixing small typo in PartialFunction.scala
|
| | | |
| | | |
| | | | |
Fixing a one-letter typo in the documentation of PartialFunction.scala (from "an plain" to "a plain").
|
|\ \ \ \
| |_|/ /
|/| | | |
some fixes for macros: one esoteric, and one quite critical
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It's not like we're achieving any generality by iterating through all
keys in System.getProperties and looking for ones which resemble
"boot.class.path", so let's be simpler.
|
| | | |
| | | |
| | | |
| | | | |
pun intended
|
| | |/
| |/|
| | |
| | |
| | |
| | | |
Due to SI-7465 we were erroneously assuming that System.getProperties
only contains string key and string values. This led to a CCE when there
was something else.
|
|\ \ \
| | | |
| | | | |
SI-5734 Allow setting of socket timeout for remote actors
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
TcpService is locked while connections are being established, preventing
messages being sent to remote nodes. There was no way to specify a connect
timeout, so the service was waiting for a ConnectException to be thrown if
the remote node was unavailable (which can take several minutes).
Added a system property to allow setting a socket connect timeout to
prevent the TcpService from being locked for minutes at a time.
Default behaviour is unchanged, all tests pass and the patch has been
running in production without issue.
|
|\ \ \ \
| | | | |
| | | | | |
SI-7398 Add support for java8 default methods
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In classfile parser: mark symbols which represent interface
methods yet have code attributes with new flag DEFAULTMETHOD.
These must be kept distinct from regular method bodies so that
an error can be issued when a regular concrete method is
overridden without the override keyword, but not when the
overridden method is a default.
In java source parser: mark Modifiers of interface default
methods with DEFAULTMETHOD flag.
Writing the test was everything I dreamed, and more! However,
% test/partest --debug test/files/run/t7398.scala
Skipping java8-specific test under java version 1.7.0_21
testing: [...]/files/run/t7398.scala [ OK ]
All of 1 tests were successful (elapsed time: 00:00:04)
% test/partest --debug test/files/run/t7398.scala
Attempting java8-specific test under java version 1.8.0-ea
testing: [...]/files/run/t7398.scala [ OK ]
All of 1 tests were successful (elapsed time: 00:00:13)
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
There was no way to make a java compilation unit.
Now there is.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Some fixes for string interpolation
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
At all its callsites except for a single one, the results of literal()
were wrapped in atPos(in.offset), so the simplification was pretty much
warranted. Thanks @paulp
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
See comments in code for the exhaustive list of the cases handled.
Also note that treatment of non-formatting percents has been changed.
Embedding literal %'s now requires escaping.
Moreover, this commit also features exact error positions for string
interpolation, something that has been impossible until the fix for
SI-7271, also included in this patch.
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Positions of static parts are now set explicitly during parsing rather
than filled in wholesale during subsequent atPos after parsing.
I also had to change the offsets that scanner uses for initial static
parts of string interpolations so that they no longer point to the
opening double quote, but rather to the actual beginning of the part.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
SI-7426 Crash in pickler.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
I wonder if the supply of copy-pasted code, and the bugs
which always accompany it, will ever run low. Here we have
a couple hundred lines of tree traversal which appears
roughly identical in structure to a different couple hundred
lines of tree traversal, except one calls methods called
putXXX and the other calls methods called writeXXX.
Except there was one call to writeXXX among all the putXXX
calls. Guess where it was crashing.
This entire file should be expunged.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-5634 eliminate overly verbose error message
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
In fact I couldn't see where the error message described in
the ticket is being produced, and I'm supposing it has
already vacated the premises. I went through ClassfileParser
and UnPickler, the two enclaves most likely to harbor the
spewer, and hardened the output. No printlns, tighter
assertion messages, and string interpolation for aesthetics.
We're not savages.
|
|\ \ \ \ \ \ \
| |_|_|_|_|/ /
|/| | | | | | |
SI-7441 Don't ramble on about inapplicable implicits.
|
| | | | | | | |
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-7385 crash in erroneous code
|
| | |/ / / / /
| |/| | | | |
| | | | | | |
| | | | | | | |
Less crashing, more emitting errors.
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-6091 overeager warning for reference equality
|
| | |/ / / / /
| |/| | | | |
| | | | | | |
| | | | | | | |
Don't warn on eq and ne unless they're the real eq or ne.
|
|\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | | | |
SI-6771 Alias awareness for checkableType in match analysis.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Failure to dealias the type of the scrutinee led the pattern
matcher to incorrectly reason about the type test in:
type Id[X] = X; (null: Id[Option[Int]]) match { case Some(_) => }
Before, `checkableType` returned `Id[?]`, now it returns `Some[?]`.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
To simplify building a release on jenkins, we run distpack-opt in one job,
store the `dists/` directory in a tar ball, archive that artifact and
copy it to the downstream jobs that package on windows and unix.
To make the tarball portable between machines, it must not use absolute symlinks.
|
|\ \ \ \ \ \ \
| |_|/ / / / /
|/| | | | | | |
Warn on selection of vals from DelayedInit subclasses.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Which are likely to yield null, if the program didn't start.
This is a common source of confusion for people new to
the language, as was seen during the Coursera course.
The test case shows that the usage pattern within Specs2
won't generate these warnings.
|
|\ \ \ \ \ \ \
| |_|_|/ / / /
|/| | | | | | |
SI-7369 Avoid spurious unreachable warnings in patterns
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Unreachability analysis draws on the enumerated domain of types
(e.g sealed subclasses + null, or true/false), and also looks at all
stable identifier patterns tested for equality against the same 'slot'
in a pattern.
It was drawing the wrong conclusions about stable identifier patterns.
Unlike the domain constants, two such values may hold the same value,
so we can't assume that matching X precludes matching Y in the same
slot in a subsequent case.
For example:
val X: Boolean = true; val Y: Boolean = true
def m1(t1: Tuple1[Boolean]) = t1 match {
case Tuple1(true) =>
case Tuple1(false) =>
case Tuple1(false) => // correctly unreachable
}
def m2(t1: Tuple1[Boolean]) = t1 match {
case Tuple1(X) =>
case Tuple1(Y) => // spurious unreachable warning
}
//
// Before
//
reachability, vars:
V2: Boolean ::= true | false// Set(false, Y, X, true) // = x1._1
V1: (Boolean,) ::= null | ... // = x1
equality axioms:
V2=true#4 \/ V2=false#5 /\
-V2=false#5 \/ -V2=Y#3 /\
-V2=false#5 \/ -V2=X#2 /\
-V2=false#5 \/ -V2=true#4 /\
-V2=Y#3 \/ -V2=X#2 /\
-V2=Y#3 \/ -V2=true#4 /\
-V2=X#2 \/ -V2=true#4
//
// After
//
reachability, vars:
V2: Boolean ::= true | false// Set(false, Y, X, true) // = x1._1
V1: (Boolean,) ::= null | ... // = x1
equality axioms:
V2=true#4 \/ V2=false#5 /\
-V2=false#5 \/ -V2=true#4
|
|\ \ \ \ \ \ \
| |_|_|_|/ / /
|/| | | | | | |
SI-7367 scaladoc crash on constructing the model for annotations.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Scaladoc only checks primary constructor when building annotation
model.
Here we instead find the constructor matching the annotation's symbol.
Also change TreeFactory.makeTree to return TreeEntity rather than
Option[TreeEntity] and force the caller check for EmptyTree.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
There's a very dangerous situation running around when you
combine universal equality with value classes:
// All over your code
val x = "abc"
if (x == "abc") ...
// Hey let's make x a value class
val x = new ValueClass("abc")
// Uh-oh
There was until now no warning when comparing a value class
with something else. Now there is.
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-6675 Avoid spurious warning about pattern bind arity.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
In 692372ce, we added a warning (under -Xlint) when binding
a `TupleN` in to a single pattern binder, which wasn't allowed
before 2.10.0, and more often than not represents a bug.
However, that warning overstretched, and warned even when
using a Tuple Pattern to bind to the elements of such a value.
This commit checks for this case, and avoids the spurious warnings.
A new test case is added for this case to go with the existing
test for SI-6675:
$ ./tools/partest-ack 6675
% tests-with-matching-paths ... 3
% tests-with-matching-code ... 2
# 3 tests to run.
test/partest --show-diff --show-log \
test/files/neg/t6675-old-patmat.scala \
test/files/neg/t6675.scala \
test/files/pos/t6675.scala \
""
Testing individual files
testing: [...]/files/pos/t6675.scala [ OK ]
Testing individual files
testing: [...]/files/neg/t6675-old-patmat.scala [ OK ]
testing: [...]/files/neg/t6675.scala [ OK ]
All of 3 tests were successful (elapsed time: 00:00:03)
|