summaryrefslogtreecommitdiff
path: root/test/files
Commit message (Collapse)AuthorAgeFilesLines
* Add SerialVersionUID to ListSetRui Gonçalves2016-05-171-1/+3
|
* Make ListMap and ListSet implementations similarRui Gonçalves2016-05-172-4/+4
| | | | ListSet and ListMap are two collections which share the exact same internal structure. This commit makes the two approaches as similar as possible by renaming and reordering internal methods, improving their Scaladoc and their code style. The Scaladoc of the classes and companion objects is also improved in order to alert users of the time complexity of the collections' operations.
* Improve performance and behavior of ListMap and ListSetRui Gonçalves2016-05-175-36/+4
| | | | | | | | Makes the immutable `ListMap` and `ListSet` collections more alike one another, both in their semantics and in their performance. In terms of semantics, makes the `ListSet` iterator return the elements in their insertion order, as `ListMap` already does. While, as mentioned in SI-8985, `ListMap` and `ListSet` doesn't seem to make any guarantees in terms of iteration order, I believe users expect `ListSet` and `ListMap` to behave in the same way, particularly when they are implemented in the exact same way. In terms of performance, `ListSet` has a custom builder that avoids creation in O(N^2) time. However, this significantly reduces its performance in the creation of small sets, as its requires the instantiation and usage of an auxilliary HashSet. As `ListMap` and `ListSet` are only suitable for small sizes do to their performance characteristics, the builder is removed, the default `SetBuilder` being used instead.
* More efficient code for deciding if a mixin forwarder is needed (#5116)Lukas Rytz2016-04-254-0/+15
| | | | Also adds a warning on junit test methods that compile as default methods.
* Merge pull request #5115 from lrytz/merge-2.11-to-2.12-apr-22Lukas Rytz2016-04-254-0/+76
|\ | | | | Merge 2.11 to 2.12 apr 22
| * Merge commit '684c314' into merge-2.11-to-2.12-apr-22Lukas Rytz2016-04-224-0/+76
| |\
| | * SI-9734 Narrow type when import REPL history (#5084)som-snytt2016-04-202-0/+40
| | | | | | | | | | | | | | | Under `-Yrepl-class-based`, imports from historical `$read` instances must be singleton-typed so that path-dependent types remain so.
| | * SI-9735 REPL prefer standard escapes for code text (#5086)som-snytt2016-04-202-0/+36
| | | | | | | | | | | | | | | When constructing code text for compilation, the REPL should prefer standard escape sequences, in case unicode escapes are disabled.
| | * SI-9488 - adds the same default toString format to Scala Futures as 2.12.xViktor Klang2016-03-221-2/+18
| | | | | | | | | | | | Includes tests to verify the toString representations.
* | | Merge pull request #5109 from lrytz/pr5064Lukas Rytz2016-04-2322-45/+70
|\ \ \ | | | | | | | | SI-9684 Deprecate JavaConversions
| * | | Rename the (deprecated) implicit conversion methods in JavaConversionsLukas Rytz2016-04-222-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | Provide higher-priority implicit conversion methods whose names don't clash with methods in JavaConverters. This allows implicit conversions to work when importing both JavaConverters._ and JavaConversions._.
| * | | SI-9684 Deprecate JavaConversionsSom Snytt2016-04-2220-45/+49
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | Implicit conversions are now in package convert as ImplicitConversions, ImplicitConversionsToScala and ImplicitConversionsToJava. Deprecated WrapAsJava, WrapAsScala and the values in package object. Improve documentation.
* / / SI-9516 Fix the behavior of Int shift Long operations. (#5117)Sébastien Doeraene2016-04-231-0/+52
|/ / | | | | | | | | | | | | | | | | | | | | In any shift operation where the lhs is an Int (or smaller) and the rhs is a Long, the result kind must be Int, and not Long. This is important because the lhs must *not* be promoted to a Long, as that causes an opcode for long shift to be emitted. This uses an rhs modulo 64, instead of int shifts which use an rhs module 32. Instead, the rhs must be downgraded to an Int. The new behavior is consistent with the same operations in the Java programming language.
* | Merge pull request #5110 from sjrd/remove-duplicate-implem-of-hashcodesLukas Rytz2016-04-222-7/+6
|\ \ | | | | | | Remove the duplicate implem of hash codes for numbers.
| * | Remove the duplicate implem of hash codes for numbers.Sébastien Doeraene2016-04-212-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, there were two separate implementations of hash code for boxed number classes: * One in Statics, used by the codegen of case class methods. * One in ScalaRunTime + BoxesRunTime, used by everything else. This commit removes the variant implemented in ScalaRunTime + BoxesRunTime, and always uses Statics instead. We use Statics because the one from ScalaRunTime causes an unnecessary module load. The entry point ScalaRunTime.hash() is kept, as deprecated, for bootstrapping reasons.
* | | Merge pull request #5096 from lrytz/traitParentsLukas Rytz2016-04-2012-62/+50
|\ \ \ | |/ / |/| | Ensure ClassBTypes constructed from symbol and classfile are identical
| * | Clean up code gen for method invocationsLukas Rytz2016-04-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code was patched many times in the history and became a bit scattered. When emitting a virtual call, the receiver in the bytecode cannot just be the method's owner (the class in which it is declared), because that class may not be accessible at the callsite. Instead we use the type of the receiver. This was basically done to fix - aladdin bug 455 (9954eaf) - SI-1430 (0bea2ab) - basically the same bug, slightly different - SI-4283 (8707c9e) - the same for field reads In this patch we extend the fix to field writes, and clean up the code. This patch basically reverts 6eb55d4b, the fix for SI-4560, which was rather a workaround than a fix. The underlying problem was that in some cases, in a method invocation `foo.bar()`, the method `bar` was not actually a member of `foo.tpe`, causing a NoSuchMethodErrors. The issue was related to trait implementation classes. The idea of the fix was to check, at code-gen time, `foo.tpe.member("bar")`, and if that returns `NoSymbol`, use `barSym.owner`. With the new trait encoding the underlying problem seems to be fixed - all tests still pass (run/t4560.scala and run/t4560b.scala).
| * | Move test run/origins.scala to pendingLukas Rytz2016-04-123-28/+0
| | | | | | | | | | | | | | | | | | | | | | | | It tests an internal debugging tool which does not appear to work as intented. If anyone can compile and run that test and get an output that looks like the check file, I'd be interested to know. Origins does not seem to support the kind of stack traces that scalac currently emits.
| * | SD-98 don't emit unnecessary mixin forwardersLukas Rytz2016-04-128-33/+49
| | | | | | | | | | | | | | | | | | | | | | | | In most cases when a class inherits a concrete method from a trait we don't need to generate a forwarder to the default method in the class. t5148 is moved to pos as it compiles without error now. the error message ("missing or invalid dependency") is still tested by t6440b.
* | | Merge pull request #5098 from sjrd/simplify-scala-runtimeLukas Rytz2016-04-202-6/+3
|\ \ \ | | | | | | | | Simplify scala.runtime
| * | | Remove dead-code runtime hash() methods.Sébastien Doeraene2016-04-132-6/+3
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ScalaRunTime had a bunch of overloads of the `hash()` method, but only the `Any` version is ever used by the codegen. Worse, their implementation was not in sync with the actual implementations in BoxesRunTime, called by the `Any` version. For example, hash(0x80000000L) != hash(0x80000000L: Any) This commit simply removes all of this dead code. Similarly, we remove BoxesRunTime.hashFromObject(), which was never called either.
* / / SI-9749 REPL strip lead ws on dot continuation (#5097)som-snytt2016-04-152-0/+18
|/ / | | | | | | | | | | Permit leading whitespace before `.` for continued selection. This is just to handle pastes, which will typically include indented text, and not to make dot-continuation especially robust.
* | Remove references to trait impl classes, mostly in doc commentsLukas Rytz2016-04-072-1/+24
| |
* | Fix minor typoNafer Sanabria2016-04-041-1/+1
| |
* | Merge pull request #5068 from retronym/topic/jdk8ism2v2.12.0-M4Lukas Rytz2016-04-014-5/+22
|\ \ | | | | | | Accomodate and exploit new library, lang features JDK 8
| * | Java types and type parameters can be annotated since JSR 308Jason Zaugg2016-03-292-0/+10
| | |
| * | SI-7474 Record extra errors in Throwable#suppressedExceptionsJason Zaugg2016-03-292-5/+12
| | | | | | | | | | | | | | | | | | | | | ... in parallel collection operations. Followup to bcbe38d18, which did away with the the approach to use a composite exception when more than one error happened.
* | | Merge pull request #4971 from adriaanm/genbcode-delambdafyAdriaan Moors2016-03-3152-65/+353
|\ \ \ | | | | | | | | Unify treatment of built-in functions and SAMs
| * | | typedFunction undoes eta-expansion regardless of expected typeAdriaan Moors2016-03-301-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | When recovering missing argument types for an eta-expanded method value, rework the expected type to a method type.
| * | | Keep Function when CBN arg thunk targets a SAMAdriaan Moors2016-03-301-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The body of `def delay[T](v: => T) = (v _): F0[T]` becomes `() => v` during `typedEta`, and then uncurry considers whether to strip the function wrapper since `v` is known to be a `Function0` thunk. Stripping is sound when the expected type is `Function0` for this expression, but that's no longer a given, since we could be expecting any nullary SAM. Also sweep up a bit around `typedEta`. Encapsulate the, erm, creative encoding of `m _` as `Typed(m, Function(Nil, EmptyTree))`.
| * | | Bring back AbstractFunction parentAdriaan Moors2016-03-304-7/+5
| | | | | | | | | | | | | | | | | | | | Jason points out we still need it for bytecode efficiency, due to mixin forwarders.
| * | | Keep SAM body in anonfun method in enclosing classJason Zaugg2016-03-301-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than in implementation of the abstract method in the expanded anonymous class. This leads to more more efficient use of the constant pool, code shapes more amenable to SAM inlining, and is compatible with the old behaviour of `-Xexperimental` in Scala 2.11, which ScalaJS now relies upon. Manual test: ``` scala> :paste -raw // Entering paste mode (ctrl-D to finish) package p1; trait T { val x = 0; def apply(): Any }; class DelambdafyInline { def t: T = (() => "") } // Exiting paste mode, now interpreting. scala> :javap -c p1.DelambdafyInline Compiled from "<pastie>" public class p1.DelambdafyInline { public p1.T t(); Code: 0: new #10 // class p1/DelambdafyInline$$anonfun$t$1 3: dup 4: aload_0 5: invokespecial #16 // Method p1/DelambdafyInline$$anonfun$t$1."<init>":(Lp1/DelambdafyInline;)V 8: areturn public final java.lang.Object p1$DelambdafyInline$$$anonfun$1(); Code: 0: ldc #22 // String 2: areturn public p1.DelambdafyInline(); Code: 0: aload_0 1: invokespecial #25 // Method java/lang/Object."<init>":()V 4: return } scala> :javap -c p1.DelambdafyInline$$anonfun$t$1 Compiled from "<pastie>" public final class p1.DelambdafyInline$$anonfun$t$1 implements p1.T,scala.Serializable { public static final long serialVersionUID; public int x(); Code: 0: aload_0 1: getfield #25 // Field x:I 4: ireturn public void p1$T$_setter_$x_$eq(int); Code: 0: aload_0 1: iload_1 2: putfield #25 // Field x:I 5: return public final java.lang.Object apply(); Code: 0: aload_0 1: getfield #34 // Field $outer:Lp1/DelambdafyInline; 4: invokevirtual #37 // Method p1/DelambdafyInline.p1$DelambdafyInline$$$anonfun$1:()Ljava/lang/Object; 7: areturn public p1.DelambdafyInline$$anonfun$t$1(p1.DelambdafyInline); Code: 0: aload_1 1: ifnonnull 6 4: aconst_null 5: athrow 6: aload_0 7: aload_1 8: putfield #34 // Field $outer:Lp1/DelambdafyInline; 11: aload_0 12: invokespecial #42 // Method java/lang/Object."<init>":()V 15: aload_0 16: invokespecial #45 // Method p1/T.$init$:()V 19: return } scala> :quit ``` Adriaan is to `git blame` for `reflection-mem-typecheck.scala`.
| * | | LMF cannot instantiate SAM of trait with non-trait superclassAdriaan Moors2016-03-296-6/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also, drop AbstractFunction for parent of anonymous subclass of function type that must have its class spun up at compile time (rather than at linkage time by LambdaMetaFactory). This revealed an old problem with typedTemplate, in which parent types may be normalized at the level of trees, while this change does not get propagated to the class's info in time for the constructor to be located when we type check the primary constructor.
| * | | LMF cannot run trait's "initializer" (constructor)Adriaan Moors2016-03-292-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | Thus, rule out traits that have a constructor (which we use as a proxy for having potentially side-effecting statements), and create an anonymous subclass for them at compile time.
| * | | Better detection of types LMF cannot instantiate.Adriaan Moors2016-03-292-34/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LambdaMetaFactory can only properly instantiate Java interfaces (with one abstract method, of course). A trait always compiles to an interface, but a subclass that can be instantiated may require mixing in further members, which LMF cannot do. (Nested traits, traits with fields,... do not qualify.) Traits that cannot be instantiated by LMF are still SAM targets, we simply created anonymous subclasses as before.
| * | | Specialization precludes use of LambdaMetaFactory for SAMAdriaan Moors2016-03-291-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a SAM type is specialized (i.e., a specialized type parameter receives a specialized type argument), do not use LambdaMetaFactory (expand during Uncurry instead). This is an implementation restriction -- the current specialization scheme is not amenable to using LambdaMetaFactory to spin up subclasses. Since the generic method is abstract, and the specialized ones are concrete, specialization is rendered moot because we cannot implement the specialized method with the lambda using LMF.
| * | | Target FunctionN, not scala/runtime/java8/JFunction.Adriaan Moors2016-03-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We compile FunctionN to Java 8's idea of a function now, so no need to target the artisanal JFunction and friends, except when the function is specialized, as I don't yet see how we can use LMF with the way specialization handles FunctionN: First, the working status quo -- the hand-crafted specialized versions of JFunction0. Notice how `apply$mcB$sp` is looking pretty SAMmy: ``` @FunctionalInterface public interface JFunction0$mcB$sp extends JFunction0 { @Override public byte apply$mcB$sp(); @Override default public Object apply() { return BoxesRunTime.boxToByte(this.apply$mcB$sp()); } } ``` Contrast this with our specialized standard FunctionN: ``` public interface Function0<R> { public R apply(); default public byte apply$mcB$sp() { return BoxesRunTime.unboxToByte(this.apply()); } } public interface Function0$mcB$sp extends Function0<Object> { } ``` The single abstract method in `Function0$mcB$sp` is `apply`, and the method that would let us avoid boxing, if it were abstract, is `apply$mcB$sp`... TODO (after M4): - do same for specialized functions (issues with boxing?) - remove scala/runtime/java8/JFunction* (need new STARR?)
| * | | SAM conversion can be disabled using `-Xsource:2.11`Adriaan Moors2016-03-263-0/+8
| | | | | | | | | | | | | | | | For completeness, `-Xsource:2.11 -Xexperimental` does enable it.
| * | | SAM conversion precedes implicit view application (as in dotty).Adriaan Moors2016-03-261-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reflects the majority vote on the PR. DSLs that need their implicit conversions to kick in instead of SAM conversion, will have to make their target types not be SAM types (e.g., by adding a second abstract method to them).
| * | | Soften sam restrictionsAdriaan Moors2016-03-262-54/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some of the earlier proposals were too strongly linked to the requirements of the Java 8 platform, which was problematic for scala.js & friends. Instead of ruling out SAM types that we can't compile to use LambdaMetaFactory, expand those during compilation to anonymous subclasses, instead of invokedynamic + LMF. Also, self types rear their ugly heads again. Align `hasSelfType` with the implementation suggested in `thisSym`'s docs.
| * | | Track Function's SAM symbol & target type using an attachmentAdriaan Moors2016-03-261-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We cannot use the expected type to track whether a Function node targets a SAM type, as the expected type may be erased (see test for an example). Thus, the type checker attaches a SAMFunction attachment to a Function node when SAM conversion is performed in adapt. Ideally, we'd move to Dotty's Closure AST, but that will need a deprecation cycle. Thanks to Jason for catching my mistake, suggesting the fix and providing the test. Both the sam method symbol and sam target type must be tracked, as their relationship can be complicated (due to inheritance). For example, the sam method could be defined in a superclass (T) of the Function's target type (U). ``` trait T { def foo(a: Any): Any } trait U extends T { def apply = ??? } (((x: Any) => x) : U).foo("") ``` This removes some of the duplication in deriving the sam method from the expected type, but some grossness (see TODO) remains.
| * | | Don't adapt erroneous tree to SAM type.Adriaan Moors2016-03-262-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | Do not report second error. Go straight to the exit. Based on review by Jason.
| * | | Test bytecode emitted for indy sammyAdriaan Moors2016-03-261-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Test that SAM conversion happens after implicit view application A function node is first type checked, and parameter types are inferred, regardless of whether the expected function type is one of our built-in FunctionN classes, or a user-defined Single Abstract Method type. `typedFunction` always assigns a built-in `FunctionN` type to the tree, though. Next, if the expected type is a (polymorphic) SAM type, this creates a tension between the tree's type and the expect type. This gap is closed by the adapt method, by applying one of the implicit conversion in the spec in order (e.g., numeric widening, implicit view application, and now, also SAM conversion) Thus, `adaptToSam` will assign the expected SAM type to the `Function` tree. (This may require some type inference.) The back-end will emit the right invokedynamic instruction that uses Java's LambdaMetaFactory to spin up a class that implements the target method (whether it's defined in FunctionN or some other Java functional interface).
| * | | Additional SAM restrictions identified by JasonAdriaan Moors2016-03-268-71/+111
| | | | | | | | | | | | | | | | | | | | Also test roundtripping serialization of a lambda that targets a SAM that's not FunctionN (it should make no difference).
| * | | More fixes based on feedback by LukasAdriaan Moors2016-03-2611-8/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Crucially, the fully-defined expected type must be checked for conformance to the original expected type!! The logic in adaptToSam that checks whether pt is fully defined probably needs some more thought. See pos/t8310 for a good test case. Argument type checking is a challenge, as we first check against a lenient pt (this lenient expected type has wildcards, and thus is not fully defined, but we should still consider sam adaptation a success even if we end up with wildcards for some unknown type parameters, they should be determined later).
| * | | Refactoring. Simplify inferImplicit's boolean leversAdriaan Moors2016-03-261-1/+1
| | | |
| * | | Treat `Function` literals uniformly, expecting SAM or FunctionN.Adriaan Moors2016-03-265-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They both compile to INDY/MetaLambdaFactory, except when they occur in a constructor call. (TODO: can we lift the ctor arg expression to a method and avoid statically synthesizing anonymous subclass altogether?) Typers: - no longer synthesize SAMs -- *adapt* a Function literal to the expected (SAM/FunctionN) type - Deal with polymorphic/existential sams (relevant tests: pos/t8310, pos/t5099.scala, pos/t4869.scala) We know where to find the result type, as all Function nodes have a FunctionN-shaped type during erasure. (Including function literals targeting a SAM type -- the sam type is tracked as the *expected* type.) Lift restriction on sam types being class types. It's enough that they dealias to one, like regular instance creation expressions. Contexts: - No longer need encl method hack for return in sam. Erasure: - erasure preserves SAM type for function nodes - Normalize sam to erased function type during erasure, otherwise we may box the function body from `$anonfun(args)` to `{$anonfun(args); ()}` because the expected type for the body is now `Object`, and thus `Unit` does not conform. Delambdafy: - must set static flag before calling createBoxingBridgeMethod - Refactored `createBoxingBridgeMethod` to wrap my head around boxing, reworked it to generalize from FunctionN's boxing needs to arbitrary LMF targets. Other refactorings: ThisReferringMethodsTraverser, TreeGen.
| * | | Review feedback from LukasAdriaan Moors2016-03-261-1/+1
| | | |
| * | | SI-9449 sam expansion for explicitly eta-expanded methodAdriaan Moors2016-03-261-0/+19
| | | |
| * | | Refactor typedFunction, rework synthesizeSAMFunction for sammyAdriaan Moors2016-03-268-6/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `typedFunction` uniformly recognizes Single Abstract Method types and built-in `FunctionN` types, type checking literals regardless of expected type. `adapt` synthesizes an anonymous subclass of the SAM type, if needed to meet the expected (non-`FunctionN`) type. (Later, we may want to carry `Function` AST nodes with SAM types through the whole pipeline until the back-end, and treat them uniformly with built-in function types there too, emitting the corresponding `invokedynamic` & `LambdaMetaFactory` bytecode. Would be faster to avoid synthesizing all this code during type checking...) Refactor `typedFunction` for performance and clarity to avoid non-local returns. A nice perk is that the error message for missing argument types now indicates with `<error>` where they are missing (see updated check file). Allow pattern matching function literals when SAM type is expected (SI-8429). Support `return` in function body of SAM target type, by making the synthetic `sam$body` method transparent to the `enclMethod` chain, so that the `return` is interpreted in its original context. A cleaner approach to inferring unknown type params of the SAM method. Now that `synthesizeSAMFunction` operates on typed `Function` nodes, we can take the types of the parameters and the body and compare them against the function type that corresponds to the SAM method's signature. Since we are reusing the typed body, we do need to change owners for the symbols, and substitute the new method argument symbols for the function's vparam syms. Impl Notes: - The shift from typing as a regular Function for SAM types was triggered by limitation of the old approach, which deferred type checking the body until it was in the synthetic SAM type subclass, which would break if the expression was subsequently retypechecked for implicit search. Other problems related to SAM expansion in ctor args also are dodged now. - Using `<:<`, not `=:=`, in comparing `pt`, as `=:=` causes `NoInstance` exceptions when `WildcardType`s are encountered. - Can't use method type subtyping: method arguments are in invariant pos. - Can't use STATIC yet, results in illegal bytecode. It would be a better encoding, since the function body should not see members of SAM class. - This is all battle tested by running `synthesizeSAMFunction` on all `Function` nodes while bootstrapping, including those where a regular function type is expected. The only thing that didn't work was regarding Function0 and the CBN transform, which breaks outer path creation in lambdalift.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-08 15:36:15 +0000