summaryrefslogtreecommitdiff
path: root/test/files/neg
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #1016 from hubertp/2.10.x-issue/5031Josh Suereth2012-07-303-0/+12
|\ | | | | Fixed SI-5031. Only consider classes when looking for companion class.
| * Fixed SI-5031. Only consider classes when looking for companion class.Hubert Plociniczak2012-07-303-0/+12
| | | | | | | | | | | | | | sym.effectiveOwner revealed this piece of inconsistency. companionModule is fine because similar check is there already. Review by @paulp.
* | Merge pull request #1011 from odersky/ticket/5882Josh Suereth2012-07-304-0/+32
|\ \ | | | | | | Closes SI-5882
| * | SI-5799 Secondary constructors in value classes not allowedMartin Odersky2012-07-292-0/+12
| | | | | | | | | | | | I changed the SIP and added a test.
| * | Closes SI-5882Martin Odersky2012-07-282-0/+20
| | | | | | | | | | | | I have added a restriction that value classes may not contain inner classes or objects. This makes sense as the "outer" field of any such classes or objects would be ephemeral, with surprising results. SIP-15 has been changed accordingly.
* | | Merge pull request #1013 from odersky/ticket/5878odersky2012-07-302-0/+19
|\ \ \ | |_|/ |/| | Closes SI-5878
| * | Closes SI-5878Martin Odersky2012-07-292-0/+19
| |/ | | | | | | We need to impose an additional rule on value classes: They may not unbox directly or indirectly to themselves.
* | Merge pull request #1002 from magarciaEPFL/fixes210Paul Phillips2012-07-283-0/+22
|\ \ | |/ |/| SI-6142: warn @inline-methods ending up not inlined (rightfully or not)
| * SI-6142: warn @inline-methods ending up not inlined (rightfully or not)Miguel Garcia2012-07-263-0/+22
| |
* | Improve unchecked warnings a lot.Paul Phillips2012-07-274-6/+100
|/ | | | | | | | Don't warn on "uncheckable" type patterns if they can be statically guaranteed, regardless of their runtime checkability. This covers patterns like Seq[Any] and lots more. Review by @adriaanm.
* Merge pull request #976 from adriaanm/ticket-4440bAdriaan Moors2012-07-253-0/+33
|\ | | | | SI-4440 workaround: avoid outer accessor that'll vanish
| * SI-4440 workaround: avoid outer accessor that'll vanishAdriaan Moors2012-07-233-0/+33
| | | | | | | | | | | | outer accessors of final classes are dropped in constructors apply some foresight in explicit outer and replace those doomed outer checks by `true` (since this is unfortunate, we generate an unchecked warning)
* | Merge pull request #974 from adriaanm/repull-unchecked-hkAdriaan Moors2012-07-243-0/+28
|\ \ | | | | | | Improve unchecked warnings.
| * | Improve unchecked warnings.Paul Phillips2012-07-233-0/+28
| |/ | | | | | | | | Spurious test was not good. Better test avoids suppressing some legitimate warnings. Review by @moors.
* | Merge pull request #979 from adriaanm/ticket-6111Adriaan Moors2012-07-242-8/+2
|\ \ | | | | | | SI-6111 accept single-subpattern unapply pattern
| * | SI-6111 accept single-subpattern unapply patternAdriaan Moors2012-07-232-8/+2
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An extractor pattern `X(p)` should type check for any `X.unapply`/`X.unapplySeq` that returns an `Option[_]` -- previously we were confused about the case where it was an `Option[(T1, ... , Tn)]`. In this case, the expected type for the pattern `p` is simply `(T1, ... , Tn)`. While I was at it, tried to clean up unapplyTypeList and friends (by replacing them by extractorFormalTypes). From the spec: 8.1.8 ExtractorPatterns An extractor pattern x(p1, ..., pn) where n ≥ 0 is of the same syntactic form as a constructor pattern. However, instead of a case class, the stable identifier x denotes an object which has a member method named unapply or unapplySeq that matches the pattern. An unapply method in an object x matches the pattern x(p1, ..., pn) if it takes exactly one argument and one of the following applies: n = 0 and unapply’s result type is Boolean. n = 1 and unapply’s result type is Option[T], for some type T. the (only) argument pattern p1 is typed in turn with expected type T n > 1 and unapply’s result type is Option[(T1, ..., Tn)], for some types T1, ..., Tn. the argument patterns p1, ..., pn are typed in turn with expected types T1, ..., Tn
* / SI-4881 infer variance from formals, then resultMartin Odersky2012-07-231-4/+1
|/ | | | | | | | Changed behavior so that when determining the target variance of a method parameter, the variance in formals comes first. If variance is still undecided by that, the variance in the result type is used as a secondary criterion. (This is also done when determining prototype type params.)
* Merge pull request #924 from hubertp/2.10.x-issue/5385Adriaan Moors2012-07-203-4/+10
|\ | | | | Fix for SI-5385.
| * Fix for SI-5385.Paul Phillips2012-07-173-4/+10
| | | | | | | | | | Nodes which hit EOF with no whitespace afterward had wrong position.
* | Merge pull request #894 from axel22/topic/static-annot-cherry-2.10.xLukas Rytz2012-07-202-0/+66
|\ \ | | | | | | Implement @static annotation on singleton object fields.
| * | WIP add private/lazy checks and a few tests.Aleksandar2012-07-192-1/+24
| | |
| * | Implement @static annotation on singleton object fields.Aleksandar Prokopec2012-07-182-0/+43
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit introduces the `@static` annotation on fields of static singleton objects. A static singleton object is a top-level singleton object or an object nested within a static singleton object. The field annotated with `@static` is generated as a true static field in the companion class of the object. The initialization of the field is done in the static initializer of the companion class, instead of the object itself. Here's an example. This: object Foo { @static val FIELD = 123 } class Foo generates : object Foo { def FIELD(): Int = Foo.FIELD } class Foo { <static> val FIELD = 123 } The accessor in `object Foo` is changed to return the static field in `class Foo` (the companion class is generated if it is not already present, and the same is done for getters if `FIELD` is a `var`). Furthermore, all the callsites to accessor `Foo.FIELD` are rewritten to access the static field directly. It is illegal to annotate a field in the singleton object as `@static` if there is already a member of the same name in `class Foo`. This allows better Java interoperability with frameworks which rely on static fields being present in the class. The `AtomicReferenceFieldUpdater`s are one such example. Instead of having a Java base class holding the `volatile` mutable field `f` and a static field containing a reference to the `AtomicReferenceFieldUpdater` that mutates `f` atomically, and extending this Java base class from Scala, we can now simply do: object Foo { @static val arfu = AtomicReferenceUpdater.newUpdater( classOf[Foo], classOf[String], "f" ) } class Foo { @volatile var f = null import Foo._ def CAS(ov: String, nv: String) = arfu.compareAndSet(this, null, "") } In summary, this commit introduces the following: - adds the `@static` annotation - for objects without a companion class and `@static` members, creates a companion class (this is done in `CleanUp`) - checks for conflicting names and if `@static` is used on static singleton object member - creates the `static` field in the companion class for `@static` members - moves the field initialization from the companion object to the static initializer of the class (the initialization of `@static` members is bypassed in the `Constructors` phase, and added to static ctors in `CleanUp`) - all callsites to the accessors of `@static` are rewritten to access the static fields directly (this is done in `GenICode`) - getters and setters to `@static` fields access the static field directly, and the field in the singleton object is not emitted (this is done in `GenICode`) - changes in `GenJVM`, `GenASM` - now computing local var indices in static initializers as well - this was an oversight before, now is necessary Future work: allow the `@static` annotation on methods as well - this will be added in a future commit. Review by @odersky, @dragos, @paulp, @heathermiller.
* | Merge pull request #936 from scalamacros/ticket/5999Adriaan Moors2012-07-202-5/+5
|\ \ | | | | | | SI-5999 consistent behavior for c.reify and c.universe.reify
| * | SI-5999 removes Context.reifyEugene Burmako2012-07-202-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently there are discrepancies between the behavior of c.reify and c.universe.reify. First step in fixing these problems is removing the duplication in the API. That's why I'm cutting away the Context.reify shortcut. Context.reify is a magic macro, hardwired in the fast track mechanism, so removing it requires redeploying the starr (because an old starr will crash if launched on sources that don't contain Context.reify). To cleanly redeploy a starr I've left a Context.reify stub in sources, but hidden it behind a `protected` modifier. When starr is redeployed (in a subsequent commit) the stub will be removed. I've also updated the tests to use c.universe.reify instead of c.reify. This will break some of them, because c.universe.reify uses a standard compiler mirror, which unlike a macro mirror doesn't like packageless classes. That's an annoyance, but I think having clean separation of commits is more important that being 100% consistent.
* | | Merge pull request #927 from dgruntz/issue/5856Adriaan Moors2012-07-202-0/+42
|\ \ \ | | | | | | | | SI-5856 enables use of $this in string interpolation
| * | | changes error message generated by compilerDominik Gruntz2012-07-171-1/+1
| | | |
| * | | SI-5856 enables use of $this in string interpolationDominik Gruntz2012-07-172-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This pull request fixes SI-5856. The scanner has been modified to return the correct token if keywords appear in $-expressions. The parser has been modified to issue an error and to only accept $<identifier>, $this and $block.
* | | | Merge pull request #937 from adriaanm/ticket-5739Adriaan Moors2012-07-201-2/+3
|\ \ \ \ | |_|/ / |/| | | SI-5739 store sub-patterns in local vals
| * | | SI-5739 store sub-patterns in local valsAdriaan Moors2012-07-171-2/+3
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also closes SI-5158 (debuggability), SI-6070 (soundness). To improve both debuggability and soundness, we now store the result of an extractor (user-defined and synthetic) in local variables. For the case class case, this also fixes the soundness bug SI-6070, as this prevents post-match mutation of bound variables. The core of the refactoring consisted of introducing the PreserveSubPatBinders trait, which introduces local variables instead of substituting symbols for the RHS of those variables (so this can be seen as reverting the premature optimization of inline the case-class getters into the case body). Since TreeMakerToCond fuses the substitutions performed in a match to find out which symbolic values binders evaluate to, masquerade PreserveSubPatBinders's binding of subPatBinders and subPatRefs as the corresponding substitution. Consider `case class Foo(bar: Int)`, then `case y@Foo(x) => println(x)` gives rise to `{val x = y.bar; println(x)}` (instead of `println(y.bar)`), and `subPatternsAsSubstitution` pretends we still replace `x` by `y.bar`, instead of storing it in a local variable so that the rest of the analysis need not be modified. Misc notes: - correct type for seq-subpattern - more error resilience (ill-typed patterns sometimes slip past the typechecker -- reopened SI-4425) TODO: come up with a more abstract framework for expressing bound symbols and their values
* | | Merge pull request #909 from lrytz/t5892Adriaan Moors2012-07-182-0/+42
|\ \ \ | |/ / |/| | SI-5892 allow implicit views in annotation args
| * | SI-5892 allow implicit views in annotation argsLukas Rytz2012-07-182-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the problem was that lazy annotations got completed in phase pickler. the `inferView` method in Typers bails out if `isPastTyper`. now the lazy annotations completes `atPhase(typerPhase)`. test case in `pos`. the second test case in `neg` is for another bug that is discussed in a comment of SI-5892. when type checking arguments of type parameter annotations, the class members should not be in scope. this was alreay fixed in 9129cfe9.
* | | Merge pull request #876 from adriaanm/ticket-6011bAdriaan Moors2012-07-167-1/+71
|\ \ \ | | | | | | | | SI-6011 switches: unreachability, guard-free form
| * | | SI-6011 switches: unreachability, guard-free formAdriaan Moors2012-07-167-1/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A complete overhaul. The original implementation in SI-5830 (#821) was pretty buggy. [from the doc comment of `collapseGuardedCases`:] Collapse guarded cases that switch on the same constant (the last case may be unguarded). Cases with patterns A and B switch on the same constant iff for all values x that match A also match B and vice versa. (This roughly corresponds to equality on trees modulo alpha renaming and reordering of alternatives.) The rewrite only applies if some of the cases are guarded (this must be checked before invoking this method). The rewrite goes through the switch top-down and merges each case with the subsequent cases it is implied by (i.e. it matches if they match, not taking guards into account) If there are no unreachable cases, all cases can be uniquely assigned to a partition of such 'overlapping' cases, save for the default case (thus we jump to it rather than copying it several times). (The cases in a partition are implied by the principal element of the partition.) The overlapping cases are merged into one case with their guards pushed into the body as follows (with P the principal element of the overlapping patterns Pi): `{case Pi if(G_i) => B_i }*` is rewritten to `case P => {if(G_i) B_i}*` The rewrite fails (and returns Nil) when: (1) there is a subsequence of overlapping cases that has an unguarded case in the middle; only the last case of each subsequence of overlapping cases may be unguarded (this is implied by unreachability) (2) there are overlapping cases that differ (tested by `caseImpliedBy`) cases with patterns A and B are overlapping if for SOME value x, A matches x implies B matches y OR vice versa <-- note the difference with case equality defined above for example `case 'a' | 'b' =>` and `case 'b' =>` are different and overlapping (overlapping and equality disregard guards) Improved by @retronym's feedback in the following ways: - fix patternEquals (it's now quadratic, but correct) - update neg/t6011 to test the improved patternEquals - remove side-effect-in-condition ugliness - introduce isGuardedCase - docs & various code clarity Also closes SI-6048 (duplicate).
* | | | Merge pull request #897 from lrytz/t5956Adriaan Moors2012-07-163-5/+23
|\ \ \ \ | |/ / / |/| | | SI-5956 trigger copy generation with correct namer
| * | | SI-5956 trigger copy generation with correct namerLukas Rytz2012-07-133-5/+23
| |/ / | | | | | | | | | | | | | | | the call to `addCopyMethod` passes `templateNamer`, which is supposed to be the namer of the case class template. with two classes of the same name, `addCopyMethod` was triggered in the wrong template.
* | | Merge pull request #902 from paulp/topic/name-implicitsAdriaan Moors2012-07-142-0/+16
|\ \ \ | |/ / |/| | Implicits to encourage more Name-dropping.
| * | Merge branch '2.10.x' into topic/name-implicitsPaul Phillips2012-07-135-1/+114
| |\|
| * | Implicits to encourage more Name-dropping.Paul Phillips2012-07-062-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This creates implicits in cakes across the land from: String => TermName String => TypeName And also from: Name => NameOps[Name] // lower priority TermName => NameOps[TermName] TypeName => NameOps[TypeName] What this is all about, using "drop" as a motivating example, is that these should all work: "abc" drop 1 // "bc": String ("abc": TermName) drop 1 // "bc": TermName ("abc": TypeName) drop 1 // "bc": TypeName (("abc": TypeName): Name) drop 1 // "bc": Name But this should not: ("bc": Name) // ambiguity error This requires drop not being directly on Name; peer implicits from String => TermName and String => TypeName; implicit classes to install drop on TermName and TypeName; and a lower priority implicit class to allow ops on Names. Review by @xeno.by .
* | | Merge branch '2.10.x' into topic/pickledflagsPaul Phillips2012-07-114-0/+113
|\ \ \ | | |/ | |/| | | | | | | Conflicts: src/reflect/scala/reflect/internal/Flags.scala
| | |
| | \
| | \
| | \
| | \
| | \
| *-----. \ Merge commit 'refs/pull/825/head'; commit 'refs/pull/827/head'; commit ↵Adriaan Moors2012-07-114-0/+113
| |\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | 'refs/pull/828/head'; commit 'refs/pull/850/head'; commit 'refs/pull/858/head' into 2.10.x
| | | | | * | SI-6042 Improve type selection from volatile type errorJason Zaugg2012-07-082-0/+12
| | | | | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Display the type of the typed qualifier (qual1), to avoid the message "Illegal type selection from volatile type null". - Show the upper bound, which is used to calculate the volatility.
| | * | | | stringinterpolation macro test filesAdriaan Moors2012-07-062-0/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds test files neg: checks the error messages generated by the compiler run: checks the macro implementation features
* | | | | | Pickled flag reorgMartin Odersky2012-07-113-16/+0
|/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cleaned up and optimized code that maps between raw and pickled flags. Avoids mystery constants. Makes a whole bunch of new flags be pickled which were not pickled before (more precisely: Everything in InitialFlags with value greater than 1 << 31 which is not in FlagsNotPickled now gets pickled whereas before it wasn't. Among these: VARARGS, IMPLCLASS, SPECIALZED, DEFAULTINIT, SYNCHRONIZED. I am curious how many tickets will get fixed by this change. The first one I noted is t5504, which previously enforced the buggy behavior through a neg check! There are also some build manager check file changes that have to do with the fact that flags now print in a different order for performance reasons.
* | | | | Merge pull request #838 from adriaanm/ticket-2442Adriaan Moors2012-07-071-1/+1
|\ \ \ \ \ | |_|_|_|/ |/| | | | SI-2442 sealedness for java enums non-experimental
| * | | | SI-2442 sealedness for java enums non-experimentalAdriaan Moors2012-07-061-1/+1
| |/ / /
* | | | Merge pull request #834 from paulp/issue/3836-2Adriaan Moors2012-07-062-0/+41
|\ \ \ \ | |/ / / |/| | | Fix SI-3836 not-really-ambiguous import detection.
| * | | Fix SI-3836 not-really-ambiguous import detection.Paul Phillips2012-07-052-0/+41
| | | | | | | | | | | | | | | | | | | | Normalize types before declaring that two imports are ambiguous, because they might be the same thing. Review by @moors.
* | | | Merge pull request #830 from heathermiller/topic/tryeither-fixesAdriaan Moors2012-07-061-2/+2
|\ \ \ \ | | | | | | | | | | SI-5981, SI-5979, SI-5973, SI-5890 Closed. Maintenance to Try.
| * | | | SI-5981, SI-5979, SI-5973 Closed. Maintenance to Try.Heather Miller2012-07-051-2/+2
| |/ / /
* | | | SI-6008 use static knowledge of success of type testsAdriaan Moors2012-07-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | augment the equality axioms to take into account that a type test against the static type of a variable succeeds unless the variable is null for exhaustivity we disregard null, so the type test always succeeds during unreachability we model this knowledge as the obvious implication