summaryrefslogtreecommitdiff
path: root/test/files/run
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #2609 from retronym/ticket/7507Paul Phillips2013-06-031-0/+31
|\ | | | | SI-7507 Fix lookup of private[this] member in presence of self type.
| * SI-7507 Fix lookup of private[this] member in presence of self type.Jason Zaugg2013-05-311-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the following code: trait Cake extends Slice trait Slice { self: Cake => // must have self type that extends `Slice` private[this] val bippy = () // must be private[this] locally(bippy) } `ThisType(<Slice>)`.findMember(bippy)` excluded the private local member on the grounds that the first class in the base type sequence, `Cake`, was not contained in `Slice`. scala> val thisType = typeOf[Slice].typeSymbol.thisType thisType: $r.intp.global.Type = Slice.this.type scala> thisType.baseClasses res6: List[$r.intp.global.Symbol] = List(trait Cake, trait Slice, class Object, class Any) This commit changes `findMember` to use the symbol of the `ThisType`, rather than the first base class, as the location of the selection.
* | SI-7375 ClassTag for value class aliasesEugene Burmako2013-05-315-0/+45
|/ | | | reifyRuntimeClass now always dealiases its argument prior to processing.
* Merge pull request #2536 from adriaanm/ticket-7359Adriaan Moors2013-05-175-75/+21
|\ | | | | [backport #1727] SI-7359 cyclic nested java class
| * [backport #1727] SI-7359 cyclic nested java classAdriaan Moors2013-05-165-75/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #2504 from scalamacros/ticket/7464Jason Zaugg2013-05-172-10/+4
|\ \ | |/ |/| SI-7464 allows FieldMirror.set to update vals
| * SI-7464 allows FieldMirror.set to update valsEugene Burmako2013-05-172-10/+4
| | | | | | | | | | 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 #2494 from scalamacros/ticket/5923Eugene Burmako2013-05-1117-0/+123
|\ \ | | | | | | makes sense of implicit macros!
| * | [nomaster] SI-7047 fixes silent for c.inferImplicitXXXEugene Burmako2013-05-113-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-116-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-113-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] SI-5923 instantiates targs in deferred macro applicationsEugene Burmako2013-05-115-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #2505 from scalamacros/topic/macrosPaul Phillips2013-05-112-0/+42
|\ \ \ | |/ / |/| | some fixes for macros: one esoteric, and one quite critical
| * | fixes a crash in ReflectionUtils.systemPropertiesEugene Burmako2013-05-092-0/+42
| |/ | | | | | | | | | | Due to SI-7465 we were erroneously assuming that System.getProperties only contains string key and string values. This led to a CCE when there was something else.
* | fixes a checkfile breakage in 2.10.xEugene Burmako2013-05-111-1/+1
| | | | | | | | | | | | The breakage is caused by https://github.com/scala/scala/commit/fbb13630d3 and https://github.com/scala/scala/commit/a8edefcef8 having been merged independently from each other.
* | Merge pull request #2456 from paulp/pr/jdk8-210xGrzegorz Kossakowski2013-05-119-8/+39
|\ \ | | | | | | SI-7398 Add support for java8 default methods
| * | SI-7398 Add support for java8 default methodsPaul Phillips2013-04-261-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In classfile parser: mark symbols which represent interface methods yet have code attributes with new flag DEFAULTMETHOD. These must be kept distinct from regular method bodies so that an error can be issued when a regular concrete method is overridden without the override keyword, but not when the overridden method is a default. In java source parser: mark Modifiers of interface default methods with DEFAULTMETHOD flag. Writing the test was everything I dreamed, and more! However, % test/partest --debug test/files/run/t7398.scala Skipping java8-specific test under java version 1.7.0_21 testing: [...]/files/run/t7398.scala [ OK ] All of 1 tests were successful (elapsed time: 00:00:04) % test/partest --debug test/files/run/t7398.scala Attempting java8-specific test under java version 1.8.0-ea testing: [...]/files/run/t7398.scala [ OK ] All of 1 tests were successful (elapsed time: 00:00:13)
| * | Refactor DirectTest so java can be tested.Paul Phillips2013-04-268-8/+8
| |/ | | | | | | | | There was no way to make a java compilation unit. Now there is.
* | SI-7325 cleans up corner cases of percent handling in StringContext.fEugene Burmako2013-05-044-2/+46
| | | | | | | | | | | | | | | | | | | | See comments in code for the exhaustive list of the cases handled. Also note that treatment of non-formatting percents has been changed. Embedding literal %'s now requires escaping. Moreover, this commit also features exact error positions for string interpolation, something that has been impossible until the fix for SI-7271, also included in this patch.
* | SI-7271 fixes positions of string interpolation partsEugene Burmako2013-04-272-0/+46
|/ | | | | | | | | Positions of static parts are now set explicitly during parsing rather than filled in wholesale during subsequent atPos after parsing. I also had to change the offsets that scanner uses for initial static parts of string interpolations so that they no longer point to the opening double quote, but rather to the actual beginning of the part.
* Merge pull request #2322 from retronym/ticket/7200Jason Zaugg2013-04-201-0/+34
|\ | | | | SI-7200 Test case for fixed type inference error.
| * SI-7200 Test case for fixed type inference error.Jason Zaugg2013-03-271-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Broken in 2.9.2 and 2.10.0, but working in 2.10.1 --- sandbox/2.10.0.log +++ sandbox/2.10.1.log def coflatMap[A >: Nothing <: Any, B >: Nothing <: Any](f: Test.Nel[A] => B): Test.Nel[A] => Test.Nel[B] = ((l: Test.Nel[A]) => Test.this.Nel.apply[B](f.apply(l), l.tail match { case immutable.this.Nil => immutable.this.Nil - case (hd: A, tl: List[A])scala.collection.immutable.::[A]((h @ _), (t @ _)) => { - val r: Test.Nel[Nothing] = NelFoo.this.coflatMap[A, Nothing](f).apply(Test.this.Nel.apply[A](h, t)); + case (hd: A, tl: List[A])scala.collection.immutable.::[?A1]((h @ _), (t @ _)) => { + val r: Test.Nel[B] = NelFoo.this.coflatMap[A, B](f).apply(Test.this.Nel.apply[A](h, t)); { - <synthetic> val x$1: Nothing = r.head; - r.tail.::[Nothing](x$1) + <synthetic> val x$1: B = r.head; + r.tail.::[B](x$1) } } })) b74c33eb86 represents the exact moment of progression. Comments in pos/t7200b.scala, a minimal test that demonstrates the problem without type constructors or code execution, pinpoint the line of code responsible for the fix. Incidentally, I'm currently on a train somewhere between Solothurn and Biel, and am consequently without the power of scala-bisector. Undeterred, and inspired by a line I saw in Skyfall last night ("sometimes the olds ways are better"), I just pulled off a two-hop bisection. Take that, O(log N)! The one remaining worry is the appearance of the type variable ?A1 in the output of -Xprint:typer for run/t7200.scala.
* | SI-7319 Clear error buffer during Typer reset.Jason Zaugg2013-04-152-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Contexts share error/warning buffers with their children, and this also applies ot the shared `startContext`. That context flushes the buffers in `startContext` in `resetContexts`. It also removes `typerReportAnyContextErrors`, which appears to be an elaborate no-op. It is only ever passed a context `c` which is a direct child of `this.context`. So taking a buffered error out of `c` and reissuing it into `this.context` merely re-inserts into into the same error buffer. Consrast this with `silent`, which uses a child context with a fresh error buffer. SI-7319 Flush error buffer in typerReportAnyContextErrors. After this change, we no longer rely on the backstop in resetContexts introduced in the previous commit.
* | Merge pull request #2367 from vigdorchik/si-6387-revertAdriaan Moors2013-04-095-17/+16
|\ \ | | | | | | Revert "SI-6387 Clones accessor before name expansion"
| * | Revert "SI-6387 Clones accessor before name expansion"Eugene Vigdorchik2013-04-085-17/+16
| | | | | | | | | | | | | | | | | | This reverts commit 4e10b2c833fa846c68b81e94a08d867e7de656aa. Add 6387 test to pending and 7341 to up-to-date.
* | | Merge pull request #2349 from scalamacros/ticket/6937Adriaan Moors2013-04-0912-21/+59
|\ \ \ | |/ / |/| | SI-6937 core type tags are no longer referentially unique
| * | SI-6937 core type tags are no longer referentially uniqueEugene Burmako2013-04-0312-21/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Type tag factory used to evaluate the provided type creator in the context of the initial mirror in order to maintain referential equality of instances of standard tags. Unfortunately this evaluation might fail if the mirror provided doesn't contain the classes being referred to. Therefore I think we should avoid evaluating type creators there. Note that failure of evaluation doesn't mean that there's something bad going on. When one creates a type tag, the correct mirror / classloader to interpret that tag in might be unknown (like it happens here). This is okay, and this is exactly what the 2.10.0-M4 refactoring has addressed. Something like `res2.typeTag[A].in(currentMirror)` should be okay.
* | | SI-6900 Fix tailrec for dependent method typesJason Zaugg2013-04-021-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Uncurry's info transformer could generate a MethodType with cloned parameter symbols. This type was used for the LabelDef generated in the TailCalls phase. But, the RHS of the method still contains types that refer to the original parmameter symbol. Spurious type errors ensued. I've spent a good chunk of time pursuing a more principled fix, in which we keep the symbols in the tree in sync with those in the MethodType. You can relive the procession of false dawns: https://github.com/scala/scala/pull/2248 Ultimately that scheme was derailed by a mismatch between the type parameter `T` and the skolem `T&` in the example below. trait Endo[A] { def apply(a: => A): A } class Test { def foo[T] = new Endo[(T, Unit)] { def apply(v1: => (T, Unit)) = v1 // no bridge created } } Interestingly, by removing the caching in SingleType, I got past that problem. But I didn't characterize it further. This commit sets asides the noble goal of operating in the world of types, and sledgehammers past the crash by casting the arguments to and the result of the label jump generated in TailCalls.
* | | Merge pull request #2319 from retronym/ticket/6793Paul Phillips2013-04-023-0/+31
|\ \ \ | | | | | | | | SI-6793 Don't use super param accessors if inaccessible.
| * | | SI-6793 Don't use super param accessors if inaccessible.Jason Zaugg2013-03-263-0/+31
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "Alias replacement" has been with us since 2005 (13c59adf9). Given: package a { class C1(val v0: String) class C2(v1: String) extends a.C1(v1) { v1 } } The reference to `v1` is rewritten as `C2.super.v0()`, and no field is generated in `C2`. (Oddly, this optimization doesn't seem to kick in if these classes are in the empty package. That's probably a distinct bug.) However, this rewriting is done without consideration of the accessibility of `v0` from `C2`. This commit disables this optimization if there if `v0` is not accessible.
* | | SI-6715 Shouldn't return "" from TermNames.originalNameKato Kazuyoshi2013-04-031-0/+15
| | |
* | | Use java-diff-utils for diffing in partest.Adriaan Moors2013-03-292-490/+571
| |/ |/| | | | | | | | | | | | | We now use the unified diff format, hence the updated check files. It's not clear to me how partest's classpath is managed, but the approach in this commit works for the ant task and script invocation. The diffutils jar is injected in the parent classloader.
* | Merge pull request #2292 from retronym/ticket/7285Adriaan Moors2013-03-272-3/+11
|\ \ | | | | | | SI-7285 Fix match analysis with nested objects
| * | SI-7285 Fix match analysis with nested objects.Jason Zaugg2013-03-231-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fix for SI-6146 introduced `nestedMemberType` to enumerate sealed subtypes based on the (prefixed) type of the scrutinee and the symbols of its sealed subclasses. That method needed to widen `ThisType(modSym)`s to `ModuleTypeRef(modSym)` before calling `asSeenFrom`. However, this could lead to confused in the match analysis, which sees `ModuleTypeRef` as distinct from singleton types on the same modules (after all, they aren't =:=). Spurious warnings ensued. This commit makes two changes: - conditionally re-narrow the result of `asSeenFrom` in `nestedMemberType`. - present `a.b.SomeModule.type` as `SomeModule` in warnings emitted by the pattern matcher.
| * | Expand test for SI-6124 to demonstrate cause of SI-7285.Jason Zaugg2013-03-232-3/+14
| |/
* | Merge pull request #2291 from retronym/ticket/7290Adriaan Moors2013-03-271-0/+9
|\ \ | | | | | | SI-7290 Discard duplicates in switchable alternative patterns.
| * | SI-7290 Discard duplicates in switchable alternative patterns.Jason Zaugg2013-03-231-0/+9
| |/ | | | | | | | | | | | | | | | | The pattern matcher must not allow duplicates to hit the backend when generating switches. It already eliminates then if they appear on different cases (with an unreachability warning.) This commit does the same for duplicated literal patterns in an alternative pattern: discard and warn.
* | Merge pull request #2288 from paulp/pr/2273-with-editsPaul Phillips2013-03-272-0/+17
|\ \ | | | | | | SI-6387 Clones accessor before name expansion
| * | SI-6387 Clones accessor before name expansionEugene Vigdorchik2013-03-252-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a symbol's name is expanded due to a conflict during composition (e.g. multiple traits with same-named members, but which are not both visible at the language level in the concrete class) the compiler renames some symbols with expanded names which embed the full name of the declaring class to avoid clashes. In the rare cases when the accessor overrides the member in base class, such expansion either results in AbstractMethodError when the base method is abstract, or, even worse, can change the semantics of the program. To avoid such issues, we clone the accessor symbol, clear its ACCESSOR flag and enter the symbol with an unchanged name.
* | | Merge pull request #2270 from retronym/ticket/7246-2Paul Phillips2013-03-258-8/+87
|\ \ \ | | | | | | | | SI-7246 Make $outer pointer elision Java aware
| * | | SI-7246 Make $outer pointer elision Java awareJason Zaugg2013-03-238-8/+87
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In e0853b3, a space-saving optimization elided the outer pointer of inner classes if the the (protected) outer pointer of the immediate parent class was guaranteed to point to the same instance. But, this check failed to account for Java parent classes, which don't follow the Scala scheme. This commit disables the optimization in that case. The original test case in e0853b3 was anemic, I've fleshed it out to: - test the presense or absense of $outer pointers with Java reflection - test the optimization works in the presense of aliased and annotated aliased types. (The former worked already, the latter required a change to the implementation.) - Test the negative case when the prefixes don't line up and the subclass in fact needs its own $outer. This patch is based on work by Euguene Vigdorchik with some additions by Jason Zaugg.
* | | Merge pull request #2257 from JamesIry/2.10.x_classfile_51Paul Phillips2013-03-251-0/+126
|\ \ \ | |_|/ |/| | Read version 51 (JDK 7) class files.
| * | Read version 51 (JDK 7) class files.James Iry2013-03-141-0/+126
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit makes the ClassFileReader/ICodeReader parse class files from JDK 7 (class file version 51). It does that by skipping over the method handle related entries in the constant pool and by doing some dummy processing on invoke dynamic instructions. The inliner is updated to not try to inline a method with an invoke dynamic instruction. A place holder INVOKE_DYNAMIC instruction is added to ICode but it is designed to create an error if there's ever any attempt to analyze it. Because the inliner is the only phase that ever tries to analyze ICode instructions not generated from Scala source and because Scala source will never emit an INVOKE_DYNAMIC, the place holder INVOKE_DYNAMIC should never cause any errors. A test is included that generates a class file with INVOKE_DYNAMIC and then compiles Scala code that depends on it.
* | Merge pull request #2274 from vigdorchik/ticket/si-5699James Iry2013-03-222-0/+35
|\ \ | | | | | | SI-5699 correct java parser for annotation defs.
| * | SI-5699 correct java parser for annotation defs.Eugene Vigdorchik2013-03-192-0/+35
| |/ | | | | | | | | Correct java source parser not to insert a constructor with the type of its value method.
* | Merge pull request #2245 from retronym/ticket/7242Paul Phillips2013-03-222-0/+91
|\ \ | | | | | | SI-7242 Fix crash when inner object mixes in its companion
| * | SI-7242 Fix crash when inner object mixes in its companionJason Zaugg2013-03-132-0/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given: class C { trait T { C.this } // C$T$$$outer$ : C object T extends T { C.this } // C$T$$$outer$ : C.this.type } object T ended up with a definitions for both of the accessors. These cannot co-exist, as they have the same erased type. A crash ensued almost immediately in explitouter. Fortunately, the solution is straightforward: we can just omit the mixin outer accessor altogether, the objects own outer accessor is compatible with it. scala> :javap C.T Compiled from "<console>" public interface C$T{ public abstract C C$T$$$outer(); } scala> :javap C.T$ Compiled from "<console>" public class C$T$ extends java.lang.Object implements C$T{ public C C$T$$$outer(); public C$T$(C); } I also added an assertion to give a better error message in case we find ourselves here again. Also includes tests from SI-3994, which I'll mark as a duplicate.
* | | Merge pull request #2261 from soc/SI-7258James Iry2013-03-202-3/+3
|\ \ \ | | | | | | | | SI-7258 Don't assume order of reflection values in t6223
| * | | SI-7258 Don't assume order of reflection values in t6223Simon Ochsenreither2013-03-152-3/+3
| | |/ | |/| | | | | | | | | | | | | | | | | | | test/files/run/t6223's check file expects a specific ordering of the reflected values. The ordering is not guaranteed by the runtime/reflection API and can change. Therefore, sort the values before comparing them.
* / | SI-7249 Reign in overzealous Function0 optimization.Jason Zaugg2013-03-132-0/+8
|/ / | | | | | | | | | | | | | | | | | | | | | | The fix for SI-1247 went too far, and could result in premature evaluation of the expression that yields the Function0. This commit checks that said expression is safe to inline. If not, a wrapper `() => ....` is still required. The optimization is still enabled in sitations like the original test case, run/t1247.scala.
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-22 21:29:24 +0000