summaryrefslogtreecommitdiff
path: root/test/files
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #3686 from densh/topic/re-enabled-typechecked-typesJason Zaugg2014-05-021-5/+4
|\ | | | | Re-enable typechecked types part of quasiquote test suite
| * Re-enable typechecked types part of quasiquote test suiteDenys Shabalin2014-04-201-5/+4
| | | | | | | | It was accidentally disabled.
* | Merge pull request #3635 from retronym/ticket/8329Jason Zaugg2014-04-211-0/+29
|\ \ | | | | | | SI-8329 Better hygiene for patmat partial functions
| * | SI-8329 Better hygiene for patmat partial functionsJason Zaugg2014-03-151-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't enter synthetic parameters of `applyOrElse` et al into scope when typechecking the user-code; instead reference those symbolically. There is an exception to this principle. Currently we allow: val x: PartialFunction[A, B] = x => x match { ... } For this pattern of code, we use the given name `x` for the corresponding method parameter of `applyOrElse` and `isDefinedAt` and we actually need this to be in scope when we typecheck the scrutinee. This construct is tested in `run/virtpatmat_partial.scala`. A new parameter, `paramSynthetic`, differentiates this case from the more typical `val x: PF[A, B] = { case ... => ... ; ... } case, which uses a fresh name need not be in scope. (We could get away with it, as it is fresh, but I thought it better to exclude it.)
* | | Merge pull request #3670 from retronym/ticket/8463Jason Zaugg2014-04-212-0/+48
|\ \ \ | | | | | | | | SI-8463 Avoid unpositioned errors from search for views
| * | | SI-8463 Avoid unpositioned errors from search for viewsJason Zaugg2014-04-022-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ideally, I'd like to fix this using `saveErrors = false` here to firewall the enclosing context from the ambiguiouty error encountered during implicit search. I originally proposed that patch as a fix for SI-8419 in https://github.com/scala/scala/pull/3460 but withdrew from that approach as I uncovered a deeper bug that meant that we actually shouldn't have even been looking for views in that case. But, this runs into SI-8230 and these failures: test/partest --update-check \ /Users/jason/code/scala/test/files/pos/t2504.scala \ /Users/jason/code/scala/test/files/pos/t4457_1.scala \ /Users/jason/code/scala/test/files/neg/t4457_2.scala Turns out that typechecking the ostensible straight forward application, `Array("abc")`, hinges on us leaking an ambiguity error from `viewExists` to find a path through overload resolution! This commit takes a tiny step forward by using `context.tree` rather than `EmptyTree` as the argument to `inferImplicit`. This avoids unpositioned type errors.
* | | | Merge pull request #3682 from retronym/ticket/8497Jason Zaugg2014-04-212-0/+14
|\ \ \ \ | | | | | | | | | | SI-8497 Fix regression in pickling of AnnotatedTypes
| * | | | SI-8497 Fix regression in pickling of AnnotatedTypesJason Zaugg2014-04-142-0/+14
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes an inconsistency introduced in these two spots: https://github.com/scala/scala/pull/3033/files#diff-6ce1a17ebee31068f41c36a8a2b3bc9aR79 https://github.com/scala/scala/pull/3033/files#diff-c455cb229f5227b1bcaa1544478fe3acR452 The bug shows up when pickling then unpickling an AnnotatedType that has only non-static annotations.
* | | | Merge pull request #3645 from retronym/ticket/8430Jason Zaugg2014-04-213-0/+60
|\ \ \ \ | | | | | | | | | | SI-8430 Less non-determinism in patmat exhautiveness warnings
| * | | | SI-8430 Less non-determinism in patmat exhautiveness warningsJason Zaugg2014-03-243-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Another mole whacked on the head by using `LinkedHashMap`. Caution: `LinkedHashMap` doesn't preserve its runtime type if you map through the generic interface. I've noted this gotcha as SI-8434. I've structured this patch to enforce that concrete collection with types, which is a good idea anyway. My method to track this down was to place breakpoints in `Hash{Map,Set}`.{foreach,iterator}` to see where that was used from within pattern match translation. This approach was drastically faster than my previous rounds of whack-a-mole. The counter-examples are still a bit off; I'm going to merge that aspect of this ticket with SI-7746, in which we've pinpointed the culpable part of the implementation, but haven't had success in fixing the bug.
* | | | | Merge pull request #3634 from retronym/ticket/7992Jason Zaugg2014-04-212-0/+38
|\ \ \ \ \ | | | | | | | | | | | | SI-7992 Fix super-accessor generation after a local class
| * | | | | SI-7992 Fix super-accessor generation after a local classJason Zaugg2014-03-152-0/+38
| | |_|_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The transformer in the superaccessors phase uses the var `validCurrentOwner` to track whether we're in a part of the code that won't end up in the host method, and as such, will need to access super-method via a super-accessor. But, this bit of bookkeeping was not correctly reset after traversing out of a local class. A `VerifyError` ensued. This commit changes `atOwner` to save and restore that flag, rather than leaving it set to `true`. I've also added a test variation using a by-name argument.
* | | | | Merge pull request #3658 from adriaanm/t8450Jason Zaugg2014-04-213-0/+19
|\ \ \ \ \ | |_|_|/ / |/| | | | SI-8450 no "implicit numeric widening" in silent mode
| * | | | SI-8450 no "implicit numeric widening" in silent modeAdriaan Moors2014-03-263-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this fix, we get a second, spurious warning. ``` t8450.scala:5: warning: implicit numeric widening def elapsed: Foo = (System.nanoTime - 100L).foo ^ t8450.scala:11: warning: implicit numeric widening def elapsed: Foo = (System.nanoTime - 100L).foo ^ error: No warnings can be incurred under -Xfatal-warnings. two warnings found one error found ``` By respecting silent contexts, we now get only one. I sneakily fixed similar occurrences without adding a test.
* | | | | Merge pull request #3671 from densh/si/8466Jason Zaugg2014-04-022-0/+15
|\ \ \ \ \ | | | | | | | | | | | | SI-8466 fix quasiquote crash on recursively iterable unlifting
| * | | | | SI-8466 fix quasiquote crash on recursively iterable unliftingDenys Shabalin2014-04-022-0/+15
| | |_|_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to handle unquoting quasiquotes needs to know if type is iterable and whats the depth of the iterable nesting which is called rank. (e.g. List[List[Tree]] is rank 2 iterable of Tree) The logic that checks depth of iterable nesting didn't take a situation where T is in fact Iterable[T] which caused infinite recursion in stripIterable function. In order to fix it stripIterable now always recurs no more than non-optional limit times.
* / | | | SI-8460 Fix regression in divergent implicit recoveryJason Zaugg2014-03-312-1/+30
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implicit search detects likely cycles by looking at the stack of open implicits and checking the same implicit appears twice, and if the second occurrence is trying satisfy an implicit search for a "dominant" type. Originally, this condition immediately failed the entire implicit search. However, since Scala 2.10, this mechanism has been refined to continue searching after the first divergent implicit is detected. If a second divergence is found, we fail immediately. If the followup search fails, we report the first divergence. Otherwise, we take the successful result. This mechanism was originally built around exceptions. This proved to be fragile, and was refactored in SI-7291 / accaa314 to instead use the `Context.errors` to control the process. But, since that change, the pattern of implicits in scalanlp/breeze and Shapeless have been prone to reporting the divergent implicit errors where they used to recover. So long as we left the `DivergentImplictTypeError` that originates from a nested implicit search in `context.errors`, we are unable to successfully typecheck other candidates. This commit instead stashes the first such error away in `DivergentImplicitRecovery`, to clear the way for the alternative path to succeed. We must retain any other divergent implicit errors, as witnessed by test/files/neg/t2031.scala, which loops unless we retain divergent implicit errors that we don't stash in `DivergentImplicitRecovery`.
* | | | Merge pull request #3657 from xeno-by/ticket/8388Jason Zaugg2014-03-281-20/+76
|\ \ \ \ | | | | | | | | | | SI-8388 consistently match type trees by originals
| * | | | SI-8388 consistently match type trees by originalsDenys Shabalin2014-03-251-20/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to the fact that all TypTrees are transformed into TypeTrees during typechecking one couldn't treat typed type trees in the same way as they treat untyped type trees. This change implements support for pattern matching of TypeTrees as their corresponding TypTree equivalent using tree preserved in the original. The implementation itself is a trivial wrapping of regular TypTree extractors into MaybeTypeTreeOriginal.
* | | | | Merge pull request #3656 from densh/si/8387-8350Jason Zaugg2014-03-271-0/+24
|\ \ \ \ \ | | | | | | | | | | | | SI-8350 SI-8387 tweak handling of new trees
| * | | | | SI-8387 don't match new as a function applicationDenys Shabalin2014-03-251-0/+7
| | | | | |
| * | | | | SI-8350 treat single parens equivalently to no-parens in newDenys Shabalin2014-03-251-0/+17
| | |_|_|/ | |/| | | | | | | | | | | | | | | | | | q"new C" and q"new C()" have identical trees after parsing. This commit adds knowledge of this invariant to SyntacticNew.
* | | | | Merge pull request #3659 from xeno-by/topic/uncurry-ctorsJason Zaugg2014-03-273-0/+28
|\ \ \ \ \ | |_|_|/ / |/| | | | SI-8451 makes uncurry more forgiving
| * | | | SI-8451 quasiquotes now handle quirks of secondary constructorsEugene Burmako2014-03-273-0/+28
| | |/ / | |/| | | | | | | | | | | | | | | | | | Apparently even though the rhs of a secondary constructor looks like an expr, it always gets wrapped in a block by the parser. This works just fine with the typer, but crashes in uncurry. This commit brings quasiquotes in line with the parser.
* | | | Merge pull request #3651 from xeno-by/ticket/8437Eugene Burmako2014-03-253-0/+24
|\ \ \ \ | |/ / / |/| | | SI-8437 macro runtime now also picks inherited macro implementations
| * | | SI-8437 macro runtime now also picks inherited macro implementationsEugene Burmako2014-03-253-0/+24
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously it didn't matter much that we used Class.getDeclaredMethods instead of just getMethods, but with the introduction of macro bundles it can make a difference which is fixed in this commit. I'd also like to note that the fact that getMethods only returns public methods and getDeclaredMethods also sees private methods, doesn't make a difference, because macro implementations must be public.
* | | 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-09 00:54:12 +0000