summaryrefslogtreecommitdiff
path: root/test/files/neg
Commit message (Collapse)AuthorAgeFilesLines
* deprecate Pair and TripleDen Shabalin2013-11-207-9/+9
|
* Merge pull request #3141 from soc/SI-7961Adriaan Moors2013-11-172-8/+14
|\ | | | | SI-7961 Fix false positive procedure warnings
| * SI-7961 Fix false positive procedure warningsSimon Ochsenreither2013-11-142-8/+14
| | | | | | | | | | | | | | Two issues are fixed in this commit: - `def foo: Unit` was detected as missing a return type - The warning was emitted for constructors, but `def this(...): Unit = ...` is not valid Scala syntax
* | Merge pull request #3129 from adriaanm/pr-rebase-3001Adriaan Moors2013-11-1371-182/+340
|\ \ | |/ |/| [rebase] blackbox and whitebox macros
| * blackbox restriction #4: can't customize pattern matchingEugene Burmako2013-11-124-1/+31
| | | | | | | | | | | | When an application of a blackbox macro is used as an extractor in a pattern match, it triggers an unconditional compiler error, preventing customizations of pattern matching implemented with macros.
| * blackbox restriction #3: can't affect implicit searchEugene Burmako2013-11-125-7/+36
| | | | | | | | | | | | | | | | | | When an application of a blackbox macro is used as an implicit candidate, no expansion is performed until the macro is selected as the result of the implicit search. This makes it impossible to dynamically calculate availability of implicit macros.
| * blackbox restriction #2: can't guide type inferenceEugene Burmako2013-11-124-0/+64
| | | | | | | | | | | | | | | | | | | | When an application of a blackbox macro still has undetermined type parameters after Scala’s type inference algorithm has finished working, these type parameters are inferred forcedly, in exactly the same manner as type inference happens for normal methods. This makes it impossible for blackbox macros to influence type inference, prohibiting fundep materialization.
| * blackbox restriction #1: can't refine the official return typeEugene Burmako2013-11-125-4/+28
| | | | | | | | | | | | | | | | | | | | | | When an application of a blackbox macro expands into a tree `x`, the expansion is wrapped into a type ascription `(x: T)`, where `T` is the declared return type of the blackbox macro with type arguments and path dependencies applied in consistency with the particular macro application being expanded. This invalidates blackbox macros as an implementation vehicle of type providers.
| * blackbox and whitebox macrosEugene Burmako2013-11-1257-181/+192
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the first commit in the series. This commit only: 1) Splits Context into BlackboxContext and WhiteboxContext 2) Splits Macro into BlackboxMacro and WhiteboxMacro 3) Introduces the isBundle property in the macro impl binding Here we just teach the compiler that macros can now be blackbox and whitebox, without actually imposing any restrictions on blackbox macros. These restrictions will come in subsequent commits. For description and documentation of the blackbox/whitebox separation see the official macro guide at the scaladoc website: http://docs.scala-lang.org/overviews/macros/blackbox-whitebox.html Some infrastructure work to make evolving macros easier: compile partest-extras with quick so they can use latest library/reflect/...
* | Merge pull request #3123 from som-snytt/issue/7747-scrapcodes-fixAdriaan Moors2013-11-121-6/+2
|\ \ | | | | | | SI-7747 Support class based wrappers in REPL
| * | SI-7747 Support class based wrappers clean upSom Snytt2013-11-101-6/+2
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simplified the code paths to just use one of two `Wrapper` types for textual templating. Simplified the class-based template to use the same `$iw` name for the both the class and the wrapper value. In addition, the $read value is an object extending $read, instead of containing an extra instance field, which keeps paths to values the same for both templates. Both styles trigger loading the value object by referencing the value that immediately wraps the user code, although for the class style, inner vals are eager and it would suffice to load the enclosing `$read` object. The proposed template included extra vals for values imported from history, but this is not necessary since such an import is always a stable path. (Or, counter-example to test is welcome.) The test for t5148 is updated as a side effect. Probably internal APIs don't make good test subjects. Modify -Y option message.
* / Make parameters to implicit value classes privateJason Zaugg2013-11-121-2/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So that they aren't offered as an autocomplete suggestion: implicit class Shouty(string: String) extends AnyVal { def SHOUT_! = string.toUpperCase + "!" } "". // autocompletion offers `.string` here The original incarnation of value classes didn't allow this sort of encapsulation, so we either invented goofy names like `__thingToAdd` or just picked `x` or `self`. But SI-7859 has delivered us the freedom to keep the accessor private. Should we keep any of these accessors around in a deprecated form? The implicit classes in Predef were added in 2.11.0-M2 (c26a8db067e4f), so they are okay. I think we can make reason that these APIs were both accidental and unlikely to be interpreted as public, so we can break them immediately. scala> Left(1).x res0: scala.util.Either[Int,Int] = Left(1) scala> import concurrent.duration._ import concurrent.duration._ scala> 1.n res1: Int = 1
* Parser stack reduction peekingAheadSom Snytt2013-11-082-5/+8
| | | | | | | | Restores a form of the previous peekAhead bookkeeping. Instead of tracking the current token and offset outside of xxxAhead, peekingAhead uses `in.prev` and will push back if the operation results in an empty tree.
* Parser stack reduction discussionSom Snytt2013-11-085-13/+13
| | | | Check files
* Rewrites the parser stack reduction logic.Paul Phillips2013-11-083-9/+6
| | | | | | | Centralizes the scattered logic surrounding erroneous pattern syntax. Consolidates the redundant lookahead implementations. Eliminates var manipulation in favor of recursion.
* Force several tests to run using inline delambdafication.James Iry2013-11-063-0/+3
| | | | | | The differences when running with method based delambdafication aren't important enough yet to create specialized versions that use method based delambdafication.
* Create test variants where delambdafication alters signatures.James Iry2013-11-064-0/+32
| | | | | | This commit includes several tests where there's a variation in signatures between inline delambdafication and method based delambdafication.
* Add a skeletal Delambdafy phase.James Iry2013-11-014-44/+48
| | | | | | This commit adds a do-nothing phase called "Delambdafy" that will eventually be responsible for doing the final translation of lambdas into classes.
* Merge pull request #3076 from soc/SI-7605-deprecate-proceduresJames Iry2013-10-293-0/+18
|\ | | | | SI-7605 Deprecate procedure syntax
| * SI-7605 Deprecate procedure syntaxSimon Ochsenreither2013-10-243-0/+18
| | | | | | | | | | | | | | | | | | | | This commit covers three cases: - constructor definitions (def this {...}) - concrete method definitions (def foo {...}) - abstract method declarations (def foo) The deprecation is currently hidden behind -Xfuture pending IDE support for migrating users from procedures to methods.
* | Merge pull request #3082 from retronym/ticket/6385Grzegorz Kossakowski2013-10-296-20/+21
|\ \ | | | | | | SI-6385 Avoid bridges to identical signatures over value classes
| * | SI-6385 Avoid bridges to identical signatures over value classesJason Zaugg2013-10-286-20/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As Paul noted in the comments to SI-6260 (from which I mined some test cases) "there is no possible basis for conflict here": scala> class C[A](val a: Any) extends AnyVal defined class C scala> class B { def x[A](ca: C[A]) = () } defined class B scala> class D extends B { override def x[A](ca: C[A]) = () } <console>:8: error: bridge generated for member method x: [A](ca: C[A])Unit in class D which overrides method x: [A](ca: C[A])Unit in class B clashes with definition of the member itself; both have erased type (ca: Object)Unit class D extends B { override def x[A](ca: C[A]) = () } ^ What was happening? Bridge computation compares `B#x` and `D#x` exitingErasure, which results in comparing: ErasedValueType(C[A(in B#x)]) =:= ErasedValueType(C[A(in D#x)]) These types were considered distinct (on the grounds of the unique type hash consing), even though they have the same erasure and involve the same value class. That triggered creation of an bridge. After post-erasure eliminates the `ErasedValuedType`s, we find that this marvel of enginineering is bridges `(Object)Unit` right back onto itself. The previous resolution of SI-6385 (d435f72e5fb7fe) was a test case that confirmed that we detected the zero-length bridge and reported it nicely, which happened after related work in SI-6260. But we can simply avoid creating in it in the first place. That's what this commit does. It does so by reducing the amount of information carried in `ErasedValueType` to the bare minimum needed during the erasure -> posterasure transition. We need to know: 1. which value class wraps the value, so we can box and unbox as needed 2. the erasure of the underlying value, which will replace this type in post-erasure. This construction means that the bridge above computation now compares: ErasedValueType(C, Any) =:= ErasedValueType(C, Any]) I have included a test to show that: - we don't incur any linkage or other runtime errors in the reported case (run/t6385.scala) - a similar case compiles when the signatures align (pos/t6260a.scala), but does *not* compile when the just erasures align (neg/t6260c.scala) - polymorphic value classes continue to erase to the instantiated type of the unbox: (run/t6260b.scala) - other cases in SI-6260 remains unsolved and indeed unsolvable without an overhaul of value classes: (neg/t6260b.scala) In my travels I spotted a bug in corner case of null, asInstanceOf and value classes, which I have described in a pending test.
* | | Remove orphaned check files and flags files.Jason Zaugg2013-10-274-15/+0
|/ / | | | | | | (for f in $(find test -name '*.check' -o -name '*.flags'); do bare=$(echo $f | sed -E 's/\.\w+$//'); ([[ -f "$bare" ]] || [[ -d "$bare" ]] || [[ -f "$bare.scala" ]] || [[ -f "$bare.test" ]] || echo $f) done;) | xargs rm
* | Update description of explicitouter phase.Jason Zaugg2013-10-244-4/+4
| | | | | | | | Patern translation now happens earlier.
* | Merge pull request #3026 from retronym/ticket/3871Jason Zaugg2013-10-234-0/+242
|\ \ | |/ |/| Tests for protected access
| * SI-3871 Testing protected access against the specJason Zaugg2013-10-232-0/+224
| | | | | | | | | | I've marked a few minor cases in the test with !!! where I believe the behaviour goes beyond the spec.
| * SI-3871 Missing test case for protected bug.Jason Zaugg2013-10-092-0/+18
| | | | | | | | c39f26382dddaa7 fixed the bug but didn't commit a test case.
* | Merge pull request #3070 from xeno-by/topic/macro-impl-wrong-shapeJason Zaugg2013-10-238-1/+21
|\ \ | | | | | | better macro impl shape errors
| * | better macro impl shape errorsEugene Burmako2013-10-238-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the advent of quasiquotes, we allowed both arguments and return types of macro impls to be c.Tree's (as opposed to traditional c.Expr[T]'s). This warrants an update of macro def <-> macro impl signature mismatch errors that include a printout of suggested macro impl signatures. Now along with a signature that contains exprs, we suggest another signature that has all exprs replaced by trees
* | | Merge pull request #3068 from retronym/ticket/7020-3-1Jason Zaugg2013-10-233-0/+50
|\ \ \ | | | | | | | | Deterministic warnings for pattern matcher, take 2
| * | | SI-7020 Deterministic warnings for pattern matcher, take 2Jason Zaugg2013-10-223-0/+50
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous swing at determinism, ebb01e05cbe4, made decent contact but apparently didn't hit it out of the park. The test wavered every hundred or so runs, as witnessed occasionally in nightly builds or pull request validation. I setup a test to run neg/7020.scala a few hundred times, and could trigger the failure reliably. I then swept through the pattern matcher in search of HashMap and HashSet creation, and changed them all to the Linked variety. The results of that are published in retronym#ticket/7020-3 [1]. This commit represents the careful whittling down of that patch to the minimal change required to exhibit determinism. [1] https://github.com/retronym/scala/compare/ticket/7020-3
* | | Merge pull request #3060 from harrah/t7519-bJason Zaugg2013-10-233-0/+28
|\ \ \ | | | | | | | | SI-7519: Additional test case covering sbt/sbt#914
| * | | SI-7519: Additional test case covering sbt/sbt#914Mark Harrah2013-10-203-0/+28
| |/ /
* | | Merge pull request #3047 from xeno-by/topic/deprecateEugene Burmako2013-10-2213-47/+39
|\ \ \ | |/ / |/| | deprecates raw tree manipulation facilities in macros.Context
| * | changes some manual tree constructions in macro tests to quasiquotesEugene Burmako2013-10-1813-47/+37
| | |
| * | deprecates raw tree manipulation facilities in macros.ContextEugene Burmako2013-10-186-18/+20
| | |
* | | Merge pull request #3007 from densh/pull/fresh-name-and-package-supportEugene Burmako2013-10-192-3/+3
|\ \ \ | | | | | | | | Add support for packages into quasiquotes and toolbox, improve handling of fresh names, unhardcode quasiquote expansion logic
| * | | eliminate isCaseDefEnd override by moving the logic into stock parserDen Shabalin2013-10-181-1/+1
| | | |
| * | | SI-6841 SI-6657 add support for packages into quasiquotes and toolboxDen Shabalin2013-10-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | In order to implement this a new parser entry point `parseStatsOrPackages` that augments current parseStats with ability to parse "package name { ... }" syntax.
* | | | Merge pull request #3051 from retronym/merge/2.10.x-to-master-4Grzegorz Kossakowski2013-10-193-50/+0
|\ \ \ \ | |_|/ / |/| | | Merge 2.10.x to master (again)
| * | | Merge remote-tracking branch 'origin/2.10.x' into merge/2.10.x-to-master-4Jason Zaugg2013-10-183-50/+0
| |\ \ \
| | * | | Disable tests for SI-7020Jason Zaugg2013-10-173-48/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These are still impudently being non-deterministic. I've reopened the ticket so we can take another swing at it. A well targetted s/HashMap/LinkedHashMap/ will almost certainly be the salve. fail - neg/t7020.scala [output differs]% scalac t7020.scala t7020.scala:3: warning: match may not be exhaustive. It would fail on the following inputs: List((x: Int forSome x not in (1, 2, 4, 5, 6, 7))), List((x: Int forSome x not in (1, 2, 4, 5, 6, 7)), _), List(1, _), List(2, _), List(4, _), List(5, _), List(6, _), List(7, _), List(??, _), List(_, _) List(5) match { ^ t7020.scala:10: warning: match may not be exhaustive. It would fail on the following inputs: List((x: Int forSome x not in (1, 2, 4, 5, 6, 7))), List((x: Int forSome x not in (1, 2, 4, 5, 6, 7)), _), List(1, _), List(2, _), List(4, _), List(5, _), List(6, _), List(7, _), List(??, _), List(_, _) List(5) match { ^
* | | | | Merge pull request #3030 from xeno-by/topic/fundep-viewsEugene Burmako2013-10-1811-35/+138
|\ \ \ \ \ | |/ / / / |/| | | | SI-3346 implicit parameters can now guide implicit view inference
| * | | | SI-3346 implicit parameters can now guide implicit view inferenceEugene Burmako2013-10-1111-35/+138
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This simple patch makes it possible for implicit views to benefit from fundep-guided type inference, eliminating a nasty special case in implicit inference. Here are the changes that I had to apply to the tests (they exposed quite a number of interesting questions that I was happy to answer): 1) neg/t5845.scala now works, so I moved it to pos. That easily makes sense, because the test was just a canary to track previous state of things. 2) neg/divergent_implicit.scala, neg/t5578.scala and neg/t7519.scala changed their messages to less informative ones, because inapplicable implicit views now get disqualified early and therefore don't display their error messages to the user. This is an unfortunate but necessary byproduct of this change, and one can argue that the behavior is now completely consistent with implicit vals (that also don't explain why this or that implicit val got disqualified, but rather display a generic implicit value not found message). 3) scaladoc/implicits-chaining.scala and scaladoc/implicits-base.scala. Immediate culling of apriori inapplicable implicit views messes things up for Scaladoc, because it's interested in potentially applicable views, having infrastructure to track various constraints (type bounds, requirements for implicit parameters, etc) that guide applicability of views and then present it to the user. Therefore, when scaladoc is detected, implicit search reverts to the old behavior. 4) We still cannot have Jason's workaround to type constructor inference mentioned in comments to SI-3346, because it's not really about implicit parameters of implicit views, but about type inference flowing from the implicit parameter list to a preceding parameter list in order to affect inference of an implicit view. This is something that's still too ambitious.
* | | | | Merge pull request #3041 from gkossakowski/merge-2.10.xJason Zaugg2013-10-183-0/+34
|\ \ \ \ \ | | | | | | | | | | | | Merge 2.10.x into master
| * \ \ \ \ Merge remote-tracking branch 'scala/2.10.x' into merge-2.10.xGrzegorz Kossakowski2013-10-163-0/+34
| |\ \ \ \ \ | | | |/ / / | | |/| | | | | | | | | | | | | | | | | | | | | Conflicts: build.number test/files/neg/classmanifests_new_deprecations.check
| | * | | | SI-7783 Don't issue deprecation warnings for inferred TypeTreesJason Zaugg2013-09-274-7/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Deprecation checks in RefChecks were looking into all TypeTrees to find references to deprecated type aliases. However, when the compiler infers a type argument or type of a member it creates a TypeTree (with a null original) that was also leading to warnings. I ran into this problem often when upgrading a build from SBT 0.12 to 0.13: a plugin I was using used the deprecated type alias, and I suffered transitively when I used methods from its API. This commit disables the checks for inferred TypeTree-s.
* | | | | | Test cases for SAM restrictions.Jason Zaugg2013-10-173-0/+95
|/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Only one seems to indicate something new: ((x: Int) => 0): NonClassType I believe that we shouldn't pursue SAM translation for that case, and fallthrough to Function1. That would allow for an implicit view to finish the job.
* | | | | Merge remote-tracking branch 'scala/master' into fix-merge-3018Grzegorz Kossakowski2013-10-1440-69/+220
|\ \ \ \ \ | | |_|/ / | |/| | | | | | | | | | | | | Conflicts: src/compiler/scala/tools/nsc/typechecker/Typers.scala
| * | | | Merge pull request #3032 from retronym/ticket/7239-testPaul Phillips2013-10-122-0/+16
| |\ \ \ \ | | | | | | | | | | | | SI-7239 A bonus test case from [scala-user]
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-05 06:02:33 +0000