summaryrefslogtreecommitdiff
path: root/src/reflect
Commit message (Collapse)AuthorAgeFilesLines
* Update links to docs, codehaus and citeseerJanek Bogucki2015-09-044-5/+5
| | | | | | | | | | | | | | | | | docs.scala-lang.org - Align some links to new layout for docs.scala-lang.org - Include link to concrete parallel collection performance characteristics codehaus - Subsitute a link to a JIRA email for the 404 JRUBY-3576 JIRA link in Codec.scala. jira.codehaus.org is not redirecting this. citeseer - Replace the citeseer link with a direct link to a PDF which is not behind a login challenge.
* Update Java and Sun URLs to replacement Java and Oracle URLsJanek Bogucki2015-09-021-1/+1
| | | | | | | For each URL - Where it redirected the target of the redirection was used - Where is no longer existed a replacement was selected
* Fix typos in spec, docs and commentsMichał Pociecha2015-08-234-4/+4
|
* Delegate null test to OptionJanek Bogucki2015-08-042-4/+2
| | | | | Option(null) is None while Option(v) is Some(v) which makes the null test redundant.
* ScalaDoc fixes for reflectJanek Bogucki2015-07-288-13/+12
|
* Rename the ENUM / DEFAULTMETHOD flags to include JAVA_Lukas Rytz2015-07-245-107/+107
| | | | | Similar to the new JAVA_ANNOTATION flag, be more explicit about flags for java entities.
* SI-9393 fix modifiers of ClassBTypes for Java annotationsLukas Rytz2015-07-244-9/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Scala classfile and java source parsers make Java annotation classes (which are actually interfaces at the classfile level) look like Scala annotation classes: - the INTERFACE / ABSTRACT flags are not added - scala.annotation.Annotation is added as superclass - scala.annotation.ClassfileAnnotation is added as interface This makes type-checking @Annot uniform, whether it is defined in Java or Scala. This is a hack that leads to various bugs (SI-9393, SI-9400). Instead the type-checking should be special-cased for Java annotations. This commit fixes SI-9393 and a part of SI-9400, but it's still easy to generate invalid classfiles. Restores the assertions that were disabled in #4621. I'd like to leave these assertions in: they are valuable and helped uncovering the issue being fixed here. A new flag JAVA_ANNOTATION is introduced for Java annotation ClassSymbols, similar to the existing ENUM flag. When building ClassBTypes for Java annotations, the flags, superclass and interfaces are recovered to represent the situation in the classfile. Cleans up and documents the flags space in the area of "late" and "anti" flags. The test for SI-9393 is extended to test both the classfile and the java source parser.
* [backport] Fix superclass for Java interface symbols created in JavaMirrorsLukas Rytz2015-07-231-0/+1
| | | | | | | | | | According to the spec [1] the superclass of an interface is always Object. Restores the tests that were moved to pending in bf951ec1, fixex part of SI-9374. [1] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.1
* Merge pull request #4650 from lrytz/t8502-packageJason Zaugg2015-07-212-3/+4
|\ | | | | SI-8502 create PackageClass instead of Class symbol stubs for pkgs
| * SI-8502 create PackageClass instead of Class symbol stubs for pkgsLukas Rytz2015-07-202-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://github.com/scala/scala/pull/4111 creates a stub type symbol for missing packages, deferring (or avoiding) a crash if a package is missing. The symbol created was a ClassSymbol, which could lead to an assertion failure in flattten: case TypeRef(pre, sym, args) if isFlattenablePrefix(pre) => assert(args.isEmpty && sym.enclosingTopLevelClass != NoSymbol, sym.ownerChain) `pre` is the stub ClassSymbol, so `isFlattenablePrefix` is true (but it should be false). The assertion then fails because the enclosing class of a top-level class defined in a missing package is NoSymbol. This failed only with GenBCode, which traverses more of the symbol graph while building ClassBTypes: it looks collects the nested classes of `Outer` into a `NestedInfo`.
* | Fix 23 typos (t-v)Janek Bogucki2015-07-153-3/+3
|/
* Fix 25 typos (s)Janek Bogucki2015-07-063-4/+4
|
* Fix 27 typos (p-r)Janek Bogucki2015-06-303-4/+4
|
* Fix 23 typos (m-o)Janek Bogucki2015-06-283-4/+4
|
* Merge pull request #4574 from janekdb/2.11.x-typos-g-iJason Zaugg2015-06-233-3/+3
|\ | | | | Fix 25 typos (g-i)
| * Fix 25 typos (g-i)Janek Bogucki2015-06-223-3/+3
| |
* | Merge pull request #4566 from lrytz/t9359Adriaan Moors2015-06-221-5/+8
|\ \ | | | | | | SI-9359 Fix InnerClass entry flags for nested Java enums
| * | SI-9359 Fix InnerClass entry flags for nested Java enumsLukas Rytz2015-06-191-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-9253 avoid IndexOutOfBoundsException in TypeMaps.correspondingTypeArgumentBruno Bieth2015-06-221-1/+1
| |/ |/|
* | Fix 36 typos (d-f)Janek Bogucki2015-06-211-1/+1
|/
* Fix some typos (a-c)Janek Bogucki2015-06-182-2/+2
|
* SI-9212 Fix toolbox with varargs constructorsJason Zaugg2015-06-091-0/+1
| | | | It was already working for methods, but not for constructors.
* [indylambda] Enable caching for lambda deserializationJason Zaugg2015-05-182-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-174-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-152-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `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-9298 Fix erasure of value classes in JavaJason Zaugg2015-05-051-0/+2
| | | | | | | | | | | | 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-1/+1
|\ | | | | Remove references to the old PDF version of the specification
| * Remove references to the old PDF version of the specificationGuillaume Martres2015-04-301-1/+1
| |
* | Merge pull request #4486 from mpociecha/ticket/8679Lukas Rytz2015-05-041-0/+1
|\ \ | | | | | | SI-8679 Add support for ScalaLongSignature attribute in scalap
| * | SI-8679 Add support for ScalaLongSignature attribute in scalapMichał Pociecha2015-05-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | scalap didn't support really big class files. It was returning an empty String for such files. The reason was that there were only ScalaSignatures taken into account. This commit adds support for ScalaLongSignature. We try to get such an attribute when we didn't find ScalaSignature. Also there's added an additional case to the logic retrieving bytes for a signature. Since ScalaLongSignature can contain many parts, we have to merge their byte arrays. Changes are tested by a new partest-based test. These two files are really big, but it was required (t8679.scala is a reduced version of BigScalaClass - an example attached to JIRA). There are also added TODOs with a JIRA ticket: We have three places, where we process Scala signatures. In the future it would be better to reuse some common logic, if it's possible.
* | | Merge pull request #4463 from retronym/topic/indylambda-emit-indyLukas Rytz2015-05-042-1/+5
|\ \ \ | |/ / |/| | Use LambdaMetafactory where possible for lambda creation.
| * | SI-8359 Emit invokedynamic for lambdasJason Zaugg2015-04-212-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Suitable lambdas are identified in Delambdafy and marked with such with a tree annotation that includes the data needed by the backend to emit an invokedynamic instruction. GenBCode to rewrite instantiation of such anonymous function classes with an invokedynamic instruction. At this stage, I don't plan to merge the support for this into GenASM. Between these points, the lambda capture is represented as an application of a dummy factory symbol: ``` <dummy>(captures...) : FunctionN ``` Demo: ``` % wget http://central.maven.org/maven2/org/scala-lang/modules/scala-java8-compat_2.11/0.3.0/scala-java8-compat_2.11-0.3.0.jar % qscala -classpath scala-java8-compat_2.11-0.3.0.jar -Ydelambdafy:method -target:jvm-1.8 -Ybackend:GenBCode Welcome to Scala version 2.11.6-20150309-144147-c91c978c81 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_25). Type in expressions to have them evaluated. Type :help for more information. scala> (() => "").getClass res0: Class[_ <: () => String] = class $$Lambda$1/871790326 ``` I have also corrected an error in a previous commit. The newly added symbol test, `isDelambdafyTarget`, needs to check for the `ARTIFACT` flag, as that is what is added to the method by `Uncurry`.
* | | Fix many typosMichał Pociecha2015-04-216-7/+7
| | | | | | | | | | | | | | | This commit corrects many typos found in scaladocs and comments. There's also fixed the name of a private method in ICodeCheckers.
* | | Fix typo in Quasiquote doc that was confusingJean-Rémi Desjardins2015-04-101-1/+1
|/ /
* | Merge pull request #4373 from retronym/topic/indylambda-permutations-2Lukas Rytz2015-04-101-0/+1
|\ \ | | | | | | SI-8359 Adjust parameter order of accessor method in Delambdafy
| * | SI-8359 Adjust parameter order of accessor method in DelambdafyJason Zaugg2015-03-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under `-Ydelambdafy:method`, a public, static accessor method is created to expose the private method containing the body of the lambda. Currently this accessor method has its parameters in the same order structure as those of the lambda body method. What is this order? There are three categories of parameters: 1. lambda parameters 2. captured parameters (added by lambdalift) 3. self parameters (added to lambda bodies that end up in trait impl classes by mixin, and added unconditionally to the static accessor method.) These are currently emitted in order #3, #1, #2. Here are examples of the current behaviour: BEFORE (trait): ``` % cat sandbox/test.scala && scalac-hash v2.11.5 -Ydelambdafy:method sandbox/test.scala && javap -private -classpath . 'Test$class' trait Member; class Capture; trait LambdaParam trait Test { def member: Member def foo { val local = new Capture (arg: LambdaParam) => "" + arg + member + local } } Compiled from "test.scala" public abstract class Test$class { public static void foo(Test); private static final java.lang.String $anonfun$1(Test, LambdaParam, Capture); public static void $init$(Test); public static final java.lang.String accessor$1(Test, LambdaParam, Capture); } ``` BEFORE (class): ``` % cat sandbox/test.scala && scalac-hash v2.11.5 -Ydelambdafy:method sandbox/test.scala && javap -private -classpath . Test trait Member; class Capture; trait LambdaParam abstract class Test { def member: Member def foo { val local = new Capture (arg: LambdaParam) => "" + arg + member + local } } Compiled from "test.scala" public abstract class Test { public abstract Member member(); public void foo(); private final java.lang.String $anonfun$1(LambdaParam, Capture); public Test(); public static final java.lang.String accessor$1(Test, LambdaParam, Capture); } ``` Contrasting the class case with Java: ``` % cat sandbox/Test.java && javac -d . sandbox/Test.java && javap -private -classpath . Test public abstract class Test { public static class Member {}; public static class Capture {}; public static class LambaParam {}; public static interface I { public abstract Object c(LambaParam arg); } public abstract Member member(); public void test() { Capture local = new Capture(); I i1 = (LambaParam arg) -> "" + member() + local; } } Compiled from "Test.java" public abstract class Test { public Test(); public abstract Test$Member member(); public void test(); private java.lang.Object lambda$test$0(Test$Capture, Test$LambaParam); } ``` We can see that in Java 8 lambda parameters come after captures. If we want to use Java's LambdaMetafactory to spin up our anoymous FunctionN subclasses on the fly, our ordering must change. I can see three options for change: 1. Adjust `LambdaLift` to always prepend captured parameters, rather than appending them. I think we could leave `Mixin` as it is, it already prepends the self parameter. This would result a parameter ordering, in terms of the list above: #3, #2, #1. 2. More conservatively, do this just for methods known to hold lambda bodies. This might avoid needlessly breaking code that has come to depend on our binary encoding. 3. Adjust the parameters of the accessor method only. The body of this method can permute params before calling the lambda body method. This commit implements option #2. In also prototyped #1, and found it worked so long as I limited it to non-constructors, to sidestep the need to make corresponding changes elsewhere in the compiler to avoid the crasher shown in the enclosed test case, which was minimized from a bootstrap failure from an earlier a version of this patch. We would need to defer option #1 to 2.12 in any case, as some of these lifted methods are publicied by the optimizer, and we must leave the signatures alone to comply with MiMa. I've included a test that shows this in all in action. However, that is currently disabled, as we don't have a partest category for tests that require Java 8.
* | | Merge pull request #4411 from xeno-by/ticket/9252Lukas Rytz2015-04-091-5/+1
|\ \ \ | | | | | | | | 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-271-5/+1
| | | | | | | | | | | | | | | | | | | | 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)
* | | | Merge pull request #4318 from soc/topic/remove-deprecation-warningsLukas Rytz2015-03-2813-44/+42
|\ \ \ \ | |/ / / |/| | | Remove deprecation warnings
| * | | Removed warningsEECOLOR2015-03-266-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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-267-21/+22
| | | |
| * | | Deprecations: Use of isPackage, hasSymbol, getter, setter...Simon Ochsenreither2015-03-263-17/+15
| | | | | | | | | | | | | | | | ... replaced by hasPackageFlag, hasSymbolIn, getterIn, setterIn.
* | | | Merge pull request #4361 from retronym/ticket/9182Lukas Rytz2015-03-261-1/+2
|\ \ \ \ | |/ / / |/| | | SI-9182 Fix runtime reflection with package object, overloads
| * | | SI-9182 Fix runtime reflection with package object, overloadsJason Zaugg2015-02-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Eponymous modules and methods should be allowed to live in the same package scope. This can happen when using a module and and implicit class, or when defining the overloads manually. This commit tones back an assertion that was added for sanity checking runtime reflection thread safety to only fire when we are sure that neither the existing and current symbol of the given name are methods.
* | | | Merge pull request #4378 from som-snytt/issue/9102Jason Zaugg2015-03-241-3/+6
|\ \ \ \ | | | | | | | | | | SI-9102: Reflect method invoke with mixed args
| * | | | SI-9102: Improve testSom Snytt2015-03-111-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cover the second use case reported on the ML (ctors). Improve formatting per the review. And it really does look a lot better.
| * | | | SI-9102: Reflect method invoke with mixed argsSom Snytt2015-03-111-3/+6
| |/ / / | | | | | | | | | | | | | | | | | | | | A missing default branch when a method had value class or by-name params caused other args to present as null under reflective invocation.
* / / / Reuse the same compiler instance for all tests in a JUnit classLukas Rytz2015-03-111-0/+8
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | Note that JUnit creates a new instance of the test class for running each test method. So the compiler instance is added to the companion. However, the JVM would quickly run out of memory when running multiple tests, as the compilers cannot be GCd. So we make it a `var`, and set it to null when a class is done. For that we use JUnit's `@AfterClass` which is required to be on a static method. Therefore we add a Java class with such a static method that we can extend from Scala.
* | | Merge pull request #4340 from retronym/topic/infix-completionAdriaan Moors2015-02-192-0/+4
|\ \ \ | | | | | | | | SI-9153 More complete and stable results for completions
| * | | SI-9153 More complete and stable results for completionsJason Zaugg2015-02-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Three items of background are needed to understand this bug. 1. When typechecking an application like `qual.m({stats; expr})`, the argument is typechecked using the formal parameter type of `m` as the expected type. If this fails with a type error located within in `expr`, the typer instead re-typechecks under `ContextMode.ReTyping` without an expected type, and then searches for an implicit adaptation to enable `view(qual).m(args)`. Under this mode, `Typer#typed1` clears the type of incoming trees. 2. The presentation compiler performs targetted operations like type completions by: - typechecking the enclosing tree, registering all typechecker `Context`s created in the process (`registerContext`) - finding the smallest enclosing `Context` around the target position (`doLocateContext`) - Using this context to perform implicit search, which can contribute members to the completion. (`applicableViews` within `interactive.Global#typeMembers`) 3. When verifiying whether or not a candidate implicit is applicable as a view from `F => T`, implicit search typechecks a dummy call of the form `q"candiate(${Ident("<argument>").setType(typeOf[F])})". Now, picture yourself at the nexus of these three storms. In the enclosed test case, we search for completions at: x + 1.<caret> 1. Because the code is incomplete, the application of `Int#+` doesn't typecheck, and the typer also tries to adapt `x` to a method applicable to the re-typechecked argument. 2. This process registers a context with `retypechecking` set to true. (If multiple contexts at the same position are registered, the last one wins.) 3. Implicit search uses this context to typecheck `Predef.Ensuring(<argument>.setType(Int))`, but the argument is promptly stripped of its type and retypechecking fails as there is no definition named `<argument>` in scope. As such, we missed out on extension methods, like `ensuring` in the list of completions. This commit changes the presentation compiler to turn off retyping mode in the context before starting to work with it. (Are the other modes that might cause similar bugs?) Once I made that change, I noticed that the results the enclosed test was not stable. I tracked this down to the use of a `HashMap` to carry the applicable implicit views, together with the way that the presentation compiler removes duplicates. This commit switched to a `LinkedHashMap`.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-06 18:49:21 +0000