summaryrefslogtreecommitdiff
path: root/src/compiler/scala/tools/nsc/backend/jvm/GenASM.scala
Commit message (Collapse)AuthorAgeFilesLines
* Remove GenASM, merge remaining common code snippetsSimon Ochsenreither2015-10-271-3355/+0
| | | | | | | | With GenBCode being the default and only supported backend for Java 8, we can get rid of GenASM. This commit also fixes/migrates/moves to pending/deletes tests which depended on GenASM before.
* SI-9535 correct bytecode and generic signatures for @throws[TypeParam]Lukas Rytz2015-10-261-3/+10
| | | | | | | For @throws[E] where E is not a class type, GenASM incorrectly writes the non-class type to the classfile. GenBCode used to crash before this commit. Now GenBCode correctly emits the erased type (like javac) and adds a generic signature.
* Merge pull request #4689 from retronym/topic/trait-default-specializationLukas Rytz2015-09-181-1/+2
|\ | | | | Preparation for using default methods in traits
| * Allow BCode to emit default interface methodsJason Zaugg2015-08-111-1/+2
| | | | | | | | | | | | | | | | | | | | A DefDef owned by a trait may now have have a method body. Such a method must be emitted without ACC_ABSTRACT, and with the code attribute. Tested by intercepting the compile pipeline and adding the DEFAULTMETHOD flag and a method body before running the backend.
* | Merge remote-tracking branch 'origin/2.11.x' into 2.12.xSeth Tisue2015-09-081-1/+1
| | | | | | | | | | | | | | | | 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
* | Merge remote-tracking branch 'origin/2.11.x' into 2.12.xSeth Tisue2015-08-201-2/+6
|\ \ | |/ |/| | | | | | | | | | | | | | | all conflicts were because the changes changed code that doesn't exist anymore in 2.12; they were resolved with `git checkout --ours` c201eac changed bincompat-forward.whitelist.conf but I dropped the change in this merge because it refers to AbstractPromise which no longer exists in 2.12
| * Merge pull request #4678 from stusmall/2.11.xLukas Rytz2015-08-101-0/+4
| |\ | | | | | | Improved error message for "filename too long" build errors
| | * SI-3623 Improved error message for "filename too long" build errorsstusmall2015-08-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | When building on ecryptfs filenames can be limited to ~142 characters. This limit doesn't take long to hit and can leave the the user with a hard to diagnosis error message. Some legacy file systems will have similarly small limits. This just adds a hint that the error might be related to the underlying fs.
| * | ScalaDoc fixes for compilerJanek Bogucki2015-07-291-2/+2
| |/
| * Rename the ENUM / DEFAULTMETHOD flags to include JAVA_Lukas Rytz2015-07-241-1/+1
| | | | | | | | | | Similar to the new JAVA_ANNOTATION flag, be more explicit about flags for java entities.
* | Merge pull request #4638 from lrytz/t9393Jason Zaugg2015-07-241-1/+1
|\ \ | | | | | | SI-9393 fix modifiers of ClassBTypes for Java annotations
| * | Rename the ENUM / DEFAULTMETHOD flags to include JAVA_Lukas Rytz2015-07-221-1/+1
| | | | | | | | | | | | | | | Similar to the new JAVA_ANNOTATION flag, be more explicit about flags for java entities.
* | | 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 6 typos (w-z)Janek Bogucki2015-07-171-1/+1
| |
* | Merge branch '2.11.x' into merge/2.11.x-to-2.12.x-20150624Jason Zaugg2015-06-241-17/+11
|\|
| * SI-9359 Fix InnerClass entry flags for nested Java enumsLukas Rytz2015-06-191-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The access flags in InnerClass entries for nested Java enums were basically completely off. A first step is to use the recently introduced backend method `javaClassfileFlags`, which is now moved to BCodeAsmCommon. See its doc for an explanation. Then the flags of the enum class symbol were off. An enum is - final if none of its values has a class body - abstract if it has an abstract method (https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.9) When using the ClassfileParser: - ENUM was never added. I guess that's just an oversight. - ABSTRACT (together with SEALED) was always added. This is to enable exhaustiveness checking, see 3f7b8b5. This is a hack and we have to go through the class members in the backend to find out if the enum actually has the `ACC_ABSTRACT` flag or not. When using the JavaParser: - FINAL was never added. - ABSTRACT was never added. This commit fixes all of the above and tests cases (Java enum read from the classfile and from source).
| * SI-9356 more careful assertion in back-endAdriaan Moors2015-06-161-11/+9
| | | | | | | | | | | | | | | | | | | | | | Calling `exists` on a `Symbol` triggers unpickling, which failed for reasons I did not investigate. Replaced `sym.exists` by `sym != NoSymbol`, which is good enough here. Also replaced assertion by a `devWarning`, since the logic seems too ad-hoc to actually crash the compiler when it's invalidated. Partially reverts b45a91fe22. See also #1532.
* | Require and target Java 8Jason Zaugg2015-05-261-3/+0
|/ | | | | | | | | | | | | | | - 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).
* Removed warningsEECOLOR2015-03-261-4/+4
| | | | | | | | | | | | | | | | | | | | | - 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`
* new{Term,Type}Name→{Term,Type}Name, tpename/nme→{type,term}NamesSimon Ochsenreither2015-03-261-1/+1
|
* Deprecations: Use of isPackage, hasSymbol, getter, setter...Simon Ochsenreither2015-03-261-2/+2
| | | | ... replaced by hasPackageFlag, hasSymbolIn, getterIn, setterIn.
* SI-9226 Fix NPE in GenASM.writeIfNotTooBigSimon Schäfer2015-03-161-1/+1
| | | | | | | | | | On 2.11.6 line 535 (as reported in the issue) points to the changed line. Exception.getMessage can return null. Checking for null on the matched variable is not necessary. No tests, because I have no idea on how to reproduce the problem.
* Emit the ScalaInlineInfo attribute under GenASMLukas Rytz2015-03-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal of this commit is to allow the new inliner (in GenBCode, coming soon) to inline methods generated by the GenASM backend of 2.11.6. The ScalaInlineInfo attribute is added to every classfile generated by GenASM. It contains metadata about the class and its methods that will be used by the new inliner. Storing this metadata to the classfile prevents the need to look up a class symbol for a certain class file name, a process that is known to be brittle due to name mangling. Also, some symbols are not exactly the same when originating in a class being compiled or an unpickled one. For example, method symbols for mixed-in members are only added to classes being compiled. The classfile attribute is relatively small, because all strings it references (class internal names, method names, method descriptors) would exist anyway in the constant pool. It just adds a few references and bits for each method in the classfile. Jar sizes before: 480142 scala-actors.jar 15531408 scala-compiler.jar 5543249 scala-library.jar 4663078 scala-reflect.jar 785953 scalap.jar After: 490491 scala-actors.jar (102.1%) 15865500 scala-compiler.jar (102.1%) 5722504 scala-library.jar (103.2%) 4788370 scala-reflect.jar (102.7%) 805890 scalap.jar (102.5%)
* Fix InnerClass / EnclosingMethod for closures nested in value classesLukas Rytz2015-02-071-6/+24
| | | | | | | | | | | | | | | | | | | | | 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).
* Fix InnerClass/EnclosingMethod for trait impl and specialized classesLukas Rytz2015-02-071-10/+17
| | | | | | | | | | Trait implementation classes and specialized classes are always considered top-level in terms of the InnerClass / EnclosingMethod attributes. These attributes describe source-level properties, and such classes are a compilation artifact. Note that the same is true for delambdafy:method closure classes (they are always top-level).
* SI-9105 Fix EnclosingMethod for classes defined in lambdasLukas Rytz2015-02-071-5/+6
| | | | | | | | | | | | | | | | | | | | | This change fixes both GenASM and GenBCode, except for the change to renaming in LamdaLift mentioned below. The reason for an inconsistent EnclosingMethod attribute was the symbol owner chain. Initially, closure class symbols don't exist, they are only created in UnCurry (delambdafy:inline). So walking the originalOwner of a definition does not yield closure classes. The commit also fixes uses of isAnonymousClass, isAnonymousFunction and isDelambdafyFunction in two ways: 1. by phase-travelling to an early phase. after flatten, the name includes the name of outer classes, so the properties may become accidentally true (they check for a substring in the name) 2. by ensuring that the (destructive) renames during LambdaLift don't make the above properties accidentally true. This was in fact the cause for SI-8900.
* Construct ClassBTypes from parsed classfilesLukas Rytz2015-01-161-6/+14
| | | | | | | | | | | | | | | | | | | | This infrastructure is required for the inliner: when inlining code from a classfile, the corresponding ClassBType is needed for various things (eg access checks, InnerClass attribute). The test creates two ClassBTypes for the same class: once using the (unpickled) Symbol, once using the parsed ASM ClassNode, and verifies that the two are the same. There's a cleanup to the InnerClass attribute: object T { class Member; def foo = { class Local } } class T For Java compatibility the InnerClass entry for Member says the class is nested in T (not in the module class T$). We now make sure to add that entry only to T, not to T$ (unless Member is actually referenced in the classfile T$, in that case it will be added, as required).
* Merge pull request #4201 from mpociecha/fix-typos-in-docs-and-commentsGrzegorz Kossakowski2015-01-141-2/+2
|\ | | | | Fix many typos in docs and comments
| * Fix many typos in docs and commentsmpociecha2014-12-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | This commit corrects many typos found in scaladocs, comments and documentation. It should reduce a bit number of PRs which fix one typo. There are no changes in the 'real' code except one corrected name of a JUnit test method and some error messages in exceptions. In the case of typos in other method or field names etc., I just skipped them. Obviously this commit doesn't fix all existing typos. I just generated in IntelliJ the list of potential typos and looked through it quickly.
* | SI-9044 Fix order of interfaces in classfilesLukas Rytz2014-12-181-17/+1
|/ | | | | | | | | | It was reversed since ced3ca8ae1. The reason is that the backend used `mixinClasses` to obtain the parents of a class, which returns them in linearization order. `mixinClasses` als returns all ancestors (not only direct parents), which means more work for `minimizeInterfaces`. This was introduced in cd62f52 for unclear reasons. So we switch back to using `parents`.
* SI-8931 make generic signature consistent with interface list in classfilesAntoine Gourlay2014-11-051-19/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An optimization was introduced in 7a99c03 (SI-5278) to remove redundant interfaces from the list of implemented interfaces in the bytecode. However the same change was not propagated to the generic signature of a class, which also contains a list of direct parent classes and interfaces. The JVM does not check the well-formedness of signatures at class loading or linking (see §4.3.4 of jdk7 jvms), but other tools might assume the number of implemented interfaces is the same whether one asked for generic or erased interfaces. It doesn't break reflection so nobody complained, but it does show: scala> val c = classOf[Tuple1[String]] c: Class[(String,)] = class scala.Tuple1 scala> c.getInterfaces // Product is gone res0: Array[Class[_]] = Array(interface scala.Product1, interface scala.Serializable) scala> c.getGenericInterfaces // Product is back! res1: Array[java.lang.reflect.Type] = Array(scala.Product1<T1>, interface scala.Product, interface scala.Serializable) This moves the optimization to erasure, for use in emitting the generic signature, and the backend calls into it later for the list of interfaces.
* SI-4788/SI-5948 Respect RetentionPolicy of Java annotationsSimon Ochsenreither2014-10-071-14/+62
| | | | | | | | | | | | | | | | | Note that I removed the check to ignore @deprecated: - @deprecated extends StaticAnnotation, so they aren't supposed to show up in the RuntimeInvisibleAnnotation attribute anyway, and the earlier check for "extends ClassfileAnnotationClass" makes this check superflous anyway. - Otherwise, if @deprecated was extending ClassfileAnnotationClass it would seem inconsistent that we don't emit @deprecated, but would do so for @deprecatedOverriding, @deprecatedInheritance, etc. Anyway, due to ClassfileAnnotation not working in Scala, and the additional check which only allows Java-defined annotations, this is pretty pointless from every perspective.
* Don't remove elements from a map during iteration.Jason Zaugg2014-09-301-2/+4
| | | | | | Doing so relies on implementation details which might change. See #3911 / SI-8774.
* Fix InnerClass / EnclosingMethod attributesLukas Rytz2014-09-011-52/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit seems bigger than it is. Most of it is tests, and moving some code around. The actual changes are small, but a bit subtle. The InnerClass and EnclosingMethod attributes should now be close to the JVM spec (which is summarized in BTypes.scala). New tests make sure that changes to these attributes, and changes to the way Java reflection sees Scala classfiles, don't go unnoticed. A new file, BCodeAsmCommon, holds code that's shared between the two backend (it could hold more, future work). In general, the difficulty with emitting InnerClass / EnclosingMethod is that we need to find out source-level properties. We need to make sure to do enough phase-travelling, and work around destructive changes to the ownerchain in lambdalift (we use originalOwner a lot). The change to JavaMirrors is prompted by the change to the EnclosingMethod attribute, which changes Java reflection's answer to getEnclosingMethod and getEnclosingConstructor. Classes defined in field initializers no longer have an enclosing method, just an enclosing class, which broke an assumption in JavaMirrors. There's one change in erasure. Before this change, when an object declaration implements / overrides a method, and a bridge is required, then the bridge method was actually a ModuleSymbol (it would get the lateMETHOD flag and be emitted as a method anyway). This is confusing, when iterating through the members of a class, you can find two modules with the same name, and one of them doesn't have a module class. Now, such bridge methods will be MethodSymbols. Removed Symbol.originalEnclosingMethod, that is a backend thing and doesn't need to live in the symbol API.
* Merge pull request #3826 from lrytz/opt/refactorTrackedGrzegorz Kossakowski2014-07-251-0/+4
|\ | | | | Assortiment of cleanups and comments around the backend
| * Support writing classfile of version 52Lukas Rytz2014-07-081-0/+1
| |
| * Minor cleanups and comments in GenBCodeLukas Rytz2014-07-081-0/+3
| |
* | 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.
* Cleanups for tracing in GenBCode, improve some commentsLukas Rytz2014-05-211-2/+5
|
* Upgrade ASM to 5.0.2Lukas Rytz2014-05-201-8/+9
| | | | | | | | | | | | | This commit is a squashed version of all commits in PR #3747. For future upgrades, consult the README and check the commits in https://github.com/scala/scala/pull/3747/commits There's one bug in ASM 5.0.2 that breaks scalac: http://forge.ow2.org/tracker/?func=detail&aid=317200&group_id=23&atid=100023 This bug is fixed in ASM trunk, the patch has been merged into this commit. A future upgrade of ASM should contain the fix.
* SI-8549 Honour the @SerialVersionUID annotatationJason Zaugg2014-05-051-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | In PR #1673 / 4267444, the annotation `SerialVersionId` was changed from a `StaticAnnotation` to `ClassFileAnnotation` in order to avoid silently ignoring non-literal UIDs like: @SerialVersionUID(0 - 12345L) class C And to flag non-constant UIDs: @SerialVersionUID("!!!".length) While this indeed was fold constants, the change was incomplete. The compiler API for reading the argument from a `ClassFileAnnoation` is different, on must look for a `LiteralAnnotArg`, rather than a `Literal`. This commit: - amends the backend accordingly - removes relevant duplication between `GenASM` and `GenBCode` - tests that the static field is generated accordingly This will mean that we will break deserialization of objects from Scalal 2.11.0 that use this annotation.
* Merge pull request #3493 from retronym/ticket/3452-2Grzegorz Kossakowski2014-02-161-128/+146
|\ | | | | SI-3452 Correct Java generic signatures for mixins, static forwarders
| * SI-3452 Reduce low-hanging duplication bewteen GenASM and GenBCodeJason Zaugg2014-02-151-1/+1
| |
| * SI-3452 Refactoring code in GenASMJason Zaugg2014-02-151-145/+146
| | | | | | | | For a non copypasta for of reuse in GenBCode.
| * SI-3452 A better fix for static forwarder generic sigsJason Zaugg2014-02-151-15/+21
| | | | | | | | | | | | | | | | | | | | | | | | The previous commit fixed this in the wrong way. The addition to the test case (testing an inherited method from a base class in addition to the test with a mxin method) still failed. Like mixin, static forwarder generation uses the exact erased siganture of the forwardee for the forwarder. It really ought to use the as-seen-from signature (adding requisite boxing/ unboxing), but until we do that we have to avoid emitting generic signatures that are incoherent.
| * SI-3452 Correct Java generic signatures for mixins, static forwardersJason Zaugg2014-02-091-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Parts of this patch and some of the commentary are from @paulp] This took me so long to figure out I can't even tell you. Partly because there were two different bugs, one which only arose for trait forwarders and one for mirror class forwarders, and every time I'd make one set of tests work another set would start failing. The runtime failures associated with these bugs were fairly well hidden because you usually have to go through java to encounter them: scala doesn't pay that much attention to generic signatures, so they can be wrong and scala might still generate correct code. But java is not so lucky. Bug #1) During mixin composition, classes which extend traits receive forwarders to the implementations. An attempt was made to give these the correct info (in method "cloneBeforeErasure") but it was prone to giving the wrong answer, because: the key attribute which the forwarder must capture is what the underlying method will erase to *where the implementation is*, not how it appears to the class which contains it. That means the signature of the forwarder must be no more precise than the signature of the inherited implementation unless additional measures will be taken. This subtle difference will put on an unsubtle show for you in test run/t3452.scala. trait C[T] trait Search[M] { def search(input: M): C[Int] = null } object StringSearch extends Search[String] { } StringSearch.search("test"); // java // java.lang.NoSuchMethodError: StringSearch.search(Ljava/lang/String;)LC; The principled thing to do here would be to create a pair of methods in the host class: a mixin forwarder with the erased signature `(String)C[Int]`, and a bridge method with the same erased signature as the trait interface facet. But, this turns out to be pretty hard to retrofit onto the current setup of Mixin and Erasure, mostly due to the fact that mixin happens after erasure which has already taken care of bridging. For a future, release, we should try to move all bridging after mixin, and pursue this approach. But for now, what can we do about `LinkageError`s for Java clients? This commit simply checks if the pre-erasure method signature that we generate for the trait forward erases identically to that of the interface method. If so, we can be precise. If not, we emit the erased signature as the generic signature. Bug #2) The same principle is at work, at a different location. During genjvm, objects without declared companion classes are given static forwarders in the corresponding class, e.g. object Foo { def bar = 5 } which creates these classes (taking minor liberties): class Foo$ { static val MODULE$ = new Foo$ ; def bar = 5 } class Foo { static def bar = Foo$.MODULE$.bar } In generating these, genjvm circumvented the usual process whereby one creates a symbol and gives it an info, preferring to target the bytecode directly. However generic signatures are calculated from symbol info (in this case reusing the info from the module class.) Lacking even the attempt which was being made in mixin to "clone before erasure", we would have runtime failures of this kind: abstract class Foo { type T def f(x: T): List[T] = List() } object Bar extends Foo { type T = String } Bar.f(""); // java // java.lang.NoSuchMethodError: Bar.f(Ljava/lang/String;)Lscala/collection/immutable/List; Before/after this commit: < signature f (Ljava/lang/String;)Lscala/collection/immutable/List<Ljava/lang/String;>; --- > signature f (Ljava/lang/Object;)Lscala/collection/immutable/List<Ljava/lang/Object;>; This takes the warning count for compiling collections under `-Ycheck:jvm` from 1521 to 26.
* | Optimation: use AnyRefMap in GenASM javaName cachesJason Zaugg2014-02-091-2/+2
|/ | | | These are a hotspot in the backend.
* Merge commit '97b9b2c06a' from 2.10.x into masterAdriaan Moors2014-01-171-3/+3
|\ | | | | | | | | | | | | | | | | Check files updated: test/files/presentation/t8085*.check Conflicts: build.xml src/compiler/scala/tools/nsc/ast/parser/Parsers.scala src/compiler/scala/tools/nsc/symtab/classfile/ICodeReader.scala
| * Report error on code size overflow, log method name.Adriaan Moors2013-12-121-5/+4
| | | | | | | | | | | | | | We used to silently skip class files that would exceed the JVM's size limits. While rare, this should still be an error. While I was at it, also included the name of the offending method.
* | SI-8058 Better support for enum treesSimon Ochsenreither2014-01-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace the approach of “detect some magic combination of flags to trigger some action” by introducing an enum flag which makes the semantics and the intentions of the code using it more explicit. This basically involves wiring up the existing ACC_ENUM bit to a new modifier flag and making sure it is set correctly when encountering enums. The existing enum tests files/pos/t5165 and files/pos/t2764 keep working, showing that this hasn't introduced any obvious regressions. Tests for the changes in Namer which prevent scalac from messing with enum trees can't be added yet, because one currently can't define an enum in Scala without the help of the macro paradise. The intention is to add the @enum macro as a full test suite as soon as one can depend on macro annotations. One might wonder why we don't check for clazz.superClass == JavaEnumClass (where clazz is the owning class) in isEnumConstant. The reason is that this causes illegal cyclic reference error. Explanation by Eugene why this happens: (23:17:52) xeno_by: so here's what happens as far as I can understand at 11pm :) (23:18:09) xeno_by: scalac tries to complete the signature of the newly expanded class (23:18:11) xeno_by: to do that (23:18:40) xeno_by: to do that it needs three things (23:18:51) xeno_by: because the signature of a class is ClassInfoType which consists of three things (23:19:05) xeno_by: parents (23:19:08) xeno_by: decls (23:19:09) xeno_by: and symbol (23:19:20) xeno_by: symbol is easy - it's already there (23:19:30) xeno_by: parents are also easy (23:19:39) xeno_by: you just typecheck the things that come after "extends" (23:19:42) xeno_by: but decls are tricky (23:19:51) xeno_by: scalac goes through all the members of the class (23:20:03) xeno_by: and doesn't typecheck them... no, it doesn't (23:20:07) xeno_by: it just enters them (23:20:32) xeno_by: i.e. creates symbols for them and assigns lazy completers to those symbols so that if someone wants to know their signatures, they will go through the completers (23:20:34) xeno_by: and then (23:20:38) xeno_by: wait (23:20:40) xeno_by: there's one but (23:20:42) xeno_by: BUT (23:20:47) xeno_by: while we enter those symbols (23:20:53) xeno_by: our ClassInfoType is not ready yet (23:21:09) xeno_by: the class we're completing is still considered to be in the middle of being completing (23:21:12) xeno_by: so (23:21:24) xeno_by: when inside enterSym you try to ask that class for its super class (23:21:35) xeno_by: what happens is that check asks the class for its type signature (23:21:45) xeno_by: the ClassInfoType that consists of parents and decls (23:21:54) xeno_by: even though the parents are already calculated (23:22:01) xeno_by: the ClassInfoType as a whole is not (23:22:16) xeno_by: so scalac says that you're trying to complete something that's currently being completed (23:22:20) xeno_by: cyclic reference error (23:22:59) xeno_by: "cyclic" in English looks an awful lot like "суслик" in Russian (which means "gopher")
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-07 16:13:55 +0000