summaryrefslogtreecommitdiff
path: root/test/files/scalacheck
Commit message (Collapse)AuthorAgeFilesLines
* 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 #3647 from densh/si/8411Jason Zaugg2014-03-251-0/+5
|\ | | | | SI-8411 match desugared partial functions
| * SI-8411 match desugared partial functionsDenys Shabalin2014-03-221-0/+5
| |
* | 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.
* / 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.
* 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.
* | 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 #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.
* | 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 `..$`.
* Merge pull request #3566 from adriaanm/t6455Grzegorz Kossakowski2014-02-251-1/+1
|\ | | | | SI-6455 no longer rewrite .withFilter to .filter
| * SI-6455 under -Xfuture, don't rewrite .withFilter to .filterAdriaan Moors2014-02-241-1/+1
| | | | | | | | | | This has been deprecated for two major releases now, but `filter`'s still preferred over `withFilter` in the wild.
* | Merge pull request #3546 from VladimirNik/typedTreesPrinter-2.11.0Jason Zaugg2014-02-211-1/+71
|\ \ | | | | | | CodePrinter added to Printers 2.11.0
| * | block wrapping for trees modifiedVladimirNik2014-02-201-0/+43
| | |
| * | block processing fixed for syntactics in typechecked treesVladimirNik2014-02-201-2/+2
| | |
| * | Attributed val/var processing for syntactics (SI-8180)VladimirNik2014-02-201-1/+28
| |/ | | | | | | | | | | TypedTreesPrinter added changes based on pull request comments: print root packages flag; tests for syntactics; SyntacticEmptyTypeTree added to Printers
* / Fix quasiquote terminology to be consistent with SchemeDenys Shabalin2014-02-208-129/+129
|/ | | | | | | | | | | | | | | 1. Rename cardinality into rank. Shorter word, easier to understand, more appropriate in our context. 2. Previously we called any dollar substitution splicing but this is not consistent with Scheme where splicing is substitution with non-zero rank. So now $foo is unquoting and ..$foo and ...$foo is unquote splicing or just splicing. Correspondingly splicee becomes unquotee. 3. Rename si7980 test into t7980
* Merge remote-tracking branch 'origin/master' into topic/palladium0Eugene Burmako2014-02-168-19/+78
|\ | | | | | | | | | | | | | | Conflicts: src/compiler/scala/reflect/macros/compiler/Resolvers.scala src/compiler/scala/reflect/macros/contexts/Typers.scala src/compiler/scala/tools/reflect/ToolBoxFactory.scala src/reflect/scala/reflect/api/BuildUtils.scala
| * Merge pull request #3499 from densh/topic/single-element-tupleEugene Burmako2014-02-166-3/+20
| |\ | | | | | | Make handling of tuples more consistent in quasi-quotes
| | * Make handling of tuples more consistent in quasi-quotesDenys Shabalin2014-02-106-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On one hand we know that q"($expr)" is the same as q"$expr". On the other if we wrap it into a list and splice as q"(..$expr)" we get a Tuple1 constructor call which is inconsistent. This pull request fixes this inconsistency by making q"(..$expr)" being equivalent q"(${expr.head})" for single-element list. We also add support for matching of expressions as single-element tuples (similarly to blocks) and remove liftables and unliftables for Tuple1 (which aren't clearly defined any longer due to q"(foo)" == q"foo" invariant).
| * | Merge pull request #3455 from densh/topic/patdefEugene Burmako2014-02-162-16/+58
| |\ \ | | | | | | | | Fix SI-8202 and improve support for splicing patterns into vals
| | * | Improve support for patterns in valsDenys Shabalin2014-02-092-16/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commits adds construction-only support for splicing patterns into vals (a.k.a. PatDef). Due to non-locality of the desugaring it would have been quite expensive to support deconstruction as the only way to do it with current trees is to perform implodePatDefs transformation on every single tree.
| | * | SI-8202 bug compatibility with SI-8211 for quasiquotesDenys Shabalin2014-02-091-0/+4
| | |/
* | | renames some methods in ReificationSupportEugene Burmako2014-02-152-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | As per Denys's request, renames methods in ReificationSupport that are eponymous to methods in Universe, so that we don't get nasty name intersections. This change is not source/binary-compatible, because we don't make any promises about the contents of the build API. Feedback welcome.
* | | some renamingsEugene Burmako2014-02-154-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It’s almost 1am, so I’m only scratching the surface, mechanistically applying the renames that I’ve written down in my notebook: * typeSignature => info * declarations => decls * nme/tpnme => termNames/typeNames * paramss => paramLists * allOverriddenSymbols => overrides Some explanation is in order so that I don’t get crucified :) 1) No information loss happens when abbreviating `typeSignature` and `declarations`. We already have contractions in a number of our public APIs (e.g. `typeParams`), and I think it’s fine to shorten words as long as people can understand the shortened versions without a background in scalac. 2) I agree with Simon that `nme` and `tpnme` are cryptic. I think it would be thoughtful of us to provide newcomers with better names. To offset the increase in mouthfulness, I’ve moved `MethodSymbol.isConstructor` to `Symbol.isConstructor`, which covers the most popular use case for nme’s. 3) I also agree that putting `paramss` is a lot to ask of our users. The double-“s” convention is very neat, but let’s admit that it’s just weird for the newcomers. I think `paramLists` is a good compromise here. 4) `allOverriddenSymbols` is my personal complaint. I think it’s a mouthful and a shorter name would be a much better fit for the public API.
* | | establishes scala.reflect.api#internalEugene Burmako2014-02-147-10/+10
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reflection API exhibits a tension inherent to experimental things: on the one hand we want it to grow into a beautiful and robust API, but on the other hand we have to deal with immaturity of underlying mechanisms by providing not very pretty solutions to enable important use cases. In Scala 2.10, which was our first stab at reflection API, we didn't have a systematic approach to dealing with this tension, sometimes exposing too much of internals (e.g. Symbol.deSkolemize) and sometimes exposing too little (e.g. there's still no facility to change owners, to do typing transformations, etc). This resulted in certain confusion with some internal APIs living among public ones, scaring the newcomers, and some internal APIs only available via casting, which requires intimate knowledge of the compiler and breaks compatibility guarantees. This led to creation of the `internal` API module for the reflection API, which provides advanced APIs necessary for macros that push boundaries of the state of the art, clearly demarcating them from the more or less straightforward rest and providing compatibility guarantees on par with the rest of the reflection API. This commit does break source compatibility with reflection API in 2.10, but the next commit is going to introduce a strategy of dealing with that.
* | Merge pull request #3437 from Ichoran/issue/6736Adriaan Moors2014-02-121-1/+2
|\ \ | | | | | | SI-6736 Range.contains is wrong
| * | Reasonable Range operations consistently work when overfull.Rex Kerr2014-02-091-1/+2
| |/ | | | | | | | | | | Operations are reasonable when they don't require indexing or conversion into a collection. These include head, tail, init, last, drop, take, dropWhile, takeWhile, dropRight, takeRight, span. Tests added also to verify the new behavior.
* / Tweak parser entry point for pqDenys Shabalin2014-02-112-1/+10
|/ | | | | | Previously pq used pattern1 which required parens to be used in alternative pattern. This commit tweaks it to allow pq"a | b" syntax. Also adds some tests for alternative syntax.
* Add support for a more straightforward alternative to import selectorsDenys Shabalin2014-02-073-14/+82
|
* Represent tq"" as SyntacticEmptyTypeTree rather than TypeTree()Denys Shabalin2014-02-073-2/+15
| | | | | | | | | | | | Such representation codifies the fact that type tree that doesn't have embedded syntactic equivalent must have been inferred or otherwise provided by the compiler rather than specified by the end user. Additionally it also ensures that we can still match trees without explicit types (e.g. vals without type) after typechecking. Otherwise the same quote couldn't be used in situations like: val q"val x = 42" = typecheck(q"val x = 42")
* Merge pull request #3475 from densh/topic/holemap-orderingEugene Burmako2014-02-061-0/+5
|\ | | | | Fix inconsistent binding in patterns with 10+ holes
| * Fix inconsistent binding in patterns with 10+ holesDenys Shabalin2014-02-061-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously a map that was storing bindings of fresh hole variables with their contents (tree & cardinality) used to be a SortedMap which had issues with inconsistent key ordering: "$fresh$prefix$1" < "$fresh$prefix$2" ... "$fresh$prefix$8" < "$fresh$prefix$9" "$fresh$prefix$9" > "$fresh$prefix$10" This issue is solved by using a LinkedHashMap instead (keys are inserted in the proper order.)
* | SI-8173 add support for patterns like init :+ last to quasiquotesDenys Shabalin2014-02-027-47/+111
|/ | | | | | | | | | | | Adds support for patterns like: val q"{ ..$init; $last }" = q"{ a; b; c }" // init == List(q"a", q"b") // last == q"c" Which under the hood get compiled as `:+` patterns: SyntacticBlock(init :+ last)
* Merge pull request #3374 from densh/si/6844-8076Jason Zaugg2014-01-292-2/+44
|\ | | | | SI-6844 SI-8076 improve handling of function parameters in quasiquotes
| * SI-8076 improve support for implicit argument listDenys Shabalin2014-01-162-2/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for construction and deconstruction of implicit argument list which was originally suggested by @cvogt. 1. Splicing vale into implicit argument list automatically adds implicit flag to them: val x = q"val x: Int" q"def foo(implicit $x)" // <=> q"def foo(implicit x: Int)" 2. One might extract implicit argument list separately from other argument lists: val q”def foo(...$argss)(implicit ..$impl)" = q"def foo(implicit x: Int) // argss is Nil, impl contains valdef for x But this doesn't require you to always extract it separatly: val q”def foo(...$argss)" = q"def foo(implicit x: Int) // argss contains valdef for x
* | Merge pull request #3402 from densh/si/7275Eugene Burmako2014-01-292-16/+64
|\ \ | | | | | | SI-7275 allow flattening of blocks with ..$
| * | Addresses feedback from JasonDenys Shabalin2014-01-271-1/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Adds tests for new synthetic unit stripping. 2. Marks implementation-specific parts of Holes as private. 3. Trims description of iterated method a bit. 4. Provides a bit more clear wrapper for q interpolator. 5. Refactors SyntacticBlock, adds documentation. 6. Makes q"{ ..$Nil }" return q"" to be consist with extractor.
| * | SI-7275 allow flattening of blocks with ..$Denys Shabalin2014-01-232-15/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit extends current splicing rules to allow flattening of trees into other trees. Without such support it is impossible to correctly create vals with patterns and use it in other location as they could expand into multiple-statement blocks: scala> q"val (a, b) = (1, 2)" res0: reflect.runtime.universe.Tree = { <synthetic> <artifact> private[this] val x$1 = scala.Tuple2(1, 2): @scala.unchecked match { case scala.Tuple2((a @ _), (b @ _)) => scala.Tuple2(a, b) }; val a = x$1._1; val b = x$1._2; () } scala> q"..$res0; println(a + b)" res1: reflect.runtime.universe.Tree = { <synthetic> <artifact> private[this] val x$1 = scala.Tuple2(1, 2): @scala.unchecked match { case scala.Tuple2((a @ _), (b @ _)) => scala.Tuple2(a, b) }; val a = x$1._1; val b = x$1._2; println(a.$plus(b)) }
* | | SI-8171 make tq"" an alias for empty type treeDenys Shabalin2014-01-241-1/+7
|/ /
* | Merge pull request #3373 from densh/topic/std-liftable-refinementAdriaan Moors2014-01-171-1/+49
|\ \ | | | | | | A few minor changes to standard liftable instances and liftable support
| * | Test edge cases of literal liftingDen Shabalin2014-01-161-0/+11
| | | | | | | | | | | | | | | | | | | | | Previously in some corner situation proper Liftable instance might not have been resolved. In particular q"${true}" and q"${""}" used to fail.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-10 09:58:04 +0000