summaryrefslogtreecommitdiff
path: root/src/compiler/scala/tools/nsc/transform/UnCurry.scala
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #5704 from som-snytt/issue/10190-elide-stringLukas Rytz2017-02-211-2/+6
|\ | | | | SI-10190 Elide string to empty instead of null
| * SI-10190 Elide string to empty instead of nullSom Snytt2017-02-151-2/+6
| | | | | | | | | | | | | | | | Avoid NPE when eliding string-valued functions. For example, `log(s"$cheap$expensive")` needn't print null. This is a natural and inexpensive way to elide strings.
* | Fix typos in compiler and reflectJanek Bogucki2017-02-131-2/+2
|/ | | | | | | | | | | | Miscellania: Miscellania is a small island off the northernmost part of the Fremennik Isles - RunScape Wiki Miscellanea: A collection of miscellaneous objects or writings - Merriam-Webster
* SI-10068 Only permit elidable methodsSom Snytt2016-12-141-1/+10
| | | | | | | | In refchecks, check that symbol with `@elidable` is a method. When eliding in uncurry, doublecheck. The check is enabled under `-Xsource:2.13`.
* SI-10071 Separate compilation for varargs methodsIulian Dragos2016-11-251-61/+34
| | | | | | | | | | | | | | | | | | Make sure that methods annotated with varargs are properly mixed-in. This commit splits the transformation into an info transformer (that works on all symbols, whether they come from source or binary) and a tree transformer. The gist of this is that the symbol-creation part of the code was moved to the UnCurry info transformer, while tree operations remained in the tree transformer. The newly created symbol is attached to the original method so that the tree transformer can still retrieve the symbol. A few fall outs: - I removed a local map that was identical to TypeParamsVarargsAttachment - moved the said attachment to StdAttachments so it’s visible between reflect.internal and nsc.transform - a couple more comments in UnCurry to honour the boy-scout rule
* SI-10059 reset the `DEFERRED` flag for Java varargs forwardersLukas Rytz2016-11-161-1/+1
| | | | | | | | | | | | | | | | | | | | When an abstract method is annotated `@varargs`, make sure that the generated synthetic Java varargs method does not have the `DEFERRED` flag (`ACC_ABSTRACT` in bytecode). The flag lead to an NPE in the code generator, because the ASM framework leaves certain fields `null` for abstract methods (`localVariables` in this case). Interestingly this did not crash in 2.11.x: the reason is that the test whether to emit a method body or not has changed in the 2.12 backend (in c8e6050). val isAbstractMethod = [..] methSymbol.isDeferred [..] // 2.11 val isAbstractMethod = rhs == EmptyTree // 2.12 So in 2.11, the varargs forwarder method was actually left abstract in bytecode, leading to an `AbstractMethodError: T.m([I)I` at run-time.
* Fields phase expands lazy vals like modulesAdriaan Moors2016-08-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They remain ValDefs until then. - remove lazy accessor logic now that we have a single ValDef for lazy vals, with the underlying machinery being hidden until the fields phase leave a `@deprecated def lazyAccessor` for scala-refactoring - don't skolemize in purely synthetic getters, but *do* skolemize in lazy accessor during typers Lazy accessors have arbitrary user code, so have to skolemize. We exempt the purely synthetic accessors (`isSyntheticAccessor`) for strict vals, and lazy accessors emitted by the fields phase to avoid spurious type mismatches due to issues with existentials (That bug is tracked as https://github.com/scala/scala-dev/issues/165) When we're past typer, lazy accessors are synthetic, but before they are user-defined to make this hack less hacky, we could rework our flag usage to allow for requiring both the ACCESSOR and the SYNTHETIC bits to identify synthetic accessors and trigger the exemption. see also https://github.com/scala/scala-dev/issues/165 ok 7 - pos/existentials-harmful.scala ok 8 - pos/t2435.scala ok 9 - pos/existentials.scala previous attempt: skolemize type of val inside the private[this] val because its type is only observed from inside the accessor methods (inside the method scope its existentials are skolemized) - bean accessors have regular method types, not nullary method types - must re-infer type for param accessor some weirdness with scoping of param accessor vals and defs? - tailcalls detect lazy vals, which are defdefs after fields - can inline constant lazy val from trait - don't mix in fields etc for an overridden lazy val - need try-lift in lazy vals: the assign is not seen in uncurry because fields does the transform (see run/t2333.scala) - ensure field members end up final in bytecode - implicit class companion method: annot filter in completer - update check: previous error message was tangled up with unrelated field definitions (`var s` and `val s_scope`), now it behaves consistently whether those are val/vars or defs - analyzer plugin check update seems benign, but no way to know... - error message gen: there is no underlying symbol for a deferred var look for missing getter/setter instead - avoid retypechecking valdefs while duplicating for specialize see pos/spec-private - Scaladoc uniformly looks to field/accessor symbol - test updates to innerClassAttribute by Lukas
* Merge pull request #5141 from adriaanm/fieldsAdriaan Moors2016-08-111-2/+5
|\ | | | | Introducing: the fields phase [ci: last-only]
| * Uncurry's info transform: non-static module --> methodAdriaan Moors2016-08-111-2/+5
| | | | | | | | | | | | | | We do this during uncurry so we can insert the necessary applications to the empty argument list. Fields is too late. Refchecks is no longer an info transform.
* | SI-8786 fix generic signature for @varargs forwarder methodsLukas Rytz2016-08-111-51/+67
|/ | | | | | | | | | | | | | | | | | | | | When generating a varargs forwarder for def foo[T](a: T*) the parameter type of the forwarder needs to be Array[Object]. If we gnerate Array[T] in UnCurry, that would be erased to plain Object, and the method would not be a valid varargs. Unfortunately, setting the parameter type to Array[Object] lead to an invalid generic signature - the generic signature should reflect the real signature. This change adds an attachment to the parameter symbol in the varargs forwarder method and special-cases signature generation. Also cleanes up the code to produce the varargs forwarder. For example, type parameter and parameter symbols in the forwarder's method type were not clones, but the same symbols from the original method were re-used.
* Lambda impl methods static and more stably namedJason Zaugg2016-06-011-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The body of lambdas is compiled into a synthetic method in the enclosing class. Previously, this method was a public virtual method named `fully$qualified$Class$$anonfun$n`. For lambdas that didn't capture a `this` reference, a static method was used. This commit changes two aspects. Firstly, all lambda impl methods are now emitted static. An extra parameter is added to those that require a this reference. This is an improvement as it: - allows, shorter, more readable names for the lambda impl method - avoids pollution of the vtable of the class. Note that javac uses private instance methods, rather than public static methods. If we followed its lead, we would be unable to support important use cases in our inliner Secondly, the name of the enclosing method has been included in the name of the lambda impl method to improve debuggability and to improve serialization compatibility. The serialization improvement comes from the way that fresh names for the impl methods are allocated: adding or removing lambdas in methods not named "foo" won't change the numbering of the `anonfun$foo$n` impl methods from methods named "foo". This is in line with user expectations about anonymous class and lambda serialization stability. Brian Goetz has described this tricky area well in: http://cr.openjdk.java.net/~briangoetz/eg-attachments/lambda-serialization.html This commit doesn't go as far a Javac, we don't use the hash of the lambda type info, param names, etc to map to a lambda impl method name. As such, we are more prone to the type-1 and -2 failures described there. However, our Scala 2.11.8 has similar characteristics, so we aren't going backwards. Special case in the naming: Use "new" rather than "<init>" for constructor enclosed lambdas, as javac does. I have also changed the way that "delambdafy target" methods are identifed. Rather than relying on the naming convention, I have switched to using a symbol attachment. The assumption is that we only need to identify them from within the same compilation unit. This means we can distinguish impl metbods for expanded functions (ones called from an `apply` method of an ahead-of-time expanded anonfun class), from those that truly end up as targets for lambda metafactory. Only the latter are translated to static methods in this patch.
* General cleanups and less warnings during a Scala buildsoc2016-04-041-1/+0
|
* Keep Function when CBN arg thunk targets a SAMAdriaan Moors2016-03-301-2/+5
| | | | | | | | | | | | | | | 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))`.
* Keep SAM body in anonfun method in enclosing classJason Zaugg2016-03-301-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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`.
* Better detection of types LMF cannot instantiate.Adriaan Moors2016-03-291-15/+6
| | | | | | | | | | | 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-3/+5
| | | | | | | | | | | | | 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.
* Soften sam restrictionsAdriaan Moors2016-03-261-2/+25
| | | | | | | | | | | | | 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.
* Treat `Function` literals uniformly, expecting SAM or FunctionN.Adriaan Moors2016-03-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Refactoring. Sweep Sammy's backyard.Adriaan Moors2016-03-261-94/+38
|
* Remove dead code now that `genBCodeActive` is always true.Adriaan Moors2016-03-261-17/+6
|
* New trait encoding: use default methods, jettison impl classesJason Zaugg2016-03-181-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, concrete methods in traits were encoded with "trait implementation classes". - Such a trait would compile to two class files - the trait interface, a Java interface, and - the implementation class, containing "trait implementation methods" - trait implementation methods are static methods has an explicit self parameter. - some methods don't require addition of an interface method, such as private methods. Calls to these directly call the implementation method - classes that mixin a trait install "trait forwarders", which implement the abstract method in the interface by forwarding to the trait implementation method. The new encoding: - no longer emits trait implementation classes or trait implementation methods. - instead, concrete methods are simply retained in the interface, as JVM 8 default interface methods (the JVM spec changes in [JSR-335](http://download.oracle.com/otndocs/jcp/lambda-0_9_3-fr-eval-spec/index.html) pave the way) - use `invokespecial` to call private or particular super implementations of a method (rather `invokestatic`) - in cases when we `invokespecial` to a method in an indirect ancestor, we add that ancestor redundantly as a direct parent. We are investigating alternatives approaches here. - we still emit trait fowrarders, although we are [investigating](https://github.com/scala/scala-dev/issues/98) ways to only do this when the JVM would be unable to resolve the correct method using its rules for default method resolution. Here's an example: ``` trait T { println("T") def m1 = m2 private def m2 = "m2" } trait U extends T { println("T") override def m1 = super[T].m1 } class C extends U { println("C") def test = m1 } ``` The old and new encodings are displayed and diffed here: https://gist.github.com/retronym/f174d23f859f0e053580 Some notes in the implementation: - No need to filter members from class decls at all in AddInterfaces (although we do have to trigger side effecting info transformers) - We can now emit an EnclosingMethod attribute for classes nested in private trait methods - Created a factory method for an AST shape that is used in a number of places to symbolically bind to a particular super method without needed to specify the qualifier of the `Super` tree (which is too limiting, as it only allows you to refer to direct parents.) - I also found a similar tree shape created in Delambdafy, that is better expressed with an existing tree creation factory method, mkSuperInit.
* Remove -Y settings that are no longer used in 2.12Lukas Rytz2016-02-161-4/+1
| | | | | | Added a deprecation warning for `-optimize`. Later we'll also graduate `-Yopt` to `-opt`, probably for 2.12.0-M5.
* Merge commit 'bf599bc' into merge/2.11.x-to-2.12.x-20160203Jason Zaugg2016-02-031-1/+1
|\ | | | | | | | | | | | | | | | | Conflicts: src/compiler/scala/tools/nsc/backend/opt/ConstantOptimization.scala src/compiler/scala/tools/nsc/transform/Constructors.scala src/compiler/scala/tools/nsc/typechecker/Contexts.scala src/scaladoc/scala/tools/nsc/doc/html/page/Template.scala src/scaladoc/scala/tools/nsc/doc/html/resource/lib/jquery.layout.js
| * Fix some simple extra wordsEitan Adler2016-01-171-1/+1
| | | | | | | | The the word 'the' is often used twice. Fix that.
* | Remove unused imports and other minor cleanupsSimon Ochsenreither2015-12-181-4/+5
| | | | | | | | | | | | | | | | | | | | - Language imports are preceding other imports - Deleted empty file: InlineErasure - Removed some unused private[parallel] methods in scala/collection/parallel/package.scala This removes hundreds of warnings when compiling with "-Xlint -Ywarn-dead-code -Ywarn-unused -Ywarn-unused-import".
* | Merge commit 'bb3ded3' into merge-2.11-to-2.12-oct-5Lukas Rytz2015-10-051-7/+0
|\|
| * SI-8127 Remove dead code in UncurryJason Zaugg2015-09-211-7/+0
| | | | | | | | | | It remains from the days of yore, when patterns survived this long in the compiler.
| * SI-9442 Fix the uncurry-erasure typesVlad Ureche2015-08-231-2/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using the "uncurry-erased" type (the one after the uncurry phase) can lead to incorrect tree transformations. For example, compiling: ``` def foo(c: Ctx)(l: c.Tree): Unit = { val l2: c.Tree = l } ``` Results in the following AST: ``` def foo(c: Ctx, l: Ctx#Tree): Unit = { val l$1: Ctx#Tree = l.asInstanceOf[Ctx#Tree] val l2: c.Tree = l$1 // no, not really, it's not. } ``` Of course, this is incorrect, since `l$1` has type `Ctx#Tree`, which is not a subtype of `c.Tree`. So what we need to do is to use the pre-uncurry type when creating `l$1`, which is `c.Tree` and is correct. Now, there are two additional problems: 1. when varargs and byname params are involved, the uncurry transformation desugares these special cases to actual typerefs, eg: ``` T* ~> Seq[T] (Scala-defined varargs) T* ~> Array[T] (Java-defined varargs) =>T ~> Function0[T] (by name params) ``` we use the DesugaredParameterType object (defined in scala.reflect.internal.transform.UnCurry) to redo this desugaring manually here 2. the type needs to be normalized, since `gen.mkCast` checks this (no HK here, just aliases have to be expanded before handing the type to `gen.mkAttributedCast`, which calls `gen.mkCast`)
* | Merge remote-tracking branch 'origin/2.11.x' into 2.12.xSeth Tisue2015-09-081-2/+39
| | | | | | | | | | | | | | | | only trivial merge conflicts here. not dealing with PR #4333 in this merge because there is a substantial conflict there -- so that's why I stopped at 63daba33ae99471175e9d7b20792324615f5999b for now
* | Uncurry does Literal RHS for ConstantType def, not ConstructorsAdriaan Moors2015-08-241-3/+15
| | | | | | | | | | | | | | | | | | Uncurry seems more logical to me. Ideally, Erasure would erase ConstantTypes, since they do not exist in bytecode. In any case, doing this earlier, when we're rewriting method anyway, simplifies constructors, which should be focussing on, well, constructors (& fields).
* | Merge remote-tracking branch 'origin/2.11.x' into ↵Jason Zaugg2015-07-231-1/+1
|\| | | | | | | merge/2.11.x-to-2.12.x-20152307
| * Fix 23 typos (t-v)Janek Bogucki2015-07-151-1/+1
| |
| * Avoid inefficient specialied lambdas w. delambdafy jvm-1.8, GenASMJason Zaugg2015-05-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | A previous change disabled -Ydelambdafy:method for specialized lambdas, as `DelambdafyTransformer` made no attempt to emit the requisite machinery to avoid boxing. This was loosened to allow them under `-target:jvm-1.8`, in the knowledge that `indylambda` would do the right thing. However, this wasn't quite right: indylambda is only supported in `GenBCode`, so we should consider that setting as well.
* | Require and target Java 8Jason Zaugg2015-05-261-1/+1
|/ | | | | | | | | | | | | | | - Require Java 8 in ant build - use -source 1.8 and -target 1.8 for javac - Default scalac's -target to `jvm-1.8`, ignore and deprecate attempts to use `jvm-1.{6.7}` - Remove fragile javap-app test. The feature itself is slated for removal. - Remove obsolete Java6 checkfile - Adapt DCE tests - Remove deprecated/redundant -target:jvm-1.6 from flags where the intent was to trigger generation of stack map frames. - Remove tests with -target:jvm-1.5 that tested without stack map frames - Ignore OpenJDK JVM warnings (via test/[files|scaladoc]/filters).
* SI-9302 -Xdisable-assertions raises elide levelSom Snytt2015-05-051-3/+1
| | | | | | | | | | Previously, the flag caused any elidable to be elided. This commit simply sets -Xelide-below to ASSERTION + 1. The flag is useful because there's no mnemonic for specifying the magic constant as an option argument. `-Xelide-below ASSERTION` means asserts are enabled.
* Support specialized method-handle based lambdasJason Zaugg2015-04-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | ``` scala> (x: Int) => {??? : Int} res2: Int => Int = $$Lambda$1371/1961176822@6ed3ccb2 scala> res2(42) scala.NotImplementedError: an implementation is missing at scala.Predef$.$qmark$qmark$qmark(Predef.scala:225) at .$anonfun$1(<console>:8) at $$Lambda$1371/1961176822.apply$mcII$sp(Unknown Source) ... 33 elided scala> (x: Int, y: Long) => {??? : Int} res4: (Int, Long) => Int = $$Lambda$1382/1796047085@6f8e8894 scala> res4(0, 0L) scala.NotImplementedError: an implementation is missing at scala.Predef$.$qmark$qmark$qmark(Predef.scala:225) at .$anonfun$1(<console>:8) at $$Lambda$1382/1796047085.apply$mcIIJ$sp(Unknown Source) ... 33 elided ```
* Merge pull request #4367 from retronym/topic/indylambda-specializationAdriaan Moors2015-04-131-1/+17
|\ | | | | Disable -Ydelambdafy:method for specialized FunctionN
| * Disable -Ydelambdafy:method for specialized FunctionNJason Zaugg2015-04-101-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Delambdafy phase generates its `FunctionN` subclasses after the specialization phase. As such, `((x: Int) => x).apply(42)` incurs boxing. This commit falls back to the `-Ydelambdafy:inline` in this case. This is done by running the specialization type map over the type of the function, and seeing if anything changes. To make this work robustly, we first need to ensure that the specialization info transformer has processed all the function types. This is not a fundamental limitation; we could in principle generate the specialized code. A followup change will use `-Ydelambdafy:method` as the basis for invokedymnamic lambdas. As part of that stream of work, we will synthesize specialization-aware lambdas, and remove the fallback to `-Ydelambdafy:inline`. I have updated some tests that intend to test the delambdafy transform to avoid use of specialized function types.
* | Removed warningsEECOLOR2015-03-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Added `since` to deprecation statement - Added unit to parameter list - Removed usage of deprecated method polyType - Replaced deprecated `debugwarn` with `devWarning` - Changed switch statement to if else in order to remove a warning - Switched implementation of `init` and `processOptions` to prevent warning - Replaced deprecated `Console.readLine` with `scala.io.StdIn.readLine` - Replaced deprecated `startOrPoint` with `start` - Replaced deprecated `tpe_=` with `setType` - Replaced deprecated `typeCheck` with `typecheck` - Replaced deprecated `CompilationUnit.warning` with `typer.context.warning` - Replaced deprecated `scala.tools.nsc.util.ScalaClassLoader` with `scala.reflect.internal.util.ScalaClassLoader` - Replaced deprecated `scala.tools.ListOfNil` with `scala.reflect.internal.util.ListOfNil` - Replaced deprecated `scala.tools.utils.ScalaClassLoader` with `scala.reflect.internal.util.ScalaClassLoader` - Replaced deprecated `emptyValDef` with `noSelfType` - In `BoxesRunTime` removed unused method and commented out unused values. Did not delete to keep a reference to the values. If they are deleted people might wonder why `1` and `2` are not used. - Replaced deprecated `scala.tools.nsc.util.AbstractFileClassLoader` with `scala.reflect.internal.util.AbstractFileClassLoader`
* | Fix InnerClass / EnclosingMethod for closures nested in value classesLukas Rytz2015-02-071-0/+4
|/ | | | | | | | | | | | | | | | | | | | | Members of value classes are moved over to the companion object early. This change ensures that closure classes nested in value classes appear that way to Java reflection. This commit also changes the EnclosingMethod attribute for classes (and anonymous functions) nested in anonymous function bodies. Before, the enclosing method was in some cases the function's apply method. Not always though: () => { class C ... val a = { class D ...} } The class C used to be nested in the function's apply method, but not D, because the value definition for a was lifted out of the apply. After this commit, we uniformly set the enclosing method of classes nested in function bodies to `null`. This is consistent with the source-level view of the code. Note that under delambdafy:method, closures never appear as enclosing classes (this didn't change in this commit).
* This ensures that typechecking custom unapplications in silent modeEugene Burmako2014-09-111-1/+1
| | | | | | doesn't leak uncatchable errors. Interestingly enough, the problem only manifested itself for custom unapply methods, not for synthetic ones generated for case classes.
* SI-8743 Fix crasher with poly-methods annotated with @varargsJason Zaugg2014-07-231-25/+16
| | | | | | | | | | | | | The code that generated the Java varargs forwarder was basing things on the `ValDef-s` of the parameters of the source method. But, their types refer to a type parameter skolems of the enclosing method, which led to a type mismatch when typechecking the forwarder. Instead, I've reworked the code to simply use the `DefDef`-s symbol's info, which *doesn't* refer to skolems. This actually simplifies the surrounding code somewhat; rather than repeated symbols in a map we can just time travel the pre-uncurry method signatures to figure out which params are releated.
* Rip out reporting indirection from CompilationUnitAdriaan Moors2014-07-041-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Inline the forwarders from CompilationUnit, which should not affect behavior. Since all forwarders lead to global.reporter, don't first navigate to a compilation unit, only to then forward back to global.reporter. The cleanup in the previous commits revealed a ton of confusion regarding how to report an error. This was a mechanical search/replace, which has low potential for messing things up, since the list of available methods are disjoint between `reporter` and `currentRun.reporting`. The changes involving `typer.context` were done previously. Essentially, there are three ways to report: - via typer.context, so that reporting can be silenced (buffered) - via global.currentRun.reporting, which summarizes (e.g., deprecation) - via global.reporter, which is (mostly) stateless and straightforward. Ideally, these should all just go through `global.currentRun.reporting`, with the typing context changing that reporter to buffer where necessary. After the refactor, these are the ways in which we report (outside of typer): - reporter.comment - reporter.echo - reporter.error - reporter.warning - currentRun.reporting.deprecationWarning - currentRun.reporting.incompleteHandled - currentRun.reporting.incompleteInputError - currentRun.reporting.inlinerWarning - currentRun.reporting.uncheckedWarning Before: - c.cunit.error - c.enclosingUnit.deprecationWarning - context.unit.error - context.unit.warning - csymCompUnit.warning - cunit.error - cunit.warning - currentClass.cunit.warning - currentIClazz.cunit.inlinerWarning - currentRun.currentUnit.error - currentRun.reporting - currentUnit.deprecationWarning - currentUnit.error - currentUnit.warning - getContext.unit.warning - getCurrentCUnit.error - global.currentUnit.uncheckedWarning - global.currentUnit.warning - global.reporter - icls.cunit.warning - item.cunit.warning - reporter.comment - reporter.echo - reporter.error - reporter.warning - reporting.deprecationWarning - reporting.incompleteHandled - reporting.incompleteInputError - reporting.inlinerWarning - reporting.uncheckedWarning - typer.context.unit.warning - unit.deprecationWarning - unit.echo - unit.error - unit.incompleteHandled - unit.incompleteInputError - unit.uncheckedWarning - unit.warning - v1.cunit.warning All these methods ended up calling a method on `global.reporter` or on `global.currentRun.reporting` (their interfaces are disjoint). Also clean up `TypeDiagnostics`: inline nearly-single-use private methods.
* SI-8363 Disable -Ydelambdafy:method in constructor positionJason Zaugg2014-03-101-1/+3
| | | | | | | | | | | | | | As @magarciaEPFL has done in his experimental optimizer [1], we can avoid running into limitations of lambdalift (either `VerifyError`s, ala SI-6666, or compiler crashes, such as this bug), by using the old style of "inline" lambda translation when in a super- or self- construtor call. We might be able to get these working later on, but for now we shouldn't block adoption of `-Ydelamndafy:method` for this corner case. [1] https://github.com/magarciaEPFL/scala/blob/GenRefactored99sZ/src/compiler/scala/tools/nsc/transform/UnCurry.scala#L227
* disambiguates uses of “local” in internal symbol APIEugene Burmako2014-02-121-1/+1
| | | | | | | | | | | | | | | | | There’s been a conflation of two distinct meanings of the word “local” in the internal symbol API: the first meaning being “local to this” (as in has the LOCAL flag set), the second meaning being “local to block” (as in declared in a block, i.e. having owner being a term symbol). Especially confusing is the fact that sym.isLocal isn’t the same as sym.hasFlag(LOCAL), which has led to now fixed SI-6733. This commit fixes the semantic mess by deprecating both Symbol.isLocal and Symbol.hasLocalFlag (that we were forced to use, because Symbol.isLocal had already been taken), and replacing them with Symbol.isLocalToThis and Symbol.isLocalToBlock. Unfortunately, we can’t remove the deprecated methods right away, because they are used in SBT, so I had to take small steps.
* Optimization in UncurryJason Zaugg2014-01-311-2/+1
| | | | | Only perform HashMap lookup of a tree until after checking more cheaply if it refers to a symbol with by-name parameter type.
* Merge 2.10.x into masterAdriaan Moors2014-01-181-5/+7
|\
| * SI-8143 Fix bug with super-accessors / dependent typesJason Zaugg2014-01-121-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* | SI-7897, SI-6675 improves name-based patmatPaul Phillips2013-12-151-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This emerges from a recent attempt to eliminate pattern matcher related duplication and to bake the scalac-independent logic out of it. I had in mind something a lot cleaner, but it was a whole lot of work to get it here and I can take it no further. Key file to admire is PatternExpander.scala, which should provide a basis for some separation of concerns. The bugs addressed are a CCE involving Tuple1 and an imprecise warning regarding multiple pattern crushing. Editorial: auto-tupling unapply results was a terrible idea which should never have escaped from the crib. It is tantamount to purposely throwing type safety down the toilet in the very place where people need type safety the most. See SI-6111 and SI-6675 for some other comments.
* | Refactor away duplication between -Ydelambdafy:{inline,method}Jason Zaugg2013-11-231-64/+7
| |
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-14 07:34:26 +0000