summaryrefslogtreecommitdiff
path: root/test/files/run
Commit message (Collapse)AuthorAgeFilesLines
...
* | | Merge pull request #3189 from retronym/ticket/8002Jason Zaugg2013-11-261-0/+19
|\ \ \ | | | | | | | | private access for local companions
| * | | SI-8002 private access for local companionsJason Zaugg2013-11-241-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | We go through similar gymnastics to make companion implicits work for local class/object pairings, so we ought to be consistent when it comes to access
* | | | Merge pull request #3192 from retronym/ticket/4332Jason Zaugg2013-11-263-0/+104
|\ \ \ \ | |_|/ / |/| | | SI-4332 Plugs the gaps in views
| * | | SI-4332 Plugs the gaps in viewsJason Zaugg2013-11-263-0/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These currently result in runtime errors: scala> List(1).view.distinct.force java.lang.UnsupportedOperationException: SeqView(...).newBuilder scala> List(1).view.inits.toList java.lang.UnsupportedOperationException: SeqView(...).newBuilder Two tests are enclosed: 1. reflect on the views to make any method that returns `Repr` is overriden in `*ViewLike`. This guards against new additions to the collections API. 2. exercise the newly added overrides Some care is needed with `tail`, we must re-override it in `mutable.IndexedSeqView` to be explicit about the end point of the slice, because the `IndexedSeqView#Sliced` defines length in terms of that. (Higher up the chain, it is just `iterator.size`, that's why `SeqView#tail` just sets up a slice from `1 to Int.MaxValue`.) Parallel collections views are not touched, as these are likely to be deprecated or removed shortly. Before this change, the test reported the following. Not all of these methods were buggy. For instance, `sortBy`, `sortWith` are implemented in terms of `sorted` which was implemented in `SeqViewLike`. Even in those cases, I have opted to override the methods in the `ViewLike` to guard against changes in the base class implementation and to simplify the rules in the test. ====================================================================== Checking scala.collection.TraversableView ====================================================================== trait TraversableLike ---------------------------------------------------------------------- def filterNot(p: A => Boolean): Repr def inits: Iterator[Repr] def tails: Iterator[Repr] override def tail: Repr ====================================================================== Checking scala.collection.IterableView ====================================================================== trait IterableLike ---------------------------------------------------------------------- def dropRight(n: Int): Repr def sliding(size: Int): Iterator[Repr] def takeRight(n: Int): Repr trait TraversableLike ---------------------------------------------------------------------- def filterNot(p: A => Boolean): Repr def inits: Iterator[Repr] def tails: Iterator[Repr] override def tail: Repr ====================================================================== Checking scala.collection.SeqView ====================================================================== trait IterableLike ---------------------------------------------------------------------- def dropRight(n: Int): Repr def sliding(size: Int): Iterator[Repr] def takeRight(n: Int): Repr trait SeqLike ---------------------------------------------------------------------- def combinations(n: Int): Iterator[Repr] def distinct: Repr def permutations: Iterator[Repr] def sortBy[B](f: A => B)(implicit ord: scala.math.Ordering[B]): Repr def sortWith(lt: (A, A) => Boolean): Repr trait TraversableLike ---------------------------------------------------------------------- def filterNot(p: A => Boolean): Repr def inits: Iterator[Repr] def tails: Iterator[Repr] override def tail: Repr ====================================================================== Checking scala.collection.mutable.IndexedSeqView ====================================================================== trait IndexedSeqOptimized ---------------------------------------------------------------------- override def dropRight(n: Int): Repr override def tail: Repr override def takeRight(n: Int): Repr trait IterableLike ---------------------------------------------------------------------- def sliding(size: Int): Iterator[Repr] trait SeqLike ---------------------------------------------------------------------- def combinations(n: Int): Iterator[Repr] def distinct: Repr def permutations: Iterator[Repr] def sortBy[B](f: A => B)(implicit ord: scala.math.Ordering[B]): Repr def sortWith(lt: (A, A) => Boolean): Repr trait TraversableLike ---------------------------------------------------------------------- def filterNot(p: A => Boolean): Repr def inits: Iterator[Repr] def tails: Iterator[Repr] ====================================================================== Checking scala.collection.immutable.StreamView ====================================================================== trait IterableLike ---------------------------------------------------------------------- def dropRight(n: Int): Repr def sliding(size: Int): Iterator[Repr] def takeRight(n: Int): Repr trait SeqLike ---------------------------------------------------------------------- def combinations(n: Int): Iterator[Repr] def distinct: Repr def permutations: Iterator[Repr] def sortBy[B](f: A => B)(implicit ord: scala.math.Ordering[B]): Repr def sortWith(lt: (A, A) => Boolean): Repr trait TraversableLike ---------------------------------------------------------------------- def filterNot(p: A => Boolean): Repr def inits: Iterator[Repr] def tails: Iterator[Repr] override def tail: Repr
* | | | Merge pull request #3183 from xeno-by/topic/pure-expression-does-nothingAdriaan Moors2013-11-251-6/+0
|\ \ \ \ | | | | | | | | | | SI-8001 spurious "pure expression does nothing" warning
| * | | | SI-8001 spurious "pure expression does nothing" warningEugene Burmako2013-11-231-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `isPureExprForWarningPurposes` doesn’t warn on `()`, but `(): Unit` leaves it confused. This patch fixes the problem. The fix is important in the context of the recent split between blackbox and whitebox macros. Macro engines wrap expansions of blackbox macros in type ascriptions, so a macro that expands into `()` would actually produce `(): Unit`, which would trigger a spurious warning. Thanks @milessabin for spotting this problem!
* | | | | Merge pull request #3165 from retronym/ticket/uncurry-tidy-2Adriaan Moors2013-11-254-0/+65
|\ \ \ \ \ | |_|/ / / |/| | | | Unifying -Ydelambdafy:{inline, method}
| * | | | Substitute new parameter symbols into lambda bodyJason Zaugg2013-11-233-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, new synthetic parameter symbols were created for the apply method parameters, but only used in its `MethodType`. The `ValDef` trees of the function, along with their symbols, were used directly as the parameter trees of the apply method. % cat sandbox/test.scala object Test { (x: Int) => { (y: Int) => ??? } } % scalac-hash v2.10.3 -Xprint:typer,uncurry -uniqid ../scala2/sandbox/test.scala | egrep 'syntax|\bx' [info] v2.10.3 => /Users/jason/usr/scala-v2.10.3-0-g88b5d19 [[syntax trees at end of typer]] // test.scala ((x#12152: Int#351) => x#12152)#12151 [[syntax trees at end of uncurry]] // test.scala final def apply#15952(x#12152: Int#351): Int#351 = x#12152 This approach dates back a long way: c64152bc3. @odersky tells me it was most likely due to insufficent substitution/cloning machinery at the time. % qbin/scalac -Xprint:typer,uncurry -uniqid ../scala2/sandbox/test.scala | egrep 'syntax|\bx' [[syntax trees at end of typer]] // test.scala ((x#13685: Int#1760) => x#13685)#13671 [[syntax trees at end of uncurry]] // test.scala final def apply#13959(x#13960: Int#1760): Int#1760 = x#13960 To make this work, I had to fix a problem in symbol substition; this was commited in the previous commit. In the enclosed test, at Uncurry, the symbol of the nested class `N` had a `ClassInfoType`, which listed as a parent `M[a.C]`. When we substituted the new method parameter symbol `a` for the eponymous function parameter symbol, this was not touched.
| * | | | Symbol substutition must consider ClassInfoType#parentsJason Zaugg2013-11-231-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An upcoming change to uncurry, in which I plan to make substitution of `lambda params -> apply method params` requires that I first to fix a problem in symbol substition. This situation can arise when the body of this definition: def owner1(a: A) = { class C extends M[a.B] } is transplanted into a new owner that has a different symbol for `a`. I speculated that value classes might also be prone to the fact that symbol substitution neglected `ClassInfoType#parents`. We can test change with Value Classes: Partial Functions that are dependent on value class param type used to fail with a spurious overriding error, now they work correctly.
* | | | | Merge pull request #3162 from retronym/ticket/7985Jason Zaugg2013-11-222-0/+8
|\ \ \ \ \ | | | | | | | | | | | | SI-7985 Allow qualified type argument in patterns
| * | | | | SI-7985 Allow projection of lower-cased prefix as pattern type argJason Zaugg2013-11-191-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per the last commit, tighten up the interpretation of a lower cased identifier meaning that we're looking at a type variable.
| * | | | | SI-7985 Allow qualified type argument in patternsJason Zaugg2013-11-191-0/+3
| | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | We were considering the lower case `s` in `case _: Array[scala.Int]` as a sign that we were dealing with a type variable pattern. Now, we only do this if a lookahead confirms the absence of a the `.`
* | | | | Merge pull request #3152 from paulp/pr/deprecationsJason Zaugg2013-11-222-2/+2
|\ \ \ \ \ | | | | | | | | | | | | Removing deprecated code.
| * | | | | Removing deprecated code.Paul Phillips2013-11-182-2/+2
| |/ / / / | | | | | | | | | | | | | | | | | | | | Code which has been deprecated since 2.10.0 and which allowed for straightforward removal.
* | | | | Merge pull request #3131 from densh/pr/deprecate-pair-and-tripleJason Zaugg2013-11-2214-146/+146
|\ \ \ \ \ | |_|_|/ / |/| | | | Deprecate Pair and Triple
| * | | | deprecate Pair and TripleDen Shabalin2013-11-2014-146/+146
| |/ / /
* / / / SI-6329 Graduation day for pending tests for tag materializationJason Zaugg2013-11-214-0/+20
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two kids in the class or '6329 had to repeat the senior year, but with a little help from 76b92ef, they've finally graduated. Here's the class photo: commit 3e855661136bb6c530ef1d3a24dc83800e7f1134 Author: Eugene Burmako <xeno.by@gmail.com> Date: Thu Sep 6 22:19:56 2012 +0200 test suite for SI-6329 test/files/run/t6329_repl.check | 13 +++++++++++++ test/files/run/t6329_repl.scala | 8 ++++++++ test/files/run/t6329_repl_bug.check | 13 +++++++++++++ test/files/run/t6329_repl_bug.pending | 10 ++++++++++ test/files/run/t6329_vanilla.check | 2 ++ test/files/run/t6329_vanilla.scala | 4 ++++ test/files/run/t6329_vanilla_bug.check | 2 ++ test/files/run/t6329_vanilla_bug.pending | 7 +++++++ 8 files changed, 59 insertions(+)
* | | Merge pull request #3119 from Ichoran/issue/5263James Iry2013-11-182-0/+170
|\ \ \ | | | | | | | | New mutable hash map with Long keys: partially solves SI-5263 and is relevant to SI-6825.
| * | | New AnyRefMap fixes SI-5263 to the extent practical.Rex Kerr2013-11-181-0/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An open addressing hash map based on a similar scheme to mutable.LongMap. It delivers performance equivalent to Java's HashMap for pretty much all AnyRefs, plus it works nicely with Scala's collections. Revisions made sure that all return types in the public API are specified. Also switched to a leading-zeros method of calculating the initial mask (to save a few ns). Also edited out java.util comparison numbers and moved constants to companion.
| * | | New mutable hash map with Long keys: partially solves SI-5263 and is relevantRex Kerr2013-11-181-0/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to SI-6825. The hash map is based on an open addressing scheme that provides dramatically faster (mostly due to specialization) get and contains operations than either the standard Java HashMap or any of the existing Scala hash maps. It doesn't work well above 500,000,000 elements as the arrays cannot scale past 2^30 elements. Maps are not faster in general due to the lack of specialization of Function1[Long, V]. Revisions made sure that all return types in the public API are specified. Also switched to a leading-zeros method of calculating the initial mask (to save a few ns), and used an occasionally-more-efficient version of seekEntryOrOpen. Also edited out specific performance numbers and moved constants to companion.
* | | | Merge pull request #3135 from adriaanm/revive-xml-testsJames Iry2013-11-1810-0/+268
|\ \ \ \ | |_|/ / |/| | | Revived tests that once depended on xml
| * | | Revived tests that once depended on xmlAdriaan Moors2013-11-1410-0/+268
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I was a bit overzealous in moving stuff over to scala-xml in 9c50dd5274 These were all compiler tests that accidentally touched on xml. I've tried to delicately decouple them so they can roam the scalac pastures as intended.
* | | | Revert "temporarily disables run/reflection-sync-subtypes"Jason Zaugg2013-11-142-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 04e2dbb29830d0e511cdfa8c132a9fad91d657ed, by avoiding the ill-fated attempt to short-circuit the global reflection lock. I think we can do better performance wise, but lets at least get something correct to start with.
* | | | Merge pull request #3133 from adriaanm/merge-2.10Adriaan Moors2013-11-143-0/+15
|\ \ \ \ | |/ / / |/| | | Merge 2.10
| | | |
| | \ \
| *-. \ \ Merge commit '075f6f260c'; commit 'e09a8a2b7f' into merge-2.10Adriaan Moors2013-11-133-0/+15
| |\ \ \ \ | | | |_|/ | | |/| |
| | * | | SI-6546 InnerClasses attribute refers to absent classPaul Phillips2013-11-043-0/+15
| | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At issue is that the optimizer would eliminate closure classes completely, then neglect to eliminate those classes from the container's InnerClasses attribute. This breaks tooling which expects those entries to correspond to real classes. The code change is essentially mgarcia's - I minimized it and put the caches in perRunCaches, and added the test case which verifies that after being compiled under -optimise, there are no inner classes. Before/after: 7,8d6 < InnerClasses: < public final #22; //class A_1$$anonfun$f$1 37,45c35,40 < #21 = Utf8 A_1$$anonfun$f$1 < #22 = Class #21 // A_1$$anonfun$f$1 < #23 = Utf8 Code --- > #21 = Utf8 Code
* | | | Merge pull request #3129 from adriaanm/pr-rebase-3001Adriaan Moors2013-11-13153-250/+374
|\ \ \ \ | |/ / / |/| | | [rebase] blackbox and whitebox macros
| * | | blackbox restriction #4: can't customize pattern matchingEugene Burmako2013-11-123-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | When an application of a blackbox macro is used as an extractor in a pattern match, it triggers an unconditional compiler error, preventing customizations of pattern matching implemented with macros.
| * | | blackbox restriction #3: can't affect implicit searchEugene Burmako2013-11-125-4/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an application of a blackbox macro is used as an implicit candidate, no expansion is performed until the macro is selected as the result of the implicit search. This makes it impossible to dynamically calculate availability of implicit macros.
| * | | blackbox restriction #2: can't guide type inferenceEugene Burmako2013-11-127-1/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an application of a blackbox macro still has undetermined type parameters after Scala’s type inference algorithm has finished working, these type parameters are inferred forcedly, in exactly the same manner as type inference happens for normal methods. This makes it impossible for blackbox macros to influence type inference, prohibiting fundep materialization.
| * | | blackbox restriction #1: can't refine the official return typeEugene Burmako2013-11-1213-17/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an application of a blackbox macro expands into a tree `x`, the expansion is wrapped into a type ascription `(x: T)`, where `T` is the declared return type of the blackbox macro with type arguments and path dependencies applied in consistency with the particular macro application being expanded. This invalidates blackbox macros as an implementation vehicle of type providers.
| * | | blackbox and whitebox macrosEugene Burmako2013-11-12137-248/+258
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the first commit in the series. This commit only: 1) Splits Context into BlackboxContext and WhiteboxContext 2) Splits Macro into BlackboxMacro and WhiteboxMacro 3) Introduces the isBundle property in the macro impl binding Here we just teach the compiler that macros can now be blackbox and whitebox, without actually imposing any restrictions on blackbox macros. These restrictions will come in subsequent commits. For description and documentation of the blackbox/whitebox separation see the official macro guide at the scaladoc website: http://docs.scala-lang.org/overviews/macros/blackbox-whitebox.html Some infrastructure work to make evolving macros easier: compile partest-extras with quick so they can use latest library/reflect/...
* | | Merge pull request #3123 from som-snytt/issue/7747-scrapcodes-fixAdriaan Moors2013-11-122-0/+355
|\ \ \ | | | | | | | | SI-7747 Support class based wrappers in REPL
| * | | SI-7747 Support class based wrappers clean upSom Snytt2013-11-101-21/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simplified the code paths to just use one of two `Wrapper` types for textual templating. Simplified the class-based template to use the same `$iw` name for the both the class and the wrapper value. In addition, the $read value is an object extending $read, instead of containing an extra instance field, which keeps paths to values the same for both templates. Both styles trigger loading the value object by referencing the value that immediately wraps the user code, although for the class style, inner vals are eager and it would suffice to load the enclosing `$read` object. The proposed template included extra vals for values imported from history, but this is not necessary since such an import is always a stable path. (Or, counter-example to test is welcome.) The test for t5148 is updated as a side effect. Probably internal APIs don't make good test subjects. Modify -Y option message.
| * | | SI-7747 Support class based wrappers as alternative through switch ↵Prashant Sharma2013-11-102-0/+360
| |/ / | | | | | | | | | | | | | | | | | | | | | -Yrepl-class-based Refactoring to reduce the number of if-else Fix test.
* / / SI-7958 Deprecate methods `future` and `promise` in the `scala.concurrent` ↵Philipp Haller2013-11-124-5/+5
|/ / | | | | | | | | | | | | | | | | | | | | | | | | package object - The corresponding `apply` methods in the `Future` and `Promise` objects should be used instead. - Adjusted tests to use non-deprecated versions - Fixed doc comments not to use deprecated methods - Added comment about planned removal in 2.13.0
* | Merge pull request #3094 from retronym/topic/erasure-optJames Iry2013-11-081-2/+2
|\ \ | | | | | | Avoid needless TypeRef allocation during erasure.
| * | Avoid needless TypeRef allocation during erasure.Jason Zaugg2013-11-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - ThisType(some.package) need not be erased, we can let that prefix through unchanged and avoid churning through allocations. - Sharpen the condition in `rebindInnerClass`. The answer to the deleted comment in the code, is "anonymous and local classes", which are specifically excluded in the new formulation. - Finally, detect if erasure of the TypeRef is an identity and reuse the original. Waste not, want not. To expand on the first point, here is what used to happen during erasure: scala> val scalaPack = typeOf[Predef.type].prefix scalaPack: $r.intp.global.Type = scala.type scala> typeDeconstruct.show(scalaPack) res19: String = ThisType(package scala) scala> typeDeconstruct.show(erasure.scalaErasure(scalaPack)) res20: String = TypeRef(TypeSymbol(final class scala extends )) Showing one step of the erasure type map: scala> typeDeconstruct.show(scalaPack.asInstanceOf[SubType].underlying.typeOfThis) res21: String = SingleType(pre = ThisType(package <root>), package scala)
* | | Collections library tidying and deprecation. Separate parts are listed below.Rex Kerr2013-11-0713-2/+15
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Collections library tidying, part one: scripting. Everything in scala.collection.scripting is deprecated now, along with the << method that is implemented in a few other classes. Scripting does not seem used at all, and anyone who did can easily write a wrapper that does the same thing. Deprecated *Proxy collections. The only place proxies were used in the library was in swing.ListView, and that was easy to change to a lazy val. Proxy itself is used in ScalaNumberProxy and such, so it was left undeprecated. Deprecated Synchronized* traits from collections. Synchronizability does not compose well, and it requires careful examination of every method (which has not actually been done). Places where the Scala codebase needs to be fixed (eventually) include: scala.reflect.internal.util.Statistics$QuantMap scala.tools.nsc.interactive.Global (several places) Deprecated LinkedList (including Double- and -Like variants). Interface is idiosyncratic and dangerously low-level. Although some low-level functionality of this sort would be useful, this doesn't seem to be the ideal implementation. Also deprecated the extractFirst method in Queue as it exposes LinkedList. Cannot shift internal representations away from LinkedList at this time because of that method. Deprecated non-finality of several toX collection methods. Improved documentation of most toX collection methods to describe what the expectation is for their behavior. Additionally deprecated overriding of - toIterator in IterableLike (should always forward to iterator) - toTraversable in TraversableLike (should always return self) - toIndexedSeq in immutable.IndexedSeq (should always return self) - toMap in immutable.Map (should always return self) - toSet in immutable.Set (should always return self) Did not do anything with IterableLike.toIterable or Seq/SeqLike.toSeq since for some odd reason immutable.Range overrides those. Deprecated Forwarders from collections. Forwarding, without an automatic mechanism to keep up to date with changes in the forwarded class, is inherently unreliable. Absent a mechanism to keep current, they're deprecated. ListBuffer is the only class in the collections library that uses forwarders, and that functionality can be rolled into ListBuffer itself. Deprecating immutable set/map adaptors. They're a bad idea (barring compiler support) for the same reason that all the other adaptors are a bad idea: they get out of date and probably have a variety of performance bugs. Deprecated inheritance from leaf classes in immutable collections. Inheriting from leaf-classes in immutable collections is rarely a good idea since whenever you use any interesting collections method you'll revert to the original class. Also, the methods are often designed to work with only particular behavior, and an override would be difficult (at best) to make work. Fortunately, people seem to have realized this and there are few to no cases of people extending PagedSeq and TreeSet and the like. Note that in many cases the classes will become sealed not final. Deprecated overriding of methods and inheritance from various mutable collections. Some mutable collections seem unsuited for overriding since to override anything interesting you would need vast knowledge of internal data structures and/or access to private methods. These include - ArrayBuilder.ofX classes. - ArrayOps - Some methods of BitSet (moved others from private to protected final) - Some methods of HashTable and FlatHashTable - Some methods of HashMap and HashSet (esp += and -= which just forward) - Some methods of other maps and sets (LinkedHashX, ListMap, TreeSet) - PriorityQueue - UnrolledBuffer This is a somewhat aggressive deprecation, the theory being better to try it out now and back off if it's too much than not attempt the change and be stuck with collections that can neither be safely inherited nor have implementation details changed. Note that I have made no changes--in this commit--which would cause deprecation warnings in any of the Scala projects available on Maven (at least as gathered by Adriaan). There are deprecation warnings induced within the library (esp. for classes/traits that should become static) and the compiler. I have not attempted to fix all the deprecations in the compiler as some of them touch the IDE API (but these mostly involved Synchronized which is inherently unsafe, so this should be fixed eventually in coordination with the IDE code base(s)). Updated test checks to include new deprecations. Used a higher level implementation for messages in JavapClass.
* | Merge pull request #3042 from gourlaysama/t7634-repl-sh-is-brokenAdriaan Moors2013-11-072-0/+30
|\ \ | | | | | | SI-7634 resurrect the REPL's :sh command
| * | SI-7634 resurrect the REPL's :sh commandAntoine Gourlay2013-11-062-0/+30
| | | | | | | | | | | | | | | | | | ProcessResult had a companion object in 2.10 that somehow disappeared in 2.11. It only called "new ProcessResult(...)", so the REPL might just as well do that.
* | | Force several tests to run using inline delambdafication.James Iry2013-11-065-1/+5
| | | | | | | | | | | | | | | | | | The differences when running with method based delambdafication aren't important enough yet to create specialized versions that use method based delambdafication.
* | | Create test variants where delambdafication alters signatures.James Iry2013-11-066-2/+110
| | | | | | | | | | | | | | | | | | This commit includes several tests where there's a variation in signatures between inline delambdafication and method based delambdafication.
* | | Make GenASM not eliminate loadmodule on static methods.James Iry2013-11-062-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | During development of delayed delambdafy there was a problem where GenASM would eliminate a loadmodule for all methods defined within that module even if those methods were static. The result would be broken byte code that failed verification. This commit fixes that and adds a test.
* | | Flesh out the Delambdafy phase.James Iry2013-11-064-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit puts a real body on the Delambdafy phase. From a lambda, Delambdafy will create 1) a static forwarder at the top level of the class that contained the lambda 2) a new top level class that a) has fields and a constructor taking the captured environment (including possbily the "this" reference) b) an apply method that calls the static forwarder c) if needed a bridge method for the apply method 3) an instantiation of the newly created class which replaces the lambda Trees.scala is modified to add two more convenient factories for templates and classdefs. A few basic tests are included to verify that it works as expected. Further commits will have additional tests.
* | | Adds a setting to delay delambdafication. If set then uncurry liftsJames Iry2013-11-068-0/+156
| | | | | | | | | | | | | | | the body of a lambda into a local def. Tests are included to show the different tree shapes.
* | | Add a skeletal Delambdafy phase.James Iry2013-11-012-3/+5
| | | | | | | | | | | | | | | | | | This commit adds a do-nothing phase called "Delambdafy" that will eventually be responsible for doing the final translation of lambdas into classes.
* | | Merge pull request #3082 from retronym/ticket/6385Grzegorz Kossakowski2013-10-292-0/+26
|\ \ \ | | | | | | | | SI-6385 Avoid bridges to identical signatures over value classes
| * | | SI-6385 Avoid bridges to identical signatures over value classesJason Zaugg2013-10-282-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As Paul noted in the comments to SI-6260 (from which I mined some test cases) "there is no possible basis for conflict here": scala> class C[A](val a: Any) extends AnyVal defined class C scala> class B { def x[A](ca: C[A]) = () } defined class B scala> class D extends B { override def x[A](ca: C[A]) = () } <console>:8: error: bridge generated for member method x: [A](ca: C[A])Unit in class D which overrides method x: [A](ca: C[A])Unit in class B clashes with definition of the member itself; both have erased type (ca: Object)Unit class D extends B { override def x[A](ca: C[A]) = () } ^ What was happening? Bridge computation compares `B#x` and `D#x` exitingErasure, which results in comparing: ErasedValueType(C[A(in B#x)]) =:= ErasedValueType(C[A(in D#x)]) These types were considered distinct (on the grounds of the unique type hash consing), even though they have the same erasure and involve the same value class. That triggered creation of an bridge. After post-erasure eliminates the `ErasedValuedType`s, we find that this marvel of enginineering is bridges `(Object)Unit` right back onto itself. The previous resolution of SI-6385 (d435f72e5fb7fe) was a test case that confirmed that we detected the zero-length bridge and reported it nicely, which happened after related work in SI-6260. But we can simply avoid creating in it in the first place. That's what this commit does. It does so by reducing the amount of information carried in `ErasedValueType` to the bare minimum needed during the erasure -> posterasure transition. We need to know: 1. which value class wraps the value, so we can box and unbox as needed 2. the erasure of the underlying value, which will replace this type in post-erasure. This construction means that the bridge above computation now compares: ErasedValueType(C, Any) =:= ErasedValueType(C, Any]) I have included a test to show that: - we don't incur any linkage or other runtime errors in the reported case (run/t6385.scala) - a similar case compiles when the signatures align (pos/t6260a.scala), but does *not* compile when the just erasures align (neg/t6260c.scala) - polymorphic value classes continue to erase to the instantiated type of the unbox: (run/t6260b.scala) - other cases in SI-6260 remains unsolved and indeed unsolvable without an overhaul of value classes: (neg/t6260b.scala) In my travels I spotted a bug in corner case of null, asInstanceOf and value classes, which I have described in a pending test.
* | | | Remove empty check files and flags files.Jason Zaugg2013-10-2738-0/+0
|/ / / | | | | | | | | | for f in $(find test -name '*.check' -o -name '*.flags'); do [[ $(wc -c $f | sed -E 's/ *([0-9]+).*/\1/') == "0" ]] && rm $f; done
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-16 19:55:34 +0000