summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* SI-8388 consistently match type trees by originalsDenys Shabalin2014-03-254-50/+174
| | | | | | | | | | | | 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 #3647 from densh/si/8411Jason Zaugg2014-03-252-4/+20
|\ | | | | SI-8411 match desugared partial functions
| * SI-8411 match desugared partial functionsDenys Shabalin2014-03-222-4/+20
| |
* | introduces Mirror.typeOfEugene Burmako2014-03-252-0/+20
| | | | | | | | | | | | | | | | | | 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-251-0/+1
|\ \ | | | | | | SI-8200 provide an identity liftable for trees
| * | SI-8200 provide an identity liftable for treesDenys Shabalin2014-03-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+4
|\ \ \ | | | | | | | | 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-2/+4
| | |/ | |/| | | | | | | | | | | | | 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 Refactor ConcatIteratorJason Zaugg2014-03-241-5/+5
| | | | | | | | | | | | | | | Make the head iterator a constructor parameter, for easier construction and implementation of ++.
* | | SI-8428 Fix regression in iterator concatenationJason Zaugg2014-03-201-1/+1
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Refine handoff of undet. params from implicit searchJason Zaugg2014-03-181-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-171-1/+2
|\ \ | |/ |/| SI-8425 don't create double-dollar names in c.freshName
| * SI-8425 don't create double-dollar names in c.freshNameEugene Burmako2014-03-181-1/+2
| | | | | | | | | | | | 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-164-7/+32
|\ \ | |/ |/| SI-4492 More informative error when class not found on classpath
| * SI-4492 More informative error when class not found on classpathAdriaan Moors2014-03-144-7/+32
| | | | | | | | | | | | | | | | | | | | | | | | 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 #3630 from adriaanm/t8368Adriaan Moors2014-03-142-2/+3
|\ \ | | | | | | SI-8368 respect user-supplied scala.usejavacp
| * | SI-8368 respect user-supplied scala.usejavacpAdriaan Moors2014-03-142-2/+3
| |/ | | | | | | Now also works when the option is -Dscala.usejavacp=false...
* | Merge pull request #3617 from VladimirNik/typedTreesPrinter-2.11.0-SI-8386Adriaan Moors2014-03-141-2/+3
|\ \ | | | | | | SI-8386 showCode fails to pretty print application to assign
| * | SI-8386 fixedVladimirNik2014-03-111-2/+3
| | |
* | | Merge pull request #3598 from som-snytt/issue/8266-amend-adviceAdriaan Moors2014-03-141-1/+2
|\ \ \ | | | | | | | | SI-8266 Amend advice for deprecated octal 042
| * | | SI-8266 Amend advice for deprecated octal 042Som Snytt2014-02-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #3624 from puffnfresh/patch-1Adriaan Moors2014-03-141-1/+0
|\ \ \ \ | | | | | | | | | | Remove "will not terminate" from toStream doc
| * | | | Remove "will not terminate" from toStream docBrian McKenna2014-03-121-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's at least not always true: scala> val example = Iterator.continually(1).toStream example: scala.collection.immutable.Stream[Int] = Stream(1, ?)
* | | | | Merge pull request #3629 from xeno-by/topic/setter-conflictAdriaan Moors2014-03-141-0/+4
|\ \ \ \ \ | | | | | | | | | | | | SI-8086 follow-up that fixes the problem with `setter`
| * | | | | SI-8086 follow-up that fixes the problem with `setter`Eugene Burmako2014-03-131-0/+4
| |/ / / / | | | | | | | | | | | | | | | | | | | | This is a super-low risk follow-up for 47dba05 that fixes the same problem with a neighboring method.
* | | | | Merge pull request #3623 from paulp/pr/source-210Adriaan Moors2014-03-143-3/+12
|\ \ \ \ \ | |_|_|_|/ |/| | | | 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-3/+12
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+4
|\ \ \ \ | | | | | | | | | | 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-2/+4
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-131-1/+1
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-4/+4
|\ \ \ | | | | | | | | SI-8395 Regression in pattern matching with nested binds
| * | | SI-8395 Regression in pattern matching with nested bindsJason Zaugg2014-03-121-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-122-2/+3
|\ \ \ \ | |/ / / |/| | | SI-8376 Fix overload resolution with Java varargs
| * | | SI-8376 Better type printing for Java varargsJason Zaugg2014-03-101-1/+1
| | | | | | | | | | | | | | | | | | | | `T*` rather than `<repeated>[T]`, as we alreday do for Scala repeated parameters.
| * | | SI-8376 Fix overload resolution with Java varargsJason Zaugg2014-03-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #3619 from huitseeker/issue/SI-8392Adriaan Moors2014-03-111-1/+3
|\ \ \ \ | | | | | | | | | | SI-8392 Guards QuasiquoteClass against non-availability in scala-reflect
| * | | | SI-8392 Guards QuasiquoteClass against non-availability in scala-reflectFrançois Garillot2014-03-111-1/+3
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This assimilates behavior on Quasiquotes to the one on Reflection : if we don't have the right resource on classpath, we do without rather than throwing. See the bug report for more on rationale (-Xsource flag, early quasiquote loading in Analyzer through FastTrack, etc). Review by @gkossakowski or @xeno-by
* | | | Merge pull request #3616 from retronym/ticket/8363Adriaan Moors2014-03-111-1/+3
|\ \ \ \ | | | | | | | | | | SI-8363 Disable -Ydelambdafy:method in constructor position
| * | | | SI-8363 Disable -Ydelambdafy:method in constructor positionJason Zaugg2014-03-101-1/+3
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | | Merge pull request #3604 from densh/si/8366Adriaan Moors2014-03-114-5/+29
|\ \ \ \ | | | | | | | | | | SI-8366 make partial function and match trees disjoint
| * | | | SI-8366 make partial function and match trees disjointDenys Shabalin2014-03-104-5/+29
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #3621 from szeiger/tmp/si8368Adriaan Moors2014-03-111-1/+8
|\ \ \ \ | | | | | | | | | | SI-8368 respect user-supplied -Dscala.usejavacp in Windows runner
| * | | | SI-8368 respect user-supplied -Dscala.usejavacp in Windows runnerStefan Zeiger2014-03-111-1/+8
| |/ / /
* / / / Fixes syntax error in unix runner.François Garillot2014-03-111-1/+1
|/ / /
* | | Merge pull request #3611 from densh/si/8385Adriaan Moors2014-03-102-1/+5
|\ \ \ | | | | | | | | SI-8385 make sure $quasiquote$tuple gets reified properly
| * | | Move extra tuple placeholder case to reifyTreePlaceholderDenys Shabalin2014-03-101-4/+4
| | | |
| * | | Update quasiquote debug output minimization passDenys Shabalin2014-03-091-1/+1
| | | |
| * | | SI-8385 make sure $quasiquote$tuple gets reified properlyDenys Shabalin2014-03-091-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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 #3609 from xeno-by/ticket/8370Adriaan Moors2014-03-101-1/+1
|\ \ \ \ | | | | | | | | | | SI-8370 fixes an infinite loop in repl init
| * | | | SI-8370 fixes an infinite loop in repl initEugene Burmako2014-03-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under a weird coincidence of circumstances provided by `sbt console-quick`, new XML parsing logic in compiler plugin initialization could lead to stack overflow errors. Here's the abridged sequence events that led to this unfortunate problem (full description can be found on the JIRA issue page): 1) Initialization of the compiler underlying the REPL would kick off plugin initialization. 2) PluginDescription.fromXML would call into DocumentBuilderFactory, i.e. DocumentBuilderFactory.newInstance.newDocumentBuilder.parse(xml). 3) That thing would call into javax.xml.parsers.SecuritySupport.getResourceAsStream, requesting META-INF/services/javax.xml.parsers.DocumentBuilderFactory. 4) That request would get serviced by TranslatingClassLoader provided by the REPL to expose dynamically compiled code. 5) TranslatingClassLoader would call translatePath that would call into IMain.symbolOfIdent trying to map the requested resource onto one of the classes defined by the REPL (which don't exist yet, because REPL hasn't yet finished initializing). 6) IMain.symbolOfIdent would request IMain.global, which is exactly the instance of the compiler that underlies the REPL, and that's currently being initialized. 7..inf) Repeat until a StackOverflowError.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-25 03:56:29 +0000