| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
Merge 2.10.x to 2.11.x
|
| | |\
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/library/scala/concurrent/Promise.scala
test/files/jvm/future-spec/PromiseTests.scala
|
| | | |\
| | | |
| | | | |
SI-8689 Avoid internal error in Promise after sequence of completions
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Calling `completeWith` when the `DefaultPromise` is already completed,
leads to callbacks not being properly executed.
This happened because `Future.InternalCallbackExecutor` extends
`BatchingExecutor`[1] which assumes `unbatchedExecute` to be async,
when in this case it is sync, and if there is an exception thrown
by executing the batch, it creates a new batch with the remaining
items from the current batch and submits that to `unbatchedExecute`
and then rethrows, but if you have a sync `unbatchedExecute`, it will
fail since it is not reentrant, as witnessed by the failed `require`
as reported in this issue.
This commit avoids problem by delegating `completeWith` to
`tryComplete`, which has the effect of using `onComplete` +
`tryComplete` i.s.o. `complete`, which means that when it fails
(because of a benign race condition between completers) it won't
throw an exception.
It has been tested by the minimized reproducer.
[1] Actually, in the 2.10.x branch where this patch is starting out,
"The BatchingExecutor trait had to be inlined into
InternalCallbackExecutor for binary compatibility.". This comment
will be more literally correct in the context of 2.11.x and beyond
|
| | | |/ |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Fingers crossed, I have no local java 6 here to test.
No test because no q"" on 2.10.
|
| | | |\
| | | |
| | | | |
[backport] SI-7756 Uncripple refchecks in case bodies
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In 65340ed4ad2e, parts of RefChecks were disabled when
we traversed into the results of the new pattern matcher.
Similar logic existed for the old pattern matcher, but in
that case the Match / CaseDef nodes still existed in the tree.
The new approach was too broad: important checks no longer
scrutinized the body of cases.
This commit turns the checks back on when it finds the remnants
of a case body, which appears as an application to a label def.
Conflicts:
src/compiler/scala/tools/nsc/typechecker/RefChecks.scala
Cherry pick of 3df1d77fc984b976efa68098206e801cf3b83a9e
|
| | | |\ \
| | | | |
| | | | | |
[backport] SI-7470 implements fundep materialization
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
To quote gkossakowski:
Thinking about it more, could we hide this behind 'Y' flag instead?
We have lesser obligation to keep around Y flags and this is something
we should remove from 2.11/2.12.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Backports 21a8c6c from the 2.11.x branch under -Xfundep-materialization
as per Miles Sabin's request. Thanks Miles!
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Backport the doc with two material changes:
1. need to use Groups to extract from Match,
so say that in lieu of the 2.11 advice that
the Regex instance can be used without
recomputing the match;
2. and relatedly, in 2.10 there is no secondary
constructor, so the doc for group names is
moved back up to the class doc.
Original doc update on PR #3923 was:
0e26910372d349c6ff7bbaa17fc8fe0bf568c5fe
f98c53cb03f800b3d790f3866ab90f827fd131f5
|
| | | |\ \ \
| | | | | |
| | | | | | |
[backport] transformers no longer ignore UnApply.fun
|
| | | | |/ /
| | | | |
| | | | |
| | | | | |
Backports 7122560063 and 4133eb8454 from the 2.11.x branch
|
| | | |\ \ \
| | | | | |
| | | | | | |
[backport] SI-7710 fix memory performance of RegexParsers in jdk7u6+
|
| | | | |/ /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Backport of scala/scala-parser-combinators@91584dc.
---
Starting with 1.7.0_06 [1], String.substring no longer reuses the internal
char array of the String but make a copy instead. Since we call
subSequence twice for *every* input character, this results in horrible
parse performance and GC.
With the benchmark from the (duplicate) ticket SI-8542, I get:
BEFORE:
parseAll(new StringReader(String))
For 100 items: 49 ms
For 500 items: 97 ms
For 1000 items: 155 ms
For 5000 items: 113 ms
For 10000 items: 188 ms
For 50000 items: 1437 ms
===
parseAll(String)
For 100 items: 4 ms
For 500 items: 67 ms
For 1000 items: 372 ms
For 5000 items: 5693 ms
For 10000 items: 23126 ms
For 50000 items: 657665 ms
AFTER:
parseAll(new StringReader(String))
For 100 items: 43 ms
For 500 items: 118 ms
For 1000 items: 217 ms
For 5000 items: 192 ms
For 10000 items: 196 ms
For 50000 items: 1424 ms
===
parseAll(String)
For 100 items: 2 ms
For 500 items: 8 ms
For 1000 items: 16 ms
For 5000 items: 79 ms
For 10000 items: 161 ms
For 50000 items: 636 ms
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6924259
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
fixes pluginsEnterStats
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Initial implementation of pluginsEnterStats was incorrect, because I got
the foldLeft wrong, making it perpetuate the initial value of stats.
This worked fine if zero or one macro plugins were active at a time,
but broke down if there were multiple of such plugins (concretely,
I discovered this issue when trying to marry macro paradise with scalahost).
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Errant `self.length` changed to `length`.
No tests; found and tested by collections-laws.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Tested on:
- Mac: FF35/Safari 8/Chrome 41
- Win: IE11
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Added `.seq` in two essential places so that a parallel collection passed as an argument won't mess up side-effecting sequential computations in `List.flatMap` and `GenericTraversableTemplate.transpose` (thanks to retronym for finding the danger spots).
Tests that `.seq` is called by constructing a `GenSeq` whose `.seq` disagrees with anything non-`.seq` (idea & working implementation from retronym).
Also updates the `.seq` test for `Vector#++` to use the new more efficient method.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-9153 More complete and stable results for completions
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The checkfile of the tests added in the last commit offered
a type member from `RichInt` in the completions for the type
`Int`. However, only term members can be extension methods;
type members cannot.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Three items of background are needed to understand this bug.
1. When typechecking an application like `qual.m({stats; expr})`, the
argument is typechecked using the formal parameter type of `m` as the
expected type. If this fails with a type error located within in
`expr`, the typer instead re-typechecks under `ContextMode.ReTyping`
without an expected type, and then searches for an implicit adaptation
to enable `view(qual).m(args)`. Under this mode, `Typer#typed1`
clears the type of incoming trees.
2. The presentation compiler performs targetted operations like
type completions by:
- typechecking the enclosing tree, registering all typechecker
`Context`s created in the process (`registerContext`)
- finding the smallest enclosing `Context` around the target
position (`doLocateContext`)
- Using this context to perform implicit search, which can
contribute members to the completion. (`applicableViews` within
`interactive.Global#typeMembers`)
3. When verifiying whether or not a candidate implicit is applicable
as a view from `F => T`, implicit search typechecks a dummy call
of the form `q"candiate(${Ident("<argument>").setType(typeOf[F])})".
Now, picture yourself at the nexus of these three storms.
In the enclosed test case, we search for completions at:
x + 1.<caret>
1. Because the code is incomplete, the application of `Int#+`
doesn't typecheck, and the typer also tries to adapt `x` to a
method applicable to the re-typechecked argument.
2. This process registers a context with `retypechecking` set to
true. (If multiple contexts at the same position are registered,
the last one wins.)
3. Implicit search uses this context to typecheck
`Predef.Ensuring(<argument>.setType(Int))`, but the argument
is promptly stripped of its type and retypechecking fails
as there is no definition named `<argument>` in scope.
As such, we missed out on extension methods, like `ensuring` in the
list of completions.
This commit changes the presentation compiler to turn off retyping
mode in the context before starting to work with it. (Are the other
modes that might cause similar bugs?)
Once I made that change, I noticed that the results the enclosed test
was not stable. I tracked this down to the use of a `HashMap` to
carry the applicable implicit views, together with the way that
the presentation compiler removes duplicates. This commit
switched to a `LinkedHashMap`.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This avoids a minor inefficiency of interning the name on
each implicit candidate. Instead, we follow the usual practice
and use a pre-baked name from `StdNames`.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Optimization of IterableLike.scala
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Changed takeRight to have two tighter loops instead of one with a conditional. See about 10% performance improvement.
Other changes were (surprisingly, in some cases) not a win. Overall, IterableLike is pretty well optimized.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-8917 collection.mutable.BitSet's &= operator doesn't clear end
|
| | |/ / / /
| | | | |
| | | | |
| | | | | |
Made &= run to the end of its own bitset, ignoring the size of what it's &-ing with (which is exactly what you want for &=).
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Fix SI-7943 -- make `TrieMap.getOrElseUpdate` atomic.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Override `getOrElseUpdate` method in `TrieMap`.
The signature and contract of this method corresponds closely to the
`computeIfAbsent` from `java.util.concurrent.ConcurrentMap`.
Eventually, `computeIfAbsent` should be added to
`scala.collection.concurrent.Map`.
Add tests.
Review by @Ichoran
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In a bug reminiscent of SI-7603 / ab8a223, when running multiple
instances of Scaladoc in one JVM/classloader, we are exposed to
race conditions in unprotected mutable state in a top-level object.
This commit moves that state into the `Universe` object, which
corresponds to a single Scaladoc instance. It also removes a little
premature abstraction from the code.
Note: the statistics code is still not thread safe, but this is no
worse than the compiler itself, and not a real problem, as they are
only enabled begind a `-Y` option.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-9148: Appends companion type to link tooltips
|
| | |/ / / / / |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Simpler & Scala.js-friendly `ClassTag.unapply`
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Inline overloaded calls to `unapply`, so we can get rid of them in 2.13.
Note that theres a lot of `box(unbox(x))` going on behind the scenes.
Is this needed?
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Use `j.l.Class.isInstance` for Scala.js, so that `unapply`
works correctly when referencing raw JavaScript classes.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-4959 - UNIX bin scripts now work for paths with spaces
|
| | | |_|/ / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The bin scripts fsc, scala, scalac, scaladoc, and scalap were not
working when spaces were in the true path of the file (after symbolic
links were resolved). This is now fixed.
The problem affected OS X, Linux, and mingw on Windows. It did not
affect cygwin, because the code was special-cased for cygwin to use
cygpath to convert to short filenames, which eliminates spaces.
It did not affect the Windows command prompt, because that uses a
separate batch file.
The problem was that there was a shell function, classpathArgs, used
to generate the arguments for the classpath. Shell functions can only
return status codes, and emit text which can be captured in a command
substitution. Thus, they can contain strings, but not distinguish
which spaces should be part of a word, and which ones should separate
words.
The solution was to switch to using a bash array, as java_args and
scala_args were already doing. In this way, each element of the array
can contain spaces, but the elements are kept distinct.
There was an additional problem with mingw. There was some code that
used 'cmd //c' to convert the path to Windows format (drive letters
with colons, backslashes and semicolons instead the UNIX-style slashes
with colon separators). It turns out that when there are spaces in the
path, 'cmd //c' adds quotes around the result to protect it. This was
superfluous and actually caused a problem with parsing the first and
last paths in the classpath, leading to trouble in finding jars.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-9116 Set.subsets has a param list
|
| | | |_|/ / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Now both of the overloaded variants have a parameter list.
This seems to make type inference happier. Or it makes someone
happier.
The user is unaware whether `subsets()` takes a default arg.
But happily, empty application still kicks in.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-7660: Document behaviour of Set#++ for duplicate elements
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Updated documentation of + and ++ in SetLike to explicitly state that duplicate elements
are not added to the set.
|
| |\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
SI-9157 Avoid exponential blowup with chained type projections
|
| | | |_|/ / / / /
| |/| | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Calling `findMember` in the enclosed test was calling into
`NonClassTypeRef#relativeInfo` an exponentially-increasing number
of times, with respect to the length of the chained type projections.
The numbers of calls increased as: 26, 326, 3336, 33446, 334556.
Can any pattern spotters in the crowd that can identify the sequence?
(I can't.)
Tracing the calls saw we were computing the same `memberType`
repeatedly. This part of the method was not guarded by the cache.
I have changed the method to use the standard idiom of using the
current period for cache invalidation. The enclosed test now compiles
promptly, rather than in geological time.
|
| |\ \ \ \ \ \ \ \
| |/ / / / / / /
|/| | | | | | | |
SI-9059 Random.alphanumeric is inefficient
|
| | | |_|/ / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Generate alphanumeric values by taking random element of string
containing all alphanumerics.
Instead of generating nextPrintableChar then filtering for
alphanumerics, we can just take from a string containing all
alphanumerics. This provides a significant performance improvement.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Fixes and tests for InnerClass / EnclsoingMethod classfile attributes
|
