summaryrefslogtreecommitdiff
path: root/test/files/neg
Commit message (Collapse)AuthorAgeFilesLines
* addresses pull request feedbackEugene Burmako2014-01-201-1/+1
|
* SI-8158 compiler hangs printing out fancy typesEugene Burmako2014-01-203-0/+52
| | | | | | | | | | | | | | | Apparently, even though the compiler has safeguards against infinite type printouts, having a depth counter, we didn’t account for the cases when printouts are both self-referential and self-multiplying. For one, SI-8158 provides an example of such a type, which is a structural type that refers to itself twice in return types of its methods. At first, printing such a type would go deeper and deeper, but then it will hit the depth limit and start multiply indefinitely. This commit fixes this particular problem by recognizing self-references as this.type’s and printing them out as such. The subsequent commit will introduce a more general facility.
* Merge commit 'aefe3fb844' into merge-2.10.xAdriaan Moors2014-01-172-0/+12
|\
| * SI-6563 Test case for already-fixed crasherJason Zaugg2014-01-062-0/+12
| | | | | | | | Progressed to working in SI-7636 / c4bf1d5.
| * [nomaster] codifies the state of the art wrt SI-8104Eugene Burmako2013-12-286-0/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | As it was discovered in SI-8104, whiteboxity doesn’t apply equally to type parameters and type members of materialized type classes. During implicit search and subsequent type inference, whitebox type parameters are consistently erased to wildcards, whereas whitebox type members sometimes remain as is and get in the way of signature conformance checks. Unfortunately, 2.10.x can’t make use of type parameter whiteboxity, because it requires fundep materializers that were only merged into 2.11: https://github.com/scala/scala/pull/2499, and therefore Si-8104 seems to be a hard blocker for 2.10.x at the moment. Stay tuned for updates.
* | Merge commit '97b9b2c06a' from 2.10.x into masterAdriaan Moors2014-01-172-12/+0
|\| | | | | | | | | | | | | | | | | Check files updated: test/files/presentation/t8085*.check Conflicts: build.xml src/compiler/scala/tools/nsc/ast/parser/Parsers.scala src/compiler/scala/tools/nsc/symtab/classfile/ICodeReader.scala
| * Revert "SI-6426, importable _."Adriaan Moors2013-12-102-12/+0
| | | | | | | | | | | | | | This reverts commit d2316df920ffa4804fe51e8f8780240c46efa982. We can't make `_` an illegal identifier -- it's legal in Java, so we must be able to name these Java underscores.
| * [nomaster] better error messages for various macro definition errorsEugene Burmako2013-12-0618-24/+18
| | | | | | | | backport of 1d3ec4e708154ec05554f540d7d68ed55dc12426
* | Merge pull request #3380 from retronym/ticket/8157Adriaan Moors2014-01-172-0/+8
|\ \ | | | | | | Make overloading, defaults restriction PolyType aware
| * | SI-8157 Make overloading, defaults restriction PolyType awareJason Zaugg2014-01-172-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Named/Default args levies an implementation restriction that only one overloaded alternative may declare defaults. But, this restriction failed to consider polymorphic methods. Rather than matching on MethodType, this commit uses `Type#paramms`, which handles PolyTypes and curried MethodTypes in one fell swoop.
* | | Merge pull request #3283 from paulp/pr/dotless-targsAdriaan Moors2014-01-172-0/+9
|\ \ \ | |/ / |/| | Dotless type application for infix operators.
| * | Dotless type application for infix operators.Paul Phillips2013-12-172-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you have an aesthetic expresion like def f(xs: Iterator[Int]) = ( xs takeWhile (_ < 1000) map (_ * -1) filter (_ % 2 == 0) flatMap (x => List(x, x)) reduceOption (_ + _) maxBy (_.toString) ) And then for whatever reason you have to perform explicit type application in the midst of that expression, it's aggravating in the extreme that it has (had) to be rewritten in its entirety to accommodate that change. So now you can perform type application in the middle of it. For reasons not entirely clear to me postfix operators are excluded. The discussion as well as the approval for the infix variation of it can be found at: https://groups.google.com/forum/#!msg/scala-language/eJl1wnkEz9M/hR984-lqC5EJ
* | | Merge pull request #3293 from soc/SI-7469Adriaan Moors2014-01-152-2/+2
|\ \ \ | | | | | | | | Remove misc. @deprecated elements
| * | | SI-7469 Remove misc. @deprecated elementsSimon Ochsenreither2014-01-092-2/+2
| | | |
* | | | Merge pull request #3285 from som-snytt/issue/8015-FF-NLsAdriaan Moors2014-01-155-0/+32
|\ \ \ \ | | | | | | | | | | Count lines by EOLs
| * | | | SI-8015 Unprintables in messagesSom Snytt2014-01-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The line content to display should include the whole line, inclusive of embedded line breaks, and any control chars should be displayed in unicode escape.
| * | | | SI-8015 Count lines by EOLsSom Snytt2014-01-085-0/+32
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | Source lines were counted by "line break chars", including FF. Clients of `pos.line` seem to all expect the ordinary line num, so that is what they get. Unicode processing now precedes line ending processing.
* | | | Merge pull request #3260 from soc/SI-8035Adriaan Moors2014-01-158-5/+64
|\ \ \ \ | | | | | | | | | | Deprecate automatic () insertion in argument lists
| * | | | SI-8035 Deprecate automatic () insertion in argument listsSimon Ochsenreither2014-01-098-5/+64
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This promotes the () insertion warning from -Ywarn-adapted-args to a deprecation warning. -Xfuture tunrs it into a compiler error. Auto tupling remains unchanged for now. The tests have been fixed the following way: - Warnings caused by general sloppiness (Try(), Future(), ...) have been fixed. - Warnings which raise interesting questions (x == (), ...) received an updated checkfile for now.
* | | | Merge pull request #3363 from retronym/ticket/8146Jason Zaugg2014-01-154-0/+33
|\ \ \ \ | | | | | | | | | | Fix non-deterministic <:< for deeply nested types
| * | | | SI-8146 Test cases for typechecking decidabilityJason Zaugg2014-01-144-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Taken from "On Decidability of Nominal Subtyping with Variance" (Pierce, Kennedy), which was implemented in 152563b. Part of the implementation (SubTypePair) will be changed in the following commit to fix the non-deterministic errors typechecking heavily nested types involving aliases or annotations.
* | | | | Merge pull request #3355 from xeno-by/topic/saturday-nightJason Zaugg2014-01-1469-260/+224
|\ \ \ \ \ | | | | | | | | | | | | reshuffles names for blackbox/whitebox contexts, changes bundle notation
| * | | | | prohibits constructor overloading for macro bundlesEugene Burmako2014-01-123-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per Jason’s feedback, this commit handles overloaded constructors in macro bundles. The backend now checks that we have a constructor of a correct type. The frontend now prohibits multiple constructors altogether.
| * | | | | changes bundles to be classes, not traits extending MacroEugene Burmako2014-01-1215-68/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adjusts bundle notation to read `class Bundle(val c: Context)` instead of `class Bundle extends Macro`. This avoids calling compileLate in the macro compiler and associated tooling problems.
| * | | | | *boxContext => *box.Context , *boxMacro => *box.MacroEugene Burmako2014-01-1264-213/+212
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Performs the following renamings: * scala.reflect.macros.BlackboxContext to scala.reflect.macros.blackbox.Context * scala.reflect.macros.BlackboxMacro to scala.reflect.macros.blackbox.Macro * scala.reflect.macros.WhiteboxContext to scala.reflect.macros.whitebox.Context * scala.reflect.macros.WhiteboxMacro to scala.reflect.macros.whitebox.Macro https://groups.google.com/forum/#!topic/scala-internals/MX40-dM28rk
* | | | | Merge pull request #3275 from paulp/pr/patmatAdriaan Moors2014-01-1312-41/+151
|\ \ \ \ \ | | | | | | | | | | | | Improves name-based patmat.
| * | | | | SI-7850 CCE in patmat with invalid isEmpty.Paul Phillips2013-12-154-9/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Name-based pattern matcher needed some hardening against unapply methods with the right name but wrong types. Only isEmpty methods which return Boolean are acceptable. Catching it directly rather than indirectly also allowed for better error messages.
| * | | | | SI-7897, SI-6675 improves name-based patmatPaul Phillips2013-12-159-32/+119
| | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This emerges from a recent attempt to eliminate pattern matcher related duplication and to bake the scalac-independent logic out of it. I had in mind something a lot cleaner, but it was a whole lot of work to get it here and I can take it no further. Key file to admire is PatternExpander.scala, which should provide a basis for some separation of concerns. The bugs addressed are a CCE involving Tuple1 and an imprecise warning regarding multiple pattern crushing. Editorial: auto-tupling unapply results was a terrible idea which should never have escaped from the crib. It is tantamount to purposely throwing type safety down the toilet in the very place where people need type safety the most. See SI-6111 and SI-6675 for some other comments.
* | | | | Merge pull request #3184 from retronym/ticket/2066Adriaan Moors2014-01-134-0/+112
|\ \ \ \ \ | |_|/ / / |/| | | | SI-2066 Plug a soundness hole higher order type params, overriding
| * | | | SI-2066 Plug a soundness hole higher order type params, overridingJason Zaugg2013-11-274-0/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PolyType-s parameterized by higher order type parameters (HOTPs) should only be relatable with <:< or =:= if the variances of their type parameters line up. This is only enforced for HOTPs defined in method type arguments. Invariant type parameters subsume variant ones. Concretely, as described by @S11001001: > A method taking [F[_]] can implement a method taking [F[+_]]. > Likewise, a method taking [F[_[+_]]] can implement a method > taking [F[_[_]]], as with [F[_[_[_]]]] implementing [F[_[_[+_]]]], > and so on, the variance subsumption flipping at each step. > > This is just the opposite of the variance for passing type > parameters to either instantiate types or call methods; a F[+_] > is a suitable F[_]-argument, a F[_[_]] a suitable F[_[+_]]-argument, > and so on. > > All of the above rules can be duplicated for contravariant positions > by substituting - for +. Also, something similar happens for > weakening/strengthening bounds, I believe. These cases are tested in the `// okay` lines in `neg/t2066.scala`.
* | | | | Merge pull request #3235 from xeno-by/topic/macro-plugin-interfaceEugene Burmako2014-01-087-1/+59
|\ \ \ \ \ | |_|_|/ / |/| | | | new hooks in AnalyzerPlugins to enable macro experimentation
| * | | | hooks for naming and synthesis in Namers.scala and Typers.scalaEugene Burmako2013-12-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Interestingly enough, despite of the implementation surface being quite noticeable, it is enough to hijack just `enterSym` and typechecking of stats for packages, templates and blocks in order to enable macro annotations. That and `ensureCompanionObject`, which I couldn't abstract away so far. An architectural note: given that a hooked method is called `X`, there are two implementations of this method. `pluginsX` is defined in AnalyzerPlugins.scala and lets macro plugins customize `X`. `standardX` is defined next to `X` and provides a default implementation. Finally `X` is changed to trivially forward to `pluginsX`. Existing and future callers of `X` now can be completely oblivious of the introduced hooks, because calls to `X` will continue working and will be correctly hooked. This makes the infrastructure more robust. The only downside is that in case when a macro plugin wants to call into the default implementation, it needs to call `standardX`, because `X` will lead to a stack overflow. However, in my opinion this not a big problem, because such failures are load and clear + for every `pluginsX` we actually provide documentation that says what is its standard impl is.
| * | | | humane reporting of macro impl binding version errorsEugene Burmako2013-12-306-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Macro defs are linked to macro impls by the virtue of MacroImplBinding structures that are persisted between compilation runs serialized within instances of macroImpl annotations. Along with the evolution of our macro engine, we sometimes have to evolve the format of MacroImplBinding, which means that it has to be versioned. Version mismatches are checked upon every macro expansion, ensuring that macros that we expand were compiled with exactly the same version of the macro engine that we’re running. That’s all really cool apart from the fact that version mismatches result in aborting the entire compilation with an obscure message without giving a hint about the culprits. This commit improves the situation by providing pretty per-expansion compilation errors that tell the programmer what macro expansions are at fault and what macro engines were used to compile them.
| * | | | macroExpandApply => macroExpandEugene Burmako2013-12-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Back then, when we needed separate macro expanders for both applications and unapplications, it made sense to have two different methods that do macro expansions. However, after @paulp’s upgrade of the pattern matching engine, we no longer need a dedicated expander for unapply, so I’m removing it and renaming `macroExpandApply` to just `macroExpand`.
* | | | | Merge pull request #3239 from soc/SI-8052Jason Zaugg2014-01-031-20/+33
|\ \ \ \ \ | |/ / / / |/| | | | SI-8052 Disallow `macro` as an identifier
| * | | | SI-8052 Disallow `macro` as an identifierSimon Ochsenreither2013-12-091-20/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note that the change could look a lot cleaner, at the cost of returning more generic error messages. I decided that at least for 2.11 I'll keep scalac remembering that macro was a standard identifier name once, so that we can point out more precisely what's wrong with users' code.
* | | | | Merge pull request #3288 from xeno-by/topic/f-interpolatorJason Zaugg2013-12-306-2/+36
|\ \ \ \ \ | | | | | | | | | | | | makes boxity of fast track macros configurable
| * | | | | makes boxity of fast track macros configurableEugene Burmako2013-12-196-2/+36
| | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, all built-in macros were assumed to be whitebox, but that’s actually not the case. Just quasiquote macros have to be whitebox, while the rest can be blackbox. This also fixes SI-8091, because blackbox macros are typechecked differently and therefore the necessary implicit conversion kicks in. If `f”...”` were to remain a whitebox macro, then due to the changes introduced in commit https://github.com/scala/scala/commit/a3b33419b02cafb7e2c6fed6dd96151859fc7d77 we would have to explicitly ascribe its expansion as String to achieve the same effect. After I made reify blackbox, several tests had to be changed, because we now explicitly ascribe the expansion with `c.Expr[T]`, which changes `toString`. Also, a number of less obvious corrections had to be applied, because things like `reify(<constant>).splice` have stopped being optimized away due to `reify(<constant>)` no longer having a narrow `c.Expr[<constant>.type]`, making it ineligible for constant folding. Moreover, this change forced me to adjust our approach to positioning blackbox wrappings, because after being changed to blacbox and starting using wrappings, f”...” interpolators used in the compiler started crashing -Yrangepos builds. Now wrapping Typed nodes are assigned with transparent positions.
* | | | | Merge pull request #3309 from xeno-by/topic/expand-dynamicJason Zaugg2013-12-304-0/+30
|\ \ \ \ \ | | | | | | | | | | | | SI-7777 SI-8006 assorted fixes for dynamics
| * | | | | SI-8006 prevents infinite applyDynamicNamed desugaringsEugene Burmako2013-12-284-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since mkInvoke, the applyDynamic/selectDynamic/etc desugarer, is disconnected from typedNamedApply, the applyDynamicNamed argument rewriter, the latter doesn’t know whether it needs to apply the rewriting because the application has just been desugared or it needs to hold on because it’s already performed a desugaring on this tree. This commit introduces the attachment that links these translation facilities, preventing infinite applyDynamicNamed desugarings.
* | | | | | Merge pull request #3311 from xeno-by/topic/fine-points-of-whiteboxity-masterEugene Burmako2013-12-283-0/+36
|\ \ \ \ \ \ | | | | | | | | | | | | | | (master) codifies the state of the art wrt SI-8104
| * | | | | | codifies the state of the art wrt SI-8104Eugene Burmako2013-12-283-0/+36
| |/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As it was discovered in SI-8104, whiteboxity doesn’t apply equally to type parameters and type members of materialized type classes. During implicit search and subsequent type inference, whitebox type parameters are consistently erased to wildcards, whereas whitebox type members sometimes remain as is and get in the way of signature conformance checks.
* / / / / / SI-6355 SI-7059 it is possible to overload applyDynamicEugene Burmako2013-12-285-7/+35
|/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As our discussion at https://issues.scala-lang.org/browse/SI-6355 shows, it looks like it is possible to overload applyDynamic, even though a straightforward way is closed. This commit codifies the pattern proposed by @paulp and makes sure that it doesn’t break in the future.
* | | | | Merge pull request #3276 from som-snytt/issue/6120-spurious-checkAdriaan Moors2013-12-194-31/+4
|\ \ \ \ \ | | | | | | | | | | | | SI-6120 Suppress extra warnings
| * | | | | SI-6120 Suppress extra warningsSom Snytt2013-12-164-31/+4
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a mere polish for the fix to allow multiple warnings. Sensibility checks in refchecks were shown to be redundant. This commit includes a mild refactor to reduce tabbage, and uses a local var to flag that a warning has already been emitted. It would be better to have the checks return true if warned, to facilitate `nonSensically || unrelatedly`, etc., but that's a lot of `else false`. The check files that were updated with the redundant warnings are reverted.
* / / / / SI-5508 Fix crasher with private[this] in nested traitsJason Zaugg2013-12-193-22/+0
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, accessors for private local trait fields are added very late in the game when the `Mixin` tree transformer treats the trait. By contrast, fields with weaker access have accessors created eagerly in `Namers`. // Mixin#addLateInterfaceMembers val getter = member.getter(clazz) if (getter == NoSymbol) addMember(clazz, newGetter(member)) `addMember` mutates the type of the interface to add the getter. (This seems like a pretty poor design: usually if a phase changes types, it should do in an `InfoTransformer`.) However, if an inner class or anonymous function of the trait has been flattened to a spot where it precedes the trait in the enclosing packages info, this code hasn't had a chance to run, and the lookup of the getter crashes as mixins `postTransform` runs over a selection of the not-yet-materialized getter. // Mixin#postTransform case Select(qual, name) if sym.owner.isImplClass && !isStaticOnly(sym) => val iface = toInterface(sym.owner.tpe).typeSymbol val ifaceGetter = sym getter iface This commit ensures that `Flatten` lifts inner classes to a position *after* the enclosing class in the stats of the enclosing package. Bonus fix: SI-7012 (the followup ticket to SI-6231 / SI-2897)
* | | | Merge pull request #3258 from ↵Adriaan Moors2013-12-132-2/+2
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | jrudolph/w/fix-typo-that-that-occurs-twice-in-error-messages fix typo in error messages
| * | | | fix typo in error messagesJohannes Rudolph2013-12-102-2/+2
| | | | |
* | | | | Merge pull request #3204 from retronym/topic/patmat-classtag-compoundAdriaan Moors2013-12-133-0/+24
|\ \ \ \ \ | | | | | | | | | | | | Test case for recently improved unchecked warning
| * | | | | Test case for recently improved unchecked warningJason Zaugg2013-12-123-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to https://github.com/scala/scala/pull/2848, the enclosed test compiled without warning and printed: true false Features interacting: - implicit class tags to enable type patterns on abstract types - type tests on compound types. I think the unchecked warning is acceptable for now.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-12 01:50:08 +0000