summaryrefslogtreecommitdiff
path: root/src/reflect/scala/reflect/internal/tpe
Commit message (Collapse)AuthorAgeFilesLines
* Fix typos in compiler and reflectJanek Bogucki2017-02-134-6/+6
| | | | | | | | | | | | Miscellania: Miscellania is a small island off the northernmost part of the Fremennik Isles - RunScape Wiki Miscellanea: A collection of miscellaneous objects or writings - Merriam-Webster
* remove deprecated compiler flag "-Yeta-expand-keeps-star"Lars Hupel2016-12-011-9/+1
| | | | This was slated for removal in 2.12.
* Merge pull request #5506 from retronym/topic/existential-idsAdriaan Moors2016-11-291-1/+3
|\ | | | | Avoid name table pollution with fresh existentials
| * Avoid name table pollution with fresh existentialsJason Zaugg2016-11-081-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During large compilations runs, the large numbers of globally unique fresh names for existentials captured from prefixes of `asSeenFrom`. is a) somewhat wasteful (all these names are interned in the name table) , and, b) form a pathological case for the current implementation of `Names#hashValue`, which leads to overfull hash-buckets in the name table. `hashValue` should probably be improved, but my attempts to do so have shown a small performance degradation in some benchmarks. So this commit starts by being more frugal with these names, only uniquely naming within an `asSeenFrom` operation. References scala/scala-dev#246
* | Typo and spelling correctionsJanek Bogucki2016-11-111-2/+2
|/
* Minor changes after reviewJason Zaugg2016-08-231-2/+2
|
* Address review commentsJason Zaugg2016-08-231-18/+0
| | | | | | | | | | - clarify the intent of tests - Consolidate stripExistentialsAndTypeVars with similar logic in mergePrefixAndArgs - Refactor special cases in maybeRewrap The name isn't great, but I'm struggling to come up with a pithy way to describe the rogue band of types.
* SI-5294 Use bounds of abstract prefix in asSeenFromJason Zaugg2016-08-231-5/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ASF was failing to recognize the correspondence between a prefix if it has an abstract type symbol, even if it is bounded by the currently considered class. Distilling the test cases, this led to incorrect typechecking of the RHS of `G` in: ``` trait T { type A trait HasH { type H[U] <: U } type F[N <: HasH] = N#H[T] type G[N <: HasH] = F[N]#A // RHS was incorrectly reduced to T.this.A } ``` In the fuller examples (included as test cases), this meant that type level functions written as members of `HList` could not be implemented in terms of each other, e.g. defining `Apply[N]` as `Drop[N]#Head` had the wrong semantics. This commit checks checks if the prefix has the candidate class as a base type, rather than checking if its type symbol has this as a base class. The latter formulation discarded information about the instantation of the abstract type. Using the example above: ``` scala> val F = typeOf[T].member(TypeName("F")).info F: $r.intp.global.Type = [N <: T.this.HasH]N#H[T] scala> F.resultType.typeSymbol.baseClasses // old approach res14: List[$r.intp.global.Symbol] = List(class Any) scala> F.resultType.baseClasses // new approach res13: List[$r.intp.global.Symbol] = List(trait T, class Object, class Any) ``` It is worth noting that dotty rejects some of these programs, as it introduces the rule that: > // A type T is a legal prefix in a type selection T#A if > // T is stable or T contains no abstract types except possibly A. > final def isLegalPrefixFor(selector: Name)(implicit ctx: Context) However, typechecking the program above in this comment in dotty yields: <trait> trait T() extends Object { type A <trait> trait HasH() extends Object { type H <: [HK$0] => <: HK$0 } type F = [HK$0] => HK$0#H{HK$0 = T}#Apply type G = [HK$0] => HK$0#H{HK$0 = T}#Apply#A } As the equivalent code [1] in dotc's `asSeenFrom` already looks for a base type of the prefix, rather than looking for a superclass of the prefix's type symbol. [1] https://github.com/lampepfl/dotty/blob/d2c96d02fccef3a82b88ee1ff31253b6ef17f900/src/dotty/tools/dotc/core/TypeOps.scala#L62
* Improved refinement type and existential type handlingJason Zaugg2016-08-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lazy base type seq elements are encoded as a refined type with an empty scope and a list of type refs over some common type symbol that will be merged when `BaseTypeSeq#apply` is called. The first change in this commit is to mark the creation and consumption of such elements with calls to `[is]IntersectionTypeForBaseTypeSeq`. They are distinguished by using the actual type symbol rather than a refinement class symbol, which in turn simplifies the code in `BaseTypeSeq#typeSymbol`. I have also made `lub` aware of this encoding: it is now able to "see through" to the parents of such refined types and merge them with other base types of the same class symbol (even other refined types representing lazy BTS elements.) To make this fix work, I also had to fix a bug in LUBs of multiple with existential types. Because of the way the recursion was structured in `mergePrefixAndArgs`, the order of list of types being merged changed behaviour: quantified varialbles of existential types were being rewrapped around the resultting type, but only if we hadn't encountered the first regular `TypeRef`. This can be seen with the following before/after shot: ``` // 2.11.8 scala> val ts = typeOf[Set[Any]] :: typeOf[Set[X] forSome { type X <: Y; type Y <: Int}] :: Nil; def merge(ts: List[Type]) = mergePrefixAndArgs(ts, Variance.Contravariant, lubDepth(ts)); val merged1 = merge(ts); val merged2 = merge(ts.reverse); (ts.forall(_ <:< merged1), ts.forall(_ <:< merged2)) ts: List[$r.intp.global.Type] = List(Set[Any], Set[_ <: Int]) merge: (ts: List[$r.intp.global.Type])$r.intp.global.Type merged1: $r.intp.global.Type = scala.collection.immutable.Set[_ >: Int] merged2: $r.intp.global.Type = scala.collection.immutable.Set[_53] forSome { type X <: Int; type _53 >: X } res0: (Boolean, Boolean) = (false,true) // HEAD ... merged1: $r.intp.global.Type = scala.collection.immutable.Set[_10] forSome { type X <: Int; type _10 >: X } merged2: $r.intp.global.Type = scala.collection.immutable.Set[_11] forSome { type X <: Int; type _11 >: X } res0: (Boolean, Boolean) = (true,true) ``` Furthermore, I have fixed the computation of the base type sequences of existential types over refinement types, in order to maintain the invariant that each slot of the base type sequence of a existential has the same type symbol as that of its underlying type. Before, what I've now called a `RefinementTypeRef` was transformed into a `RefinedType` during rewrapping in the existential, which led to it being wrongly considered as a lazy element of the base type sequence. The first change above should also be sufficient to avoid the bug, but I felt it was worth cleaning up `maybeRewrap` as an extra line of defence. Finally, I have added another special case to `BaseTypeSeq#apply` to be able to lazily compute elements that have been wrapped in an existential. The unit test cases in `TypesTest` rely on these changes. A subsequent commit will build on this foundation to make a fix to `asSeenFrom`.
* Type#contains should peer into RefinementTypeRef-sJason Zaugg2016-08-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Usually, `contains` should not look into class symbol infos. For instance, we expect that: ``` scala> trait C { def foo: Int }; typeOf[C].contains(IntClass) defined trait C res1: Boolean = false ``` We do, however, look at the decls of a `RefinedType` in contains: ``` scala> typeOf[{ def foo: Int }].contains(IntClass) res2: Boolean = true ``` Things get a little vague, however, when we consider a type ref to the refinement class symbol of a refined type. ``` scala> TypeRef(NoPrefix, typeOf[{ def foo: Int }].typeSymbol, Nil) res3: $r.intp.global.Type = AnyRef{def foo: Int} scala> .contains(IntClass) res4: Boolean = false ``` These show up in the first element of the base type seq of a refined type, e.g: ``` scala> typeOf[{ def foo: Int }].typeSymbol.tpe_* res5: $r.intp.global.Type = AnyRef{def foo: Int} scala> typeOf[{ def foo: Int }].baseTypeSeq(0).getClass res7: Class[_ <: $r.intp.global.Type] = class scala.reflect.internal.Types$RefinementTypeRef scala> typeOf[{ def foo: Int }].typeSymbol.tpe_*.getClass res6: Class[_ <: $r.intp.global.Type] = class scala.reflect.internal.Types$RefinementTypeRef ``` This commit takes the opinion that a `RefinementTypeRef` should be transparent with respect to `contains`. This paves the way for fixing the base type sequences of existential types over refinement types. The implementation of `ContainsCollector` was already calling `normalize`, which goes from `RefinementTypeRef` to `RefinedType`. This commit maps over the result, which looks in the parents and decls.
* Lower-case spelling of @deprecated messagesSimon Ochsenreither2016-05-281-1/+1
|
* Less distribution of logic across TypeRef subclassesAdriaan Moors2016-02-121-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Redeem myself for e1c732db44 -- hopefully. I inlined `thisInfo` (== `sym.info`), and made sure to use `relativeInfo` wherever prefix and args influence the result of the query that we're delegating to the underlying type. For type aliases, use `normalize` for `baseClasses` and `decls`, since `relativeInfo` breaks the gnarly SI-8177. I think normalize is okay for aliases, as the prefix should not matter when computing base classes, and infos for the members in `decls` are given the `asSeenFrom` treatment individually downstream. (It's a tight rope between rewriting too many symbols and maintaining correctness. Documented the trade-off in the code.) Renamed the unimaginative `transform` to `relativize`, which, although everything is relative, hopefully says a bit more about its usage than `transform`. Removed a lot of over-factoring in the TypeRef hierarchy. Ultimately, we need to reduce the number of TypeRef subclasses further, I think. It's really hard to follow what's going on. Removed the `thisInfo` cache, since `sym.info` and `relativeInfo` are both cached. Made the cache invalidation hooks a bit more OO-y. Compare `Symbol`s with `eq` -- they don't define an `equals` method. Also, don't recurse in isSubtype when a `baseType` results in `NoType`. This happens a lot and is cheap to check, so I posit (without proof), that it's better for performance (and clarity) to check before recursing.
* SI-9542 Unify different reprs. of module type refsJason Zaugg2016-02-011-17/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The new unit test shows failures in transitivity of subtyping and type equivalence, which boil down the the inconsistent handling of the semantically equivalent: ThisType(pre, ModuleClass) ModuleTypeRef(pre, ModuleClass) SingleType(pre, Module) This commit: - adds a case to `normalizePlus` to unwrap a `ThisType` to a `ModuleTypeRef` - Use `normalizePlus` more widely during subtype comparison - refactor `fourthTry` (part of `isSubType`) to remove code that becomes obviated by the use of `normalizePlus`. This fixes the regression in the extension methods phase which was triggered by https://github.com/scala/scala/pull/4749. We can also fix that regression by tweaking the extension methods phase itself to emit the `ThisType` representation of the owner of the value class, as before. I plan to demonstrate the two approaches to fixing the regression on separate branches, and the propose that the merged result of these two is useds.
* Merge commit '8eb1d4c' into merge-2.11-to-2.12-nov-24Lukas Rytz2015-11-241-4/+14
|\
| * Attacking exponential complexity in TypeMapsJason Zaugg2015-11-131-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Don't normalize existentials during the `contain`-s type map; `ExistentialType#normalize' calls contains internally and an exponential blowup ensues. - Ensure that the type map used in variance validation never returns modified types in order to avoid needless cloning of symbols. The enclosed test case still gets stuck in Uncurry, thanks to the way that `TypeMap#mapOver(List[Symbol])` recurses through the type first to check whether the type map would be an no-op or not. If not, it repeats the type map with cloned symbols. Doing the work twice at each level of recursion blows up the complexity. Removing that "fast path" allows the enclosed test to compile completely. As at this commit, it gets stuck in uncurry, which dealiases `s.List` to `s.c.i.List` within the type. Some more background on the troublesome part of `TypeMap`: http://lrytz.github.io/scala-aladdin-bugtracker/displayItem.do%3Fid=1210.html https://github.com/scala/scala/commit/f8b2b21050e7a2ca0f537ef70e3e0c8eead43abc
* | Merge commit 'a170c99' into 2.12.xLukas Rytz2015-09-221-1/+1
|\|
| * Improve drifted URLsJanek Bogucki2015-09-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Any.scala: Link to the guide instead of the SIP. - AnyVal.scala: Remove SIP link and align guide link to Any.scala. - Commands.scala: Use a less out of date team link. - Logic.scala: Link was broken. Substitute found. - Process.scala: Links were 403 & 404. Fixed as this is a code sample. - TypeMaps.scala: Move old EPFL Trac to JIRA. - RedBlackTree.scala: Replaced broken link with substitutes based on site maintainer input [1]. [1] When asked where Data-Set-RBTree.html had gone Don@UNSW advised "I think it's on the Haskell wiki now. It was Chris Okazaki's version". The closest I could find to what this document probably was is this paper by Hinze edited by Okasaki, http://www.cs.ox.ac.uk/ralf.hinze/publications/WAAAPL99b.ps.gz The paper cites the Okasaki document so I included a link to that as well. The Haskell Wiki does have a link to a RB document but that's broken too, https://wiki.haskell.org/Research_papers/Data_structures > Constructing red-black trees
* | Merge remote-tracking branch 'origin/2.11.x' into ↵Jason Zaugg2015-07-231-1/+1
|\| | | | | | | merge/2.11.x-to-2.12.x-20152307
| * Fix 23 typos (t-v)Janek Bogucki2015-07-151-1/+1
| |
* | Merge remote-tracking branch 'origin/2.11.x' into ↵Jason Zaugg2015-07-131-1/+1
|\| | | | | | | | | | | | | | | | | | | | | | | | | merge/2.11.x-to-2.12.x-20150713 Conflicts: src/eclipse/partest/.classpath src/eclipse/repl/.classpath test/files/run/nothingTypeNoFramesNoDce.scala test/files/run/repl-javap-app.check Also fixup two .classpath files with updated partest, xml and parser combinators JARs.
| * Fix 23 typos (m-o)Janek Bogucki2015-06-281-1/+1
| |
* | Merge branch '2.11.x' into merge/2.11.x-to-2.12.x-20150624Jason Zaugg2015-06-241-1/+1
|\|
| * SI-9253 avoid IndexOutOfBoundsException in TypeMaps.correspondingTypeArgumentBruno Bieth2015-06-221-1/+1
| |
* | Merge remote-tracking branch 'origin/2.11.x' into ↵Jason Zaugg2015-05-011-1/+1
|\| | | | | | | merge/2.11.x-to-2.12.x-20150501
| * Fix many typosMichał Pociecha2015-04-211-1/+1
| | | | | | | | | | This commit corrects many typos found in scaladocs and comments. There's also fixed the name of a private method in ICodeCheckers.
* | SI-9074 Fix generic substitution with package objects, overloadingJason Zaugg2015-03-241-3/+6
|/ | | | | | | | | | | | | Takes a leaf out of dotty's book [1] and makes `asSeenFrom` transparently change the prefix from the package class to the package object when needed. This fixes generic subsitution during overload resolution, as reported in SI-9074. This subsumes the former fix for SI-6225, which is removed here. [1] https://github.com/lampepfl/dotty/pull/282
* Fix many typos in docs and commentsmpociecha2014-12-142-2/+2
| | | | | | | | | | | | | This commit corrects many typos found in scaladocs, comments and documentation. It should reduce a bit number of PRs which fix one typo. There are no changes in the 'real' code except one corrected name of a JUnit test method and some error messages in exceptions. In the case of typos in other method or field names etc., I just skipped them. Obviously this commit doesn't fix all existing typos. I just generated in IntelliJ the list of potential typos and looked through it quickly.
* Merge pull request #4101 from adriaanm/sam-exLukas Rytz2014-11-101-0/+16
|\ | | | | [sammy] eta-expansion, overloading, existentials
| * [sammy] use correct type for method to overrideAdriaan Moors2014-11-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't naively derive types for the single method's signature from the provided function's type, as it may be a subtype of the method's MethodType. Instead, once the sam class type is fully defined, determine the sam's info as seen from the class's type, and use those to generate the correct override. ``` scala> Arrays.stream(Array(1, 2, 3)).map(n => 2 * n + 1).average.ifPresent(println) 5.0 scala> IntStream.range(1, 4).forEach(println) 1 2 3 ``` Also, minimal error reporting Can't figure out how to do it properly, but some reporting is better than crashing. Right? Test case that illustrates necessity of the clumsy stop gap `if (block exists (_.isErroneous))` enclosed as `sammy_error_exist_no_crash` added TODO for repeated and by-name params
| * [sammy] eta-expansion, overloading (SI-8310)Adriaan Moors2014-11-061-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Playing with Java 8 Streams from the repl showed we weren't eta-expanding, nor resolving overloading for SAMs. Also, the way Java uses wildcards to represent use-site variance stresses type inference past its bendiness point (due to excessive existentials). I introduce `wildcardExtrapolation` to simplify the resulting types (without losing precision): `wildcardExtrapolation(tp) =:= tp`. For example, the `MethodType` given by `def bla(x: (_ >: String)): (_ <: Int)` is both a subtype and a supertype of `def bla(x: String): Int`. Translating http://winterbe.com/posts/2014/07/31/java8-stream-tutorial-examples/ into Scala shows most of this works, though we have some more work to do (see near the end). ``` scala> import java.util.Arrays scala> import java.util.stream.Stream scala> import java.util.stream.IntStream scala> val myList = Arrays.asList("a1", "a2", "b1", "c2", "c1") myList: java.util.List[String] = [a1, a2, b1, c2, c1] scala> myList.stream.filter(_.startsWith("c")).map(_.toUpperCase).sorted.forEach(println) C1 C2 scala> myList.stream.filter(_.startsWith("c")).map(_.toUpperCase).sorted res8: java.util.stream.Stream[?0] = java.util.stream.SortedOps$OfRef@133e7789 scala> Arrays.asList("a1", "a2", "a3").stream.findFirst.ifPresent(println) a1 scala> Stream.of("a1", "a2", "a3").findFirst.ifPresent(println) a1 scala> IntStream.range(1, 4).forEach(println) <console>:37: error: object creation impossible, since method accept in trait IntConsumer of type (x$1: Int)Unit is not defined (Note that Int does not match Any: class Int in package scala is a subclass of class Any in package scala, but method parameter types must match exactly.) IntStream.range(1, 4).forEach(println) ^ scala> IntStream.range(1, 4).forEach(println(_: Int)) // TODO: can we avoid this annotation? 1 2 3 scala> Arrays.stream(Array(1, 2, 3)).map(n => 2 * n + 1).average.ifPresent(println(_: Double)) 5.0 scala> Stream.of("a1", "a2", "a3").map(_.substring(1)).mapToInt(_.parseInt).max.ifPresent(println(_: Int)) // whoops! ReplGlobal.abort: Unknown type: <error>, <error> [class scala.reflect.internal.Types$ErrorType$, class scala.reflect.internal.Types$ErrorType$] TypeRef? false error: Unknown type: <error>, <error> [class scala.reflect.internal.Types$ErrorType$, class scala.reflect.internal.Types$ErrorType$] TypeRef? false scala.reflect.internal.FatalError: Unknown type: <error>, <error> [class scala.reflect.internal.Types$ErrorType$, class scala.reflect.internal.Types$ErrorType$] TypeRef? false at scala.reflect.internal.Reporting$class.abort(Reporting.scala:59) scala> IntStream.range(1, 4).mapToObj(i => "a" + i).forEach(println) a1 a2 a3 ```
* | SI-7602 Avoid crash in LUBs with erroneous codeJason Zaugg2014-11-071-1/+3
|/ | | | | | | | | If a class contains a double defintion of a method that overrides an interface method, LUBs could run into a spot where filtering overloaded alternatives to those that match the interface method fails to resolve to a single overload, which crashes the compiler. This commit uses `filter` rather than `suchThat` to avoid the crash.
* Use named class for UndoPair.Grzegorz Kossakowski2014-04-251-3/+10
| | | | | | | | | Use specific, named class for UndoPair instead of generic Tuple2. This makes analysis of heap dumps much easier because profilers let you inspect memory consumption on per-class basis. The UndoPair case class is defined in companion object to not hold an outer pointer reference.
* Merge pull request #3557 from adriaanm/t8224Jason Zaugg2014-02-211-37/+32
|\ | | | | SI-8224 Fix regression in f-bound aware LUBs
| * SI-8224 Fix regression in f-bound aware LUBsJason Zaugg2014-02-181-37/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Disable the heuristic approach to recursive bounds unless the compiler is running under `-Xstrict-inference`. [the above was not authored by the original author] In db46c71e88, steps were taken to avoid blowing up in the pathological LUB calculation needed for: def trav = List(List(), Stream()) This skipped a level in the base class sequence when f-bounds were detected at the current level. In that example, when `lublist` was about to: mergePrefixAndArgs( typeOf[LinearSeqOptimized[A, List[A]]], typeOf[LinearSeqOptimized[A, Stream[A]]], ) If it proceeded (as in 2.10.3), the LUB is invalid: error: type arguments [B[_ >: D with C <: B[_ >: D with C <: A]],s.c.immutable.LinearSeq[B[_ >: D with C <: A]] with s.c.AbstractSeq[B[_ >: D with C <: A]] with s.c.LinearSeqOptimized[B[_ >: D with C <: A],s.c.immutable.LinearSeq[A] with s.c.AbstractSeq[A] with s.c.LinearSeqOptimized[A,Immutable with Equals with java.io.Serializable] with java.io.Serializable] with java.io.Serializable] do not conform to trait LinearSeqOptimized's type parameter bounds [+A,+Repr <: s.c.LinearSeqOptimized[A,Repr]] To avoid this, the added code would skip to the first non-F-bounded base type of the same arity of each element in the list. This would get to: LinearSeqLike[D, Stream[D]] LinearSeqLike[C, List[C]] which are lubbable without violating the type constraints. I don't think this was the right remedy. For starters, as seen in this bug report, SI-8224, if the list of types are identical we have let a perfectly good lub slip through our fingers, and end up calculating too general a type. More generally, if the type arguments in f-bounded positions coincide, we don't risk calculating a ill-bounded LUB. Furthermore, the code was widening each of the types separately; this isn't something we want to do within `if (isUniformFrontier)`. AFAICT this was just wasteful and as all `ts0` start with the same type symbol, so `typeConstructorList` should be uniform. This commit restricts this base-class skipping to situations where the argument inferred for an type argument that is used as an f-bound is not: a) an existential (as created by `mergePrefixAndArgs` in invariant positions.), or b) equivalent to one of the corresponding input type arguments (this is the case that fixes the regression in pos/8224.scala)
* | Merge pull request #3452 from xeno-by/topic/palladium0Jason Zaugg2014-02-191-1/+1
|\ \ | |/ |/| SI-8063 and its seventy friends
| * SI-6732 deprecates internal#Symbol.isPackageEugene Burmako2014-02-141-1/+1
| | | | | | | | | | | | | | | | This is the first step in disentangling api#Symbol.isPackage, which is supposed to return false for package classes, and internal#Symbol.isPackage, which has traditionally being used as a synonym for hasPackageFlag and hence returned true for package classes (unlike isModule which is false for module classes).
* | Optimization: remove assertion from SubstMap constructorJason Zaugg2014-02-181-1/+2
|/ | | | | | | | | | A profile [1] reported 3% of a compile run was spent here. This commit demotes the eager check to -Xdev. This assertion was added in e557acb9a7. [1] https://dl.dropboxusercontent.com/u/106552/perf/rudder-nailgun-2014-02-18-1.snapshot
* SI-7753 InstantiateDependentMap narrows type of unstable argsAdriaan Moors2014-02-121-30/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Most of this comment and the initial fix were implemented by Jason Zaugg. I just cleaned it up a bit.] After a soundness fix in SI-3873, instantiation of dependent method type results behaved differently depending on whether the argument from which we were propagating information had a stable type or not. This is particular to substitution into singleton types over the parameter in question. If the argument was stable, it was substituted into singleton types, such as the one below in the prefix in `a.type#B` (which is the longhand version of `a.B`) scala> class A { type B >: Null <: AnyRef } defined class A scala> object AA extends A { type B = String } defined object AA scala> def foo(a: A): a.B = null foo: (a: A)a.B scala> foo(AA) res0: AA.B = null But what if it isn't stable? scala> foo({def a = AA; a: A { type B <: String}}) res1: a.B = null This commit changes that to: scala> foo({def a = AA; a: A { type B <: String}}) res1: A{type B <: String}#B = null
* SI-7475 Address review comments in FindMembersJason Zaugg2014-02-101-7/+10
| | | | | | | | | | | - comment the cases in `isNewMember` - check both sides for privacy (doesn't influence behaviour of any tests, but it means that method can be understood without understanding the order of traversal of members.) - hoist `findAll` - break out of the loop in `FindMembers` as soon as we determine that the candidate member is matched by an already-found member and can be discarded.
* SI-7475 Private members are not inheritableJason Zaugg2014-02-101-13/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out `findMembers` has been a bit sloppy in recent years and has returned private members from *anywhere* up the base class sequence. Access checks usually pick up the slack and eliminate the unwanted privates. But, in concert with the "concrete beats abstract" rule in `findMember`, the following mishap appeared: scala> :paste // Entering paste mode (ctrl-D to finish) trait T { def a: Int } trait B { private def a: Int = 0 } trait C extends T with B { a } // Exiting paste mode, now interpreting. <console>:9: error: method a in trait B cannot be accessed in C trait C extends T with B { a } ^ I noticed this when compiling Akka against JDK 8; a new private method in the bowels of the JDK was enough to break the build! It turns out that some finesse in needed to interpret SLS 5.2: > The private modifier can be used with any definition or declaration > in a template. They are not inherited by subclasses [...] So, can we simply exclude privates from all but the first base class? No, as that might be a refinement class! The following must be allowed: trait A { private def foo = 0; trait T { self: A => this.foo } } This commit: - tracks when the walk up the base class sequence passes the first non-refinement class, and excludes private members - ... except, if we are at a direct parent of a refinement class itself - Makes a corresponding change to OverridingPairs, to only consider private members if they are owned by the `base` Symbol under consideration. We don't need to deal with the subtleties of refinements there as that code is only used for bona-fide classes. - replaces use of `hasTransOwner` when considering whether a private[this] symbol is a member. The last condition was not grounded in the spec at all. The change is visible in cases like: // Old scala> trait A { private[this] val x = 0; class B extends A { this.x } } <console>:7: error: value x in trait A cannot be accessed in A.this.B trait A { private[this] val x = 0; class B extends A { this.x } } ^ // New scala> trait A { private[this] val x = 0; class B extends A { this.x } } <console>:8: error: value x is not a member of A.this.B trait A { private[this] val x = 0; class B extends A { this.x } } ^ Furthermore, we no longer give a `private[this]` member a free pass if it is sourced from the very first base class. trait Cake extends Slice { private[this] val bippy = () } trait Slice { self: Cake => bippy // BCS: Cake, Slice, AnyRef, Any } The different handling between `private` and `private[this]` still seems a bit dubious. The spec says: > An different form of qualification is private[this]. A member M > marked with this modifier can be accessed only from within the > object in which it is defined. That is, a selection p.M is only > legal if the prefix is this or O.this, for some class O enclosing > the reference. In addition, the restrictions for unqualified > private apply. This sounds like a question of access, not membership. If so, we should admit `private[this]` members from parents of refined types in `FindMember`. AFAICT, not too much rests on the distinction: do we get a "no such member", or "member foo inaccessible" error? I welcome scrutinee of the checkfile of `neg/t7475f.scala` to help put this last piece into the puzzle. One more thing: findMember does not have *any* code the corresponds to the last sentence of: > SLS 5.2 The modifier can be qualified with an identifier C > (e.g. private[C]) that must denote a class or package enclosing > the definition. Members labeled with such a modifier are accessible > respectively only from code inside the package C or only from code > inside the class C and its companion module (§5.4). > Such members are also inherited only from templates inside C. When I showed Martin this, he suggested it was an error in the spec, and we should leave the access checking to callers of that inherited qualified-private member.
* SI-7475 findMember and findMembers: estranged no moreJason Zaugg2014-02-101-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Swathes of important logic are duplicated between `findMember` and `findMembers` after they separated on grounds of irreconcilable differences about how fast they should run: d905558 Variation #10 to optimze findMember fcb0c01 Attempt #9 to opimize findMember. 71d2ceb Attempt #8 to opimize findMember. 77e5692 Attempty #7 to optimize findMember 275115e Fixing problem that caused fingerprints to fail in e94252e Attemmpt #6 to optimize findMember 73e61b8 Attempt #5 to optimize findMember. 04f0b65 Attempt #4 to optimize findMember 0e3c70f Attempt #3 to optimize findMember 41f4497 Attempt #2 to optimize findMember 1a73aa0 Attempt #1 to optimize findMember This didn't actually bear fruit, and the intervening years have seen the implementations drift. Now is the time to reunite them under the banner of `FindMemberBase`. Each has a separate subclass to customise the behaviour. This is primarily used by `findMember` to cache member types and to assemble the resulting list of symbols in an low-allocation manner. While there I have introduced some polymorphic calls, the call sites are only bi-morphic, and our typical pattern of compilation involves far more `findMember` calls, so I expect that JIT will keep the virtual call cost to an absolute minimum. Test results have been updated now that `findMembers` correctly excludes constructors and doesn't inherit privates. Coming up next: we can actually fix SI-7475!
* SI-7475 Refactor findMember computation into a classJason Zaugg2014-02-101-0/+223
| | | | | | | | | | | | | | | | | | | This affords us: - a better chance to share code with `findMembers` again - the ability to break up the logic into smaller methods for scrutability and JIT-tability. The cost is the use of the heap rather than the stack for the working area of the computation. But I didn't notice a difference between `locker.lib` and `quick.lib` after this change. I've left the old implementation in place with an assertion to verify identical results. In the next commit, this stepping stone will be removed, and we'll update `findMembers` to share the code. Some problem areas have been highlighted and will be addressed after the refactoring phase is complete.
* SI-8237 Avoid cyclic constraints when inferring hk type argsJason Zaugg2014-02-091-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An `AppliedTypeVars` spawned from `HKTypeVar#applyArgs` (necessarily) shares the same `TypeConstraints`. But, we can have multiple ATVs based on a single HKTV floating around during inference, and they can appear on both sides of type relations. An example of this is traced out in the enclosed test. This commit avoids registering upper/lower bound constraints when this is detected. In the enclosed test, we end up with an empty set of constraints for `?E`, which results in inference of Nothing, which is what we expect. I have also improved the printing of ATVs (to include the args) and sharpened the log message when `solve` leaves type variables instantiated to `NoType`, rather than some other type that doesn't conform to the bounds. Both of these changes helped me to get to the bottom of this ticket. The improved `ATV#toString` shows up in some updated checkfiles. The reported test has quite a checkered history: - in 2.10.0 it worked, but more by good luck than good planning - after the fix for SI-7226 / 221f52757aa6, it started crashing - from 3bd897ba0054f (a merge from 2.10.x just before 2.11.0-M1) we started getting a type inference failure, rather than a crash. "no type parameters for method exists [...] because cyclic instantiation". - It still crashes in `isGround` in 2.10.3.
* Optimization in InstantiateDependentMapJason Zaugg2014-02-011-1/+1
| | | | Avoid creating a throwaway array in existentialsNeeded.
* SI-2066 -Xsource:2.10: lenient treatment of variance in <:<, =:=Jason Zaugg2014-01-241-2/+2
| | | | | | | | | The soundness hole was exploited in Scalaz. They have fixed their codebase correctly for Scalac 7.1.x, but have less freedom to break source compatiblity in 7.0.x. After this commit, they could choose to compile that branch with -Xsource:2.10
* Merge pull request #3368 from retronym/ticket/8151Grzegorz Kossakowski2014-01-213-8/+8
|\ | | | | SI-8151 Remove -Yself-in-annots and associated implementation
| * SI-8151 Remove -Yself-in-annots and associated implementationJason Zaugg2014-01-153-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This experimental option typechecked arguments of annotations with an injected value in scope named `self`: @Foo(self.foo < 1) This has been slated for removal [1] for some time. This commit removes it in one fell swoop, without any attempt at source compatibility with code that constructs or pattern matches on AnnotatedType. [1] https://groups.google.com/d/msg/scala-internals/VdZ5UJwQFGI/C6tZ493Yxx4J
* | temporarily disables the toStringSubjects cacheEugene Burmako2014-01-201-7/+12
| |
* | capitalizes “s” in tostringEugene Burmako2014-01-201-12/+12
| | | | | | | | | | As suggested by the reviewers, tostringXXX variables in TypeToStrings.scala have been renamed to toStringXXX.
* | introduces failsafe against endless type printingEugene Burmako2014-01-201-1/+12
| | | | | | | | | | | | | | | | | | | | The parent commit works around a particular problem that led to a compiler freeze in SI-8158, whereas this commit introduces a general solution - a cache that tracks all types that we've recursed into during printing. I can't immediately come up with an example of a type that would be caught by this safety net, but unknown unknowns are the worst of them all, so why not guard against them while we can.
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-02 10:24:07 +0000