summaryrefslogtreecommitdiff
path: root/test/files
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #3647 from densh/si/8411Jason Zaugg2014-03-253-0/+19
|\ | | | | SI-8411 match desugared partial functions
| * SI-8411 match desugared partial functionsDenys Shabalin2014-03-223-0/+19
| |
* | introduces Mirror.typeOfEugene Burmako2014-03-252-0/+56
| | | | | | | | | | | | | | | | | | I just realized that our tag-based shortcuts were incomplete, because they only work with root mirrors (doing just u.typeTag[T].tpe means that the type is going to be resolved in u.rootMirror because that's the default). This commit fixes this oversight. I'm hoping for 2.11.0-RC3, but also feel free to reschedule to 2.12.0-M1 if it becomes clear that RC3 isn't happening.
* | Merge pull request #3653 from densh/si/8200Jason Zaugg2014-03-252-5/+13
|\ \ | | | | | | SI-8200 provide an identity liftable for trees
| * | SI-8200 provide an identity liftable for treesDenys Shabalin2014-03-242-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This liftable hasn't been originally included in the set of standard liftables due to following contradiction: 1. On one hand we can have identity lifting that seems to be quite consistent with regular unquoting: q"..${List(1,2)}" <==> q"1; 2" q"${List(1,2)}" <==> q"s.c.i.List(1, 2)" q"..${List(q"a", q"b")}” <==> q"a; b" q"${List(q"a", q"b")}" <==> q"s.c.i.List(a, b)" This is also consistent with how lisp unquoting works although they get lifting for free thanks to homoiconicity: // scala scala> val x = List(q"a", q"b); q"f($x)" q"f(s.c.i.List(a, b))" // scheme > (let [(x (list a b))] `(f ,x)) '(f (list a b)) 2. On the other hand lifting is an operation that converts a value into a code that when evaluated turns into the same value. In this sense Liftable[Tree] means reification of a tree into a tree that represents it, i.e.: q"${List(q"a", q"b")}" <==> q"""s.c.i.List(Ident(TermName("a")), Ident(TermName("b")))""" But I belive that such lifting will be very confusing for everyone other than a few very advanced users. This commit introduces the first option as a default Liftable for trees.
* | | Merge pull request #3637 from densh/si/8420Jason Zaugg2014-03-251-0/+21
|\ \ \ | | | | | | | | SI-8420 don't crash on unquoting of non-liftable native type
| * | | SI-8420 don't crash on unquoting of non-liftable native typeDenys Shabalin2014-03-171-0/+21
| | |/ | |/| | | | | | | | | | | | | Previously quasiquote's type-based dispatch failed to handle situation where unquotee's type is native but non-liftable and was used to splice with non-zero cardinality.
* | | SI-8428 Fix regression in iterator concatenationJason Zaugg2014-03-201-0/+12
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | Regressed in e3ddb2d7, which introduced `ConcatIterator` to avoid super-linear runtime on chains of concatenated iterators. `ConcatIterator` maintains a queue of thunks for the remaining iterators. Both `next` and `hasNext` delegate to `advance`, which evaluates the thunks and discards any empty iterators from the start of the queue. The first non-empty iterator is stored in the var `current`. It also overrides `++`, and creates a new `ConcatIterator` with the given `that` as an extra element in the queue. However, it failed to copy `current` across, which led to data loss.
* | SI-8341 minor fixup for comments in testAdriaan Moors2014-03-181-3/+3
| |
* | SI-8341 Refine handoff of undet. params from implicit searchJason Zaugg2014-03-182-0/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In SI-7944 / 251c2b93, we discovered that typechecking of an implicit candidate could leave orphaned undetermined type parameters in the implicit search context. This resulted in naked type parameters leaking into implicit expansions. The fix seemed easy: just copy any symbols from `implicitSearchContext.undetparams` to the enclosing context (other than ones in `SearchResult#subst`). However, the test case in this ticket reveals a subtle flaw in that fix: `implicitSerachContext.undetparams` only contains the type params from the most recently typechecked candidate! Why? Implicit search uses the same context to typecheck all plausibly compatible candidates. The typechecking itself is driven by `typedImplicit1`. Side note, that explains the heisenbug behaviour noted in the ticket: Not *all* plausibly implicit candidates are typechecked. If the current 'best' eligible candidate is more specific than the next candidate, we can skip that altogether.Implicit search actually exploits this for performance by ordering the candidates according to usage statistics. This reordering, means that commenting out lines elsewhere in the file changed the behaviour! This commit simply stores the undet. tparams in the `SearchResult`, where it is safe from the vaguries of typechecking other candidates. That makes `Test1` and `Test2` with in the enclosed test case fail uniformly, both with each other, and with an explicit call to the view. This is ostensibly a regression from 2.10.3. To get there, we need an implicit search that has to infer `Nothing` in a covariant position. In 2.10.3, we would just let the `G` out into the wild, which did the right thing for the wrong reasons.
* | Merge pull request #3638 from xeno-by/topic/freshname-hotfixv2.11.0-RC2Adriaan Moors2014-03-173-0/+16
|\ \ | |/ |/| SI-8425 don't create double-dollar names in c.freshName
| * SI-8425 don't create double-dollar names in c.freshNameEugene Burmako2014-03-183-0/+16
| | | | | | | | | | | | If we append a dollar to a user-provided prefix that ends in a dollar, we create a potential for confusion for backend phases. That's why this commit prevents such situations from happening.
* | Merge pull request #3631 from adriaanm/t4492Adriaan Moors2014-03-163-12/+12
|\ \ | |/ |/| SI-4492 More informative error when class not found on classpath
| * SI-4492 More informative error when class not found on classpathAdriaan Moors2014-03-143-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | Position the error based on Select tree that failed to type check, presumably due to an underlying MissingRequirementError, which has no position. There are lots of other ways we could rewrap a MRE and supplement position info, but that remains TODO. Jason's review comment is recorded in the code. Also try to detect the case of a missing module and provide some advice, as well as linking to the forthcoming 2.11 guide at http://docs.scala-lang.org/overviews/core/scala-2.11.html.
* | Merge pull request #3598 from som-snytt/issue/8266-amend-adviceAdriaan Moors2014-03-141-1/+1
|\ \ | | | | | | SI-8266 Amend advice for deprecated octal 042
| * | SI-8266 Amend advice for deprecated octal 042Som Snytt2014-02-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Improve the advice for `f"\042"` to read: ``` use ${'"'} or a triple-quoted literal """with embedded " or \u0022""" instead. ``` as per the discussion on SI-6476. Knuth says that Charles XII came close to introducing octal arithmetic to Sweden, and Wikipedia doesn't deny it. I imagine an alternative history in which octal literals are deprecated in Scala but required by legislation in Akka. #octal-fan-fiction
* | | Merge pull request #3628 from gzm0/test-fixAdriaan Moors2014-03-142-2/+2
|\ \ \ | | | | | | | | Minor fixes in test. The equals method always returned true.
| * | | Minor fixes in test. The equals method always returned true.Tobias Schlatter2014-03-132-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit ensures that the classes we use to test HashMaps and HashSets in t6196 and t6200 have proper equals and hashCode methods. (The old equals method returned always true and therefore hashCode violated its contract).
* | | | Merge pull request #3623 from paulp/pr/source-210Adriaan Moors2014-03-143-0/+8
|\ \ \ \ | |_|_|/ |/| | | SI-8402 Restore 2.10 variance behavior under -Xsource:2.10
| * | | SI-8265 Restore 2.10 variance behavior under -Xsource:2.10Paul Phillips2014-03-123-0/+8
| |/ / | | | | | | | | | | | | | | | | | | Issue deprecation warning under -Xsource:2.10 so time travelers can have an authentic deprecation experience before finding that their unsound code no longer compiles in 2.11. The relevant ticket to the soundness issue is SI-6566.
* / / SI-8403 Fix regression in name binding with imports in templatesJason Zaugg2014-03-131-0/+9
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | Regressed in dbd8457 which changed `Context#make` to automatically include the imports from the given `Tree` if it was an `Import` tree, rather than requiring callers to call `makeNewImport`. However, this turns out to double up the imports for the "inner" namer of a template that starts with imports. The inner namer has a new scope, but the same owner and tree as its parent. This commit detects this case by seeing if the `Import` tree used to consruct the child context is the same as the parent context. If that is the case, we don't augment `Context#imports`.
* | Merge pull request #3622 from retronym/ticket/8395Adriaan Moors2014-03-121-0/+9
|\ \ | | | | | | SI-8395 Regression in pattern matching with nested binds
| * | SI-8395 Regression in pattern matching with nested bindsJason Zaugg2014-03-121-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Regressed in https://github.com/scala/scala/pull/2848. In particular, see 0cf47bdb5b and 017460e63c. Because of the regression, this pattern: (s @ (_s @ (_: String))) was translated into `typeTestStep`, rather than a `bindingStep`. This came down the the use of `unbind` in the `TypeBound` extractor. My first step was to remove the `unbind`. That led to another problem: the tree now matches `SymbolAndTypeBound`, which extracted `symbol = s, tpe = String`, ignoring the `_s`. I changed that extractor to no longer recursively apply to the sub-pattern tree, which is what `MaybeTypedBound` used to do. I also checked for other uses of `unbind` in the match translation. The only place I found it is in `BoundTree#pt`. I believe that this usage is correct, or at least, not obviously incorrect.
* | | Merge pull request #3615 from retronym/ticket/8376Adriaan Moors2014-03-125-0/+38
|\ \ \ | |/ / |/| | SI-8376 Fix overload resolution with Java varargs
| * | SI-8376 Better type printing for Java varargsJason Zaugg2014-03-103-0/+15
| | | | | | | | | | | | | | | `T*` rather than `<repeated>[T]`, as we alreday do for Scala repeated parameters.
| * | SI-8376 Fix overload resolution with Java varargsJason Zaugg2014-03-102-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When comparing specificity of two vararg `MethodTypes`, `isAsSpecific` gets to: ``` case mt @ MethodType(_, _) if bothAreVarargs => checkIsApplicable(mt.paramTypes mapConserve repeatedToSingle) ``` The formal parameter type of a Java varargs parameter is represented as `tq"${defintions.JavaRepeatedParamClass}[$elemTp]"`. For a Scala repeated parameter, we instead use `defintions.RepeatedParamClass`. `bothAreVarargs` detects `JavaRepeatedParamClass`, by virtue of: ``` def isRepeatedParamType(tp: Type) = isScalaRepeatedParamType(tp) || isJavaRepeatedParamType(tp) ``` But, `repeatedToSingle` only considers `RepeatedParamClass`. This bug was ostensibly masked in 2.10.3, but became apparent after a not-quite-refactoring in 0fe56b9770. It would be good to pin that change down to a particular line, but I haven't managed that yet.
* | | Merge pull request #3616 from retronym/ticket/8363Adriaan Moors2014-03-112-0/+8
|\ \ \ | | | | | | | | SI-8363 Disable -Ydelambdafy:method in constructor position
| * | | SI-8363 Disable -Ydelambdafy:method in constructor positionJason Zaugg2014-03-102-0/+8
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As @magarciaEPFL has done in his experimental optimizer [1], we can avoid running into limitations of lambdalift (either `VerifyError`s, ala SI-6666, or compiler crashes, such as this bug), by using the old style of "inline" lambda translation when in a super- or self- construtor call. We might be able to get these working later on, but for now we shouldn't block adoption of `-Ydelamndafy:method` for this corner case. [1] https://github.com/magarciaEPFL/scala/blob/GenRefactored99sZ/src/compiler/scala/tools/nsc/transform/UnCurry.scala#L227
* | | Add more tests for partial functionsDenys Shabalin2014-03-102-0/+10
| | |
* | | SI-8366 make partial function and match trees disjointDenys Shabalin2014-03-102-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously one could match a partial function with match quasiquote: scala> val q"$scrutinee match { case ..$cases }" = q"{ case Foo => Bar }" scrutinee: universe.Tree = <empty> cases: List[universe.CaseDef] = List(case Foo => Bar) This was quite annoying as it leaked encoding of partial functions as Match trees with empty tree in place of scrutinee. This commit make sure that matches and partial functions are disjoint and don't match one another (while preserving original encoding under the hood out of sight of the end user.)
* | | Merge pull request #3611 from densh/si/8385Adriaan Moors2014-03-101-0/+8
|\ \ \ | | | | | | | | SI-8385 make sure $quasiquote$tuple gets reified properly
| * | | SI-8385 make sure $quasiquote$tuple gets reified properlyDenys Shabalin2014-03-091-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | Previously due to greediness of SyntacticApplied there was a chance that quasiquote tuple placeholder got reified as its representation rather than its meaning.
* | | | Merge pull request #3594 from densh/si/8331Adriaan Moors2014-03-102-0/+24
|\ \ \ \ | | | | | | | | | | SI-8331 make sure type select & applied type doesn't match terms
| * | | | SI-8331 make sure type select & applied type doesn't match termsDenys Shabalin2014-03-092-0/+24
| |/ / / | | | | | | | | | | | | | | | | | | | | Due to tree re-use it used to be the fact that type quasiquotes could match term trees. This commit makes sure selections and applied type and type applied are all non-overlapping between q and tq.
* | | | Merge pull request #3607 from xeno-by/ticket/8367Adriaan Moors2014-03-106-16/+17
|\ \ \ \ | |_|/ / |/| | | SI-8367 revert SI-8192's change to primaryConstructor when isJavaDefined
| * | | SI-8367 revert SI-8192's change to primaryConstructor when isJavaDefinedAdriaan Moors2014-03-076-16/+17
| | | | | | | | | | | | | | | | this is some weird stuff
* | | | Merge pull request #3606 from xeno-by/ticket/8375Jason Zaugg2014-03-1017-7/+74
|\ \ \ \ | | | | | | | | | | SI-8375 saner binary incompat errors for macros
| * | | | Addresses pull request feedbackEugene Burmako2014-03-081-1/+1
| | | | |
| * | | | SI-8375 saner binary incompat errors for macrosEugene Burmako2014-03-0717-7/+74
| |/ / / | | | | | | | | | | | | | | | | | | | | Inspired by Brian McKenna's RC1 migration experience, this commit improves macro impl binding validation in order to provide more helpful diagnostic for this quite frequent class of errors.
* | | | Merge pull request #3603 from xeno-by/ticket/8364Jason Zaugg2014-03-102-0/+12
|\ \ \ \ | |_|/ / |/| | | SI-8364 fixes cxTree lookup for imports
| * | | SI-8364 fixes cxTree lookup for importsEugene Burmako2014-03-072-0/+12
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | This is reminiscent of the bug that I recently fixed in paradise: https://github.com/scalamacros/paradise/commit/0dc4e35883d357b7cbcdfd83b5b4821c1dcc0bb1. When doing something non-standard with contexts, we usually have to keep in mind that new contexts are created not only for trees that demarcate blocks of code, but also for imports.
* | | Merge pull request #3610 from xeno-by/ticket/8369Jason Zaugg2014-03-084-0/+23
|\ \ \ | | | | | | | | SI-8369 resetAttrs now correctly accounts for skolems
| * | | SI-8369 resetAttrs now correctly accounts for skolemsEugene Burmako2014-03-074-0/+23
| |/ / | | | | | | | | | | | | resetAttrs (née resetLocalAttrs) has been oblivious to existence of skolems. Not anymore, which prevents us from reverting to the untyper nightmare.
* | | SI-8372: unspliceable type printed in error messageGrzegorz Kossakowski2014-03-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The b8a76f688c6ce2a4c305da064303bb46b53be875 introduced ArrayOps.{unzip, unzip3} methods. Both of those methods have ClassTags as context bounds on their type parameters so they can create (and return) instances of Arrays. The type inference for those methods is supposed to be guided by implicit evidence that T <: (T1, T2) (or T <: (T1, T2, T3) in unzip3 case). However, context bounds are desugared into implicit parameters that prepended in front of implicit parameters declared in source code. That means the implicit evidence won't have a chance to guide type inference because it comes as last implicit parameter. This commit desugars context bounds and puts them at the end of implicit parameter list. This way type inference is guided properly and we get expected compiler errors for missing class tags. The change to parameters order breaks binary compatibility with respect to 2.11.0-RC1. I added filters to our binary compatibility configuration files. We can get rid of them as soon as 2.11.0 is out.
* | | Test case for SI-8372: issue with ArrayOps.unzipGrzegorz Kossakowski2014-03-072-0/+17
|/ / | | | | | | | | This commit merely documents current (suboptimal) error message printed for the code reported in SI-8372. The next commit will fix the problem.
* | Merge pull request #3592 from densh/si/8281Eugene Burmako2014-03-031-0/+12
|\ \ | | | | | | SI-8281 check for unbound placeholder parameters in quasiquote parser
| * | SI-8281 check for unbound placeholder parameters in quasiquote parserDenys Shabalin2014-02-281-0/+12
| | |
* | | SI-8332 implicit class param unquoting in quasiquotesDenys Shabalin2014-03-022-2/+17
| | | | | | | | | | | | | | | | | | A new api that simplifies handling of implicit parameters has been mistakingly supporting just methods parameters. This commit adds support for class parameters too.
* | | Merge pull request #3596 from densh/si/8333Eugene Burmako2014-03-011-1/+5
|\ \ \ | | | | | | | | SI-8333 can't use modifiers if class is in a block
| * | | SI-8333 can't use modifiers if class is in a blockDenys Shabalin2014-02-281-1/+5
| |/ / | | | | | | | | | | | | | | | Was caused by the ordering of parser cases. Need to check for definition first due to the fact that modifiers unquote looks like identifier from parser point of view.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-24 14:35:19 +0000