summaryrefslogtreecommitdiff
path: root/test/files/scalacheck/quasiquotes/DefinitionDeconstructionProps.scala
Commit message (Collapse)AuthorAgeFilesLines
* run ScalaCheck tests directly, not through partestSeth Tisue2017-01-271-290/+0
| | | | | | | | | | | ScalaCheck ever being under partest in the first place is ancient history, from back in the Ant build days (shudder) ScalaCheck support was removed from partest 1.1.0, which we already upgraded to in a recent commit also upgrades ScalaCheck from 1.11.6 to 1.13.4, since we might as well. no source changes were necessary.
* SI-8451 quasiquotes now handle quirks of secondary constructorsEugene Burmako2014-03-271-0/+6
| | | | | | 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.
* SI-8332 implicit class param unquoting in quasiquotesDenys Shabalin2014-03-021-2/+12
| | | | | | A new api that simplifies handling of implicit parameters has been mistakingly supporting just methods parameters. This commit adds support for class parameters too.
* Fix quasiquote terminology to be consistent with SchemeDenys Shabalin2014-02-201-1/+1
| | | | | | | | | | | | | | | 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
* some renamingsEugene Burmako2014-02-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Add support for a more straightforward alternative to import selectorsDenys Shabalin2014-02-071-0/+53
|
* SI-8173 add support for patterns like init :+ last to quasiquotesDenys Shabalin2014-02-021-6/+16
| | | | | | | | | | | | 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)
* SI-8076 improve support for implicit argument listDenys Shabalin2014-01-161-1/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* SI-7979 Fix quasiquotes crash on mismatch between fields and constructorDen Shabalin2013-12-101-0/+16
|
* simplify imports in quasiquotes scalacheck testsDen Shabalin2013-11-121-7/+2
|
* SI-6841 SI-6657 add support for packages into quasiquotes and toolboxDen Shabalin2013-10-141-0/+24
| | | | | | In order to implement this a new parser entry point `parseStatsOrPackages` that augments current parseStats with ability to parse "package name { ... }" syntax.
* better support for ValDefs, VarDefs and DefDefsDen Shabalin2013-09-051-0/+9
|
* first-class early def splicing and extraction supportDen Shabalin2013-09-051-2/+43
|
* refactor definition tests into separate subsuiteDen Shabalin2013-09-051-0/+97