summaryrefslogtreecommitdiff
path: root/test/files/neg
Commit message (Collapse)AuthorAgeFilesLines
* Fields phase expands lazy vals like modulesAdriaan Moors2016-08-2910-37/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They remain ValDefs until then. - remove lazy accessor logic now that we have a single ValDef for lazy vals, with the underlying machinery being hidden until the fields phase leave a `@deprecated def lazyAccessor` for scala-refactoring - don't skolemize in purely synthetic getters, but *do* skolemize in lazy accessor during typers Lazy accessors have arbitrary user code, so have to skolemize. We exempt the purely synthetic accessors (`isSyntheticAccessor`) for strict vals, and lazy accessors emitted by the fields phase to avoid spurious type mismatches due to issues with existentials (That bug is tracked as https://github.com/scala/scala-dev/issues/165) When we're past typer, lazy accessors are synthetic, but before they are user-defined to make this hack less hacky, we could rework our flag usage to allow for requiring both the ACCESSOR and the SYNTHETIC bits to identify synthetic accessors and trigger the exemption. see also https://github.com/scala/scala-dev/issues/165 ok 7 - pos/existentials-harmful.scala ok 8 - pos/t2435.scala ok 9 - pos/existentials.scala previous attempt: skolemize type of val inside the private[this] val because its type is only observed from inside the accessor methods (inside the method scope its existentials are skolemized) - bean accessors have regular method types, not nullary method types - must re-infer type for param accessor some weirdness with scoping of param accessor vals and defs? - tailcalls detect lazy vals, which are defdefs after fields - can inline constant lazy val from trait - don't mix in fields etc for an overridden lazy val - need try-lift in lazy vals: the assign is not seen in uncurry because fields does the transform (see run/t2333.scala) - ensure field members end up final in bytecode - implicit class companion method: annot filter in completer - update check: previous error message was tangled up with unrelated field definitions (`var s` and `val s_scope`), now it behaves consistently whether those are val/vars or defs - analyzer plugin check update seems benign, but no way to know... - error message gen: there is no underlying symbol for a deferred var look for missing getter/setter instead - avoid retypechecking valdefs while duplicating for specialize see pos/spec-private - Scaladoc uniformly looks to field/accessor symbol - test updates to innerClassAttribute by Lukas
* Address review commentsJason Zaugg2016-08-231-0/+7
| | | | | | | | | | - clarify the intent of tests - Consolidate stripExistentialsAndTypeVars with similar logic in mergePrefixAndArgs - Refactor special cases in maybeRewrap The name isn't great, but I'm struggling to come up with a pithy way to describe the rogue band of types.
* Improved refinement type and existential type handlingJason Zaugg2016-08-232-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lazy base type seq elements are encoded as a refined type with an empty scope and a list of type refs over some common type symbol that will be merged when `BaseTypeSeq#apply` is called. The first change in this commit is to mark the creation and consumption of such elements with calls to `[is]IntersectionTypeForBaseTypeSeq`. They are distinguished by using the actual type symbol rather than a refinement class symbol, which in turn simplifies the code in `BaseTypeSeq#typeSymbol`. I have also made `lub` aware of this encoding: it is now able to "see through" to the parents of such refined types and merge them with other base types of the same class symbol (even other refined types representing lazy BTS elements.) To make this fix work, I also had to fix a bug in LUBs of multiple with existential types. Because of the way the recursion was structured in `mergePrefixAndArgs`, the order of list of types being merged changed behaviour: quantified varialbles of existential types were being rewrapped around the resultting type, but only if we hadn't encountered the first regular `TypeRef`. This can be seen with the following before/after shot: ``` // 2.11.8 scala> val ts = typeOf[Set[Any]] :: typeOf[Set[X] forSome { type X <: Y; type Y <: Int}] :: Nil; def merge(ts: List[Type]) = mergePrefixAndArgs(ts, Variance.Contravariant, lubDepth(ts)); val merged1 = merge(ts); val merged2 = merge(ts.reverse); (ts.forall(_ <:< merged1), ts.forall(_ <:< merged2)) ts: List[$r.intp.global.Type] = List(Set[Any], Set[_ <: Int]) merge: (ts: List[$r.intp.global.Type])$r.intp.global.Type merged1: $r.intp.global.Type = scala.collection.immutable.Set[_ >: Int] merged2: $r.intp.global.Type = scala.collection.immutable.Set[_53] forSome { type X <: Int; type _53 >: X } res0: (Boolean, Boolean) = (false,true) // HEAD ... merged1: $r.intp.global.Type = scala.collection.immutable.Set[_10] forSome { type X <: Int; type _10 >: X } merged2: $r.intp.global.Type = scala.collection.immutable.Set[_11] forSome { type X <: Int; type _11 >: X } res0: (Boolean, Boolean) = (true,true) ``` Furthermore, I have fixed the computation of the base type sequences of existential types over refinement types, in order to maintain the invariant that each slot of the base type sequence of a existential has the same type symbol as that of its underlying type. Before, what I've now called a `RefinementTypeRef` was transformed into a `RefinedType` during rewrapping in the existential, which led to it being wrongly considered as a lazy element of the base type sequence. The first change above should also be sufficient to avoid the bug, but I felt it was worth cleaning up `maybeRewrap` as an extra line of defence. Finally, I have added another special case to `BaseTypeSeq#apply` to be able to lazily compute elements that have been wrapped in an existential. The unit test cases in `TypesTest` rely on these changes. A subsequent commit will build on this foundation to make a fix to `asSeenFrom`.
* Merge pull request #5266 from som-snytt/issue/9847Adriaan Moors2016-08-148-10/+79
|\ | | | | SI-9847 Nuance pure expr statement warning
| * SI-9847 Nuance pure expr statement warningSom Snytt2016-07-088-10/+79
| | | | | | | | | | | | | | | | | | | | Clarify the current warning, which means that an expression split over multiple lines may not be parsed as naively expected. When typing a block, attempt minor nuance. For instance, a single expression is not in need of parens. Try to avoid duplicate warnings for expressions that were adapted away from result position.
* | Merge pull request #5307 from adriaanm/issue-157Adriaan Moors2016-08-133-14/+19
|\ \ | | | | | | Propagate overloaded function type to expected arg type
| * | Propagate overloaded function type to expected arg typeAdriaan Moors2016-08-123-14/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Infer missing parameter types for function literals passed to higher-order overloaded methods by deriving the expected argument type from the function types in the overloaded method type's argument types. This eases the pain caused by methods becoming overloaded because SAM types and function types are compatible, which used to disable parameter type inference because for overload resolution arguments are typed without expected type, while typedFunction needs the expected type to infer missing parameter types for function literals. It also aligns us with dotty. The special case for function literals seems reasonable, as it has precedent, and it just enables the special case in typing function literals (derive the param types from the expected type). Since this does change type inference, you can opt out using the Scala 2.11 source level. Fix scala/scala-dev#157
* | | SD-128 fix override checks for default methodsLukas Rytz2016-08-123-0/+39
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The check for inheriting two conflicting members was wrong for default methods, leading to a missing error message. We were also not issuing "needs `override' modifier" when overriding a default method. Removes two methods: - `isDeferredOrJavaDefault` had a single use that is removed in this commit. - `isDeferredNotJavaDefault` is redundant with `isDeferred`, because no default method has the `DEFERRED` flag: - For symbols originating in the classfile parser this was the case from day one: default methods don't receive the `DEFERRED` flag. Only abstract interface methods do, as they have the `JAVA_ACC_ABSTRACT` flag in bytecode, which the classfile parser translates to `DEFERRED`. - For symbols created by the Java source parser, we don't add the `DEFERRED` to default methods anymore since 373db1e. Fixes scala/scala-dev#128
* | Merge pull request #5252 from adriaanm/t8339Stefan Zeiger2016-08-122-3/+2
|\ \ | | | | | | SI-8339 remove deprecated rewrite of withFilter -> filter
| * | SI-8339 drop deprecated fallback `withFilter` -> `filter`Adriaan Moors2016-08-112-3/+2
| | | | | | | | | | | | | | | | | | | | | You must implement the `withFilter` method to use `if`-guards in a `for`-comprehension. (Drop pos/t7239.scala because it relied on this rewrite.)
* | | Merge pull request #5141 from adriaanm/fieldsAdriaan Moors2016-08-1139-191/+531
|\ \ \ | | | | | | | | Introducing: the fields phase [ci: last-only]
| * | | Drive accessor synthesis from info transformerAdriaan Moors2016-08-113-95/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Derive/filter/propagate annotations in info transformer, don't rely on having type checked the derived trees in order to see the annotations. Use synthetics mechanism for bean accessors -- the others will soon follow. Propagate inferred tpt from valdef to accessors by setting type in right spot of synthetic tree during the info completer. No need to add trees in derivedTrees, and get rid of some overfactoring in method synthesis, now that we have joined symbol and tree creation. Preserve symbol order because tests are sensitive to it. Drop warning on potentially discarded annotations, I don't think this warrants a warning. Motivated by breaking the scala-js compiler, which relied on annotations appearing when trees are type checked. Now that ordering constraint is gone in the new encoding, we may as well finally fix annotation assignment.
| * | | Allow 'overriding' deferred varAdriaan Moors2016-08-112-0/+7
| | | | | | | | | | | | | | | | Discovered by scala-js's test suite.
| * | | Fields phase synthesizes modulesAdriaan Moors2016-08-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For now, keep the info transform in refchecks. Ultimately, refchecks should only check, not transform trees/infos. Fixes https://github.com/scala/scala-dev/issues/126: the accessor for a module in a trait is correctly marked non-final (it's deferred).
| * | | Fields phaseAdriaan Moors2016-08-1133-95/+523
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One step towards teasing apart the mixin phase, making each phase that adds members to traits responsible for mixing in those members into subclasses of said traits. Another design tenet is to not emit symbols or trees only to later remove them. Therefore, we model a val in a trait as its accessor. The underlying field is an implementation detail. It must be mixed into subclasses, but has no business in a trait (an interface). Also trying to reduce tree creation by changing less in subtrees during tree transforms. A lot of nice fixes fall out from this rework: - Correct bridges and more precise generic signatures for mixed in accessors, since they are now created before erasure. - Correct enclosing method attribute for classes nested in trait fields. Trait fields are now created as MethodSymbol (no longer TermSymbol). This symbol shows up in the `originalOwner` chain of a class declared within the field initializer. This promoted the field getter to being the enclosing method of the nested class, which it is not (the EnclosingMethod attribute is a source-level property). - Signature inference is now more similar between vals and defs - No more field for constant-typed vals, or mixed in accessors for subclasses. A constant val can be fully implemented in a trait. TODO: - give same treatment to trait lazy vals (only accessors, no fields) - remove support for presuper vals in traits (they don't have the right init semantics in traits anyway) - lambdalift should emit accessors for captured vals in traits, not a field Assorted notes from the full git history before squashing below. Unit-typed vals: don't suppress field it affects the memory model -- even a write of unit to a field is relevant... unit-typed lazy vals should never receive a field this need was unmasked by test/files/run/t7843-jsr223-service.scala, which no longer printed the output expected from the `0 to 10 foreach` Use getter.referenced to track traitsetter reify's toolbox compiler changes the name of the trait that owns the accessor between fields and constructors (`$` suffix), so that the trait setter cannot be found when doing mkAssign in constructors this could be solved by creating the mkAssign tree immediately during fields anyway, first experiment: use `referenced` now that fields runs closer to the constructors phase (I tried this before and something broke) Infer result type for `val`s, like we do for `def`s The lack of result type inference caused pos/t6780 to fail in the new field encoding for traits, as there is no separate accessor, and method synthesis computes the type signature based on the ValDef tree. This caused a cyclic error in implicit search, because now the implicit val's result type was not inferred from the super member, and inferring it from the RHS would cause implicit search to consider the member in question, so that a cycle is detected and type checking fails... Regardless of the new encoding, we should consistently infer result types for `def`s and `val`s. Removed test/files/run/t4287inferredMethodTypes.scala and test/files/presentation/t4287c, since they were relying on inferring argument types from "overridden" constructors in a test for range positions of default arguments. Constructors don't override, so that was a mis-feature of -Yinfer-argument-types. Had to slightly refactor test/files/presentation/doc, as it was relying on scalac inferring a big intersection type to approximate the anonymous class that's instantiated for `override lazy val analyzer`. Now that we infer `Global` as the expected type based on the overridden val, we make `getComment` private in navigating between good old Skylla and Charybdis. I'm not sure why we need this restriction for anonymous classes though; only structural calls are restricted in the way that we're trying to avoid. The old behavior is maintained nder -Xsource:2.11. Tests: - test/files/{pos,neg}/val_infer.scala - test/files/neg/val_sig_infer_match.scala - test/files/neg/val_sig_infer_struct.scala need NMT when inferring sig for accessor Q: why are we calling valDefSig and not methodSig? A: traits use defs for vals, but still use valDefSig... keep accessor and field info in synch
* | | Merge pull request #5327 from lrytz/2.12.xLukas Rytz2016-08-113-0/+13
|\ \ \ | |/ / |/| | SI-7187 deprecate eta-expansion of zero-arg method values
| * | SI-7187 deprecate eta-expansion of zero-arg method valuesAdriaan Moors2016-08-103-0/+13
| | | | | | | | | | | | | | | | | | | | | For backwards compatiblity with 2.11, we already don't adapt a zero-arg method value to a SAM. In 2.13, we won't do any eta-expansion for zero-arg method values, but we should deprecate first.
* | | Reduce deprecations and warningsSimon Ochsenreither2016-08-021-2/+2
|/ /
* | Merge pull request #5279 from retronym/ticket/SD-183Adriaan Moors2016-07-262-12/+28
|\ \ | | | | | | SD-183 Make refinement classes ineligible as SAMs
| * | SD-183 Make refinement classes ineligible as SAMsJason Zaugg2016-07-142-12/+28
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Only non-refinement class types need apply, which is the same restriction that we levy on parent types of a class. ``` scala> class C; class D extends C; type CD = C with D; class E extends CD <console>:11: error: class type required but C with D found class C; class D extends C; type CD = C with D; class E extends CD ^ scala> class C; class D extends C; type DC = D with C; class E extends DC <console>:11: error: class type required but D with C found class C; class D extends C; type DC = D with C; class E extends DC ^ ``` Prior to this change: ``` scala> trait T { def t(a: Any): Any }; trait U; abstract class C extends T defined trait T defined trait U defined class C ```` For indy-based lambdas: ``` scala> val tu: T with U = x => x tu: T with U = $$Lambda$1812/317644782@3c3c4a71 scala> tu: U java.lang.ClassCastException: $$Lambda$1812/317644782 cannot be cast to U ... 30 elided ``` For anon class based lambdas: ``` scala> ((x => x): C with U) <console>:14: error: class type required but C with U found ((x => x): C with U) ^ scala> implicit def anyToCWithU(a: Any): C with U = new C with U { def t(a: Any) = a } warning: there was one feature warning; re-run with -feature for details anyToCWithU: (a: Any)C with U scala> (((x: Any) => x): C with U) // SAM chosen but fails to typecheck the expansion uncurry <console>:17: error: class type required but C with U found (((x: Any) => x): C with U) // SAM chosen but fails to typecheck the expansion uncurry ^ ``` Fixes https://github.com/scala/scala-dev/issues/183 While it is tempting to special case refinement classes with no decls by flattening their parents into the parents of the lambda. But there are some subtle issues at play with lineriazation order, as Martin pointed out when I brought this up before: http://www.scala-lang.org/old/node/6817.html
* | Merge pull request #5257 from szeiger/wip/final-tuplesLukas Rytz2016-07-204-6/+6
|\ \ | | | | | | SI-7301 Make tuple classes final
| * | SI-7301 Make tuple classes finalStefan Zeiger2016-07-074-6/+6
| |/ | | | | | | | | This includes undoing the special case for `-Xfuture` introduced in https://github.com/scala/scala/pull/2299 and updating tests to take the new errors into account.
* | Deprecated and rename Some#x to Some#valueDale Wijnand2016-07-151-2/+2
| |
* | SI-9849 set privateWithin on default gettersLukas Rytz2016-07-122-0/+23
|/ | | | | | | | | | | | A default getter get the same access flag (private / protected) as the method whose default it implements. However, we forgot to set the privateWithin flag, which defines the scope in a qualified private / protected modifier. For a private[p], the default getter was therefore public, which is less restricted (a private[p] method has privateWithin set to p, but the private flag is not set). For a protected[p], the default getter was protected, which is more restricted.
* Emit trait method bodies in staticsJason Zaugg2016-06-282-0/+25
| | | | | | | | | | | | | | | | | | | | And use this as the target of the default methods or statically resolved super or $init calls. The call-site change is predicated on `-Yuse-trait-statics` as a stepping stone for experimentation / bootstrapping. I have performed this transformation in the backend, rather than trying to reflect this in the view from Scala symbols + ASTs. We also need to add an restriction related to invokespecial to Java parents: to support a super call to one of these to implement a super accessor, the interface must be listed as a direct parent of the class. The static method names has a trailing $ added to avoid duplicate name and signature errors in classfiles.
* Merge pull request #5209 from adriaanm/trait-no-native-methLukas Rytz2016-06-032-0/+8
|\ | | | | Prohibit @native method in trait
| * Prohibit @native method in traitAdriaan Moors2016-06-022-0/+8
| | | | | | | | | | | | | | On the JVM, a @native interface method results in a VerifyError. Other platforms could decide to be more permissive, but it seems like allowing them in classes is enough.
* | Merge pull request #5147 from som-snytt/issue/8667-too-many-argsAdriaan Moors2016-06-0213-45/+176
|\ \ | |/ |/| SI-8667 Improve too-many-args message
| * SI-8667 Caret at bad argSom Snytt2016-05-1313-46/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Pick the first excessive positional arg for the caret. Note that erroring on named args doesn't do the obvious thing in this regard. If `k` was removed from the signature, then `f(k=1, i=2, j=3)` doesn't tell us much about the wrong arg, because naming takes the `k=1` as an assignment, `i` as duplicate naming. No arg is deemed extra, though further inspection of the conflicting args might get there. Since assignment syntax in parens is more|less deprecated (?), no more effort is done here.
| * SI-8667 Improve too-many-args messageSom Snytt2016-05-1313-22/+136
| | | | | | | | | | | | | | | | | | | | | | | | Use removeNames to help diagnose the application. Supplement the error message with how many extra args and any other residual assignments that the user might have thought was a properly named arg. The error message is gradual: succinct for short arg lists, more verbose for longer applications. Very long arg lists are probably generated, so that message is the least colloquial.
* | Merge pull request #5076 from soc/topic/deprecations-sinceLukas Rytz2016-05-3015-46/+45
|\ \ | | | | | | Improvements to deprecations related to `since` parameter
| * | Add since arg to deprecationWarning and use itSimon Ochsenreither2016-05-292-6/+6
| | |
| * | Lower-case spelling of @deprecated messagesSimon Ochsenreither2016-05-285-14/+13
| | |
| * | SI-9084 Add `since` (if available) to deprecation warningsSimon Ochsenreither2016-05-2815-49/+49
| | |
* | | Merge pull request #5191 from som-snytt/issue/9382Lukas Rytz2016-05-302-0/+16
|\ \ \ | | | | | | | | SI-9382 Privatize enhanced x in Tuple2Zipped.Ops
| * | | SI-9382 Privatize enhanced x in Tuple2Zipped.OpsSom Snytt2016-05-252-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Probably there should be an Abide rule to avoid leaking the "underlying value" of a value class. The spec or SIP defines "underlying type" but doesn't mention the underlying value. The argument for concealing the member is that it is redundant and makes autocompletion results harder to read. Also, possibly an additional implicit might want to add a member so-named.
* | | | Merge pull request #5193 from som-snytt/issue/9794Lukas Rytz2016-05-302-1/+9
|\ \ \ \ | |_|/ / |/| | | SI-9794 Error advice uses decoded method name
| * | | SI-9794 Error advice uses decoded method nameSom Snytt2016-05-262-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | So much work went into polishing this error message, it's worth buffing the method name when it's an operator. The message now says `+` instead of `$plus`.
* | | | Merge pull request #5102 from milessabin/2.12.xJason Zaugg2016-05-278-0/+78
|\ \ \ \ | |/ / / |/| | | SI-2712 Add support for partial unification of type constructors
| * | | SI-2712 Add support for higher order unificationMiles Sabin2016-05-248-0/+78
| | | |
* | | | Rename -Yopt to -opt, -Yopt-warnings to -opt-warningsLukas Rytz2016-05-256-7/+7
| |/ / |/| | | | | | | | Keep -Yopt-inline-heuristics and -Yopt-trace unchanged
* | | Merge pull request #4935 from som-snytt/issue/8044-tickvarAdriaan Moors2016-05-244-0/+16
|\ \ \ | |/ / |/| | SI-8044 Allow binding backquoted varid in patterns
| * | SI-8044 Test for quoted not-a-varidSom Snytt2016-05-202-0/+8
| | |
| * | SI-8044 Allow binding backquoted varid in patternsSom Snytt2016-05-202-0/+8
| |/ | | | | | | | | | | | | | | | | | | | | | | | | Previously, a varid could not be backquoted, so that it was not possible to introduce variables with names such as `type` in a match expression. This commit allows backquoted varids in `case x @ _` and `case x: Int`. In neither position is a stable id accepted, that is, an id with leading uppercase. Therefore, this commit merely relaxes the backquoted varid to be taken as a normal varid in these contexts.
* | Merge pull request #5179 from liff/topic/SI-9781Adriaan Moors2016-05-232-0/+8
|\ \ | | | | | | Check left side of an assignment expression for errors; fixes SI-9781
| * | SI-9781 Don't convert erroneous expression to assignmentOlli Helenius2016-05-202-0/+8
| |/ | | | | | | | | | | | | | | | | `convertToAssignment` is triggered on a type error but it doesn't seem to really care what the error is as long as the expression can be converted to an assignment expression. This patch fixes that by checking whether the qualifier of the selection contains any errors before deciding to continue with the conversion.
* | Merge pull request #5106 from milessabin/topic/hkgadtAdriaan Moors2016-05-232-0/+66
|\ \ | | | | | | SI-9760 Fix for higher-kinded GADT refinement
| * | Added pos test with multiple cases; added neg tests.Miles Sabin2016-05-062-0/+66
| | |
* | | SI-9361 fixed assert allowing display of improved error message.Miles Sabin2016-05-142-0/+16
| |/ |/|
* | SI-9045 Error on recursive ctorSom Snytt2016-05-045-3/+18
| | | | | | | | If the constructor invokes itself, say so.