summaryrefslogtreecommitdiff
path: root/test
Commit message (Collapse)AuthorAgeFilesLines
...
* | | | | | 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.
* | | | | Merge pull request #3625 from retronym/ticket/8403Adriaan Moors2014-03-141-0/+9
|\ \ \ \ \ | |_|_|_|/ |/| | | | SI-8403 Fix regression in name binding with imports in templates
| * | | | 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`.
* / / / SI-8407 "symbol not found" in Scaladoc use cases: warning onlyJason Zaugg2014-03-132-0/+24
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The refactoring in aedec1980 mistakenly used the non-silent typer to typecheck the use cases. It temptingly had the desired type (`ScalaDocAnalyzer`), but sadly the wrong properties (it will report errors, rather than buffer.) This meant that "symbol not found" errors in use cases would prevent Scaladoc generation. This commit introduces a little downcast on the silent typer. A more principled approach would be to go through the rigmarole of the virtual class pattern for `Analzyer.Typer`, but that will have to remain work for another day.
* | | 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-113-0/+15
|\ \ \ \ | | | | | | | | | | SI-8363 Disable -Ydelambdafy:method in constructor position
| * | | | SI-8363 Disable -Ydelambdafy:method in constructor positionJason Zaugg2014-03-103-0/+15
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #3593 from densh/si/8285Eugene Burmako2014-03-012-1/+18
|\ \ \ | | | | | | | | SI-8285 use correct kind of map for quasiquote positions
| * | | SI-8285 use correct kind of map for quasiquote positionsDenys Shabalin2014-02-282-1/+18
| |/ / | | | | | | | | | | | | | | | | | | Previously mutable.ListMap was used with assumption that it preserved order of inserted elements (but it doesn't). Surprisingly logic that assumed ordered elements worked mosly fine on unordered ones. I guess two bugs can cancel each other out.
* | | Merge pull request #3591 from densh/si/8275Eugene Burmako2014-03-012-6/+37
|\ \ \ | |_|/ |/| | SI-8275 allow to directly extract block contents of the case def
| * | Fix block construction/deconstruction asymmetryDenys Shabalin2014-02-282-6/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Deconstruction of blocks in case clauses uncovered asymmetry between construction and deconstruction of blocks: tree match { case cq"$pat => ..$cases" => cq"$pat => ..$cases" } Such an identity-like transformation used to produce an incorrect tree due to the fact that zero-element block was mistakingly associated with empty tree. Such association was used as a solution to block flatenning: val ab = q"a; b" q"..$ab; c" // ==> q"a; b; c" val a = q"a" q"..$a; c" // ==> q"a; c" val empty = q"" q"..$empty; c" // ==> q"c" This commit changes meaning of zero-element block to a be a synthetic unit instead. This is consistent with parsing of `{}`, cases, ifs and non-abstract empty-bodied methods. A local tweak to block flattenning is used to flatten empty tree as empty list instead.
| * | SI-8275 allow to directly extract block contents of the case defDenys Shabalin2014-02-281-0/+11
| |/ | | | | | | | | Due to the fact that blocks in cases are implicit one might expect to be able to extract its contents with `..$`.
* / test case that verifies SI-8352Eugene Burmako2014-02-273-0/+12
|/
* SI-4728 test caseLukas Rytz2014-02-263-2/+7
|
* Merge pull request #3583 from adriaanm/t8197Adriaan Moors2014-02-251-2/+5
|\ | | | | SI-8197 clarify overloading resolution with default args
| * SI-8197 clarify overloading resolution with default argsAdriaan Moors2014-02-251-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit was co-authored with Lukas. His analysis is below. If there are multiple applicable alternatives, drop those that use default arguments. This is done indirectly by checking applicability based on arity. TODO: this `namesMatch` business is not spec'ed, and is the wrong fix for SI-4592. We should instead clarify what the spec means by "typing each argument with an undefined expected type". What does typing a named argument entail when we don't know what the valid parameter names are? (Since we're doing overload resolution, there are multiple alternatives that can define different names.) Luckily, the next step checks applicability to the individual alternatives, so it knows whether an assignment is: - a valid named argument - a well-typed assignment (which doesn't necessarily have type `Unit`!) - an error (e.g., rhs does not refer to a variable) I propose the following solution (as a TODO): check whether a named argument (when typing it in `doTypedApply`) could be interpreted as an assign; `infer.checkNames` should use the type of the well-typed assignment instead of `Unit`. Lukas's analysis: 990fa04 misunderstood the spec of overloading resolution with defaults. it should not discard applicable alternatives that define defaults, but only those that use defaults in the given invocation. bugs were shadowed because the refactoring used `alt.hasDefault` to check whether the alternative has some parameters with defaults, but this never worked. d5bb19f fixed that part by checking the flags of parameters, which fixed some but but un-shadowed others: ``` object t { def f(x: String = "") = 1; def f(x: Object) = 2 } scala> t.f("") // should return 1, but returns 2 after d5bb19f ``` The commit message of d5bb19f also mentions that its test "should fail to compile according to SI-4728", which is another misunderstanding. ``` class A; class B extends A object t { def f(x: A = null) = 1; def f(x: B*) = 2 } t.f() ``` This should return `2`: both alternatives are applicable, so the one that uses a default is eliminated, and we're left with the vararg one. SI-4728 is different in that it uses explicit parameters, `t.f(new B)` is ambiguous.
* | Merge pull request #3581 from Ichoran/issue/3235-minimalAdriaan Moors2014-02-253-0/+21
|\ \ | | | | | | SI-3235 math.round() returns wrong results for Int and Long
| * | SI-3235 math.round() returns wrong results for Int and LongRex Kerr2014-02-253-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | Minimal fix for SI-3235. This minimal fix includes deprecation messages to aid detection of probable errors. Test verifies behavior: the correct values are returned, and deprecation messages are emitted.
* | | Merge pull request #3498 from Ichoran/issue/8240Grzegorz Kossakowski2014-02-252-0/+22
|\ \ \ | | | | | | | | SI-8240 Consider rolling back optimizations for List
| * | | SI-8240 Consider rolling back optimizations for ListRex Kerr2014-02-252-0/+22
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some compiler-specific optimizations turn out to be very helpful for Lists in general. * List map can be a lot faster (up to 5x!) * List collect can be considerably faster (up to 3x) * List flatMap can be a bit faster (2x) * List take can be slightly faster (1.1x) and have better structural sharing These appear to be unqualified wins (tested), even in a scenario with mixed collections. This is expected: detecting the builder is faster than the otherwise mandatory object creation, and multiple dispatch is mostly a wash since it was already multiple dispatch in getting to the builder. With -optimize, map is not always such a big win, but is never slower. Also added @noinline to map to work around an optimizer bug (SI-8334) and added a test to check that the pattern that triggers the optimizer bug does not affect any of the map-like methods.
* | | Merge pull request #3582 from adriaanm/t8251Grzegorz Kossakowski2014-02-251-1/+1
|\ \ \ | |/ / |/| | SI-8251 deprecate `ListBuffer::readOnly`
| * | SI-8251 deprecate `ListBuffer::readOnly`Pavel Pavlov2014-02-241-1/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the first step towards fixing the unexpected behavior of `ListBuffer`. Many of `ListBuffer`'s operations are forwarded to the underlying `List`, essentially leaking that abstraction to clients that call e.g., `toIterable`. When the buffer changes, the `Iterable` obtained through `toIterable` will reflect that change. To avoid this exposure, call `toList` to obtain an immutable copy. See also: https://groups.google.com/d/msg/scala-internals/g_-gIWgB8Os/kWazrALbLKEJ https://gist.github.com/paulp/9081797
* | Merge pull request #3566 from adriaanm/t6455Grzegorz Kossakowski2014-02-255-1/+47
|\ \ | |/ |/| SI-6455 no longer rewrite .withFilter to .filter
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-02 13:03:57 +0000