summaryrefslogtreecommitdiff
path: root/test/pending
Commit message (Collapse)AuthorAgeFilesLines
* unset inappropriate execute bitsSeth Tisue2015-09-021-0/+0
| | | | | | | | | | I imagine these date back to old Subversion days and are probably the result of inadvertent commits from Windows users with vcs client configs. having the bit set isn't really harmful most of the time, but it's just not right, and it makes the files stand out in directory listings for no reason
* Fix some typos (a-c)Janek Bogucki2015-06-182-2/+2
|
* 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-8359 Adjust parameter order of accessor method in DelambdafyJason Zaugg2015-03-241-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under `-Ydelambdafy:method`, a public, static accessor method is created to expose the private method containing the body of the lambda. Currently this accessor method has its parameters in the same order structure as those of the lambda body method. What is this order? There are three categories of parameters: 1. lambda parameters 2. captured parameters (added by lambdalift) 3. self parameters (added to lambda bodies that end up in trait impl classes by mixin, and added unconditionally to the static accessor method.) These are currently emitted in order #3, #1, #2. Here are examples of the current behaviour: BEFORE (trait): ``` % cat sandbox/test.scala && scalac-hash v2.11.5 -Ydelambdafy:method sandbox/test.scala && javap -private -classpath . 'Test$class' trait Member; class Capture; trait LambdaParam trait Test { def member: Member def foo { val local = new Capture (arg: LambdaParam) => "" + arg + member + local } } Compiled from "test.scala" public abstract class Test$class { public static void foo(Test); private static final java.lang.String $anonfun$1(Test, LambdaParam, Capture); public static void $init$(Test); public static final java.lang.String accessor$1(Test, LambdaParam, Capture); } ``` BEFORE (class): ``` % cat sandbox/test.scala && scalac-hash v2.11.5 -Ydelambdafy:method sandbox/test.scala && javap -private -classpath . Test trait Member; class Capture; trait LambdaParam abstract class Test { def member: Member def foo { val local = new Capture (arg: LambdaParam) => "" + arg + member + local } } Compiled from "test.scala" public abstract class Test { public abstract Member member(); public void foo(); private final java.lang.String $anonfun$1(LambdaParam, Capture); public Test(); public static final java.lang.String accessor$1(Test, LambdaParam, Capture); } ``` Contrasting the class case with Java: ``` % cat sandbox/Test.java && javac -d . sandbox/Test.java && javap -private -classpath . Test public abstract class Test { public static class Member {}; public static class Capture {}; public static class LambaParam {}; public static interface I { public abstract Object c(LambaParam arg); } public abstract Member member(); public void test() { Capture local = new Capture(); I i1 = (LambaParam arg) -> "" + member() + local; } } Compiled from "Test.java" public abstract class Test { public Test(); public abstract Test$Member member(); public void test(); private java.lang.Object lambda$test$0(Test$Capture, Test$LambaParam); } ``` We can see that in Java 8 lambda parameters come after captures. If we want to use Java's LambdaMetafactory to spin up our anoymous FunctionN subclasses on the fly, our ordering must change. I can see three options for change: 1. Adjust `LambdaLift` to always prepend captured parameters, rather than appending them. I think we could leave `Mixin` as it is, it already prepends the self parameter. This would result a parameter ordering, in terms of the list above: #3, #2, #1. 2. More conservatively, do this just for methods known to hold lambda bodies. This might avoid needlessly breaking code that has come to depend on our binary encoding. 3. Adjust the parameters of the accessor method only. The body of this method can permute params before calling the lambda body method. This commit implements option #2. In also prototyped #1, and found it worked so long as I limited it to non-constructors, to sidestep the need to make corresponding changes elsewhere in the compiler to avoid the crasher shown in the enclosed test case, which was minimized from a bootstrap failure from an earlier a version of this patch. We would need to defer option #1 to 2.12 in any case, as some of these lifted methods are publicied by the optimizer, and we must leave the signatures alone to comply with MiMa. I've included a test that shows this in all in action. However, that is currently disabled, as we don't have a partest category for tests that require Java 8.
* 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 #4044 from retronym/ticket/5091Lukas Rytz2014-11-051-11/+0
|\ | | | | SI-5091 Move named-args cycle test from pending to neg
| * SI-5091 Move named-args cycle test from pending to negJason Zaugg2014-10-101-11/+0
| | | | | | | | | | | | | | | | | | There is a typechecking cycle, and since 4669ac180e5 we now report this in a clearer manner. Once we change the language to unconditionally interpret an assignent in argument position as a named argument would be the only way to get this over to `pos`.
* | SI-3439 Fix use of implicit constructor params in super callJason Zaugg2014-10-101-2/+0
|/ | | | | | | | | | | | | | | | | | | | | | | | | When typechecking the primary constructor body, the symbols of constructor parameters of a class are owned by the class's owner. This is done make scoping work; you shouldn't be able to refer to class members in that position. However, other parts of the compiler weren't so happy about this arrangement. The enclosed test case shows that our checks for invalid, top-level implicits was spuriously triggered, and implicit search itself would fail. Furthermore, we had to hack `Run#compiles` to special case top-level early-initialized symbols. See SI-7264 / 86e6e9290. This commit: - introduces an intermediate local dummy term symbol which will act as the owner for constructor parameters and early initialized members - adds this to the `Run#symSource` map if it is top level - simplifies `Run#compiles` accordingly - tests this all in a top-level class, and one nested in another class.
* SI-8582 emit InnerClasses attribute in GenBCodeLukas Rytz2014-05-133-19/+0
| | | | | | | | | | | | | | | | | | | | | I removed the `-bcode` test since we have a build that passes `-Ybackend:GenBCode` to all tests. Short intro do the [`InnerClass` attribute][1]: - A class needs one `InnerClass` attribute for each of its nested classes - A class needs the `InnerClass` attribute for all (nested) classes that are mentioned in its constant pool The attribute for a nested class `A$B$C` consists of the long name of the outer class `A$B`, the short name of the inner class `C`, and an access flag set describig the visibility. The attribute seems to be used for reflection. [1]: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7.6
* SI-8582 Pending test for InnerClasses bug in GenBCodeJason Zaugg2014-05-123-0/+19
| | | | | As seen in a runtime reflection failure in Slick during a GenBCode enabled run of our beloved Community Build.
* SI-8363 Disable -Ydelambdafy:method in constructor positionJason Zaugg2014-03-101-0/+7
| | | | | | | | | | | | | | As @magarciaEPFL has done in his experimental optimizer [1], we can avoid running into limitations of lambdalift (either `VerifyError`s, ala SI-6666, or compiler crashes, such as this bug), by using the old style of "inline" lambda translation when in a super- or self- construtor call. We might be able to get these working later on, but for now we shouldn't block adoption of `-Ydelamndafy:method` for this corner case. [1] https://github.com/magarciaEPFL/scala/blob/GenRefactored99sZ/src/compiler/scala/tools/nsc/transform/UnCurry.scala#L227
* SI-4728 test caseLukas Rytz2014-02-262-13/+0
|
* reverses SI-6484Eugene Burmako2014-02-184-0/+46
| | | | | Unfortunately I have to revert b017629 because of SI-8303. There are projects (e.g. slick) that use typeOf in annotations, which effectively means bye-bye.
* Revert "SI-5920 enables default and named args in macros"Jason Zaugg2014-02-176-0/+35
| | | | | | | | | | | | | | | | | This reverts commit a02e053a5dec134f7c7dc53a2c1091039218237d. That commit lead to an error compiling Specs2: [info] [warn] /localhome/jenkinsdbuild/workspace/Community-2.11.x-retronym/dbuild-0.7.1-M1/target-0.7.1-M1/project-builds/specs2-aaa8091b47a34817ca90134ace8b09a9e0f854e9/core/src/test/scala/org/specs2/text/EditDistanceSpec.scala:6: Unused import [info] [warn] import DiffShortener._ [info] [warn] ^ [info] [error] /localhome/jenkinsdbuild/workspace/Community-2.11.x-retronym/dbuild-0.7.1-M1/target-0.7.1-M1/project-builds/specs2-aaa8091b47a34817ca90134ace8b09a9e0f854e9/core/src/test/scala/org/specs2/text/LinesContentDifferenceSpec.scala:7: exception during macro expansion: [info] [error] java.lang.UnsupportedOperationException: Position.point on NoPosition [info] [error] at scala.reflect.internal.util.Position.fail(Position.scala:53) [info] [error] at scala.reflect.internal.util.UndefinedPosition.point(Position.scala:131) [info] [error] at scala.reflect.internal.util.UndefinedPosition.point(Position.scala:126) [info] [error] at org.specs2.reflect.Macros$.sourceOf(Macros.scala:25) [info] [error] at org.specs2.reflect.Macros$.stringExpr(Macros.scala:19)
* Merge pull request #3397 from xeno-by/ticket/5920Jason Zaugg2014-02-166-35/+0
|\ | | | | SI-5920 enables default and named args in macros
| * SI-5920 enables default and named args in macrosEugene Burmako2014-02-106-35/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When producing an initial spec for macros two years ago, we sort of glossed over named/default arguments in macro applications, leaving them for future work. Once the aforementioned future has come, I’ve made several attempts at making things operational (e.g. last summer), but it’s always been unclear how to marry the quite complex desugaring that tryNamesDefaults performs with the expectations of macro programmers to see unsugared trees in macro impl parameters. Here’s the list of problems that arise when trying to encode named/default arguments of macro applications: 1) When inside macro impls we don’t really care about synthetic vals that are typically introduced to preserve evaluation order in non-positional method applications. When we inline those synthetics, we lose information about evaluation order, which is something that we wouldn’t like to lose in the general case. 2) More importantly, it’s also not very exciting to see invocations of default getters that stand for unspecified default arguments. Ideally, we would like to provide macro programmers with right-hand sides of those default getters, but that is: a) impossible in the current implementation of default parameters, b) would anyway bring scoping problems that we’re not ready to deal with just yet. Being constantly unhappy with potential solutions to the aforementioned problems, I’ve been unable to nail this down until the last weekend, when I realized that: 1) even though we can’t express potential twists in evaluation order within linearly ordered macro impl params, we can use c.macroApplication to store all the named arguments we want, 2) even though we can’t get exactly what we want for default arguments, we can represent them with EmptyTree’s, which is not ideal, but pretty workable. That’s what has been put into life in this commit. As a pleasant side-effect, now the macro engine doesn’t have to reinvent the wheel wrt reporting errors about insufficient arg or arglist count. Since this logic is intertwined with the tryNamesDefaults desugaring, we previously couldn’t make use of it and had to roll our own logic that checked that the number of arguments and parameters of macro applications correspond to each other. Now it’s all deduplicated and consistent.
* | SI-5900 Fix pattern inference regressionJason Zaugg2014-02-122-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit does not close SI-5900. It only addresses a regression in 2.11 prereleases caused by SI-7886. The fix for SI-7886 was incomplete (as shown by the last commit) and incorrect (as shown by the regression in pos/t5900a.scala and the fact it ended up inferring type parameters.) I believe that the key to fixing this problem will be unifying the inference of case class constructor patterns and extractor patterns. I've explored that idea: https://gist.github.com/retronym/7704153 https://github.com/retronym/scala/compare/ticket/5900 But didn't quite get there.
* | SI-5900 Pending test to show that SI-7886 persistsJason Zaugg2014-02-121-0/+23
| | | | | | | | | | | | | | qbin/scalac test/pending/neg/t7886b.scala && qbin/scala Test java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String at Test$$anon$1.accept(t7886b.scala:15) at Test$.g(t7886b.scala:9)
* | Revert "SI-1786 incorporate defined bounds in inference"Adriaan Moors2014-02-112-0/+75
|/ | | | | | | | | | | | | | | | Have to revert because the stricter bounds that it inferred break e.g., slick. (Backstop for that added as pos/t1786-counter.scala, as minimized by Jason) Worse, the fix was compilation order-dependent. There's a less invasive fix (SI-6169) that could be generalized in `sharpenQuantifierBounds` (used in `skolemizeExistential`), but I'd rather not mess with existentials at this point. This reverts commit e28c3edda4dd405ed382227d2a688b799bf33c72. Conflicts: src/compiler/scala/tools/nsc/typechecker/Typers.scala test/files/pos/t1786.scala
* Merge pull request #3485 from xeno-by/topic/reset-all-attrsJason Zaugg2014-02-091-1/+1
|\ | | | | kills resetAllAttrs
| * further limits discoverability of resetAttrsEugene Burmako2014-02-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit removes resetAllAttrs from the public reflection API. This method was previously deprecated, but on a second thought that doesn't do it justice. People should be aware that resetAllAttrs is just wrong, and if they have code that uses it, this code should be rewritten immediately without beating around the bush with deprecations. There's a source-compatible way of achieving that (resetLocalAttrs), so that shouldn't bring much trouble. Secondly, resetAllAttrs in compiler internals becomes deprecated. In subsequent commits I'm going to rewrite the only two locations in the compiler that uses it, and then I think we can remove it from the compiler as well.
* | SI-8131 fixes residual race condition in runtime reflectionEugene Burmako2014-01-211-32/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently some completers can call setInfo while they’re not yet done, which resets the LOCKED flag, and makes anything that uses LOCKED to track completion unreliable. Unfortunately, that’s exactly the mechanism that was used by runtime reflection to elide locking for symbols that are known to be initialized. This commit fixes the problematic lock elision strategy by introducing an explicit communication channel between SynchronizedSymbol’s and their completers. Now instead of trying hard to infer whether it’s already initialized or not, every symbol gets a volatile field that can be queried to provide necessary information.
* | removes non-determinism in reflection-sync-potpourriEugene Burmako2014-01-211-1/+1
|/ | | | | | | | Depending on the environment in which the test is run, s1 can be either “String” or “java.lang.String”. This is one of the known non-deterministic behaviors of our reflection, caused by prefix stripping only working for packages defined in the root mirror. Until we fix this, I suggest we make the test more lenient.
* Merge pull request #3355 from xeno-by/topic/saturday-nightJason Zaugg2014-01-1415-27/+27
|\ | | | | reshuffles names for blackbox/whitebox contexts, changes bundle notation
| * *boxContext => *box.Context , *boxMacro => *box.MacroEugene Burmako2014-01-1215-27/+27
| | | | | | | | | | | | | | | | | | | | 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-131-0/+18
|\ \ | | | | | | Improves name-based patmat.
| * | SI-8128 Fix regression in extractors returning existentialsJason Zaugg2014-01-091-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #3242 from retronym/ticket/8046Adriaan Moors2014-01-131-0/+22
|\ \ \ | | | | | | | | SI-8046 BaseTypeSeq fixes with aliases
| * | | SI-8046 Only use fast TypeRef#baseTypeSeq with concrete base typesJason Zaugg2013-12-101-19/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-091-0/+19
| | | |
* | | | Merge pull request #3184 from retronym/ticket/2066Adriaan Moors2014-01-131-16/+0
|\ \ \ \ | | | | | | | | | | SI-2066 Plug a soundness hole higher order type params, overriding
| * | | | SI-2066 Plug a soundness hole higher order type params, overridingJason Zaugg2013-11-271-16/+0
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #3350 from retronym/ticket/8131Jason Zaugg2014-01-101-0/+32
|\ \ \ \ | | | | | | | | | | 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/+32
| | |_|/ | |/| | | | | | | | | | | | | | Examples noted in SI-8131 show that race conditions still abound. This has been noted twice during pull request validation.
* / | | SI-8135 Disabled flaky hyperlinking presentation compiler testMirco Dotta2014-01-103-0/+67
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #3254 from xeno-by/topic/typeCheckJason Zaugg2014-01-032-2/+2
|\ \ \ | |_|/ |/| | typeCheck => typecheck
| * | typeCheck => typecheckEugene Burmako2013-12-102-2/+2
| |/ | | | | | | | | This method has always been slightly bothering me, so I was really glad when Denys asked me to rename it. Let’s see how it pans out.
* / Modularize continuations plugin.Adriaan Moors2013-12-1314-209/+0
|/ | | | | The continuations plugin and library will still ship with 2.11 (albeit unsupported). They now reside at https://github.com/scala/scala-continuations.
* deprecate Pair and TripleDen Shabalin2013-11-205-72/+72
|
* Merge pull request #3082 from retronym/ticket/6385Grzegorz Kossakowski2013-10-291-0/+17
|\ | | | | SI-6385 Avoid bridges to identical signatures over value classes
| * SI-6385 Avoid bridges to identical signatures over value classesJason Zaugg2013-10-281-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As Paul noted in the comments to SI-6260 (from which I mined some test cases) "there is no possible basis for conflict here": scala> class C[A](val a: Any) extends AnyVal defined class C scala> class B { def x[A](ca: C[A]) = () } defined class B scala> class D extends B { override def x[A](ca: C[A]) = () } <console>:8: error: bridge generated for member method x: [A](ca: C[A])Unit in class D which overrides method x: [A](ca: C[A])Unit in class B clashes with definition of the member itself; both have erased type (ca: Object)Unit class D extends B { override def x[A](ca: C[A]) = () } ^ What was happening? Bridge computation compares `B#x` and `D#x` exitingErasure, which results in comparing: ErasedValueType(C[A(in B#x)]) =:= ErasedValueType(C[A(in D#x)]) These types were considered distinct (on the grounds of the unique type hash consing), even though they have the same erasure and involve the same value class. That triggered creation of an bridge. After post-erasure eliminates the `ErasedValuedType`s, we find that this marvel of enginineering is bridges `(Object)Unit` right back onto itself. The previous resolution of SI-6385 (d435f72e5fb7fe) was a test case that confirmed that we detected the zero-length bridge and reported it nicely, which happened after related work in SI-6260. But we can simply avoid creating in it in the first place. That's what this commit does. It does so by reducing the amount of information carried in `ErasedValueType` to the bare minimum needed during the erasure -> posterasure transition. We need to know: 1. which value class wraps the value, so we can box and unbox as needed 2. the erasure of the underlying value, which will replace this type in post-erasure. This construction means that the bridge above computation now compares: ErasedValueType(C, Any) =:= ErasedValueType(C, Any]) I have included a test to show that: - we don't incur any linkage or other runtime errors in the reported case (run/t6385.scala) - a similar case compiles when the signatures align (pos/t6260a.scala), but does *not* compile when the just erasures align (neg/t6260c.scala) - polymorphic value classes continue to erase to the instantiated type of the unbox: (run/t6260b.scala) - other cases in SI-6260 remains unsolved and indeed unsolvable without an overhaul of value classes: (neg/t6260b.scala) In my travels I spotted a bug in corner case of null, asInstanceOf and value classes, which I have described in a pending test.
* | Remove empty check files and flags files.Jason Zaugg2013-10-272-0/+0
|/ | | | for f in $(find test -name '*.check' -o -name '*.flags'); do [[ $(wc -c $f | sed -E 's/ *([0-9]+).*/\1/') == "0" ]] && rm $f; done
* SI-6680 unsoundness in gadt typing.Paul Phillips2013-10-014-46/+0
| | | | | | | Introduces -Xstrict-inference to deal with the significant gap between soundness and what presently compiles. I'm hopeful that it's TOO strict, because it finds e.g. 75 errors compiling immutable/IntMap.scala, but it might be that bad.
* SI-7629 Deprecate view boundsSimon Ochsenreither2013-09-253-0/+14
| | | | | | This introduces a warning(/error with -Xfuture) with a general migration advice. The IDE can use the warning to offer a quick fix with the specific refactoring necessary.
* Merge pull request #2859 from som-snytt/issue/7622-phaserGrzegorz Kossakowski2013-09-124-53/+0
|\ | | | | SI-7622 Clean Up Phase Assembly
| * SI-7622 Clean Up Phase AssemblySom Snytt2013-08-214-53/+0
| | | | | | | | | | | | | | | | Let optimiser components and continuations plugin opt-out when required flags are not set. Wasted time on a whitespace error in check file, so let --debug dump the processed check file and its diff.
* | Merge pull request #2930 from retronym/topic/patmat-inference-prepJason Zaugg2013-09-112-0/+10
|\ \ | | | | | | Topic/patmat inference prep
| * | Removing orphan check/flag files.Paul Phillips2013-08-292-0/+10
| |/
* | Noise reduction + minor enhance in TreeCheckers.Paul Phillips2013-09-097-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Misc irrelevant work, which I can only offer as-is. It lowers the noise in -Ycheck:* output and performs some common sense chillaxes like not screaming ERROR IN INTERNAL CHECKING! WE'RE ALL GOING TO DIE! when a tree doesn't hit all nine points at the Jiffy Tree. You can see some reasonably well reduced symbol flailing if you run the included pending tests: test/partest --show-diff test/pending/pos/treecheckers Example output, Out of scope symbol reference { tree TypeTree Factory[Traversable] position OffsetPosition test/pending/pos/treecheckers/c5.scala:3 with sym ClassSymbol Factory: Factory[CC] and tpe ClassArgsTypeRef Factory[Traversable] encl(1) ModuleSymbol object Test5 ref to AbstractTypeSymbol X (<deferred> <param>) }
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-30 09:54:45 +0000