summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #2608 from retronym/ticket/7532v2.10.2-RC2v2.10.2James Iry2013-05-305-4/+30
|\ | | | | SI-7532 Fix regression in Java inner classfile reader
| * SI-7532 Fix regression in Java inner classfile readerJason Zaugg2013-05-305-4/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge pull request #2607 from retronym/ticket/7517James Iry2013-05-292-4/+25
|\ \ | |/ |/| SI-7517 Fix higher kinded type inference regression
| * SI-7517 Fix higher kinded type inference regressionJason Zaugg2013-05-302-4/+25
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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-295-5/+20
|\ | | | | 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-295-5/+20
| | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge pull request #2590 from paulp/issue/7486Jason Zaugg2013-05-274-14/+3
|\ \ | |/ |/| SI-7486 Regressions in implicit search.
| * SI-7486 Regressions in implicit search.Paul Phillips2013-05-234-14/+3
| | | | | | | | Revert e86832d7e8 and dd33e280e2.
* | Merge pull request #2588 from retronym/ticket/7509Paul Phillips2013-05-263-3/+22
|\ \ | |/ |/| SI-7509 Avoid crasher as erronous args flow through NamesDefaults
| * SI-7509 Avoid crasher as erronous args flow through NamesDefaultsJason Zaugg2013-05-233-3/+22
|/ | | | | | | | The fix for SI-7238 caused this regression. This commit marks taints whole Apply with an ErrorType if it has an erroneous argument, so as to stop a later crash trying to further process the tree.
* Merge pull request #2540 from adriaanm/ticket-7201v2.10.2-RC1Adriaan Moors2013-05-174-1/+12
|\ | | | | SI-7201 scala-library's pom points to scaladoc url
| * SI-7201 scaladoc url in scala-(library,actors,swing,reflect) pomAdriaan Moors2013-05-174-1/+12
| | | | | | | | | | | | | | | | The project/properties/info.apiURL pom property is used by SBT to link to an artifact's scaladoc. For scala library version $v, the url is http://www.scala-lang.org/api/$v/ Note that actors, reflect and swing are included in the library docs in 2.10.x.
* | Merge pull request #2530 from kzys/jira-6424Adriaan Moors2013-05-171-9/+25
|\ \ | | | | | | SI-6424 Scaladoc: Use mapNodes.get(_) to avoid NoSuchElementException
| * | SI-6424 Scaladoc: Use mapNodes.get(_) to avoid NoSuchElementExceptionKato Kazuyoshi2013-05-151-9/+25
| | | | | | | | | | | | Use mapNodes.get(_) instead of mapNodes(_) to avoid NoSuchElementException.
* | | Merge pull request #2549 from vigdorchik/slash_slashAdriaan Moors2013-05-171-4/+1
|\ \ \ | | | | | | | | Prevent slash duplication.
| * | | Prevent slash duplication.Eugene Vigdorchik2013-05-171-4/+1
| | | | | | | | | | | | | | | | | | | | Don't add trailing slash to external doc URL if it already ends with one.
* | | | Merge pull request #2536 from adriaanm/ticket-7359Adriaan Moors2013-05-176-81/+32
|\ \ \ \ | | | | | | | | | | [backport #1727] SI-7359 cyclic nested java class
| * | | | [backport #1727] SI-7359 cyclic nested java classAdriaan Moors2013-05-166-81/+32
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original commit message (from 54a84a36d5): SI-6548 reflection correctly enters jinners When completing Java classes, runtime reflection enumerates their fields, methods, constructors and inner classes, loads them and enters them into either the instance part (ClassSymbol) or the static part (ModuleSymbol). However unlike fields, methods and constructors, inner classes don't need to be entered explicitly - they are entered implicitly when being loaded. This patch fixes the double-enter problem, make sure that enter-on-load uses the correct owner, and also hardens jclassAsScala against double enters that can occur in a different scenario.
* | | | Merge pull request #2553 from paulp/issue/7486Adriaan Moors2013-05-172-3/+15
|\ \ \ \ | |_|/ / |/| | | SI-7486 regression in implicit resolution.
| * | | SI-7486 regression in implicit resolution.Paul Phillips2013-05-172-3/+15
|/ / / | | | | | | | | | What a touchy beast the compiler is.
* | | Merge pull request #2550 from scalamacros/2.10.xJason Zaugg2013-05-171-0/+3
|\ \ \ | | | | | | | | [nomaster] unbreaks test.bc
| * | | [nomaster] unbreaks test.bcEugene Burmako2013-05-171-0/+3
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | The optimizer behaves unexpectedly smartly, stripping off unused private methods. Unfortunately, sometimes private methods might be compiled down to public Java methods, so stripping them off might lead to binary incompatibilities. This particular commit recovers from this problem caused by https://github.com/scala/scala/commit/5e715396af.
* | | Merge pull request #2504 from scalamacros/ticket/7464Jason Zaugg2013-05-174-14/+8
|\ \ \ | | | | | | | | SI-7464 allows FieldMirror.set to update vals
| * | | SI-7464 allows FieldMirror.set to update valsEugene Burmako2013-05-174-14/+8
| | | | | | | | | | | | | | | | | | | | There's no reason to leave such sentinels in place inside a facility designed to circumvent usual restrictions of static types / visibility.
* | | | Merge pull request #2497 from scalamacros/topic/macro-qqqJason Zaugg2013-05-177-21/+66
|\ \ \ \ | | | | | | | | | | easy way of writing not implemented macros
| * | | | easy way of writing not implemented macrosEugene Burmako2013-05-127-21/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | | Merge pull request #2547 from paulp/issue/bogus-warningJason Zaugg2013-05-161-2/+1
|\ \ \ \ \ | | | | | | | | | | | | Fix for unreachable code warning.
| * | | | | Fix for unreachable code warning.Paul Phillips2013-05-161-2/+1
|/ / / / / | | | | | | | | | | | | | | | Oops, I miss when unreachable code was an error.
* | | | | Merge pull request #2537 from adriaanm/ticket-5886Paul Phillips2013-05-162-22/+19
|\ \ \ \ \ | | | | | | | | | | | | SI-5886 Remove check for packed type conformance.
| * | | | | SI-5886 Remove check for packed type conformance.Jason Zaugg2013-05-152-22/+19
| | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | | Merge pull request #2515 from heathermiller/issue/6555Adriaan Moors2013-05-151-7/+10
|\ \ \ \ \ | |/ / / / |/| | | | Actual SI-6555 fix, Scaladoc filter works now WITH keyboard shortcuts too
| * | | | Actual SI-6555 fix, Scaladoc filter works WITH keyboard shortcuts tooHeather Miller2013-05-121-7/+10
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit daefab18b8b0c170c372991022357413ec69b2af attempted to fix a bug related to Scaladoc filtering, meanwhile breaking Scaladoc keyboard shortcuts. Before commit daefab18b8b0c170c372991022357413ec69b2af, Scaladoc's filter wouldn't consider the last character of a search term entered into the (left) Scaladoc filter pane, but toggling with the `tab` key between filter panes did work. After daefab18b8b0c170c372991022357413ec69b2af, Scaladoc's left pane filter correctly searches for the full search term, but pressing the `tab` key causes the "focus" of the input bar to be stuck on the filter panel in the right Scaladoc filter pane, rendering it useless. End result: annoying Scaladoc interface bug present in 2.10.1, but which wasn't present in 2.10.0. This pull request fixes this, enabling both behaviors. The `tab` key toggle needed to be triggered on a `keydown` event (currently it's not), while everything else is fine to be triggered on a `keyup` event. This pull request enables the correct behavior by binding both a `keydown` and a `keyup` event rather than lumping everything all together in a `keyup` event (as was the case before).
* | | | Merge pull request #2502 from ↵Adriaan Moors2013-05-142-1/+20
|\ \ \ \ | |/ / / |/| | | | | | | | | | | viktorklang/wip-SI7383-EC-prepare-in-Future-apply-2.10-√ SI-7383 - call ExecutionContext.prepare in Future.apply
| * | | SI-7383 - Call ExecutionContext.prepare in Future.apply to allow for ↵Viktor Klang2013-05-102-1/+20
| | | | | | | | | | | | | | | | capturing local context like ThreadLocals and then re-establishing them prior to execution, as per intention of EC.prepare
* | | | Merge pull request #2500 from phaller/topic/forkjoin-updateJason Zaugg2013-05-126-1085/+1964
|\ \ \ \ | |_|/ / |/| | | SI-7442 Update bundled Fork/Join pool (JSR166y)
| * | | SI-7442 Update bundled Fork/Join pool (JSR166y)Philipp Haller2013-05-116-1085/+1964
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Updates ForkJoinPool and dependent classes to the latest jsr166y revisions: ForkJoinPool.java: Revision 1.185 Sat Feb 16 20:50:29 2013 UTC (2 months, 2 weeks ago) by jsr166 ForkJoinTask.java: Revision 1.100 Tue Feb 5 17:09:54 2013 UTC (3 months ago) by jsr166 ForkJoinWorkerThread.java: Revision 1.73 Wed Nov 21 19:54:39 2012 UTC (5 months, 2 weeks ago) by dl - Includes Akka-contributed `sun.misc.Unsafe` detection to support Android. See changeset 06d685c1bbd8a0d058ee8a3f374569f8097f2acc - Adds private `CountedCompleter` class. This class is only visible and used in `ForkJoinPool.java`. - Updates desired.sha1 for updated forkjoin.jar. - Updates binary compatibility whitelists to exclude package-private methods in the `forkjoin` package. - Also fixes SI-7438.
* | | | Merge pull request #2494 from scalamacros/ticket/5923Eugene Burmako2013-05-1155-72/+466
|\ \ \ \ | | | | | | | | | | makes sense of implicit macros!
| * | | | [nomaster] removes duplication in inferImplicitValueEugene Burmako2013-05-113-50/+28
| | | | | | | | | | | | | | | | | | | | Shame-driven development at its best.
| * | | | [nomaster] SI-7166 catches DivergentImplicit in c.inferImplicitXXXEugene Burmako2013-05-115-20/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Despite inferImplicit usually being nice and buffering errors, apparently it can also throw DivergentImplicit exception. This patch catches it and only reports it if silent is set to false. NOTE: we no longer have the DivergentImplicit exception in master, so this commit only makes sense in 2.10.x.
| * | | | [nomaster] SI-7047 fixes silent for c.inferImplicitXXXEugene Burmako2013-05-115-2/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | silent = true now throws a TypecheckException even if we don't know why an implicit search has failed (i.e. if context.hasErrors is false). NOTE: this commit is a part of a pull request for 2.10.x, which makes sense of implicit macros. Everything in that pull request is [nomaster] due to one reason or another. This commit would work equally well in both 2.10.x and master, but I'm marking it as [nomaster] as well, because I'm anyway going to resubmit the whole pull request into master soon, so there's no reason to introduce additional confusion.
| * | | | [nomaster] SI-7291: No exception throwing for diverging implicit expansionHubert Plociniczak2013-05-1117-14/+171
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we don't throw exceptions for normal errors it was a bit odd that we don't do that for DivergingImplicit. As SI-7291 shows, the logic behind catching/throwing exception was broken for divergence. Instead of patching it, I rewrote the mechanism so that we now another SearchFailure type related to diverging expansion, similar to ambiguous implicit scenario. The logic to prevent diverging expansion from stopping the search had to be slightly adapted but works as usual. The upside is that we don't have to catch diverging implicit for example in the presentation compiler which was again showing that something was utterly broken with the exception approach. NOTE: This is a partial backport of https://github.com/scala/scala/pull/2428, with a fix for SI-7291, but without removal of error kinds (the former is absolutely necessary, while the latter is nice to have, but not a must, therefore I'm not risking porting it to 2.10.x). Also, the fix for SI-7291 is hidden behind a flag named -Xdivergence211 in order not to occasionally break the code, which relies on pre-fix behavior.
| * | | | [nomaster] SI-7167 implicit macros decide what is divergenceEugene Burmako2013-05-1113-16/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Imagine a macro writer which wants to synthesize a complex implicit Complex[T] by making recursive calls to Complex[U] for its parts. E.g. if we have `class Foo(val bar: Bar)` and `class Bar(val x: Int)`, then it's quite reasonable for the macro writer to synthesize Complex[Foo] by calling `inferImplicitValue(typeOf[Complex[Bar])`. However if we didn't insert `info.sym.isMacro` check in `typedImplicit`, then under some circumstances (e.g. as described in http://groups.google.com/group/scala-internals/browse_thread/thread/545462b377b0ac0a) `dominates` might decide that `Bar` dominates `Foo` and therefore a recursive implicit search should be prohibited. Now when we yield control of divergent expansions to the macro writer, what happens next? In the worst case, if the macro writer is careless, we'll get a StackOverflowException from repeated macro calls. Otherwise, the macro writer could check `c.openMacros` and `c.openImplicits` and do `c.abort` when expansions are deemed to be divergent. Upon receiving `c.abort` the typechecker will decide that the corresponding implicit search has failed which will fail the entire stack of implicit searches, producing a nice error message provided by the macro writer. NOTE: the original commit from macro paradise also introduced a new class, which encapsulates information about implicits in flight. Unfortunately we cannot do that in 2.10.x, because of binary compatibility concerns, therefore I'm marking this commit as [nomaster] and will be resubmitting its full version in a separate pull request exclusively targetting master.
| * | | | [nomaster] macroExpandAll is now triggered in all invocations of typedEugene Burmako2013-05-114-5/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1116-11/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | [nomaster] temporarily breaks SI-5353Eugene Burmako2013-05-112-0/+0
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The subsequent fix to SI-5923 unmasks the fact that SI-5353 has not been fixed - it's just that one of its manifestation got hidden behing SI-5923. In fact, if in the code snippet from the bug report we change Array() to Array[Nothing](), things will start crashing as usual. The problem we have here is that arrays of nothings and nulls are very weird in a sense that their compile-time representations (types) and their runtime representations (JVM arrays of Object) behave differently with respect to subtyping. Due to an unlucky coincidence SI-5923 prevented some of the arrays of nothing from being compilable, so the problem was well hidden until now. A principled approach to handling the situation we have here would be to fix SI-5353 (we already know how to do that: https://github.com/scala/scala/pull/2486) and to disallow arrays of nothings and nulls as suggested in SI-7453. Unfortunately, both fixes are going to bring incompatibilities, which are not acceptable in a minor release (this pull request targets 2.10.x). Therefore we decided to turn a blind eye on the iceberg and just fix a tip of it by emulating the portion of SI-5923 that used to mask SI-5353, retaining perfect backward compatibility. Unfortunately, it's not that easy. Apparently one cannot simply report all the occurrences of Array() as errors, because if we know expected type of that expression, then everything's fine - the expected type will drive type inference and the dreaded Array[Nothing]() will not arise. All right, so let's just check whether pt == WildcardType and then report errors. However that's still not enough because of SI-3859. Having my hack failing for the third time, made me stop for a second and think whether it's worth to play with fire and introduce potential breakages for the sake of preventing a quite unlikely bug from happening. I don't think the it's okay to risk here, therefore I just disable the failing test, especially because we already have a working fix to SI-5353 submitted to master, so it's not like we're deferring the work to be done to a random point in unclear future. NOTE: That's only a temporary hack targeted at 2.10.x. There's no reason for this code to be merged into master, because master is soon going to have a principled solution to the problem: https://github.com/scala/scala/pull/2486.
* | | | Merge pull request #2496 from igormoreno/2.10.xPaul Phillips2013-05-111-1/+1
|\ \ \ \ | | | | | | | | | | Scaladoc: fixing small typo in PartialFunction.scala
| * | | | Scaladoc: fixing small typo in PartialFunction.scalaIgor Moreno2013-05-051-1/+1
| | | | | | | | | | | | | | | Fixing a one-letter typo in the documentation of PartialFunction.scala (from "an plain" to "a plain").
* | | | | Merge pull request #2505 from scalamacros/topic/macrosPaul Phillips2013-05-115-31/+67
|\ \ \ \ \ | |_|/ / / |/| | | | some fixes for macros: one esoteric, and one quite critical
| * | | | pull request feedbackEugene Burmako2013-05-112-6/+9
| | | | |
| * | | | replaces inferBootClasspath with a simple lookup at sun.boot.class.pathEugene Burmako2013-05-091-12/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's not like we're achieving any generality by iterating through all keys in System.getProperties and looking for ones which resemble "boot.class.path", so let's be simpler.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-08 02:17:51 +0000