Merged
Conversation
Fingers crossed, I have no local java 6 here to test. No test because no q"" on 2.10.
The previous behavior was to iterate over the mutated list of arbitrary length. The previous iteration of the iterator would also iterate the terminal element of the list without halting. This is fixed by capping the length of iterator. That is OK because mutating the list by adding to it during iteration is not recommended. For good measure, the exhausted iterator does not hold a reference to any remaining tail. A test is added that will no doubt be superseded by the QCC tests. (Quasi-Comprehensive Collections.) The test just checks that the extra tail is not strongly reachable from the iterator. If the garbage collector happens to kick in and determine that the object is weakly reachable, then the check terminates early.
SI-9027 Backport xml parser fix
For local definitions (eg. in a block that is an argument of a method call), the type completer may have a silent context. A CyclicReference is then not thrown but transformed into a NormalTypeError. When deciding if 'x = e' is an assignment or a named arg, we need to report cyclic references, but not other type errors. In the above case, the cyclic reference was not reported. Also makes sure that warnings are printed after typing argument expressions.
This commit corrects three tests which were failing for certain locale due to the different decimal marks in the expected value and the result (e.g. 2.50 and 2,50). From now also the expected value is formatted in accordance with the current locale.
Using U_i instead of T_i is confusing. See http://stackoverflow.com/questions/26803244/is-this-a-typo-in-the-scala-language-specification-on-parameterized-types
Mark method as deprecated due to it not providing the expected result, while fixing it will break existing code.
…ptimized String.split code path Escaping a char when calling split is slow. We end up compiling a Pattern to simply match a character literal. Instead, we just use an loop with indexOf to construct our resulting Array. Current speed up over old behaviour is about 12-1
- handle missing files gracefully (rather than NPE)
- read the class name with ASM, rather than with a dummy
classloader. The dummy classloader is prone to throwing
`LinkageError`s, as reported in the comments of SI-6502.
Manual test of the original report:
```
% qscala
Welcome to Scala version 2.11.5-20150115-183424-155dbf3fdf (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_25).
Type in expressions to have them evaluated.
Type :help for more information.
scala> :require does/not/exist
Cannot read: does/not/exist
scala> classOf[org.junit.Test]
<console>:8: error: object junit is not a member of package org
classOf[org.junit.Test]
^
scala> :require /Users/jason/.m2/repository/junit/junit/4.11/junit-4.11.jar
Added '/Users/jason/.m2/repository/junit/junit/4.11/junit-4.11.jar' to classpath.
scala> classOf[org.junit.Test]
res1: Class[org.junit.Test] = interface org.junit.Test
```
I have commited an automated test that is a minimization of this one.
Before, we got in an endless loop if using ^D to try to end the session. When piping commands into the REPL, this was rather annoying! ``` scala-hash v2.11.5 Welcome to Scala version 2.11.5-20150101-184742-3fafbc204f (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_25). Type in expressions to have them evaluated. Type :help for more information. scala> :require xxx java.lang.NullPointerException at scala.tools.nsc.interpreter.ILoop.scala$tools$nsc$interpreter$ILoop$$flatten$1(ILoop.scala:651) at scala.tools.nsc.interpreter.ILoop.require(ILoop.scala:654) That entry seems to have slain the compiler. Shall I replay your session? I can re-run each line except the last one. [y/n]^D You must enter y or n. That entry seems to have slain the compiler. Shall I replay your session? I can re-run each line except the last one. [y/n]^D ... ```
From the "Substitution is hard to do" department. In 7babdab, TreeSymSubstitutor was modified to mutate the info of symbols defined in the tree, if that symbol's info referred to one of the `from` symbols in the substitution. It would have been more principled to create a cloned symbol with the updated info, and add that to the substitution. But I wasn't able implement that correctly (let alone efficiently.) The in-place mutation of the info of a symbol led to the crasher in this bug: a singleton type over that symbol ends up with a stale cached value of 'underlying'. In the enclosed test case, this leads to a type error in the `SubstituteRecursion` of the extension methods phase. This commit performs a cleanup job at the end of `substituteSymbols` by invalidating the cache of any `SingleType`-s in the tree that refer to one of the mutated symbols.
The type error stemming from missing argument list was being swallowed when the expected type was `Unit` and there were undetermined type parameters in the expression. This commit modifies `adapt` to avoid using `instantiateExpectingUnit` when the tree is typed with `MethodType`.
When using delambdafy:method, closure classes are generated late. The class is added to a map and integrated into the PackageDef in transformStats. When declaring a package object, there are potentially multiple PackageDefs for the same package. In this case, the closure class was added to all of them. As a result, GenASM / GenBCode would run multiple times on the closure class. In GenBCode this would trigger a warning about conflicting filenames.
`pos` test is subsumed by `run`.
This saves a check file in the crowded test directory.
SI-6502 Convert test to asserts
An -Xlint:stars-align warning for the case of patterns with at least one "fixed" component and a varargs component. Warn if the fixed patterns don't exactly align with the fixed value components, such that a sequence wildcard aligns exactly with the varargs component (either a T* parameter in a case class or a Seq[T] in an extractor result). This addresses the case of the xml.Elem extractor, which does not correspond to the Elem class constructor. One can be fooled into supplying an extra field for extraction. Vanilla extractors of type `Option[Seq[_]]` are unaffected by this flag. It's OK to ask for `case X(a, b, c)` in the expectation that three results are forthcoming. There is no semantic confusion over where the varargs begin.
Implicit search declines to force the info of candidate implicits
that either a) are defined beyond the position of the implicit search
site, or b) enclose the implicit search site.
The second criterion used to prevent consideration of `O` in
the super constructor call:
implicit object O extends C( { implicitly[X] })
However, after scala#4043, the
block containing the implicit search is typechecked in a context
owned by a local dummy symbol rather than by `O`. (The dummy and
`O` share an owner.)
This led to `O` being considered as a candidate for this implicit
search. This search is undertaken during completion of the info of
`O`, which leads to it being excluded on account of the LOCKED flag.
Unfortunately, this also excludes it from use in implicit search
sites subsequent to `O`, as `ImplicitInfo` caches
`isCyclicOrErroneous`.
This commit adjusts the position of the local dummy to be identical
to that of the object. This serves to exclude `O` as a candidate
during the super call on account of criterion a).
The pattern matcher needs to substitute references to bound
variables with references to either a) synthetic temporary vals,
or to b) selections. The latter occurs under -optimize to avoid
to be frugal with local variable slots.
For instance:
```
def test(s: Some[String]) = s match {
case Some(elem) => elem.length
}
```
Is translated to:
```
def test(s: Some[String]): Int = {
case <synthetic> val x1: Some[String] = s;
case4(){
if (x1.ne(null))
matchEnd3(x1.x.length())
else
case5()
};
case5(){
matchEnd3(throw new MatchError(x1))
};
matchEnd3(x: Int){
x
}
}
```
However, for a long time this translation failed to consider
references to the binder in types. scala#4122 tried to address this
by either using standard substitution facilities where available
(references to temp vals), and by expanding the patmat's
home grown substitution to handle the more complex case of
referencing a selection.
However, this left the tree in an incoherent state; while it
patched up the `.tpe` field of `Tree`s, it failed to modify the
info of `Symbol`-s.
This led to a crash in the later uncurry phase under
`-Ydelambdafy:method`.
This commit modifies the info of such symbols to get rid of stray
refeferences to the pattern binder symbols.
Update 03-types.md
fix definition of TRY in the language specification
Update scala version to 2.11.5 for Intellij 14
SI-9072 Vector ++ concatenation of parallel collection cause inconsisten...
The clear() method in scala.collection.mutable.LinkedHashSet and scala.collection.mutable.LinkedHashMap does not set lastEntry to null. In result it holds a reference to an object that was removed from the collection.
If `qual.foo(args)` fails to typecheck, we fall back to `ImplicitView(qual).foo(args)`. However, if the original type error stemmed from an overload ambiguity, the tree `Select(qual, 'foo')` holds onto an error symbol. The fall back attempt just returns an `Apply` tree containing the erroneous qualifier, as it does not want to issue cascading type errors. This commit replaces the error symbol with a `NoSymbol`, which triggers the second try typechecking to perform overload resolution again. A more principled fix might be to more pervasively duplicate trees before mutating their types and symbols, that this is beyond the scope of this bug fix.
The selector has been wrong since 0c2614e.
[nomerge] SI-8940 Scaladoc: Fix "Order by Alphabetical" button
Merge/2.10 to 2.11 apr 1
Member
Author
|
Review by @retronym |
Member
Author
|
/synch |
Member
Author
|
for some reason, scabot doesn't trigger any builds for the merge commits. |
Member
|
Member
|
LGTM |
Contributor
|
/rebuild dcd9a83 |
Contributor
|
/rebuild 5197195 |
Contributor
|
Not sure why the bot isn't building those last few commits. Started https://scala-ci.typesafe.com/job/scala-2.11.x-validate-main/961/console manually |
Contributor
|
Last commit in the merge fails in the same way as we're seeing at other PRs: |
Member
|
That intermittent failure is being investigated as https://issues.scala-lang.org/browse/SI-9264. |
Member
|
We've got a tick on f49b447 (after a retry to workaround SI-9264), so I'm going to merge this one now. |
Member
Author
|
woohoo |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A big one..
The conflict in
Promise.scalais due to those two commits:Please check if the result is correct: https://github.com/lrytz/scala/blob/f49b447cf9d08524c08ff9f57cf04938806f6f73/src/library/scala/concurrent/Promise.scala#L63
Conflict in
names-defaults-neg.check:Manual merge, should be fine.
Confilct in
Template.scalaManual merge, should be fine. The 2.12.x commit (#4407) should be backported to 2.11.x, in fact.
The conflict in build.number is expected, it's set to 2.12.0 in the 2.12.x branch.