Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | SI-6138 Centralize and refine detection of `getClass` calls | Jason Zaugg | 2013-05-23 | 1 | -0/+8 |
| | | | | | | | | | | | | | | | | | | | | | | | `getClass` is special cased in the compiler; this is described in in the comments on `Definitions.Any_getClass`. Part of this happens in `Typer#stabilize`. This was trying to determine if an Ident or Select node was a call to `getClass` by merits of the name of the tree's symbol and by checking that the its type (if it was a MethodType or PolyType) had no parameters in the primary parameter list. Overloaded user defined `getClass` methods confused this check. In the enclosed test case, the tree `definitions.this.getClass` had an `OverloadedType`, and such types always report an empty list of `params`. This commit: - changes `stabilize` to use `isGetClass`, rather than the homebrew check - changes `isGetClass` to consider a `Set[Symbol]` containing all `getClass` variants. This moves some similar code from `Erasure` to `Definitions` - keeps a fast negative path in `isGetClass` based on the symbol's name | ||||
* | SI-7442 Update bundled Fork/Join pool (JSR166y) | Philipp Haller | 2013-05-11 | 1 | -0/+29 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Updates ForkJoinPool and dependent classes to the latest jsr166y revisions: ForkJoinPool.java: Revision 1.185 Sat Feb 16 20:50:29 2013 UTC (2 months, 2 weeks ago) by jsr166 ForkJoinTask.java: Revision 1.100 Tue Feb 5 17:09:54 2013 UTC (3 months ago) by jsr166 ForkJoinWorkerThread.java: Revision 1.73 Wed Nov 21 19:54:39 2012 UTC (5 months, 2 weeks ago) by dl - Includes Akka-contributed `sun.misc.Unsafe` detection to support Android. See changeset 06d685c1bbd8a0d058ee8a3f374569f8097f2acc - Adds private `CountedCompleter` class. This class is only visible and used in `ForkJoinPool.java`. - Updates desired.sha1 for updated forkjoin.jar. - Updates binary compatibility whitelists to exclude package-private methods in the `forkjoin` package. - Also fixes SI-7438. | ||||
* | SI-7289 Less strict type application for TypeVar. | Adriaan Moors | 2013-04-08 | 1 | -0/+4 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a type constructor variable is applied to the wrong number of arguments, return a new type variable whose instance is `ErrorType`. Dissection of the reported test case by @retronym: Define the first implicit: scala> trait Schtroumpf[T] defined trait Schtroumpf scala> implicit def schtroumpf[T, U <: Coll[T], Coll[X] <: Traversable[X]] | (implicit minorSchtroumpf: Schtroumpf[T]): Schtroumpf[U] = ??? schtroumpf: [T, U <: Coll[T], Coll[X] <: Traversable[X]](implicit minorSchtroumpf: Schtroumpf[T])Schtroumpf[U] Call it explicitly => kind error during type inference reported. scala> schtroumpf(null): Schtroumpf[Int] <console>:10: error: inferred kinds of the type arguments (Nothing,Int,Int) do not conform to the expected kinds of the type parameters (type T,type U,type Coll). Int's type parameters do not match type Coll's expected parameters: class Int has no type parameters, but type Coll has one schtroumpf(null): Schtroumpf[Int] ^ <console>:10: error: type mismatch; found : Schtroumpf[U] required: Schtroumpf[Int] schtroumpf(null): Schtroumpf[Int] ^ Add another implicit, and let implicit search weigh them up. scala> implicitly[Schtroumpf[Int]] <console>:10: error: diverging implicit expansion for type Schtroumpf[Int] starting with method schtroumpf implicitly[Schtroumpf[Int]] ^ scala> implicit val qoo = new Schtroumpf[Int]{} qoo: Schtroumpf[Int] = $anon$1@c1b9b03 scala> implicitly[Schtroumpf[Int]] <crash> Implicit search compares the two in-scope implicits in `isStrictlyMoreSpecific`, which constructs an existential type: type ET = Schtroumpf[U] forSome { type T; type U <: Coll[T]; type Coll[_] <: Traversable[_] } A subsequent subtype check `ET <:< Schtroumpf[Int]` gets to `withTypeVars`, which replaces the quantified types with type variables, checks conformance of that substitued underlying type against `Schtroumpf[Int]`, and then tries to solve the collected type constraints. The type var trace looks like: [ create] ?T ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] ) [ create] ?U ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] ) [ create] ?Coll ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] ) [ setInst] Nothing ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], T=Nothing ) [ setInst] scala.collection.immutable.Nil.type( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], U=scala.collection.immutable.Nil.type ) [ setInst] =?scala.collection.immutable.Nil.type( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], Coll==?scala.collection.immutable.Nil.type ) [ create] ?T ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] ) [ setInst] Int ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], T=Int ) [ create] ?T ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] ) [ create] ?U ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] ) [ create] ?Coll ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] ) [ setInst] Nothing ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], T=Nothing ) [ setInst] Int ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], U=Int ) [ setInst] =?Int ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], Coll==?Int ) The problematic part is when `?Int` (the type var originated from `U`) is registered as a lower bound for `Coll`. That happens in `solveOne`: for (tparam2 <- tparams) tparam2.info.bounds.hi.dealias match { case TypeRef(_, `tparam`, _) => log(s"$tvar addLoBound $tparam2.tpeHK.instantiateTypeParams($tparams, $tvars)") tvar addLoBound tparam2.tpeHK.instantiateTypeParams(tparams, tvars) case _ => } | ||||
* | Refactor existential related code out of types. | Jason Zaugg | 2013-04-02 | 1 | -0/+24 |
| | | | | | | | For imminent reuse in the subsequent commit. The binary compatibility whitelist is updated to ignore these, as they live in reflect.internal. | ||||
* | Read version 51 (JDK 7) class files. | James Iry | 2013-03-14 | 1 | -0/+4 |
| | | | | | | | | | | | | | | | | | This commit makes the ClassFileReader/ICodeReader parse class files from JDK 7 (class file version 51). It does that by skipping over the method handle related entries in the constant pool and by doing some dummy processing on invoke dynamic instructions. The inliner is updated to not try to inline a method with an invoke dynamic instruction. A place holder INVOKE_DYNAMIC instruction is added to ICode but it is designed to create an error if there's ever any attempt to analyze it. Because the inliner is the only phase that ever tries to analyze ICode instructions not generated from Scala source and because Scala source will never emit an INVOKE_DYNAMIC, the place holder INVOKE_DYNAMIC should never cause any errors. A test is included that generates a class file with INVOKE_DYNAMIC and then compiles Scala code that depends on it. | ||||
* | test.done again checks bin compat (using mima 0.1.5) | Adriaan Moors | 2013-03-01 | 1 | -0/+4 |
| | |||||
* | [nomaster] Revert "SI-6548 reflection now correctly enters jinners" | Adriaan Moors | 2013-02-10 | 1 | -8/+8 |
| | | | | | | | | | | | | | This reverts commit 54a84a36d5b435a787d93ca48d45399136c7e162. This is necessary to maintain binary compatibility with 2.10.0. run/t6989.check had to be updated as it also (indirectly) tested SI-6548 Conflicts: test/files/lib/javac-artifacts.jar.desired.sha1 test/files/run/t6548.check test/files/run/t6548/Test_2.scala | ||||
* | [nomaster] Revert "cosmetic renamings in runtime reflection" | Adriaan Moors | 2013-02-09 | 1 | -24/+24 |
| | | | | | | This reverts commit 0429f0fd9224499cd8b606490d04b1a8dcffbca8. This is necessary to maintain binary compatibility with 2.10.0. | ||||
* | [nomaster] bring back SerializeStart from fa3b8040eb | Adriaan Moors | 2013-02-09 | 1 | -10/+10 |
| | | | | This is necessary to maintain binary compatibility with 2.10.0. | ||||
* | [nomaster] run mima both ways, filter out failures | Adriaan Moors | 2013-02-09 | 1 | -0/+159 |
Using @gkossakowski's contribution to mima (in 0.1.5-SNAPSHOT), make sure bc.run doesn't fail by filtering out all binary incompatibilities. Each subsequent commit will comment out the filters it makes irrelevant, until we only need to filter out permitted binary incompatibilities. We only allow binary incompatibilities in scala.reflect.internal. |