summaryrefslogtreecommitdiff
path: root/test/files/pos
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #3189 from retronym/ticket/8002Jason Zaugg2013-11-261-0/+20
|\ | | | | private access for local companions
| * SI-8002 private access for local companionsJason Zaugg2013-11-241-0/+20
| | | | | | | | | | | | 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
* | SI-8011 Test case for recently fixed value class bugJason Zaugg2013-11-261-0/+8
| | | | | | | | | | The improvements to symbol substitution in cb37548ef made this one work.
* | Merge pull request #3183 from xeno-by/topic/pure-expression-does-nothingAdriaan Moors2013-11-254-0/+15
|\ \ | | | | | | SI-8001 spurious "pure expression does nothing" warning
| * | SI-8001 spurious "pure expression does nothing" warningEugene Burmako2013-11-234-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `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 #3137 from xeno-by/topic/implicit-macros-invalidate-on-errorAdriaan Moors2013-11-222-0/+28
|\ \ \ | | | | | | | | correctly fails implicit search for invalid implicit macros
| * | | correctly fails implicit search for invalid implicit macrosEugene Burmako2013-11-142-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a rare corner case when implicit search wouldn’t discard an invalid implicit macro (e.g. the one with mismatching macro impl or the one with macro impl defined in the same compilation run) during typechecking the corresponding candidate in typedImplicit1. This is now fixed.
* | | | Merge pull request #3160 from retronym/ticket/7983Adriaan Moors2013-11-221-0/+31
|\ \ \ \ | | | | | | | | | | Fix implicit divergence regression
| * | | | SI-7983 Fix regression in implicit divergence checkingJason Zaugg2013-11-191-0/+31
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As seen in Slick. Regressed in 039b1cb1a5b8. In that commit, a call to `normalize` was replaced with `dealiasWiden` as part of a broad sweeping change. However, while the latter does less than the former with regards to eta expansion ofhigher kinded type refs (the motivation of that commit), it also does more when it comes to singleton types: they are widened to the underlying type. This was widening away `SingleType(<<package a.b>>, <<package c>>)` before the special case assiging that type component a complexity of zero could kick in. In the test case, extracted from Slick, this meant that the divergence check would consider that the second type below to outrank the first in the complexity measure, and abort the implicit search. Shape[?, ? (Coffees, Coffees), ?] Shape[DivergenceTest.this.Flat, ?, Coffees, ?] After this change, the number of packages enclosing `DivergenceTest` no longer has a bearing on the complexity score of the type. Here's how the race was run before hand: complexity(<noprefix>): 0 complexity(<root>): 1 complexity(foo.type): 2 complexity(foo.bar.type): 3 complexity(foo.bar.baz.type): 4 complexity(DivergenceTest.this.type): 5 complexity(<noprefix>): 0 complexity(<root>): 1 complexity(foo.type): 2 complexity(foo.bar.type): 3 complexity(foo.bar.baz.type): 4 complexity(DivergenceTest.this.type): 5 complexity(DivergenceTest.this.Flat): 6 complexity(<noprefix>): 0 complexity(<root>): 1 complexity(scala.type): 2 complexity(Int): 3 complexity(?): 1 complexity(DivergenceTest.this.Shape2[DivergenceTest.this.Flat,Int,?]): 16 complexity(<noprefix>): 0 complexity(<root>): 1 complexity(foo.type): 2 complexity(foo.bar.type): 3 complexity(foo.bar.baz.type): 4 complexity(DivergenceTest.this.type): 5 complexity(?): 1 complexity(<noprefix>): 0 complexity(<root>): 1 complexity(scala.type): 2 complexity(<noprefix>): 0 complexity(Coffees): 1 complexity(<noprefix>): 0 complexity(<root>): 1 complexity(scala.type): 2 complexity(Int): 3 complexity((Coffees, Int)): 7 complexity(?): 1 complexity(DivergenceTest.this.Shape2[?,(Coffees, Int),?]): 15 dominates(DivergenceTest.this.Shape2[_ <: DivergenceTest.this.Flat, Int, U2], DivergenceTest.this.Shape2[_ <: Level, (Coffees, Int), U1]): true And afterwards: complexity(DivergenceTest.this.type): 1 complexity(DivergenceTest.this.type): 1 complexity(DivergenceTest.this.Flat): 2 complexity(scala.type): 1 complexity(Int): 2 complexity(?): 1 complexity(DivergenceTest.this.Shape2[DivergenceTest.this.Flat,Int,?]): 7 complexity(DivergenceTest.this.type): 1 complexity(?): 1 complexity(scala.type): 1 complexity(<noprefix>): 0 complexity(Coffees): 1 complexity(scala.type): 1 complexity(Int): 2 complexity((Coffees, Int)): 5 complexity(?): 1 complexity(DivergenceTest.this.Shape2[?,(Coffees, Int),?]): 9 dominates(DivergenceTest.this.Shape2[_ <: DivergenceTest.this.Flat, Int, U2], DivergenceTest.this.Shape2[_ <: Level, (Coffees, Int), U1]): false Notice that even in the after shot, `scala.Int` has a complexity of 2. It should be 1; this will be fixed in a separate commit.
* | | | Merge pull request #3131 from densh/pr/deprecate-pair-and-tripleJason Zaugg2013-11-2213-31/+31
|\ \ \ \ | |_|_|/ |/| | | Deprecate Pair and Triple
| * | | deprecate Pair and TripleDen Shabalin2013-11-2013-31/+31
| |/ /
* / / SI-7987 Test case for "macro not expanded" error with implicitsJason Zaugg2013-11-212-0/+18
|/ / | | | | | | | | | | Fixed, serendipitously, a handful of commits ago in 4a6882e772, "SI-7944 FOUND: stray undetermined type params in vicinity of implicits".
* | Merge pull request #3135 from adriaanm/revive-xml-testsJames Iry2013-11-185-0/+68
|\ \ | | | | | | Revived tests that once depended on xml
| * | Revived tests that once depended on xmlAdriaan Moors2013-11-145-0/+68
| |/ | | | | | | | | | | | | 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.
* | Merge pull request #3133 from adriaanm/merge-2.10Adriaan Moors2013-11-142-0/+22
|\ \ | |/ |/| Merge 2.10
| *-. Merge commit '075f6f260c'; commit 'e09a8a2b7f' into merge-2.10Adriaan Moors2013-11-132-0/+22
| |\ \
| | | * SI-4012 Mixin and specialization work wellVlad Ureche2013-11-052-0/+22
| | |/ | | | | | | | | | The bug was fixed along with SI-7638 in 504b5f3.
* | | Merge pull request #3129 from adriaanm/pr-rebase-3001Adriaan Moors2013-11-1316-37/+42
|\ \ \ | |/ / |/| | [rebase] blackbox and whitebox macros
| * | blackbox and whitebox macrosEugene Burmako2013-11-1216-37/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/...
* | | SI-7958 Deprecate methods `future` and `promise` in the `scala.concurrent` ↵Philipp Haller2013-11-121-1/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | | | 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 #3101 from xeno-by/ticket/7776Eugene Burmako2013-11-072-0/+20
|\ \ | | | | | | SI-7776 post-erasure signature clashes are now macro-aware
| * | SI-7776 post-erasure signature clashes are now macro-awareEugene Burmako2013-11-052-0/+20
| | | | | | | | | | | | | | | | | | | | | "double definition: macro this and method that have same type after erasure" This error doesn't make sense when macros are involved, because macros expand at compile-time, where we're not affected by erasure. Moreover, macros produce no bytecode, which means that we're safe from VerifyErrors.
* | | Merge pull request #3081 from JamesIry/wip_delayed_delambdafy_cleanupAdriaan Moors2013-11-072-0/+23
|\ \ \ | |/ / |/| | Delay delambdafication and put the lambda's body into the containing class
| * | Flesh out the Delambdafy phase.James Iry2013-11-062-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | SI-7944 FOUND: stray undetermined type params in vicinity of implicitsJason Zaugg2013-10-311-0/+24
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implicit search created a nested Context into which the results of its typechecking, namely, errors and undetermined type parameters (roughly: those inferred as Nothing) are stashed. The code the drives the process was checking for errors, but discarded those undetermined type parameters. This commit copies them from the child context to the parent, which lets `Typer#adapt` to get to: else if (hasUndetsInMonoMode) { // (9) assert(!context.inTypeConstructorAllowed, context) //@M instantiatePossiblyExpectingUnit(tree, mode, pt) } Our lost TypeVar has found its way home! The reward for which is being instantiated, based on another type inference session adapting the expression's type to the expected type.
* | Merge pull request #3082 from retronym/ticket/6385Grzegorz Kossakowski2013-10-291-0/+15
|\ \ | | | | | | SI-6385 Avoid bridges to identical signatures over value classes
| * | SI-6385 Avoid bridges to identical signatures over value classesJason Zaugg2013-10-281-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-278-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
* | SI-7928 Favour module accessors symbols in rebindJason Zaugg2013-10-231-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Refchecks tree transformer transforms a nested modules that overrides a method into a pair of symbols: the module itself, and an module accessor that matches the overridden symbol. [[syntax trees at end of typer]] // test1.scala package <empty> { abstract trait C2 extends scala.AnyRef { def O1: Any }; class C1 extends AnyRef with C2 { object O1 extends scala.AnyRef } } [[syntax trees at end of refchecks]] // test1.scala package <empty> { abstract trait C2 extends scala.AnyRef { def O1: Any }; class C1 extends AnyRef with C2 { object O1 extends scala.AnyRef @volatile <synthetic> private[this] var O1$module: C1.this.O1.type = _; <stable> def O1: C1.this.O1.type = { C1.this.O1$module = new C1.this.O1.type(); C1.this.O1$module } } } When constructing a TypeRef or SingleType with a prefix and and a symbol, the factory methods internally use `rebind` to see if the provided symbol should be replaced with an overriding symbol that is available in that prefix. Trying this out in the REPL is a bit misleading, because even if you change phase to `refchecks`, you won't get the desired results because the transform is not done in an InfoTransformer. scala> val O1 = typeOf[C1].decl(TermName("O1")) O1: $r.intp.global.Symbol = object O1 scala> typeRef(typeOf[C2], O1, Nil) res13: $r.intp.global.Type = C2#O1 scala> res13.asInstanceOf[TypeRef].sym.owner res14: $r.intp.global.Symbol = class C1 But debugging the test case, we get into `rebind` during an AsSeenFrom which is where we crashed when `suchThat` encountered the overloaded module and module accessor symbols: typeOf[OuterObject.Inner.type].memberType(symbolOf[InnerTrait.Collection]) ... singleTypeAsSeen(OuterTrait.this.Inner.type) val SingleType(pre, sym) = tp // pre = OuterTrait.this.type // sym = OuterTrait.Inner val pre1 = this(pre) // OuterObject.type singleType(pre1, sym) rebind(pre1, sym) // was crashing, now OuterObject.Inner } This commit excludes the module symbol from symbol lookup in the prefix in rebind.
* | changes some manual tree constructions in macro tests to quasiquotesEugene Burmako2013-10-185-7/+7
| |
* | deprecates raw tree manipulation facilities in macros.ContextEugene Burmako2013-10-184-6/+6
| |
* | Merge pull request #3030 from xeno-by/topic/fundep-viewsEugene Burmako2013-10-182-0/+16
|\ \ | | | | | | SI-3346 implicit parameters can now guide implicit view inference
| * | SI-3346 implicit parameters can now guide implicit view inferenceEugene Burmako2013-10-112-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This simple patch makes it possible for implicit views to benefit from fundep-guided type inference, eliminating a nasty special case in implicit inference. Here are the changes that I had to apply to the tests (they exposed quite a number of interesting questions that I was happy to answer): 1) neg/t5845.scala now works, so I moved it to pos. That easily makes sense, because the test was just a canary to track previous state of things. 2) neg/divergent_implicit.scala, neg/t5578.scala and neg/t7519.scala changed their messages to less informative ones, because inapplicable implicit views now get disqualified early and therefore don't display their error messages to the user. This is an unfortunate but necessary byproduct of this change, and one can argue that the behavior is now completely consistent with implicit vals (that also don't explain why this or that implicit val got disqualified, but rather display a generic implicit value not found message). 3) scaladoc/implicits-chaining.scala and scaladoc/implicits-base.scala. Immediate culling of apriori inapplicable implicit views messes things up for Scaladoc, because it's interested in potentially applicable views, having infrastructure to track various constraints (type bounds, requirements for implicit parameters, etc) that guide applicability of views and then present it to the user. Therefore, when scaladoc is detected, implicit search reverts to the old behavior. 4) We still cannot have Jason's workaround to type constructor inference mentioned in comments to SI-3346, because it's not really about implicit parameters of implicit views, but about type inference flowing from the implicit parameter list to a preceding parameter list in order to affect inference of an implicit view. This is something that's still too ambitious.
* | | Merge pull request #3045 from retronym/ticket/7688-4Jason Zaugg2013-10-181-0/+7
|\ \ \ | | | | | | | | Fix AsSeenFrom of ThisType from TypeVar prefix
| * | | SI-7688 Fix AsSeenFrom of ThisType from TypeVar prefixJason Zaugg2013-10-171-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Restores behaviour for the AsSeenFrom before the refactoring in b457b6c477. This commit uniformly considered that a `TypeVar` prefix should not `matchesPrefixAndClass`; a condition that formerly was only applied if the type being viewed was a `TypeRef`. This condition was originally added in cc9e8eda3364d as a backstop for pos/t2797.scala. This commit leaves that backstop in place where it was, although it expresses it more directly by checking if `pre baseType clazz` is `NoType`, which was the case that cropped up in SI-2797: scala> type T = bc._1.type forSome { val bc: (AnyRef, AnyRef) } warning: there were 1 feature warning(s); re-run with -feature for details defined type alias T scala> val et = typeOf[T].dealias.asInstanceOf[ExistentialType] et: $r.intp.global.ExistentialType = bc._1.type forSome { val bc: (AnyRef, AnyRef) } scala> et.withTypeVars( { x => | println(x.prefix.typeSymbol) | println(x.prefix.typeSymbol.isSubClass(typeOf[Tuple2[_, _]].typeSymbol)) | println(x.prefix.baseType(typeOf[Tuple2[_, _]].typeSymbol)) | true | } , reflect.internal.Depth(0)) type bc.type true <notype> res98: Boolean = true
* | | | Merge remote-tracking branch 'scala/master' into fix-merge-3018Grzegorz Kossakowski2013-10-142-11/+17
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | Conflicts: src/compiler/scala/tools/nsc/typechecker/Typers.scala
| * | | | SI-7902 Fix spurious kind error due to an unitialized symbolJason Zaugg2013-10-091-0/+17
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tracked down this error: <none> is invariant, but type Y2 is declared covariant <none>'s bounds<notype> are stricter than type X2's declared bounds >: Nothing <: Any, <none>'s bounds<notype> are stricter than type Y2's declared bounds >: Nothing <: Any to `Symbol#typeParams` returning `List(NoSymbol)` if the symbol was not initialized. This happends in the enclosed test for: // checkKindBoundsHK() hkArgs = List(type M3) hkParams = List(type M2) This commit forces the symbol of the higher-kinded type argument before checking kind conformance. A little backstory: The `List(NoSymbol)` arises from: class PolyTypeCompleter... { // @M. If `owner` is an abstract type member, `typeParams` are all NoSymbol (see comment in `completerOf`), // otherwise, the non-skolemized (external) type parameter symbols override val typeParams = tparams map (_.symbol) The variation that triggers this problem gets into the kind conformance checks quite early on, during naming of: private[this] val x = ofType[InSeq] The inferred type of which is forced during: def addDerivedTrees(typer: Typer, stat: Tree): List[Tree] = stat match { case vd @ ValDef(mods, name, tpt, rhs) if !noFinishGetterSetter(vd) => // If we don't save the annotations, they seem to wander off. val annotations = stat.symbol.initialize.annotations
| * / / SI-7899 Don't infer by-name types during, e.g. eta-expansionJason Zaugg2013-10-071-11/+0
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given: def id[A](a: A): A = a def foo(f: (=> Int) => Int) = () foo(id) We eta-expanded `id` and inferred `A` to be `=> Int` to satisfy the expected type set forth by the formal parameter `f`. We really shouldn't go about inferring types that we can't *write*. Our attempt to do so led promptly into a `ClassCastException` in the enclosed test. This commit: - drops by-name-ness during `inferExprInstance` - tests that this results in a type error for the reported bug (neg/t7899) - tests that a method with a by-name parameter can still be eta expanded to match function with a corresponding by-name parameter (run/t7899) - discovers the same latent CCE in pos/t7584 - now that would be a type error - so we compensate by using placeholder functions rather than eta-expansion. - and move that that test to `run` for good measure.
* | | Single Abstract Method support: java8 testAdriaan Moors2013-10-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Inspired by test/files/run/t7398.scala and sammy_poly. Added some notes to original tests. Elaborating on that note: we don't yet desugar `f(a)` to `f.sam(a)`, like we do for regular functions: `f(a)` becomes `f.apply(a)`. It seems pleasingly symmetrical and is easy to implement, but not sure it's a good idea...
* | | Extract SerialVersionUIDAnnotation. Make SAM body synthetic.Adriaan Moors2013-10-082-0/+10
| | | | | | | | | | | | Addressing review feedback.
* | | Single Abstract Method support: synthesize SAMsAdriaan Moors2013-10-047-2/+32
|/ / | | | | | | | | | | | | | | | | | | Under `-Xexperimental`, `typedFunction` invokes `synthesizeSAMFunction` when the expected type for the function literal (`pt`) is not the built-in `FunctionN` type of the expected arity, but `pt` does have a SAM with the expected number of arguments. PS: We'll require `import language.sam` instead of `-Xexperimental`, as soon as the SIP is ready and there are more tests.
* | SI-6680 unsoundness in gadt typing.Paul Phillips2013-10-012-1/+30
| | | | | | | | | | | | | | Introduces -Xstrict-inference to deal with the significant gap between soundness and what presently compiles. I'm hopeful that it's TOO strict, because it finds e.g. 75 errors compiling immutable/IntMap.scala, but it might be that bad.
* | Merge remote-tracking branch 'origin/2.10.x' into merge/2.10.x-to-master-2Jason Zaugg2013-09-271-0/+30
|\| | | | | | | | | | | | | | | | | | | Conflicts: bincompat-backward.whitelist.conf bincompat-forward.whitelist.conf build.xml src/compiler/scala/tools/nsc/typechecker/RefChecks.scala src/library/scala/concurrent/Future.scala src/reflect/scala/reflect/internal/Types.scala
| * Merge pull request #2919 from retronym/ticket/7815Jason Zaugg2013-09-231-0/+30
| |\ | | | | | | SI-7815 Dealias before deeming method type as dependent
| | * SI-7815 Dealias before deeming method type as dependentJason Zaugg2013-09-071-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To enable eta-expansion of method types seen from a prefix that renders the result type as independent from the parameter symbols. The enclosed test shows that we dealias types before checking dependence, and that we do this deeply (e.g. type arguments are also dealised.) An existing test, neg/error_dependentMethodTpeConversionToFunction, confirms that bona-fide dependent methods are still prohibited from eta expansion.
* | | Revert "Merge pull request #2957 from paulp/pr/parser-improvements"François Garillot2013-09-241-5/+0
| | | | | | | | | | | | | | | This reverts commit 884e1ce762d98b29594146d37b85384581d9ba96, reversing changes made to f6fcc4431f272c707d49de68add532c452dd4b0f.
* | | SI-7864 Harden "looks like an interpolated String" warningJason Zaugg2013-09-222-0/+6
| | | | | | | | | | | | | | | We can't rely on the qualifier of an `Apply` having a non-null symbol in general.
* | | SI-7854, SI-6768 better parsing/positioning in parserPaul Phillips2013-09-181-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The parser hole I found while working on the generated positions serves as the umbrella for a host of improvements. Upgraded positions assigned during some specific challenging situations mostly involving the creation of synthetic trees, e.g. for comprehensions and closures. While doing so improved some error messages. Eliminated some of the most glaring duplication in the parser. It's written like there is some payoff associated with being spectacularly imperative. Not so far.
* | | Merge pull request #2961 from paulp/pr/whitespaceJason Zaugg2013-09-18263-604/+590
|\ \ \ | | | | | | | | Cull extraneous whitespace.
| * | | Cull extraneous whitespace.Paul Phillips2013-09-18263-604/+590
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One last flurry with the broom before I leave you slobs to code in your own filth. Eliminated all the trailing whitespace I could manage, with special prejudice reserved for the test cases which depended on the preservation of trailing whitespace. Was reminded I cannot figure out how to eliminate the trailing space on the "scala> " prompt in repl transcripts. At least reduced the number of such empty prompts by trimming transcript code on the way in. Routed ConsoleReporter's "printMessage" through a trailing whitespace stripping method which might help futureproof against the future of whitespace diseases. Deleted the up-to-40 lines of trailing whitespace found in various library files. It seems like only yesterday we performed whitespace surgery on the whole repo. Clearly it doesn't stick very well. I suggest it would work better to enforce a few requirements on the way in.
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-13 07:50:30 +0000