summaryrefslogtreecommitdiff
path: root/test/files/pos
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #3367 from retronym/backport/3363Jason Zaugg2014-01-202-0/+86
|\ | | | | [nomaster] Fix non-deterministic <:< for deeply nested types
| * [nomaster] SI-8146 Fix non-deterministic <:< for deeply nested typesJason Zaugg2014-01-152-0/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backported from master. This is a squashed commmit comprising: SI-8146 Pending test, diagnosis for bug in decidability of <:< (cherry picked from commit 8beeef339ad65f3308ece6fb0440cdb31b1ad404) SI-8146 Test cases for typechecking decidability 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. (cherry picked from commit 2e28cf7f76c3d5fd0c2df4274f1af9acb42de699) SI-8146 Fix non-deterministic <:< for deeply nested types In the interests of keeping subtyping decidable [1], 152563b added some bookkeeping to `isSubType` to detect cycles. However, this was based on a hash set containing instances of `SubTypePair`, and that class had inconsistencies between its `hashCode` (in terms of `Type#hashCode`) and `equals` (in terms of `=:=`). This inconsistency can be seen in: scala> trait C { def apply: (Int @unchecked) } defined trait C scala> val intUnchecked = typeOf[C].decls.head.info.finalResultType intUnchecked: $r.intp.global.Type = Int @unchecked scala> val p1 = new SubTypePair(intUnchecked, intUnchecked) p1: $r.intp.global.SubTypePair = Int @unchecked <:<? Int @unchecked scala> val p2 = new SubTypePair(intUnchecked.withoutAnnotations, intUnchecked.withoutAnnotations) p2: $r.intp.global.SubTypePair = Int <:<? Int scala> p1 == p2 res0: Boolean = true scala> p1.hashCode == p2.hashCode res1: Boolean = false This commit switches to using `Type#==`, by way of the standard case class equality. The risk here is that you could find a subtyping computation that progresses in such a manner that we don't detect the cycle. It would need to produce an infinite stream of representations for types that were `=:=` but not `==`. If that happened, we'd fail to terminate, rather than judging the relationship as `false`. [1] http://research.microsoft.com/pubs/64041/fool2007.pdf (cherry picked from commit a09e143b7fd1c6b433386d45e9c5ae3548819b59) Conflicts: src/reflect/scala/reflect/internal/tpe/TypeComparers.scala src/reflect/scala/reflect/runtime/JavaUniverseForce.scala
* | Merge pull request #3356 from retronym/ticket/8138Jason Zaugg2014-01-181-0/+24
|\ \ | | | | | | Fix bug with super-accessors / dependent types
| * | SI-8143 Fix bug with super-accessors / dependent typesJason Zaugg2014-01-121-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Super-accessors are generated as `DefDef`'s with `EmptyTree` as a placeholder for the RHS. This is filled in later in `Mixin` in `completeSuperAccessor`. A change in `Uncurry` (SI-6443 / 493197f), however, converted this to a `{ EmptyTree }`, which evaded the pattern match in mixin. This commit adds a special case to the dependent method treatment in Uncurry to avoid generating redundant blocks.
* | | Merge pull request #3364 from retronym/ticket/8152Jason Zaugg2014-01-151-0/+13
|\ \ \ | |_|/ |/| | [nomaster] Backport variance validator performance fix
| * | [nomaster] SI-8152 Backport variance validator performance fixJason Zaugg2014-01-141-0/+13
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | % time qbin/scalac test/files/pos/t8146-performance.scala real 0m2.015s user 0m2.892s sys 0m0.215s % time scalac-hash v2.10.3 test/files/pos/t8146-performance.scala real 1m13.652s user 1m14.245s sys 0m0.508s Cherry-picks one hunk from 882f8e64.
* / SI-8111 Repair symbol owners after abandoned named-/default-argsJason Zaugg2014-01-061-0/+24
|/ | | | | | | | | | | | | | | | | | Names/Defaults eagerly transforms an application with temporaries to maintain evaluation order, and dutifully changes owners of symbols along the way. However, if this approach doesn't work out, we throw away this and try a auto-tupling. However, we an still witness symbols owned by the temporaries. This commit records which symbols are owned by the context.owner before `transformNamedApplication`, and rolls back the changes before `tryTupleApply`. Perhaps a better approach would be to separate the names/defaults applicability checks from the evaluation-order-preserving transform, and only call the latter after we have decided to go that way.
* Merge pull request #3253 from retronym/ticket/8062Adriaan Moors2013-12-113-0/+9
|\ | | | | Fix inliner cycle with recursion, separate compilation
| * SI-8062 Fix inliner cycle with recursion, separate compilationJason Zaugg2013-12-103-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ICodeReaders, which decompiles JVM bytecode to ICode, was not setting the `recursive` attribute of `IMethod`. This meant that the inliner got into a cycle, repeatedly inlining the recursive call. The method name `filter` was needed to trigger this as the inliner heuristically treats that as a more attractive inlining candidate, based on `isMonadicMethod`. This commit: - refactors the checking / setting of `virtual` - adds this to ICodeReaders - tests the case involving `invokevirtual` I'm not sure how to setup a test that fails without the other changes to `ICodeReader` (for invokestatic and invokespecial).
* | SI-8060 Avoid infinite loop with higher kinded type aliasJason Zaugg2013-12-101-0/+11
|/ | | | | | | | | | | The `dealiasLocals` map was assuming that: tp.isAliasType implies (tp.dealias ne tp) This isn't true if `!typeParamsMatchArgs`. This commit avoids the infinite loop by checking whether or not dealiasing progresses.
* [backport] SI-7776 post-erasure signature clashes are now macro-awareEugene Burmako2013-11-082-0/+12
| | | | | | | "double definition: macro this and method that have same type after erasure" This error doesn't make sense when macros are involved, because macros expand at compile-time, where we're not affected by erasure. Moreover, macros produce no bytecode, which means that we're safe from VerifyErrors.
* SI-4012 Mixin and specialization work wellVlad Ureche2013-11-052-0/+22
| | | | The bug was fixed along with SI-7638 in 504b5f3.
* Merge pull request #2919 from retronym/ticket/7815Jason Zaugg2013-09-231-0/+30
|\ | | | | SI-7815 Dealias before deeming method type as dependent
| * SI-7815 Dealias before deeming method type as dependentJason Zaugg2013-09-071-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | To enable eta-expansion of method types seen from a prefix that renders the result type as independent from the parameter symbols. The enclosed test shows that we dealias types before checking dependence, and that we do this deeply (e.g. type arguments are also dealised.) An existing test, neg/error_dependentMethodTpeConversionToFunction, confirms that bona-fide dependent methods are still prohibited from eta expansion.
* | SI-7818 Cast our way out of extended existential angstJason Zaugg2013-09-061-0/+10
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `substituteSymbols` is not sophisticated enough to operate on `TypeSkolem`-s which are based on one of the "from" symbols. The pertinant usage of `substituteSymbols` for this bug in in `Extender`. Recapping on that transform: // orig class C[T](...) extends AnyVal { def foo[U] = <rhs> } // transform class C[T] extends AnyVal { ... } object C { def foo$extension[T', U'] = <rhs'> } Where `<rhs'>` has been subtituted with, among other things, `[T, U] ~> [T', U']`. In this case our expected type contains a new type parameter (of the extension method), whereas the type of the RHS contains an existential skolem still pinned to the corresponding class type parameter. tree.tpe = Observable1#7037[_$1#12344] <_$1#12344>.info = <: T#7040 pt = Observable1#7037[T#15644] The limitation of substution is lamented in the comments of `adaptMismatchedSkolems`, which faces the harder version of the issue where the skolems are in the expected type. But, we're in the "easy" case with the skolems in the tree's type; we can cast our way out of the problem. See also f335e447 / ed915c54.
* Merge pull request #2876 from retronym/ticket/7782Jason Zaugg2013-09-042-0/+50
|\ | | | | SI-7782 Derive type skolems at the ground level
| * SI-7782 Derive type skolems at the ground levelJason Zaugg2013-08-272-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than at the current value of `skolemizationLevel`, which could be influenced by an in-flight existential subtype computation. This method is called in `PolyTypeCompleter`, which could be constructed by the lazy type completer of the enclosing class. So currently it is closing over a mutable variable; hence the Heisenbug. This issue was exposed by the changes in b74c33eb860, which was introduced in Scala 2.10.1.
* | SI-4760 Parser handles block-ending importSom Snytt2013-08-301-0/+34
| | | | | | | | | | | | | | | | | | | | Don't molest the RBRACE. Updated with additional parse tests suggested by @retronym. "What are you lazy?" Yes, I must be lazy. Can't ScalaCheck or Par-Test generate these tests automatically? That seems like a reasonable expectation.
* | Merge pull request #2860 from retronym/merge/2.10.2-to-2.10.xJames Iry2013-08-2610-35/+69
|\ \ | |/ |/| Merge/2.10.2 to 2.10.x
| * SI-7486 More tests for cycles triggered by implicit searchJason Zaugg2013-08-212-0/+16
| | | | | | | | | | | | | | Moved an existing test from `pending` to `pos`. Not sure why it was moved to `pending` in the first place. Adds a new test distilled from building Scalaz with 2.10.3-RC1.
| * Merge remote-tracking branch 'origin/2.10.2' into merge/2.10.2-to-2.10.xJason Zaugg2013-08-2110-43/+61
| |\ | | | | | | | | | | | | | | | | | | Better late than never. Conflicts: src/compiler/scala/tools/nsc/typechecker/NamesDefaults.scala
| | * Merge pull request #2608 from retronym/ticket/7532v2.10.2-RC2v2.10.2James Iry2013-05-304-0/+26
| | |\ | | | | | | | | SI-7532 Fix regression in Java inner classfile reader
| | | * SI-7532 Fix regression in Java inner classfile readerJason Zaugg2013-05-304-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 395e90a modified the detection of top-level classes in ClassfileParser in two ways: 1. used `Name#containsChar` rather than `toString.indexOf ...` (good!) 2. decoded the name before doing this check (bad!) That code is actually only run for non-Scala classfiles, whose names don't need decoding. Attempting to do so converted `R$attr` to `R@tr`, which no longer contains a '$', and was wrongly treated as a top level class. This commit reverts the use of `decodedName`, and inlines the method to its only call site for clarity.
| | * | SI-7517 Fix higher kinded type inference regressionJason Zaugg2013-05-301-0/+22
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Discovered in 2.10.2-RC1 - Ostensibly regressed in 7e52fb910b, which conceptually reverted part of 0cde930b so that (mutable) TypeVars don't use structural equality. - But, does *not* fail if 7e52fb910b is cherry-picked directly after 0cde930b, suggesting that it shone a light on a behaviour change in some other commit in between the two. - Indeed, the true regression came in https://github.com/scala/scala/commit/e5da30b843#L5L3176 - A targeted revert of e5da30b843 is undesirable, as we'd like SI-6846 to stay fixed What's happening here? In the enclosed test case, higher kinded type inference explores two possibilities: Composed.this.Split[A] K[[T]A[B[T]]] // `Split[A]` dealiased The difference in the flow of type inference can be seen from the diff below. Notice how now we no longer register `?K.addBound(Composed.this.Split)`, we instead only register `?K.addBound(K)` ```patch --- sandbox/old.log 2013-05-30 00:27:34.000000000 +0200 +++ sandbox/new.log 2013-05-30 00:28:28.000000000 +0200 @@ -1,55 +1,114 @@ ?K.unifyFull(Composed.this.Split[A]) ?K.unifySpecific(Composed.this.Split[A]) - ?K.addBound(Composed.this.Split) ?B.unifyFull(T) ?B.unifySpecific(T) `-> false ?B.unifyFull(Any) ?B.unifySpecific(Any) `-> false `-> false ?K.unifySpecific(L[[T]A[B[T]]]) - ?K.addBound(L) ?B.unifyFull(B[T]) ?B.unifySpecific(B[T]) ?B.addBound(B) `-> true ?B.unifyFull(B[T]) ?B.unifySpecific(B[T]) ?B.addBound(B) `-> true ?B.unifyFull(B[T]) ?B.unifySpecific(B[T]) ?B.addBound(B) `-> true ?B.unifyFull(B[T]) ?B.unifySpecific(B[T]) ?B.addBound(B) `-> true + ?K.addBound(L) `-> true ?K.unifyFull(Composed.this.Split[A]) ?K.unifySpecific(Composed.this.Split[A]) - ?K.addBound(Composed.this.Split) ?B.unifyFull(x) ?B.unifySpecific(x) `-> false `-> false ?K.unifySpecific(L[[T]A[B[T]]]) + ?B.unifyFull(B[T]) + ?B.unifySpecific(B[T]) + ?B.addBound(B) + `-> true + ?B.unifyFull(B[T]) + ?B.unifySpecific(B[T]) + ?B.addBound(B) + `-> true + ?B.unifyFull(B[T]) + ?B.unifySpecific(B[T]) + ?B.addBound(B) + `-> true + ?B.unifyFull(B[T]) + ?B.unifySpecific(B[T]) + ?B.addBound(B) + `-> true ?K.addBound(L) + `-> true +?K.unifyFull(Composed.this.Split[A]) + ?K.unifySpecific(Composed.this.Split[A]) + ?B.unifyFull(T) + ?B.unifySpecific(T) + `-> false + ?B.unifyFull(Any) + ?B.unifySpecific(Any) + `-> false + `-> false + ?K.unifySpecific(L[[T]A[B[T]]]) ?B.unifyFull(B[T]) ?B.unifySpecific(B[T]) ?B.addBound(B) `-> true ?B.unifyFull(B[T]) ?B.unifySpecific(B[T]) ?B.addBound(B) `-> true ?B.unifyFull(B[T]) ?B.unifySpecific(B[T]) ?B.addBound(B) `-> true ?B.unifyFull(B[T]) ?B.unifySpecific(B[T]) ?B.addBound(B) `-> true + ?K.addBound(L) + `-> true +?K.unifyFull(Composed.this.Split[A]) + ?K.unifySpecific(Composed.this.Split[A]) + ?B.unifyFull(x) + ?B.unifySpecific(x) + `-> false + `-> false + ?K.unifySpecific(L[[T]A[B[T]]]) + ?B.unifyFull(B[T]) + ?B.unifySpecific(B[T]) + ?B.addBound(B) + `-> true + ?B.unifyFull(B[T]) + ?B.unifySpecific(B[T]) + ?B.addBound(B) + `-> true + ?B.unifyFull(B[T]) + ?B.unifySpecific(B[T]) + ?B.addBound(B) + `-> true + ?B.unifyFull(B[T]) + ?B.unifySpecific(B[T]) + ?B.addBound(B) + `-> true + ?K.addBound(L) + `-> true +?K.unifyFull(L[A]) + ?K.unifySpecific(L[A]) + ?K.addBound(L) + `-> true +?K.unifyFull(L[A]) + ?K.unifySpecific(L[A]) + ?K.addBound(L) `-> true ```
| | * Merge pull request #2601 from retronym/ticket/7516James Iry2013-05-294-35/+13
| | |\ | | | | | | | | SI-7516 Revert "SI-7234 Make named args play nice w. depmet types"
| | | * SI-7516 Revert "SI-7234 Make named args play nice w. depmet types"Jason Zaugg2013-05-294-35/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 83c9c764b528a7a1c1d39c480d22c8e3a71d5a58. The tests are shunted to 'pending'. Why revert this seemingly innocous commit? 83c9c764 generates a ValDef whose tpt TypeTree has no original; this contains a reference to the symbol for `d`. resetAttrs and the retypecheck assigns a new symbol for d and leaves a the reference to the prior symbol dangling. The real bug is the resetAttrs concept.
| | * | SI-7486 Regressions in implicit search.Paul Phillips2013-05-231-8/+0
| | |/ | | | | | | | | | Revert e86832d7e8 and dd33e280e2.
* | / SI-942 A test case, five years adrift.Jason Zaugg2013-08-232-0/+8
|/ / | | | | | | | | | | | | I'm looking at the changes made in 47f35b587, which prevented cyclic errors in class file parsing. That fix is insufficient for, or otherwise complicit in, SI-7778, for which I've enclosed a pending test.
* | SI-7716 Exclude patmat synthetics from bounds checkingJason Zaugg2013-08-161-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider this pattern match translation, that occurs *before* refchecks: scala> val e: java.lang.Enum[_] = java.util.concurrent.TimeUnit.SECONDS scala> e match { case x => x } <console>:9: error: type arguments [_$1] do not conform to class Enum's type parameter bounds [E <: Enum[E]] e match { case x => x } ^ [[syntax trees at end of refchecks]] // <console> package $line5 { case <synthetic> val x1: Enum[_$1] = $line3.$read.$iw.$iw.e; case4(){ matchEnd3(x1) }; matchEnd3(x: Enum[_$1]){ x } RefChecks turns a blind eye to the non-conformant type `Enum[_$1]` in the label defs because of `65340ed4ad2e`. (Incidentally, that is far too broad, as I've noted in SI-7756.) This commit extends this exception to cover the synthetic ValDef `x1`. Commit log watchers might notice the similarities to SI-7694.
* | Merge pull request #2829 from adriaanm/ticket-7014James Iry2013-08-143-0/+21
|\ \ | | | | | | SI-7014 Annot arg may refer to annotated class's member
| * | SI-7014 Annot arg may refer to annotated class's memberAdriaan Moors2013-08-133-0/+21
| | | | | | | | | | | | This only reduces the crasher to a warning.
* | | SI-7694 Add @uncheckedBounds to the libraryJason Zaugg2013-08-131-0/+40
|/ / | | | | | | | | | | | | | | | | Followup to the previous commit that added the compiler support for opting out of bounds checking. With both pieces, we can test that the temporaries introduced by the named/default arguments transform don't trigger bounds violations.
* | Merge pull request #2721 from retronym/ticket/7649Adriaan Moors2013-07-122-0/+21
|\ \ | | | | | | SI-7649 Fix positions for reshaped tag materializers
| * | SI-7649 Fix positions for reshaped tag materializersJason Zaugg2013-07-112-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calls to `materializeClassTag[T]` are replaced during reification with `implicitly[ClassTag[T]]` in the `reify` macro. This is done to avoid referring to symbols in scala-compiler.jar. Class- and Type-Tag materialization is treated in the same way. This commit positions the replacement trees to avoid triggering assertions under -Yrangepos.
* | | SI-7638 Superaccessor lookup after specializationVlad Ureche2013-07-081-0/+51
|/ / | | | | | | | | | | | | | | | | | | | | | | | | The crash was caused by a symbol lookup to rewire the super calls, done after pickler, but specialization added new traits and new members, thus making the super rewiring impossible. To avoid such problems, this patch moves symbol lookup after specialization, so the changes done by specialization (and miniboxing) become visible to mixin. NOTE: This patch will be followed by a similar patch to master. Review by @adriaanm or @retronym.
* | SI-7505 Test case for pattern matcher + type alias bugJason Zaugg2013-06-081-0/+16
| | | | | | | | Progressed along with SI-7214 in acd74cae09.
* | A test case for a recent LUB progression.Jason Zaugg2013-05-271-0/+34
| | | | | | | | | | | | | | | | | | | | | | A test distilled from a Lift example that compiles correctly under 2.10.1, but not under 2.10.0. I pinpointed the progression to: https://github.com/scala/scala/commit/a06d31f6#L0R6611 Chalk up another win for `dealiasWiden`.
* | Merge pull request #2506 from scalamacros/ticket/7461Eugene Burmako2013-05-203-0/+16
|\ \ | |/ |/| c.typeCheck(silent = true) now suppresses ambiguous errors
| * c.typeCheck(silent = true) now suppresses ambiguous errorsEugene Burmako2013-05-093-0/+16
| | | | | | | | | | | | Otherwise use cases like the one shown in the attached test (trying to typecheck something, which leads to an ambiguous overload error) will mysteriously fail compilation.
* | SI-7486 regression in implicit resolution.Paul Phillips2013-05-171-0/+8
| | | | | | | | What a touchy beast the compiler is.
* | Merge pull request #2497 from scalamacros/topic/macro-qqqJason Zaugg2013-05-172-0/+7
|\ \ | | | | | | easy way of writing not implemented macros
| * | easy way of writing not implemented macrosEugene Burmako2013-05-122-0/+7
| | | | | | | | | | | | | | | | | | Even though it's easy to mark regular method bodies as stubs (using ???), there's no simple way of doing the same for macro methods. This patch fixes the inconvenience.
* | | SI-5886 Remove check for packed type conformance.Jason Zaugg2013-05-151-0/+18
|/ / | | | | | | | | | | | | Nothing breaks. Why did by-name arguments have this extra check? What's the difference to a () => T? The check was added originally in 8414eba.
* | [nomaster] macroExpandAll is now triggered in all invocations of typedEugene Burmako2013-05-112-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | macroExpandAll is the key player in the mechanism of expanding macros after their type arguments have been inferred. (Macro applications that contain yet uninferred type arguments don't get expanded and are delayed until the targs are inferred. Therefore later on we need to trigger those delayed expansions manually, which is done by macroExpandAll). Previously macroExpandAll was only called from a few selected places in the typechecker, but that's quite risky, since typer evolves, and who knows when this scheme breaks. To make things more robust, I'm now calling macroExpandAll in the epilogue of every single call to `typed`. Don't worry - this shouldn't impose noticeable performance penalties, since the call is guarded by a branch upon a plain boolean field. NOTE: This patch is a second take on fixing implicit macros, with the first one being a backport from macro paradise merged into master in January 2013: https://github.com/scala/scala/commit/fe60284769. The original fix had an unfortunate error, as described on scala-internals: https://groups.google.com/forum/#!msg/scala-internals/7pA9CiiD3u8, so I had to refine the approach here. This means that it's not possible to directly merge this commit into master, so I'm marking it as [nomaster] and will submit a separate pull request targetting master later on.
* | [nomaster] SI-5923 instantiates targs in deferred macro applicationsEugene Burmako2013-05-118-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Amazingly enough, the fix for the "macro not expanded" problem was super easy. (And I remember spending a day or two trying to find a quick fix somewhen around Scala Days 2012!) The problem was in the implementation of the macro expansion trigger, which was buried in a chain of if-elif-elif in `adapt`. This meant that macro expansion was mutually exclusive with a lot of important adaptations, e.g. with `instantiate`. More precisely, if an expandee contains an undetparam, its expansion should be delayed until all its undetparams are inferred and then retried later. Sometimes such inference can only happen upon a call to instantiate in one of the elif's coming after the macro expansion elif. However this elif would never be called for expandees, because control flow would always enter the macro expansion branch preceding the inference branch. Therefore `macroExpand` now takes the matters in its own hands, calling `instantiate` if the expansion has been delayed and we're not in POLYmode (see a detailed explanation in a comment to `macroExpand`). Consequences of this fix are vast. First of all, we can get rid of the "type parameter must be specified" hack. Secondly and most importantly, we can now remove the `materializeImplicit` method from Implicits and rely on implicit macros to materialize tags for us. (This is a tricky change, and I'll do it later after we merge as much of my pending work as possible). Finally, we learn that the current scheme of interaction between macros, type inference and implicits is, in principle, sound! NOTE: This patch is a second take on fixing implicit macros, with the first one being a backport from macro paradise merged into master in January 2013: https://github.com/scala/scala/commit/fe60284769. The original fix had an unfortunate error, as described on scala-internals: https://groups.google.com/forum/#!msg/scala-internals/7pA9CiiD3u8, so I had to refine the approach here. This means that it's not possible to directly merge this commit into master, so I'm marking it as [nomaster] and will submit a separate pull request targetting master later on.
* | Merge pull request #2458 from paulp/issue/7426-210Grzegorz Kossakowski2013-05-101-0/+3
|\ \ | |/ |/| SI-7426 Crash in pickler.
| * SI-7426 Crash in pickler.Paul Phillips2013-04-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I wonder if the supply of copy-pasted code, and the bugs which always accompany it, will ever run low. Here we have a couple hundred lines of tree traversal which appears roughly identical in structure to a different couple hundred lines of tree traversal, except one calls methods called putXXX and the other calls methods called writeXXX. Except there was one call to writeXXX among all the putXXX calls. Guess where it was crashing. This entire file should be expunged.
* | Merge pull request #2487 from paulp/issue/6091Paul Phillips2013-05-072-0/+11
|\ \ | | | | | | SI-6091 overeager warning for reference equality
| * | SI-6091 overeager warning for reference equalityPaul Phillips2013-05-022-0/+11
| | | | | | | | | | | | Don't warn on eq and ne unless they're the real eq or ne.
* | | Merge pull request #2440 from retronym/ticket/6771Adriaan Moors2013-05-032-0/+10
|\ \ \ | |/ / |/| | SI-6771 Alias awareness for checkableType in match analysis.
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-15 02:44:29 +0000