summaryrefslogtreecommitdiff
path: root/test/files/neg
Commit message (Collapse)AuthorAgeFilesLines
* more tests for macro bundlesEugene Burmako2014-02-2114-0/+238
| | | | | Given the recent glaring oversight in macro bundles, I have to have more tests in order to make sure that things are going to work as they should.
* more helpful bundle error messagesEugene Burmako2014-02-213-6/+6
| | | | | | | | | | | | | At the moment, bundle selection mechanism is pretty picky. If a candidate bundle's parameter isn't either blackbox.Context, whitebox.Context or PrefixType refinement thereof, then it's not a bundle and the user will get a generic error. However we can be a bit more helpful and admit classes that are almost like bundles (looksLikeMacroBundleType), have them fail isMacroBundleType, and then emit a much prettier error message to the user that would tell them that bundles must be monomorphic and their sole parameter should not just be any subtype of blackbox.Context or whitebox.Context.
* prohibits polymorphic bundlesEugene Burmako2014-02-214-2/+64
| | | | | | It's not like they were inducing bugs, but I can't see how polymorphism can be useful for macro bundles, hence imho it's better to reduce the number of degrees of freedom of the system.
* bundles now reject invalid context typesEugene Burmako2014-02-214-0/+32
| | | | | Vanilla macros only allow blackbox.Context, whitebox.Context and PrefixType refinements thereof. Bundles should behave in the same way.
* SI-8321 whitebox bundles are now recognized as suchEugene Burmako2014-02-213-0/+144
| | | | | whitebox.Context <: blackbox.Context, so in order to check for blackboxity it's not enough to check whether the context used is <: blackbox.Context.
* Merge pull request #3555 from adriaanm/rebase-3553Jason Zaugg2014-02-214-2/+12
|\ | | | | Small Predef cleanup
| * SI-8229 Source compatible name for implicit any2stringaddJason Zaugg2014-02-184-2/+12
| | | | | | | | | | | | | | | | | | | | To support the established pattern for disabling it for an compilation unit. Update scaladoc's knowledge of our "typeclasses". Leave a `private[scala]` version of `StringAdd` (public in bytecode) to ensure binary compatibility with 2.11.0-M8 for partest.
* | Merge pull request #3564 from adriaanm/t6675Jason Zaugg2014-02-212-2/+2
|\ \ | | | | | | SI-6675 deprecation warning for auto-tupling in patterns
| * | SI-6675 deprecation warning for auto-tupling in patternsAdriaan Moors2014-02-192-2/+2
| | | | | | | | | | | | | | | NOTE: when the deprecation warning becomes an error, SI-6111 must become a `won't fix`
* | | Fix quasiquote terminology to be consistent with SchemeDenys Shabalin2014-02-203-2/+2
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Rename cardinality into rank. Shorter word, easier to understand, more appropriate in our context. 2. Previously we called any dollar substitution splicing but this is not consistent with Scheme where splicing is substitution with non-zero rank. So now $foo is unquoting and ..$foo and ...$foo is unquote splicing or just splicing. Correspondingly splicee becomes unquotee. 3. Rename si7980 test into t7980
* | Merge pull request #3452 from xeno-by/topic/palladium0Jason Zaugg2014-02-1910-10/+62
|\ \ | |/ |/| SI-8063 and its seventy friends
| * tests for SI-8300Eugene Burmako2014-02-182-0/+23
| | | | | | | | | | | | Highlights the dilemma with rich type members in the cake that no longer exists. One used to have to choose between overloading or patmat/extmeth friendliness, but couldn't have both. Thanks to retronym we can have it all.
| * Merge remote-tracking branch 'origin/master' into topic/palladium0Eugene Burmako2014-02-176-112/+15
| |\
| * \ Merge remote-tracking branch 'origin/master' into topic/palladium0Eugene Burmako2014-02-1618-17/+428
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/compiler/scala/reflect/macros/compiler/Resolvers.scala src/compiler/scala/reflect/macros/contexts/Typers.scala src/compiler/scala/tools/reflect/ToolBoxFactory.scala src/reflect/scala/reflect/api/BuildUtils.scala
| * | | some renamingsEugene Burmako2014-02-154-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It’s almost 1am, so I’m only scratching the surface, mechanistically applying the renames that I’ve written down in my notebook: * typeSignature => info * declarations => decls * nme/tpnme => termNames/typeNames * paramss => paramLists * allOverriddenSymbols => overrides Some explanation is in order so that I don’t get crucified :) 1) No information loss happens when abbreviating `typeSignature` and `declarations`. We already have contractions in a number of our public APIs (e.g. `typeParams`), and I think it’s fine to shorten words as long as people can understand the shortened versions without a background in scalac. 2) I agree with Simon that `nme` and `tpnme` are cryptic. I think it would be thoughtful of us to provide newcomers with better names. To offset the increase in mouthfulness, I’ve moved `MethodSymbol.isConstructor` to `Symbol.isConstructor`, which covers the most popular use case for nme’s. 3) I also agree that putting `paramss` is a lot to ask of our users. The double-“s” convention is very neat, but let’s admit that it’s just weird for the newcomers. I think `paramLists` is a good compromise here. 4) `allOverriddenSymbols` is my personal complaint. I think it’s a mouthful and a shorter name would be a much better fit for the public API.
| * | | Merge remote-tracking branch 'origin/master' into topic/palladium0Eugene Burmako2014-02-1436-179/+186
| |\ \ \
| * | | | SI-6931 cleans up the position APIEugene Burmako2014-02-143-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I have finally overcome my fear of positions and got to cleaning up its public interface. Apparently it isn’t so bad, since there’s a sane core of methods (thanks to whoever wrote the comments to internal#Position): 1) Checks to distinguish offsets, opaque ranges and transparent ranges 2) Essentials that inclide start, point, end and source 3) Factories that create new positions based on existing ones It looks like methods from the 3rd group are exactly what we’ve been looking for in SI-6931, so we have nothing to add in this commit.
| * | | | proceeds with the quest of removing `local` from namesEugene Burmako2014-02-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Continuing in the direction set by the parent commit, this commit rephrases some more usages of `local` in names and comments in typer.
* | | | | SI-8072 rationalize public implicits in scala parallel collectionsRex Kerr2014-02-182-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pretty much everything seems like it's intended for internal use, so I moved it to a package-private object. Split toParArray out and put it in an implicit class. Added ability to .toParArray from Array and String also. Added test to verify implicits are gone.
* | | | | SI-7707 SI-7712 Exclude unused warnings from -XlintJason Zaugg2014-02-173-14/+3
| |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Experience building open source projects like Specs that use `-Xlint` suggests that this warning is too noisy to lump in with the others. We are lacking in more fine-grained control of these things, so simply turning of `-Xlint` in favour of its underlying `-Y` options ends up *losing* some other important warnings that are predicated directly on `-Xlint`. Furthermore, bug reports against M8, SI-7707 SI-7712, show that unused private/local warnings, while far less noisy, are still in need of polish. This commit moves these warnings to a pair of new -Y options, neither of which is part of `-Xlint`.. Let's ask people to opt in for 2.11, and as it stabilizes, we can consider adding it to Xlint (or the desirable evolution of that) in the next release.
* | | | Revert "SI-5920 enables default and named args in macros"Jason Zaugg2014-02-176-112/+15
| |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-15/+112
|\ \ \ | | | | | | | | SI-5920 enables default and named args in macros
| * | | SI-5920 enables default and named args in macrosEugene Burmako2014-02-106-15/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | Merge pull request #3521 from xeno-by/ticket/8270Jason Zaugg2014-02-167-1/+64
|\ \ \ \ | | | | | | | | | | SI-8270 unconfuses bundles and vanilla macros
| * | | | SI-8270 unconfuses bundles and vanilla macrosEugene Burmako2014-02-137-1/+64
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a mistake in macro impl ref typechecking that used to have an heuristic to figure out whether it looks at a bundle method ref or at a vanilla object method ref. Under some circumstances the heuristic could fail, and then the macro engine would reject perfectly good macro impls. Now every macro impl ref is typechecked twice - once as a bundle method ref and once as a vanilla object method ref. Results are then analyzed, checked against ambiguities (which are now correctly reported instead of incorrectly prioritizing towards bundles) and delivered to the macro engine. The only heuristic left in place is the one that's used to report errors. If both bundle and vanilla typechecks fail, then if a bundle candidate looks sufficiently similar to a bundle, a bundle typecheck error is reported providing some common bundle definition hints.
* | | | Merge pull request #3493 from retronym/ticket/3452-2Grzegorz Kossakowski2014-02-161-1/+5
|\ \ \ \ | | | | | | | | | | SI-3452 Correct Java generic signatures for mixins, static forwarders
| * | | | SI-3452 Correct Java generic signatures for mixins, static forwardersJason Zaugg2014-02-091-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Parts of this patch and some of the commentary are from @paulp] This took me so long to figure out I can't even tell you. Partly because there were two different bugs, one which only arose for trait forwarders and one for mirror class forwarders, and every time I'd make one set of tests work another set would start failing. The runtime failures associated with these bugs were fairly well hidden because you usually have to go through java to encounter them: scala doesn't pay that much attention to generic signatures, so they can be wrong and scala might still generate correct code. But java is not so lucky. Bug #1) During mixin composition, classes which extend traits receive forwarders to the implementations. An attempt was made to give these the correct info (in method "cloneBeforeErasure") but it was prone to giving the wrong answer, because: the key attribute which the forwarder must capture is what the underlying method will erase to *where the implementation is*, not how it appears to the class which contains it. That means the signature of the forwarder must be no more precise than the signature of the inherited implementation unless additional measures will be taken. This subtle difference will put on an unsubtle show for you in test run/t3452.scala. trait C[T] trait Search[M] { def search(input: M): C[Int] = null } object StringSearch extends Search[String] { } StringSearch.search("test"); // java // java.lang.NoSuchMethodError: StringSearch.search(Ljava/lang/String;)LC; The principled thing to do here would be to create a pair of methods in the host class: a mixin forwarder with the erased signature `(String)C[Int]`, and a bridge method with the same erased signature as the trait interface facet. But, this turns out to be pretty hard to retrofit onto the current setup of Mixin and Erasure, mostly due to the fact that mixin happens after erasure which has already taken care of bridging. For a future, release, we should try to move all bridging after mixin, and pursue this approach. But for now, what can we do about `LinkageError`s for Java clients? This commit simply checks if the pre-erasure method signature that we generate for the trait forward erases identically to that of the interface method. If so, we can be precise. If not, we emit the erased signature as the generic signature. Bug #2) The same principle is at work, at a different location. During genjvm, objects without declared companion classes are given static forwarders in the corresponding class, e.g. object Foo { def bar = 5 } which creates these classes (taking minor liberties): class Foo$ { static val MODULE$ = new Foo$ ; def bar = 5 } class Foo { static def bar = Foo$.MODULE$.bar } In generating these, genjvm circumvented the usual process whereby one creates a symbol and gives it an info, preferring to target the bytecode directly. However generic signatures are calculated from symbol info (in this case reusing the info from the module class.) Lacking even the attempt which was being made in mixin to "clone before erasure", we would have runtime failures of this kind: abstract class Foo { type T def f(x: T): List[T] = List() } object Bar extends Foo { type T = String } Bar.f(""); // java // java.lang.NoSuchMethodError: Bar.f(Ljava/lang/String;)Lscala/collection/immutable/List; Before/after this commit: < signature f (Ljava/lang/String;)Lscala/collection/immutable/List<Ljava/lang/String;>; --- > signature f (Ljava/lang/Object;)Lscala/collection/immutable/List<Ljava/lang/Object;>; This takes the warning count for compiling collections under `-Ycheck:jvm` from 1521 to 26.
* | | | | Merge pull request #3511 from som-snytt/issue/interp-octalAdriaan Moors2014-02-152-0/+19
|\ \ \ \ \ | | | | | | | | | | | | SI-8266 Deprecate octal escapes in f-interpolator
| * | | | | SI-8266 Deprecate octal escapes in f-interpolatorSom Snytt2014-02-112-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also turns the f-interpolator into a migration assistant by suggesting alternatives for the standard escapes.
* | | | | | Add an extremely well-commented testclhodapp2014-02-142-0/+228
| |_|_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit includes a test for some simple existential subtyping checks. It is exceptionally well-commented and may be helpful to someone trying to figure out what the rules are (supposed to be) in the future.
* | | | | SI-8177 tidy up in type reificationEugene Burmako2014-02-141-1/+1
| | | | |
* | | | | SI-8177 specializeSym must use memberInfo on high sideAdriaan Moors2014-02-136-0/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When determining whether member `symLo` of `tpLo` has a stronger type than member `symHi` of `tpHi`, should we use memberType or memberInfo? Well, memberType transforms (using `asSeenFrom`) `sym.tpe`, whereas memberInfo performs the same transform on `sym.info`. For term symbols, this ends up being the same thing (`sym.tpe == sym.info`). For type symbols, however, the `.info` of an abstract type member is defined by its bounds, whereas its `.tpe` is a `TypeRef` to that type symbol, so that `sym.tpe <:< sym.info`, but not the other way around. Thus, for the strongest (correct) result, we should use `memberType` on the low side. On the high side, we should use the result appropriate for the right side of the `<:<` above (`memberInfo`). I also optimized the method a little bit by avoiding calling memberType if the symbol on the high side isn't eligble (e.g., it's a class). PS: I had to add a workaround to reifyType, because we now dealias a little less eagerly, which means a type selection on refinement class symbols makes it to reify this broke the t8104 tests. I also had to update the run/t6992 test, which should now test the right thing. Tests should be commented and/or use sensible names. What is it testing? What is the expected outcome? We should not be left guessing.
* | | | | Merge pull request #3389 from retronym/ticket/8134-2Jason Zaugg2014-02-139-107/+0
|\ \ \ \ \ | | | | | | | | | | | | SI-8134 SI-5954 Fix companions in package object under separate comp.
| * | | | | SI-8134 SI-5954 Fix companions in package object under separate comp.Jason Zaugg2014-01-209-107/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tests cases enclosed exhibited two failures modes under separate compilation. 1. When a synthetic companion object for a case- or implicit-class defined in a package object is called for, `Namer#ensureCompanionObject` is used to check for an explicitly defined companion before decided to create a synthetic one. This lookup of an existing companion symbol by `companionObjectOf` would locate a symbol backed by a class file which was in the scope of the enclosing package class. Furthermore, because the owner of that symbol is the package object class that has now been noted as corresponding to a source file in the current run, the class-file backed module symbol is *also* deemed to be from the current run. (This logic is in `Run#compiles`.) Thinking the companion module already existed, no synthetic module was created, which would lead to a crash in extension methods, which needs to add methods to it. 2. In cases when the code explicitly contains the companion pair, we still ran into problems in the backend whereby the class-file based and source-file based symbols for the module ended up in the same scope (of the package class). This tripped an assertion in `Symbol#companionModule`. We get into these problems because of the eager manner in which class-file based package object are opened in `openPackageModule`. The members of the module are copied into the scope of the enclosing package: scala> ScalaPackage.info.member(nme.List) res0: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462 scala> ScalaPackage.info.member(nme.PACKAGE).info.member(nme.List) res1: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462 This seems to require a two-pronged defense: 1. When we attach a pre-existing symbol for a package object symbol to the tree of its new source, unlink the "forwarder" symbols (its decls from the enclosing package class. 2. In `Flatten`, in the spirit of `replaceSymbolInCurrentScope`, remove static member modules from the scope of the enclosing package object (aka `exitingFlatten(nestedModule.owner)`). This commit also removes the warnings about defining companions in package objects and converts those neg tests to pos (with -Xfatal-warnings to prove they are warning free.) Defining nested classes/objects in package objects still has a drawback: you can't shift a class from the package to the package object, or vice versa, in a binary compatible manner, because of the `package$` prefix on the flattened name of nested classes. For this reason, the `-Xlint` warning about this remains. This issue is tracked as SI-4344. However, if one heeds this warning and incrementatlly recompiles, we no longer need to run into a DoubleDefinition error (which was dressed up with a more specific diagnostic in SI-5760.) The neg test case for that bug has been converted to a pos.
* | | | | | SI-5900 Fix pattern inference regressionJason Zaugg2014-02-126-36/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | | | Merge pull request #3519 from adriaanm/rebase-3483Adriaan Moors2014-02-1210-0/+84
|\ \ \ \ \ \ | | | | | | | | | | | | | | SI-8244 Fix raw type regression under separate compilation
| * | | | | | SI-8244 Fix raw type regression under separate compilationJason Zaugg2014-02-1210-0/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In #1901, handling of raw types encountered in signatures during class file parsing was changed to work in the same manner as `classExistentialType`, by using `existentialAbstraction(cls.tparms, cls.tpe_*)` But this never creates fresh existential symbols, and just sticks the class type parameters it `quantified`: scala> trait T[A <: String] defined trait T scala> val cls = typeOf[T[_]].typeSymbol cls = trait T#101864 scala> cls.typeParams res0 = List(type A#101865) scala> cls.tpe_* res1 = T#101864[A#101865] scala> classExistentialType(cls) res3 = T#101864[_ <: String#7209] scala> val ExistentialType(quantified, result) = res3 List(type A#101865) In the enclosed test case, this class type parameter was substituted during `typeOf[X] memberType sym`, which led us unsoundly thinking that `Raw[_]` was `Raw[X]`. I've added a TODO comment to review the other usages of `classExistentialType`. Test variations include joint and separate compilation, and the corresponding Scala-only code. All fail with type errors now, as we expect. I've also added a distillation of a bootstrap error that failed when I forgot to wrap the `existentialType`.
* | | | | | | SI-7753 InstantiateDependentMap narrows type of unstable argsAdriaan Moors2014-02-122-3/+3
|/ / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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
* | | | | | Merge pull request #3516 from adriaanm/t8177Adriaan Moors2014-02-124-148/+0
|\ \ \ \ \ \ | | | | | | | | | | | | | | SI-8177 co-evolve more than just RefinedTypes
| * | | | | | SI-8177 refine embeddedSymbolsAdriaan Moors2014-02-124-148/+0
| | |_|_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We look for any prefix that has a refinement class for a type symbol. This includes ThisTypes, which were not considered before. pos/t8177g.scala, neg/t0764*scala now compile, as they should Additional test cases contributed by Jason & Paul.
* / | | | | A test case for a name binding progressionJason Zaugg2014-02-122-0/+31
|/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I noticed the change when adapting Slick to work with Scala 2.11 in `AbstractSourceCodeGenerator.scala`. The behaviour changed in a70c8219. This commit locks down the new, correct behaviour with a test.
* | | | | Merge pull request #3503 from adriaanm/rebase-3440Adriaan Moors2014-02-1110-6/+80
|\ \ \ \ \ | | | | | | | | | | | | SI-7475 Private members aren't inheritable, findMember overhaul
| * | | | | SI-7475 Private members are not inheritableJason Zaugg2014-02-1010-6/+80
| | |/ / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* / | | | Add a great test case.Paul Phillips2014-02-112-0/+127
|/ / / / | | | | | | | | | | | | | | | | | | | | Created to convince moors that certain code should compile, it wound up flushing out some quite nutty behavior. Some day this will compile rather than having an 11-failure checkfile.
* | | | SI-8129 Make Object#== override Any#==Jason Zaugg2014-02-102-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | And the same for != If we tried to declare these signatures in non-fictional classes, we would be chastised about collapsing into the "same signature after erasure". This will have an influence of typing, as the typechecking of arguments is sensitive to overloading: if multiple variants are feasible, the argument will be typechecked with a wildcard expected type. So people inspecting the types of the arguments to `==` before this change might have seen an interesting type for `if (true) x else y`, but now the `If` will have type `Any`, as we don't need to calculate the LUB. I've left a TODO to note that we should really make `Any#{==, !=}` non-final and include a final override in `AnyVal`. But I don't think that is particularly urgent.
* | | | Merge pull request #3428 from retronym/ticket/6260Grzegorz Kossakowski2014-02-1010-72/+28
|\ \ \ \ | | | | | | | | | | SI-6260 Avoid double-def error with lambdas over value classes
| * | | | SI-6260 Adddress pull request reviewJason Zaugg2014-02-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - fix typo - remove BRIDGE flag from the method that we promote from a bridge to a bona-fide method - note possibility for delambdafy to avoid the bridge method creation in *all* cases. - note inconsistency with anonymous class naming between `-Ydelamdafy:{inline,method}`
| * | | | SI-6260 Avoid double-def error with lambdas over value classesJason Zaugg2014-02-1010-72/+28
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Post-erasure of value classs in method signatures to the underlying type wreaks havoc when the erased signature overlaps with the generic signature from an overriden method. There just isn't room for both. But we *really* need both; callers to the interface method will be passing boxed values that the bridge needs to unbox and pass to the specific method that accepts unboxed values. This most commonly turns up with value classes that erase to Object that are used as the parameter or the return type of an anonymous function. This was thought to have been intractable, unless we chose a different name for the unboxed, specific method in the subclass. But that sounds like a big task that would require call-site rewriting, ala specialization. But there is an important special case in which we don't need to rewrite call sites. If the class defining the method is anonymous, there is actually no need for the unboxed method; it will *only* ever be called via the generic method. I came to this realisation when looking at how Java 8 lambdas are handled. I was expecting bridge methods, but found none. The lambda body is placed directly in a method exactly matching the generic signature. This commit detects the clash between bridge and target, and recovers for anonymous classes by mangling the name of the target method's symbol. This is used as the bytecode name. The generic bridge forward to that, as before, with the requisite box/unbox operations.
* | | | Merge pull request #3476 from retronym/ticket/8207Adriaan Moors2014-02-092-0/+10
|\ \ \ \ | | | | | | | | | | SI-8207 Allow import qualified by self reference
| * | | | SI-8207 Allow import qualified by self referenceJason Zaugg2014-02-062-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This regressed in SI-6815 / #2374. We check if the result of `typedQualifier(Ident(selfReference))` is a stable identifier pattern. But we actually see the expansion to `C.this`, which doesn't qualify. This commit adds a special cases to `importSig` to compensate. This is safe enough, because the syntax prevents the following: scala> class C { import C.this.toString } <console>:1: error: '.' expected but '}' found. class C { import C.this.toString } ^ So loosening the check here doesn't admit invalid programs. I've backed this up with a `neg` test. The enclosed test also checks that we can use the self reference in a singleton type, and as a qualifier in a type selection (These weren't actually broken.) Maybe it would be more principled to avoid expanding the self reference in `typedIdent`. I can imagine that the current situation is a pain for refactoring tools that try to implement a rename refactoring, for example. Seems a bit risky at the minute, but I've noted the idea in a comment.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-25 09:02:20 +0000