summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #3355 from xeno-by/topic/saturday-nightJason Zaugg2014-01-14295-972/+834
|\ | | | | reshuffles names for blackbox/whitebox contexts, changes bundle notation
| * removes Scala reflection-based macro runtimeEugene Burmako2014-01-122-35/+2
| | | | | | | | | | | | This code is currently unused, so I’m removing it in order to avoid bitrot. Once we’re sure that we can trust Scala reflection with our macros, the removed file can be easily reinstated.
| * prohibits constructor overloading for macro bundlesEugene Burmako2014-01-126-6/+32
| | | | | | | | | | | | As per Jason’s feedback, this commit handles overloaded constructors in macro bundles. The backend now checks that we have a constructor of a correct type. The frontend now prohibits multiple constructors altogether.
| * changes bundles to be classes, not traits extending MacroEugene Burmako2014-01-1234-251/+108
| | | | | | | | | | | | Adjusts bundle notation to read `class Bundle(val c: Context)` instead of `class Bundle extends Macro`. This avoids calling compileLate in the macro compiler and associated tooling problems.
| * *boxContext => *box.Context , *boxMacro => *box.MacroEugene Burmako2014-01-12280-748/+760
| | | | | | | | | | | | | | | | | | | | Performs the following renamings: * scala.reflect.macros.BlackboxContext to scala.reflect.macros.blackbox.Context * scala.reflect.macros.BlackboxMacro to scala.reflect.macros.blackbox.Macro * scala.reflect.macros.WhiteboxContext to scala.reflect.macros.whitebox.Context * scala.reflect.macros.WhiteboxMacro to scala.reflect.macros.whitebox.Macro https://groups.google.com/forum/#!topic/scala-internals/MX40-dM28rk
* | Merge pull request #3275 from paulp/pr/patmatAdriaan Moors2014-01-1330-355/+825
|\ \ | | | | | | Improves name-based patmat.
| * | Fix infinite recursion in name-based patmat.Paul Phillips2014-01-091-1/+3
| | | | | | | | | | | | | | | | | | I discovered on erroneous code it could fall into a loop looking for product selectors, because ErrorType always claims to have whatever member you're asking about.
| * | Merge pull request #13 from retronym/ticket/8128Paul Phillips2014-01-093-4/+44
| |\ \ | | | | | | | | SI-8128 Fix regression in extractors returning existentials
| | * | SI-8128 Fix regression in extractors returning existentialsJason Zaugg2014-01-093-4/+44
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The advent of the named based pattern matcher brought with it a change in the way we determine the type of the value in the "match monad". We used to take the base type to `Option` or `Seq` (guided by the method name in `unapply` vs `unapplySeq`), and simply use the type argument. Name-based patmat, instead, uses the result type of methods in the type. For example, the element type of an Option-like extractor result is given by the result type of the no-args `get` method. This approach, however, swiftly runs aground when navigating the existential atolls. Here's why: scala> class F[_] defined class F scala> val tp = typeOf[Some[F[X]] forSome { type X }] warning: there were 1 feature warning(s); re-run with -feature for details tp: $r.intp.global.Type = scala.this.Some[F[X]] forSome { type X } scala> tp.baseType(typeOf[Option[_]].typeSymbol).typeArgs.head res10: $r.intp.global.Type = F[X] forSome { type X } scala> tp.memberType(tp.member(nme.get)).finalResultType res11: $r.intp.global.Type = F[X] `res10` corresponds to 2.10.x approach in `matchMonadResult`. `res11` corresponds to the new approach in `resultOfMatchingMethod`. The last result is not wrapped by the existential type. This results in errors like (shown under -Ydebug to turn un accurate printing of skolems): error: error during expansion of this match (this is a scalac bug). The underlying error was: type mismatch; found : _$1&0 where type _$1&0 required: _$1 (0: Any) match { ^ one error found This commit addresses the regression in 2.10.x compatible extractors by using the 2.10 approach for them. The residual problem is shown in the enclosed pending test.
| * | Finalized some case classes, for better static checking.Paul Phillips2013-12-311-5/+5
| | |
| * | Eliminated some dead/redundant code based on review.Paul Phillips2013-12-313-51/+7
| | |
| * | SI-8045 type inference of extracted valuePaul Phillips2013-12-231-0/+17
| | | | | | | | | | | | Test case for SI-8045, fixed by the preceding commits.
| * | SI-7850 CCE in patmat with invalid isEmpty.Paul Phillips2013-12-158-18/+53
| | | | | | | | | | | | | | | | | | | | | | | | Name-based pattern matcher needed some hardening against unapply methods with the right name but wrong types. Only isEmpty methods which return Boolean are acceptable. Catching it directly rather than indirectly also allowed for better error messages.
| * | SI-7897, SI-6675 improves name-based patmatPaul Phillips2013-12-1523-303/+723
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This emerges from a recent attempt to eliminate pattern matcher related duplication and to bake the scalac-independent logic out of it. I had in mind something a lot cleaner, but it was a whole lot of work to get it here and I can take it no further. Key file to admire is PatternExpander.scala, which should provide a basis for some separation of concerns. The bugs addressed are a CCE involving Tuple1 and an imprecise warning regarding multiple pattern crushing. Editorial: auto-tupling unapply results was a terrible idea which should never have escaped from the crib. It is tantamount to purposely throwing type safety down the toilet in the very place where people need type safety the most. See SI-6111 and SI-6675 for some other comments.
* | | Merge pull request #3361 from adriaanm/pr3303-testAdriaan Moors2014-01-131-0/+16
|\ \ \ | | | | | | | | junit test
| * | | SI-6615 junit testAdriaan Moors2014-01-131-0/+16
| | | |
* | | | Merge pull request #3247 from soc/SI-8058-enumsAdriaan Moors2014-01-1311-15/+44
|\ \ \ \ | | | | | | | | | | SI-8058 Better support for enum trees
| * | | | SI-8058 Better support for enum treesSimon Ochsenreither2014-01-0411-15/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace the approach of “detect some magic combination of flags to trigger some action” by introducing an enum flag which makes the semantics and the intentions of the code using it more explicit. This basically involves wiring up the existing ACC_ENUM bit to a new modifier flag and making sure it is set correctly when encountering enums. The existing enum tests files/pos/t5165 and files/pos/t2764 keep working, showing that this hasn't introduced any obvious regressions. Tests for the changes in Namer which prevent scalac from messing with enum trees can't be added yet, because one currently can't define an enum in Scala without the help of the macro paradise. The intention is to add the @enum macro as a full test suite as soon as one can depend on macro annotations. One might wonder why we don't check for clazz.superClass == JavaEnumClass (where clazz is the owning class) in isEnumConstant. The reason is that this causes illegal cyclic reference error. Explanation by Eugene why this happens: (23:17:52) xeno_by: so here's what happens as far as I can understand at 11pm :) (23:18:09) xeno_by: scalac tries to complete the signature of the newly expanded class (23:18:11) xeno_by: to do that (23:18:40) xeno_by: to do that it needs three things (23:18:51) xeno_by: because the signature of a class is ClassInfoType which consists of three things (23:19:05) xeno_by: parents (23:19:08) xeno_by: decls (23:19:09) xeno_by: and symbol (23:19:20) xeno_by: symbol is easy - it's already there (23:19:30) xeno_by: parents are also easy (23:19:39) xeno_by: you just typecheck the things that come after "extends" (23:19:42) xeno_by: but decls are tricky (23:19:51) xeno_by: scalac goes through all the members of the class (23:20:03) xeno_by: and doesn't typecheck them... no, it doesn't (23:20:07) xeno_by: it just enters them (23:20:32) xeno_by: i.e. creates symbols for them and assigns lazy completers to those symbols so that if someone wants to know their signatures, they will go through the completers (23:20:34) xeno_by: and then (23:20:38) xeno_by: wait (23:20:40) xeno_by: there's one but (23:20:42) xeno_by: BUT (23:20:47) xeno_by: while we enter those symbols (23:20:53) xeno_by: our ClassInfoType is not ready yet (23:21:09) xeno_by: the class we're completing is still considered to be in the middle of being completing (23:21:12) xeno_by: so (23:21:24) xeno_by: when inside enterSym you try to ask that class for its super class (23:21:35) xeno_by: what happens is that check asks the class for its type signature (23:21:45) xeno_by: the ClassInfoType that consists of parents and decls (23:21:54) xeno_by: even though the parents are already calculated (23:22:01) xeno_by: the ClassInfoType as a whole is not (23:22:16) xeno_by: so scalac says that you're trying to complete something that's currently being completed (23:22:20) xeno_by: cyclic reference error (23:22:59) xeno_by: "cyclic" in English looks an awful lot like "суслик" in Russian (which means "gopher")
* | | | | Merge pull request #3334 from som-snytt/issue/4841-helpAdriaan Moors2014-01-132-6/+7
|\ \ \ \ \ | | | | | | | | | | | | CLI help update for -Xplugin
| * | | | | SI-4841 CLI help update for -XpluginSom Snytt2014-01-072-6/+7
| |/ / / / | | | | | | | | | | | | | | | | | | | | The argument to `-Xplugin` is now a comma-separated list of paths. This commit updates the option descriptor and a code comment.
* | | | | Merge pull request #3242 from retronym/ticket/8046Adriaan Moors2014-01-139-4/+124
|\ \ \ \ \ | | | | | | | | | | | | SI-8046 BaseTypeSeq fixes with aliases
| * | | | | SI-8046 Only use fast TypeRef#baseTypeSeq with concrete base typesJason Zaugg2013-12-105-3/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can only compute the base type sequence (BTS) of a `TypeRef` by element-wise transforming the BTS of the referenced symbol if there are no abstract types in its BTS type symbols. In the now-working test case, `pos/t8046.scala`, the difference between the old and new calculation of the BTS is: this = Three.this.Alias[Int] sym.info.baseTypeSeq = BTS(One.this.Op[A],Any) mapped BTS = BTS(Three.this.Op[Int],Any) full BTS = BTS(Three.this.Op[Int],Int => Int,Object,Any) The change to account for PolyType in ArgsTypeRef#transform is now needed to avoid the full BTS of: BTS(Three.this.Op[A],A => A,Object,Any) Interestingly, everything actually works without that change.
| * | | | | Pending test for SI-6161Jason Zaugg2013-12-091-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | Not solved with base type dealiasing
| * | | | | SI-8046 Fix baseTypeSeq in presence of type aliasesJason Zaugg2013-12-094-2/+58
| | | | | |
* | | | | | Merge pull request #3184 from retronym/ticket/2066Adriaan Moors2014-01-136-2/+135
|\ \ \ \ \ \ | |_|_|/ / / |/| | | | | SI-2066 Plug a soundness hole higher order type params, overriding
| * | | | | SI-2066 Plug a soundness hole higher order type params, overridingJason Zaugg2013-11-276-2/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PolyType-s parameterized by higher order type parameters (HOTPs) should only be relatable with <:< or =:= if the variances of their type parameters line up. This is only enforced for HOTPs defined in method type arguments. Invariant type parameters subsume variant ones. Concretely, as described by @S11001001: > A method taking [F[_]] can implement a method taking [F[+_]]. > Likewise, a method taking [F[_[+_]]] can implement a method > taking [F[_[_]]], as with [F[_[_[_]]]] implementing [F[_[_[+_]]]], > and so on, the variance subsumption flipping at each step. > > This is just the opposite of the variance for passing type > parameters to either instantiate types or call methods; a F[+_] > is a suitable F[_]-argument, a F[_[_]] a suitable F[_[+_]]-argument, > and so on. > > All of the above rules can be duplicated for contravariant positions > by substituting - for +. Also, something similar happens for > weakening/strengthening bounds, I believe. These cases are tested in the `// okay` lines in `neg/t2066.scala`.
* | | | | | Merge pull request #3303 from Ichoran/issue/6615Adriaan Moors2014-01-131-1/+4
|\ \ \ \ \ \ | | | | | | | | | | | | | | Fixes SI-6615, NPE on slice of PagedSeq.
| * | | | | | SI-6615 PagedSeq's slice throws a NPE if it starts on a page that hasn't ↵Rex Kerr2013-12-311-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | been computed yet Made sure to addMore when roving forward on a slice into unpaged territory.
* | | | | | | Merge pull request #3302 from Ichoran/issue/6364Adriaan Moors2014-01-131-0/+6
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | Resolves SI-6364, O(n) performance of wrapped set contains.
| * | | | | | | SI-6364 SetWrapper does not preserve performance / behaviorRex Kerr2013-12-311-0/+6
| |/ / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | O(n) performance of wrapped set contains was the problem. Added overrides for contains and isEmpty to SetWrapper. Note that sets are invariant in Scala, while the Java signature is for any Object, so we trap a ClassCastException if one occurs. (Is this everything that could possibly go wrong? I think so, but am not as confident as I would like.)
* | | | | | | Merge pull request #3290 from soc/SI-7680Adriaan Moors2014-01-132-16/+49
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | Update the ScalaDoc entry page of the Scala library
| * | | | | | | SI-7680 Update the ScalaDoc entry page of the Scala librarySimon Ochsenreither2013-12-192-16/+49
| | | | | | | |
* | | | | | | | Merge pull request #3335 from swartzrock/masterIchoran2014-01-124-45/+42
|\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | Fixes #3330 with Scaladoc changes only
| * | | | | | | | Fixes #3330 with Scaladoc changes onlyJason Swartz2014-01-074-45/+42
| | |_|_|_|/ / / | |/| | | | | |
* | | | | | | | Merge pull request #3346 from retronym/ticket/8129Grzegorz Kossakowski2014-01-122-7/+12
|\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | SI-8129 Plug a leak in perRunCaches
| * | | | | | | | SI-8129 Plug a leak in perRunCachesJason Zaugg2014-01-102-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I guess we've never leaned to heavily on these, because the registry of caches was forgetting about most of them immediately if they compared == at the point of creation. Consequently, maps like `treatedInfos` in Mixin were holding onto old types and symbols and leaking memory. You can reproduce the leak with: (for i in {1..200}; do echo src/library/scala/collection/*.scala; done; printf "\n") | scalac-hash v2.11.0-M7 -J-Xmx256M -Xresident nsc> warning: there were 6 deprecation warning(s); re-run with -deprecation for details (... 15 times) nsc> java.lang.OutOfMemoryError: GC overhead limit exceeded Dumping heap to java_pid90362.hprof ... Heap dump file created [340635728 bytes in 7.993 secs] ^CException in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded As a consequence of this change, I had to remove eager clearing of the uniques types cache. The comment in the code elaborates further.
* | | | | | | | | Merge pull request #3351 from xeno-by/topic/fix-platform-dependent-testJason Zaugg2014-01-101-3/+4
|\ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | fixes run/macroPlugins-namerHooks.scala
| * | | | | | | | | fixes run/macroPlugins-namerHooks.scalaEugene Burmako2014-01-101-3/+4
| | |_|_|_|_|_|_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Makes run/macroPlugins-namerHooks.scala work equally well on both Unix and Windows machines.
* | | | | | | | | Merge pull request #3350 from retronym/ticket/8131Jason Zaugg2014-01-101-0/+0
|\ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | SI-8131 Move test for reflection thread safety to pending.
| * | | | | | | | | SI-8131 Move test for reflection thread safety to pending.Jason Zaugg2014-01-101-0/+0
| |/ / / / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Examples noted in SI-8131 show that race conditions still abound. This has been noted twice during pull request validation.
* | | | | | | | | Merge pull request #3349 from dotta/issue/disable-context-bound-test-8135Jason Zaugg2014-01-103-0/+0
|\ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | SI-8135 Disabled flaky hyperlinking presentation compiler test
| * | | | | | | | | SI-8135 Disabled flaky hyperlinking presentation compiler testMirco Dotta2014-01-103-0/+0
|/ / / / / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This PR (https://github.com/scala/scala/pull/3275#issuecomment-31986434) demonstrates that the test is flaky. The disabled test was introduced with the intent of preventing a regression (here is the commit https://github.com/scala/scala/commit/ccacb06c4928fd6aebc2c2539d7565cb079dc625). It looks like there is a race condition when `askTypeAt(pos)` is called on `implicitly[Foo[A]].foo` where `pos` is matches the end point of the former expression. The issue is that the returned Tree is unattributed, which is why the error "No symbol is associated with tree implicitly[Foo[A]].foo" is reported.
* | | | | | | | | Merge pull request #3124 from DarkDimius/fix-7443Adriaan Moors2014-01-093-6/+89
|\ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | Fix SI-7443 Range.sum ignoring Numeric argument and always assuming default 'plus' implementation
| * | | | | | | | | SI-7443 Use typeclass instance for {Range,NumericRange}.sumDmitry Petrashko2013-12-293-6/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously both Range and NumeriRange used formula for sum of elements of arithmetic series and thus always assumed that provided Numeric is regular one. Bug is now fixed by conservatively checking if Numeric is one of default ones and the formula still holds.
* | | | | | | | | | Merge pull request #3333 from gourlaysama/man-pagesAdriaan Moors2014-01-092-55/+136
|\ \ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | Update man pages for scala and scalac.
| * | | | | | | | | | Update man pages for scala and scalac.Antoine Gourlay2014-01-082-55/+136
| | |_|_|/ / / / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They had fallen quite a bit behind the output of "scalac -X" and "scalac -Xshow-phases".
* | | | | | | | | | Merge pull request #3277 from adriaanm/scala-dist-mavenAdriaan Moors2014-01-0919-331/+530
|\ \ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | Scala dist maven
| * | | | | | | | | | License formatting tweak, RTF version.Adriaan Moors2014-01-072-8/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To avoid duplication in scala/scala-dist, where it'll just go stale.
| * | | | | | | | | | Explicit jline dependency.Adriaan Moors2013-12-202-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Duplicated from scala-compiler's pom (where it's optional), so that resolving scala-dist's transitive dependencies include jline. We won't see scala-compiler's optional dependency on jline when depending on scala-compiler. TODO: remove duplication once we have the scala-compiler-repl module
| * | | | | | | | | | Always copy man/* and doc/tools/*.Adriaan Moors2013-12-201-13/+14
| | | | | | | | | | |