summaryrefslogtreecommitdiff
path: root/test/files/run
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #4574 from janekdb/2.11.x-typos-g-iJason Zaugg2015-06-238-8/+8
|\ | | | | Fix 25 typos (g-i)
| * Fix 25 typos (g-i)Janek Bogucki2015-06-228-8/+8
| |
* | Merge pull request #4564 from som-snytt/issue/promptv2.11.7Adriaan Moors2015-06-2221-158/+197
|\ \ | | | | | | SI-9206 Fix REPL code indentation
| * | SI-9206 Accept paste with custom promptSom Snytt2015-06-211-0/+13
| | | | | | | | | | | | But sans test.
| * | SI-9206 Fix REPL code indentationSom Snytt2015-06-1921-158/+184
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To make code in error messages line up with the original line of code, templated code is indented by the width of the prompt. Use the raw prompt (without ANSI escapes or newlines) to determine the indentation. Also, indent only once per line.
* | | Merge pull request #4566 from lrytz/t9359Adriaan Moors2015-06-228-10/+90
|\ \ \ | |_|/ |/| | SI-9359 Fix InnerClass entry flags for nested Java enums
| * | Fix spurious test failure under -Ybackend:GenBCodeLukas Rytz2015-06-204-10/+6
| | |
| * | SI-9359 Fix InnerClass entry flags for nested Java enumsLukas Rytz2015-06-194-0/+84
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* / Fix 36 typos (d-f)Janek Bogucki2015-06-218-9/+9
|/
* Merge pull request #4559 from janekdb/2.11.x-scaladoc-2Seth Tisue2015-06-181-1/+1
|\ | | | | Fix some typos (a-c)
| * Fix some typos (a-c)Janek Bogucki2015-06-181-1/+1
| |
* | Merge pull request #4529 from lrytz/inlineAccessibilityJason Zaugg2015-06-193-1/+9
|\ \ | |/ |/| Fix illegal inlining of instructions accessing protected members
| * Fix illegal inlining of instructions accessing protected membersLukas Rytz2015-05-283-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were two issues in the new inliner that would cause a VerifyError and an IllegalAccessError. First, an access to a public member of package protected class C can only be inlined if the destination class can access C. This is tested by t7582b. Second, an access to a protected member requires the receiver object to be a subtype of the class where the instruction is located. So when inlining such an access, we need to know the type of the receiver object - which we don't have. Therefore we don't inline in this case for now. This can be fixed once we have a type propagation analyis. https://github.com/scala-opt/scala/issues/13. This case is tested by t2106. Force kmpSliceSearch test to delambdafy:inline See discussion on https://github.com/scala/scala/pull/4505. The issue will go away when moving to indy-lambda.
* | Merge pull request #4541 from vuakko/SI-9348_2.11.xAdriaan Moors2015-06-171-7/+11
|\ \ | | | | | | SI-9348 Fix missing last element in exclusive floating point ranges
| * | SI-9348 Fix missing last element in exclusive floating point rangesNiko Vuokko2015-06-171-7/+11
| | | | | | | | | | | | | | | Fix exclusive floating point ranges to contain also the last element when the end-start difference is not an integer multiple of step.
* | | Merge pull request #4545 from retronym/topic/constr-varargs-toolboxAdriaan Moors2015-06-172-0/+21
|\ \ \ | |/ / |/| | Fix toolbox with varargs constructors
| * | SI-9212 Fix toolbox with varargs constructorsJason Zaugg2015-06-092-0/+21
| | | | | | | | | | | | It was already working for methods, but not for constructors.
* | | Merge pull request #4548 from ScrapCodes/git_4522Jason Zaugg2015-06-144-9/+131
|\ \ \ | |/ / |/| | SI-7747 Make REPL wrappers serialization friendly.
| * | SI-7747 More tests and logic according to our conclusions on #4522.Prashant Sharma2015-06-104-2/+25
| | |
| * | SI-7747 Limit previous change to imports of REPL valsJason Zaugg2015-05-261-9/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We only need to introduce the temporary val in the imports wrapper when we are importing a val or module defined in the REPL. The test case from the previous commit still passes, but we are generating slightly simpler code. Compared to 2.11.6, these two commits result in the following diff: https://gist.github.com/retronym/aa4bd3aeef1ab1b85fe9
| * | SI-7747 Make REPL wrappers serialization friendlyPrashant Sharma2015-05-264-9/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Spark has been shipping a forked version of our REPL for sometime. We have been trying to fold the patches back into the mainline so they can defork. This is the last outstanding issue. Consider this REPL session: ``` scala> val x = StdIn.readInt scala> class A(a: Int) scala> serializedAndExecuteRemotely { () => new A(x) } ``` As shown by the enclosed test, the REPL, even with the Spark friendly option `-Yrepl-class-based`, will re-initialize `x` on the remote system. This test simulates this by running a REPL session, and then deserializing the resulting closure into a fresh classloader based on the class files generated by that session. Before this patch, it printed "evaluating x" twice. This is based on the Spark change described: https://github.com/mesos/spark/pull/535#discussion_r3541925 A followup commit will avoid the `val lineN$read = ` part if we import classes or type aliases only. [Original commit from Prashant Sharma, test case from Jason Zaugg]
* | | Fix several tests under GenBCodeLukas Rytz2015-05-265-7/+10
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - private-inline, t8601-closure-elim, inline-in-constructors - test closure inlining / elimination, which is not yet implemented in GenBCode. noted in https://github.com/scala-opt/scala/issues/14. - constant-optimization, t7006 - no constant folding in GenBCode yet. noted in https://github.com/scala-opt/scala/issues/29. - patmat_opt_ignore_underscore, patmat_opt_no_nullcheck, patmat_opt_primitive_typetest - not all optimizations in GenBCode yet. noted in https://github.com/scala-opt/scala/issues/30. - t3234 - tests a warning of trait inlining - trait inlining works in GenBCode - synchronized - ignore inliner warnings (they changed a bit) - t6102 - account for the changed outputo of -Ydebug has under GenBCode
* | [indylambda] Enable caching for lambda deserializationJason Zaugg2015-05-181-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We add a static field to each class that defines lambdas that will hold a `ju.Map[String, MethodHandle]` to cache references to the constructors of the classes originally created by `LambdaMetafactory`. The cache is initially null, and created on the first deserialization. In case of a race between two threads deserializing the first lambda hosted by a class, the last one to finish will clobber the one-element cache of the first. This lack of strong guarantees mirrors the current policy in `LambdaDeserializer`. We should consider whether to strengthen the combinaed guarantee here. A useful benchmark would be those of the invokedynamic instruction, which allows multiple threads to call the boostrap method in parallel, but guarantees that if that happens, the results of all but one will be discarded: > If several threads simultaneously execute the bootstrap method for > the same dynamic call site, the Java Virtual Machine must choose > one returned call site object and install it visibly to all threads. We could meet this guarantee easily, albeit excessively, by synchronizing `$deserializeLambda$`. But a more fine grained approach is possible and desirable. A test is included that shows we are able to garbage collect classloaders of classes that have hosted lambda deserialization.
* | [indylambda] Support lambda {de}serializationJason Zaugg2015-05-171-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To support serialization, we use the alternative lambda metafactory that lets us specify that our anonymous functions should extend the marker interface `scala.Serializable`. They will also have a `writeObject` method added that implements the serialization proxy pattern using `j.l.invoke.SerializedLamba`. To support deserialization, we synthesize a `$deserializeLamba$` method in each class with lambdas. This will be called reflectively by `SerializedLambda#readResolve`. This method in turn delegates to `LambdaDeserializer`, currently defined [1] in `scala-java8-compat`, that uses `LambdaMetafactory` to spin up the anonymous class and instantiate it with the deserialized environment. Note: `LambdaDeserializer` can reuses the anonymous class on subsequent deserializations of a given lambda, in the same spirit as an invokedynamic call site only spins up the class on the first time it is run. But first we'll need to host a cache in a static field of each lambda hosting class. This is noted as a TODO and a failing test, and will be updated in the next commit. `LambdaDeserializer` will be moved into our standard library in the 2.12.x branch, where we can introduce dependencies on the Java 8 standard library. The enclosed test cases must be manually run with indylambda enabled. Once we enable indylambda by default on 2.12.x, the test will actually test the new feature. ``` % echo $INDYLAMBDA -Ydelambdafy:method -Ybackend:GenBCode -target:jvm-1.8 -classpath .:scala-java8-compat_2.11-0.5.0-SNAPSHOT.jar % qscala $INDYLAMBDA -e "println((() => 42).getClass)" class Main$$anon$1$$Lambda$1/1183231938 % qscala $INDYLAMBDA -e "assert(classOf[scala.Serializable].isInstance(() => 42))" % qscalac $INDYLAMBDA test/files/run/lambda-serialization.scala && qscala $INDYLAMBDA Test ``` This commit contains a few minor refactorings to the code that generates the invokedynamic instruction to use more meaningful names and to reuse Java signature generation code in ASM rather than the DIY approach. [1] https://github.com/scala/scala-java8-compat/pull/37
* | [indylambda] Relieve LambdaMetafactory of boxing dutiesJason Zaugg2015-05-153-0/+39
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `LambdaMetafactory` generates code to perform a limited number of type adaptations when delegating from its implementation of the functional interface method to the lambda target method. These adaptations are: numeric widening, casting, boxing and unboxing. However, the semantics of unboxing numerics in Java differs to Scala: they treat `UNBOX(null)` as cause to raise a `NullPointerException`, Scala (in `BoxesRuntime.unboxTo{Byte,Short,...}`) reinterprets the null as zero. Furthermore, Java has no idea how to adapt between a value class and its wrapped type, nor from a void return to `BoxedUnit`. This commit detects when the lambda target method would require such adaptation. If it does, an extra method, `$anonfun$1$adapted` is created to perform the adaptation, and this is used as the target of the lambda. This obviates the use of `JProcedureN` for `Unit` returning lambdas, we know use `JFunctionN` as the functional interface and bind this to an `$adapted` method that summons the instance of `BoxedUnit` after calling the `void` returning lambda target. The enclosed test cases fail without boxing changes. They don't execute with indylambda enabled under regular partest runs yet, you need to add scala-java8-compat to scala-library and pass the SCALAC_OPTS to partest manually to try this out, as described in https://github.com/scala/scala/pull/4463. Once we enable indylambda by default, however, this test will exercise the code in this patch all the time. It is also possible to run the tests with: ``` % curl https://oss.sonatype.org/content/repositories/releases/org/scala-lang/modules/scala-java8-compat_2.11/0.4.0/scala-java8-compat_2.11-0.4.0.jar > scala-java8-compat_2.11-0.4.0.jar % export INDYLAMBDA="-Ydelambdafy:method -Ybackend:GenBCode -target:jvm-1.8 -classpath .:scala-java8-compat_2.11-0.4.0.jar" qscalac $INDYLAMBDA test/files/run/indylambda-boxing/*.scala && qscala $INDYLAMBDA Test ```
* SI-9302 -Xdisable-assertions raises elide levelSom Snytt2015-05-052-0/+15
| | | | | | | | | | 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.
* SI-9298 Fix erasure of value classes in JavaJason Zaugg2015-05-054-0/+27
| | | | | | | | | | | | Value classes that appear in signatures of Java defined methods should not be erased to the underlying type. Before this change, we'd get a `ClassCastException`, as the Scala call site would unbox the value class despite the fact the Java recipient would expect the boxed representation. I've tested this for primitive and object wrapped types in parameter and return position.
* Merge pull request #4475 from smarter/fix/old-spec-linksLukas Rytz2015-05-041-2/+2
|\ | | | | Remove references to the old PDF version of the specification
| * Remove references to the old PDF version of the specificationGuillaume Martres2015-04-301-2/+2
| |
* | Merge pull request #4463 from retronym/topic/indylambda-emit-indyLukas Rytz2015-05-041-0/+1
|\ \ | | | | | | Use LambdaMetafactory where possible for lambda creation.
| * | SI-8359 Update a test to work with indylambdaJason Zaugg2015-04-211-0/+1
| | |
* | | Merge pull request #4461 from adriaanm/rebase-4446Adriaan Moors2015-04-223-3/+3
|\ \ \ | | | | | | | | Fix many typos
| * | | Fix many typosMichał Pociecha2015-04-213-3/+3
| | | | | | | | | | | | | | | | | | | | This commit corrects many typos found in scaladocs and comments. There's also fixed the name of a private method in ICodeCheckers.
* | | | Merge pull request #4452 from lrytz/valueClassSelfTypeBCodeAdriaan Moors2015-04-221-0/+52
|\ \ \ \ | |/ / / |/| | | Don't crash GenBCode for value classes with a self declaration
| * | | Don't crash GenBCode for value classes with a self declarationLukas Rytz2015-04-161-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a value class has a self declaration class V(x: Long) extends AnyVal { self => /* ... */ } `vClassSymbol.typeOfThis.typeSymbol` is `class Long` in the backend. The InlineInfo for traits contains a field for the self type of the trait. This is required for re-writing calls to final trait methods to the static implementation method: the self type appears in the impl method signature. By mistake, the backend was recording the self type of all classes, not only of traits. In the case of a value class with a self declaration, this broke the assumption that the self type is always a class type (not a primitive type). The simple fix: only record the self type for traits.
* | | | SI-9268 Be robust against absent classfiles during signature parsingJason Zaugg2015-04-213-0/+57
| |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When parsing a Java generic signature that references an inner class `A$B`, we were tripping an assertion if the enclosing class `A` was absent. This commit creates a stub symbol for `B` when this happens, rather than continuing on with `NoSymbol`. The enclosed test shows that we can instantiate a class containing a method referring to such an inner class with only a warning about the absent classfile, and that an error is issued only upon a subsequent attempt to call the method.
* | | Make lambda body public rather than using static accessorJason Zaugg2015-04-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under -Ydelambdafy:method (the basis of the upcoming "indylambda" translation for -target:jvm-1.8), an anonymous function is currently encoded as: 1. a private method containing the lambda's code 2. a public, static accessor method that allows access to 1 from other classes, namely: 3. an anonymous class capturing free variables and implementing the suitable FunctionN interface. In our prototypes of indylambda, we do away with 3, instead deferring creating of this class to JDK8's LambdaMetafactory by way of an invokedynamic instruction at the point of lambda capture. This facility can use a private method as the lambda target; access is mediated by the runtime-provided instance of `java.lang.invoke.MethodHandles.Lookup` that confers the privelages of the lambda capture call site to the generated implementation class. Indeed, The java compiler uses this to emit private lambda body methods. However, there are two Scala specific factors that make this a little troublesome. First, Scala's optimizer may want to inline the lambda capture call site into a new enclosing class. In general, this isn't a safe optimization, as `invokedynamic` instructions have call-site specific semantics. But we will rely the ability to inline like this in order to eliminate closures altogether where possible. Second, to support lambda deserialization, the Java compiler creates a synthetic method `$dersializeLamda$` in each class that captures them, just to be able to get the suitable access to spin up an anoymous class with access to the private method. It only needs to do this for functional interfaces that extends Serializable, which is the exception rather than the rule. But in Scala, *every* function must support serialization, so blindly copying the Java approach will lead to some code bloat. I have prototyped a hybrid approach to these challenges: use the private method directly where it is allowed, but fall back to using the accessor method in a generic lambda deserializer or in call sites that have been inlined into a new enclosing class. However, the most straight forward approach is to simply emit the lambda bodies as public (with an mangled name and with the SYHTNETIC flag) and use them in all cases. That is what is done in this commit. This does moves us one step backwards from the goals of SI-7085, but it doesn't seem sensible to incur the inconvenience from locking down one small part of our house when we don't have a plan or the budget to complete that job. The REPL has some fancy logic to decompile the bodys of lambdas (`:javap -fun C#m`) which needed tweaking to accomodate this change. I haven't tried to make this backwards compatible with the old encoding as `-Ydelambdafy:method` is still experimental.
* | | Merge pull request #4451 from som-snytt/issue/3368-remediateAdriaan Moors2015-04-168-2/+390
|\ \ \ | |/ / |/| | SI-3368 Default to coalescing for 2.11
| * | SI-3368 Default to coalescing for 2.11Som Snytt2015-04-168-2/+390
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Preserve current behavior (no PCData nodes, only Text) for 2.11. The coalescing flag is on if enabled or if source level is not 2.12 and no flag was supplied. The subtle change is that adjacent Text nodes are thereby coalesced. This happens in the presence of CData sections, but this is at the discretion of the parser anyway. Also, no PCData nodes are emitted under coalescing, even if there were no sibling text nodes. That is the correct behavior: the general idea is that coalescing mode says, I only want to deal with text.
* | | Merge pull request #4367 from retronym/topic/indylambda-specializationAdriaan Moors2015-04-1311-36/+59
|\ \ \ | |/ / |/| | Disable -Ydelambdafy:method for specialized FunctionN
| * | Disable -Ydelambdafy:method for specialized FunctionNJason Zaugg2015-04-1011-36/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #4306 from som-snytt/issue/3368-bAdriaan Moors2015-04-093-11/+67
|\ \ \ | | | | | | | | SI-3368 CDATA gets a Node
| * | | SI-3368 ReviewSom Snytt2015-04-081-1/+1
| | | | | | | | | | | | | | | | Verbose option help and test tweak.
| * | | SI-3368 Promote xml option to -XxmlSom Snytt2015-04-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As long as Scala does XML literals, there is probably parsing behavior worth configuring. Therefore, the umbrella option is promoted to `-Xxml`. It was tempting to make it `-XML`, but we resisted.
| * | | SI-5699 Use ParserTestSom Snytt2015-04-081-10/+2
| | | | | | | | | | | | | | | | Update the test slightly to use the rig it inspired.
| * | | SI-3368 CDATA gets a NodeSom Snytt2015-04-082-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | XML Parser uses `scala.xml.PCData`. A compiler flag `-Yxml:coalescing`, analogous to `DocumentBuilderFactory.setCoalescing`, turns `PCData` nodes into `Text` nodes and coalesces sibling text nodes. This change also fixes parse errors such as rejecting a sequence of CDATA sections. A sequence of "top level" nodes are not coalesced. ``` scala> <a><b/>start<![CDATA[hi & bye]]><c/>world<d/>stuff<![CDATA[red & black]]></a> res0: scala.xml.Elem = <a><b/>start<![CDATA[hi & bye]]><c/>world<d/>stuff<![CDATA[red & black]]></a> scala> :replay -Yxml:coalescing Replaying: <a><b/>start<![CDATA[hi & bye]]><c/>world<d/>stuff<![CDATA[red & black]]></a> res0: scala.xml.Elem = <a><b/>starthi &amp; bye<c/>world<d/>stuffred &amp; black</a> ```
* | | | Merge pull request #4386 from retronym/ticket/7741Lukas Rytz2015-04-096-0/+355
|\ \ \ \ | | | | | | | | | | SI-7741: Be more tolerant of absent inner classfiles and non-Scala interface members
| * | | | SI-7741 Tread more lightly during classfile parsingJason Zaugg2015-03-256-0/+355
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Avoid forcing info of non-Scala interface members This avoids parsing the ostensibly malformed class definitions that correspond to a Groovy lambda defined in an interface. 2. Be more tolerant of absent inner classfiles Taking a leaf out of javac's book (see transcript below), we can use stub symbols for InnerClass entries that don't have corresponding class files on the compilation classpath. This will limit failures to code that directly refers to the inner class, rather than any code that simply refers to the enclosing class. It seems that groovyc has a habit of emitting incongrous bytecode in this regard. But this change seems generally useful. ``` % cat sandbox/{Test,Client}.java public class Test { public class Inner {} } public class Client { public Test.Inner x() { return null; } } % javac -d . sandbox/Test.java && javac -classpath . sandbox/Client.java % javac -d . sandbox/Test.java && rm 'Test$Inner.class' && javac -classpath . sandbox/Client.java sandbox/Client.java:2: error: cannot access Inner public Test.Inner x() { return null; } ^ class file for Test$Inner not found 1 error % cat sandbox/{Test,Client}.java public class Test { public class Inner {} } public class Client { public Test.NeverExisted x() { return null; } } % javac -classpath . sandbox/Client.java sandbox/Client.java:2: error: cannot find symbol public Test.NeverExisted x() { return null; } ^ symbol: class NeverExisted location: class Test 1 error % cat sandbox/{Test,Client}.java public class Test { public class Inner {} } public class Client { public Test x() { return null; } } topic/groovy-interop ~/code/scala2 javac -d . sandbox/Test.java && rm 'Test$Inner.class' && javac -classpath . sandbox/Client.java # allowed ```
* | | | | Merge pull request #4411 from xeno-by/ticket/9252Lukas Rytz2015-04-092-0/+6
|\ \ \ \ \ | |_|/ / / |/| | | | SI-9252 gets rid of custom logic for jArrayClass in runtime reflection
| * | | | SI-9252 gets rid of custom logic for jArrayClass in runtime reflectionEugene Burmako2015-03-272-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Apparently, I've already fixed a very similar issue two years ago. That was a fun surprise! (https://issues.scala-lang.org/browse/SI-5680)
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-29 11:58:13 +0000