summaryrefslogtreecommitdiff
path: root/test/files/neg
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #1507 from retronym/ticket/6526Josh Suereth2012-10-242-0/+57
|\ | | | | SI-6526 Tail call elimination should descend deeper.
| * SI-6526 Additional test case.Jason Zaugg2012-10-222-1/+9
| |
| * SI-6526 Tail call elimination should descend deeper.Jason Zaugg2012-10-172-0/+49
| | | | | | | | | | It wasn't traversing into Select nodes nor into the receiver of a tail call.
* | Fix for SI-6537, inaccurate unchecked warning.Paul Phillips2012-10-182-3/+8
|/ | | | | | | | I found a more direct expression of the unchecked logic, which should be much easier for others to verify. But the bug being fixed here is that the unchecked checking happens too early, and the sealed children of a symbol are not yet visible if it is being simultaneously compiled.
* SI-6483 Prohibit super[T] references in value classes.Jason Zaugg2012-10-072-0/+33
| | | | This seems the safest course of action for 2.10.0.
* Merge pull request #1455 from scalamacros/topic/manifestsJosh Suereth2012-10-052-38/+2
|\ | | | | undeprecates manifests for 2.10.0
| * undeprecates manifests for 2.10.0Eugene Burmako2012-10-032-38/+2
| | | | | | | | | | | | | | | | Since scala-reflect.jar is going to be declared experimental for 2.10.0, it doesn't make sense to deprecate manifests in favor of type tags. Class manifests, however, ARE deprecated for class tags, because class tags don't require scala-reflect.jar and are generated independently of type tags.
* | Merge pull request #1451 from gkossakowski/SI-6451Grzegorz Kossakowski2012-10-042-64/+64
|\ \ | |/ |/| SI-6451: Rename classes in `unchecked-abstract.scala` test.
| * SI-6451: Rename classes in `unchecked-abstract.scala` test.Grzegorz Kossakowski2012-10-032-64/+64
| | | | | | | | | | | | | | | | | | | | As reported Miguel, `Con` is problematic name of a class on Windows and makes this test to fail. Renamed classes to something else which hopefully make Windows build happy again. Closes SI-6451. Review by @magarciaEPFL or @paulp.
* | Merge pull request #1443 from gkossakowski/anyval-restrictionsGrzegorz Kossakowski2012-10-038-21/+67
|\ \ | | | | | | AnyVal/value classes restrictions
| * | Put more implementation restrictions on value classes.Grzegorz Kossakowski2012-10-034-4/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Nested objects, classes and lazy vals are disallowed at any nesting level in value classes; e.g. lazy vals local to a method defined in a value class. There are still allowed in universal traits. This is a temporary, implementation restriction that is planned to be addressed in future releases of Scala. Error messages has been updated to communicate that intent. Moved tests for SI-5582 and SI-6408 to pending folder. They have to stay there until implementation restrictions are addressed. Closes SI-6408 and SI-6432. Review by @odersky, @harrah and @adriaanm.
| * | Revised restrictions for value classes and unversal traitsMartin Odersky2012-10-035-19/+12
| |/ | | | | | | | | | | | | | | | | and brought compiler in line with them. One thing we can accept IMO are nested classes (nested objects are still a problem). In fact, it makes no sense to exclude nested classes from value classes but not from universal traits. A class nested in universal trait will becomes a class nested in a value class by inheritance. Note that the reflection library already contains a universal trait with a nested class (IndexedSeqLike), so we should accept them if we can.
* | Merge pull request #1446 from retronym/ticket/6436-2Grzegorz Kossakowski2012-10-034-0/+38
|\ \ | |/ |/| SI-6436 Handle ambiguous string processors
| * SI-6436 Handle ambiguous string processorsJason Zaugg2012-10-024-0/+38
| | | | | | | | | | | | | | | | Before, we got in an inifinite loop by chasing the error typed result of adaptToMemberWithArgs. One point of befuddlement remains: why did t6436 and t6436b behave differently before this change?
* | Revert "SI-4881 infer variance from formals, then result"Paul Phillips2012-09-291-1/+4
|/ | | | This reverts commit 5c5e8d4dcd151a6e2bf9e7c259c618b9b4eff00f.
* Added logic and tests for unchecked refinements.Paul Phillips2012-09-273-0/+41
|
* Nailed down the "impossible match" logic.Paul Phillips2012-09-2712-6/+185
| | | | | | | | | | | | | | | | | | I will again defer to a comment. /** Given classes A and B, can it be shown that nothing which is * an A will ever be a subclass of something which is a B? This * entails not only showing that !(A isSubClass B) but that the * same is true of all their subclasses. Restated for symmetry: * the same value cannot be a member of both A and B. * * 1) A must not be a subclass of B, nor B of A (the trivial check) * 2) One of A or B must be completely knowable (see isKnowable) * 3) Assuming A is knowable, the proposition is true if * !(A' isSubClass B) for all A', where A' is a subclass of A. * * Due to symmetry, the last condition applies as well in reverse. */
* Restored warning for impossible type tests.Paul Phillips2012-09-261-6/+6
| | | | | | | | | | | I had this in before, then removed it since it is sometimes redundant with an error message later issued by the pattern matcher (e.g. scrutinee is incompatible with pattern type.) However it also catches a lot of cases which are not errors, so I think the modest redundancy is tolerable for now. I also enhanced the logic for recognizing impossible type tests, taking sealedness into account.
* Yet more tests for unchecked warnings.Paul Phillips2012-09-262-1/+75
|
* Additional new tests for unchecked warnings.Paul Phillips2012-09-256-0/+85
|
* Improvements to unchecked warnings.Paul Phillips2012-09-255-28/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Closes SI-6275, SI-5762. The comment says is better than I can. /** On pattern matcher checkability: * * Consider a pattern match of this form: (x: X) match { case _: P => } * * There are four possibilities to consider: * [P1] X will always conform to P * [P2] x will never conform to P * [P3] X <: P if some runtime test is true * [P4] X cannot be checked against P * * The first two cases correspond to those when there is enough static * information to say X <: P or that !(X <: P) for all X and P. * The fourth case includes unknown abstract types or structural * refinements appearing within a pattern. * * The third case is the interesting one. We designate another type, XR, * which is essentially the intersection of X and |P|, where |P| is * the erasure of P. If XR <: P, then no warning is emitted. * * Examples of how this info is put to use: * sealed trait A[T] ; class B[T] extends A[T] * def f(x: B[Int]) = x match { case _: A[Int] if true => } * def g(x: A[Int]) = x match { case _: B[Int] => } * * `f` requires no warning because X=B[Int], P=A[Int], and B[Int] <:< A[Int]. * `g` requires no warning because X=A[Int], P=B[Int], XR=B[Int], and B[Int] <:< B[Int]. * XR=B[Int] because a value of type A[Int] which is tested to be a B can * only be a B[Int], due to the definition of B (B[T] extends A[T].) * * This is something like asSeenFrom, only rather than asking what a type looks * like from the point of view of one of its base classes, we ask what it looks * like from the point of view of one of its subclasses. */
* Merge remote-tracking branch 'paulp/topic/gitattributes' into 2.10.xPaul Phillips2012-09-2073-605/+605
|\
| * Normalized line endings.Paul Phillips2012-09-2073-605/+605
| | | | | | | | | | | | This brings all the files into line with the .gitattributes settings, which should henceforth be automatically maintained by git.
* | Merge pull request #1325 from odersky/ticket/6337Paul Phillips2012-09-203-8/+36
|\ \ | | | | | | Fixes SI-6337 by disallowing nested value classes.
| * | Fixes SI-6337 by disallowing nested value classes.Martin Odersky2012-09-173-8/+36
| | | | | | | | | | | | It seems for the moment too hard to allow this, and the functionality to have value classes wrap other value classes does not seem essential.
* | | Merge pull request #1356 from paulp/pullreq-1342Josh Suereth2012-09-205-13/+17
|\ \ \ | | | | | | | | Pullreq 1342
| * | | Error message improvement for SI-6336.Paul Phillips2012-09-194-13/+13
| | | | | | | | | | | | | | | | | | | | Position error messages about structural type members at the problematic parameter or type.
| * | | SI-6336 Now also catches return typesMartin Odersky2012-09-182-1/+5
| | | | | | | | | | | | | | | | | | | | As Mark's comments on SI-6336 shows, we also need to disallow value classes as return types of structural types.
* | | | Merge pull request #1339 from rkuhn/wip-6389-finite-duration-multJosh Suereth2012-09-202-7/+7
|\ \ \ \ | |_|_|/ |/| | | enable integer multiplication/divison on FiniteDuration, see SI-6389
| * | | move Duration (incl. DSL) into scala.concurrent.duration packageRoland2012-09-192-7/+7
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | so that the full package can be imported naturally: import scala.concurrent.duration._ will give you all the types (Duration, FiniteDuration, Deadline) and the DSL for constructing these.
* | | New test case for closing SI-6385Martin Odersky2012-09-202-0/+20
| | | | | | | | | | | | | | | The fixes for SI-6260 + elimination of hlaf-boxing also solve SI-6385
* | | Value classes: eliminated half-boxingMartin Odersky2012-09-202-0/+30
| | | | | | | | | | | | | | | | | | | | | We now apply erasure of value classes everywhere. previously, erasure was disabled in the value class itself. This led to irregegularities and bugs. See test run/valueclasses-pavlov.scala for something that led to a ClassCastException before.
* | | Fixes SI-6260Martin Odersky2012-09-202-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | Guards against bridge methods that clash with other methods. Two tests: The neg test is the original ticket. The run test tweaks things slightly so that the generated bridge method does not clash, and tests that the necessary unboxings are indeed performed at runtime.
* | | Merge pull request #1354 from scalamacros/ticket/6363Eugene Burmako2012-09-192-3/+4
|\ \ \ | | | | | | | | merges scala.reflect.base into scala.reflect.api
| * | | SI-6363 removes scala.reflect.baseEugene Burmako2012-09-192-3/+4
| | | | | | | | | | | | | | | | | | | | As the experience has shown, there's no need for a separate layer of reflection in scala-library.jar. Therefore I'm putting an end to it.
* | | | Fixes SI-6354: improved error messages for Dynamic signature mismatches.amin2012-09-193-2/+74
|/ / / | | | | | | | | | | | | | | | If an error occurs afer a Dynamic rewriting, augment the error message with the rewritten tree and a hint to check the Dynamic method signature.
* | | Merge pull request #1340 from gkossakowski/revert-static-annotationGrzegorz Kossakowski2012-09-185-104/+0
|\ \ \ | |_|/ |/| | Revert `@static` annotation
| * | Revert "Implement @static annotation on singleton object fields."Grzegorz Kossakowski2012-09-172-43/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 892ee3df93a10ffe24fb11b37ad7c3a9cb93d5de with exception of keeping `@static` annotation in the library so we can deploy a new starr that does not depend on it before removing it completely. Conflicts: src/compiler/scala/tools/nsc/backend/icode/GenICode.scala src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala src/compiler/scala/tools/nsc/transform/CleanUp.scala
| * | Revert "WIP add private/lazy checks and a few tests."Grzegorz Kossakowski2012-09-172-24/+1
| | | | | | | | | | | | This reverts commit 227239018b38ab7218ee6b30493c9c8e1836c8c9.
| * | Revert "Fixes SI-6189."Grzegorz Kossakowski2012-09-171-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 5a8dfad583b825158cf0abdae5d73a4a7f8cd997. Conflicts: src/compiler/scala/tools/nsc/backend/icode/GenICode.scala
| * | Revert "Fix SI-4581."Grzegorz Kossakowski2012-09-174-33/+1
| |/ | | | | | | This reverts commit 373f22a2022519ab894c1ea77460e6460d7c2ee4.
* / SI-5692 better error messageEugene Burmako2012-09-188-0/+28
|/ | | | | | Doesn't fix the underlying issue with macros and type inference, but at least now the error message says exactly what needs to be done to make the error go away.
* SI-6336 Disallows value types in structuralal refinementsMartin Odersky2012-09-162-0/+15
| | | | | Structural refinements already have a number of restrictions, e.g. cannot refer to type parameters of enclosing classes. We need to disallow value classes as well.
* Merge pull request #1302 from scalamacros/topic/reflectionEugene Burmako2012-09-146-6/+6
|\ | | | | cleaning up reflection
| * SI-6342 cleans up toolbox APIEugene Burmako2012-09-156-6/+6
| | | | | | | | | | | | 1) parseExpr => parse 2) runExpr => eval 3) Introduces compile(Tree): () => Any, since it has frequent uses
* | Merge pull request #1290 from retronym/ticket/no-implicit-to-anyrefPaul Phillips2012-09-142-0/+57
|\ \ | | | | | | A little cleanup along the Any to AnyRef trail.
| * | A little cleanup along the Any to AnyRef trail.Jason Zaugg2012-09-112-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | Followup to 35316be and d3f879a. - Remove obsolete comments and replace them with a test. - Don't emit error addendum unless we know we're dealing with a value class.
* | | Merge pull request #1299 from namin/si-6245Paul Phillips2012-09-146-0/+60
|\ \ \ | |_|/ |/| | Fix for SI-6245 with workaround for SI-2296.
| * | Fix for SI-6245 with workaround for SI-2296.amin2012-09-136-0/+60
| | | | | | | | | | | | | | | | | | | | | protected/super accessor issue: Don't subvert the creation of the standard protected accessor with the java interop accessor. For SI-2296, the compiler emits an error instead of causing an illegal access error at runtime.
* | | Eliminate breaking relative names in source.Paul Phillips2012-09-143-35/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These things are killing me. Constructions like package scala.foo.bar.baz import foo.Other DO NOT WORK in general. Such files are not really in the "scala" package, because it is not declared package scala package foo.bar.baz And there is a second problem: using a relative path name means compilation will fail in the presence of a directory of the same name, e.g. % mkdir reflect % scalac src/reflect/scala/reflect/internal/util/Position.scala src/reflect/scala/reflect/internal/util/Position.scala:9: error: object ClassTag is not a member of package reflect import reflect.ClassTag ^ src/reflect/scala/reflect/internal/util/Position.scala:10: error: object base is not a member of package reflect import reflect.base.Attachments ^ As a rule, do not use relative package paths unless you have explicitly imported the path to which you think you are relative. Better yet, don't use them at all. Unfortunately they mostly work because scala variously thinks everything scala.* is in the scala package and/or because you usually aren't bootstrapping and it falls through to an existing version of the class already on the classpath. Making the paths explicit is not a complete solution - in particular, we remain enormously vulnerable to any directory or package called "scala" which isn't ours - but it greatly limts the severity of the problem.
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-08 00:57:18 +0000