Merge 2.12.x to 2.13.x [ci: last-only] #5862
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
8000
Any types that needed to be specialized to support callsites in the current run would have already been info transformed during the specalization tree transform of those call sites. The backend requires further type information, e.g, to know about inner/enclosing class relationships. This involves calls to `sym.info` for classes on the classpath that haven't yet been info transformed. During that process, all base classes of such types are also info transformed. The specialization info transformer for classes then looks at the members of the classes to add specialialized variants. This is undesirable on grounds of performance and the risk of encountering stub symbols (references to types absent from the current compilation classpath) which can manifest as compiler crashes.
We know that `subst(tp1) <:< subst(tp2)` a priori (and cheaply!) if `tp2` is `Any`, which is commonly the case.
Reworks e4b5c00 to perform the flag mutation once per run, at the conclusion of the specialization tree transform, rather than once per compilation unit. The old approach was O(NxM), where N is the number of compilation units and M is the number of specialized overloads.
Most commonly, this method will return an empty set. This commit focuses on
making that happen with a minimum of garbage, indirection, and info forcing.
- Use mutable buffers to collect results, rather than appending sets
- Avoid forcing the specialization info transform on all referenced
types just to see if they have specialzied type parmeteters, we can
phase travel back to typer to lookup this.
- Record the entry for the RHS of the DefDef is a dedicated
field to avoid immediately looking it up in a hash map after
traversal
- Use an AnyRefMap to avoid BoxesRuntime hashCode/equals
- Use getOrElse rather than withDefaultValue to profit from a fast
path in AnyRefMap.
The existing implementation pessimistically checks that all parent directories of the about-to-be-written class file are indeed directories. This commit bypasses this logic for the common case of writing to a regular directory on disk, and optimistically assumes that the parent directory exists. If an exception is thrown during writing, it attempts to create the parent directory. This still avoids a compiler crash if a parent directory is actually a file, which is tested by the existing test, `run/t5717.scala`.
This is a hot method in the backend, and we save some cycles by avoiding BoxesRuntime.
The backend uses this string as a key to the map of BTypes, and as such needs to call `javaBinaryNameString` for each method or field reference in the code. Even though we have previously optimized the creation of this string by bypassing the Name abstraction and by correctly sizing string builders, we can still speed things up by caching the resulting String on its ClassSymbol.
These assertions don't seem to pay their way anymore, the surrounding implementation of the backend has matured, and they involve collections operations that are too costly to be called in such a hot path in the backend.
Thread a single StringBuilder through the component's stringification methods, rather than using string concat (ie, separates StringBuilders) at each level.
The class file parser, used to read the java-defined classes from the classpath, includes logic to search the output path for a .java source file that corresponds to the value of the SourceFile attribute. I haven't been able to figure out the rationale for that fix, but it involves a non-neglible overhead, so this commits disables it in the batch compiler.
Fix table
we do not speak of sbt 0.13.14. move along, move along.
Also make this whole retraction of apply/unapply in case of a clashing user-defined member conditional on `-Xsource:2.12`. It turns out, as explained by lrytz, that the retraction mechanism was fragile because it relied on the order in which completers are run. We now cover both the case that: - the completer was run, the `IS_ERROR` flag was set, and the symbol was unlinked from its scope before `addSynthetics` in `typedStat` iterates over the scope (since the symbol is already unlinked, the tree is not added, irrespective of its flags). For this case, we also remove the symbol from the synthetics in its unit (for cleanliness). - the completer is triggered during the iteration in `addSynthetics`, which needs the check for the `IS_ERROR` flag during the iteration. Before, the completer just unlinked the symbol and set the IS_ERROR flag, and I assumed the typer dropped a synthetic tree with a symbol with that flag, because the tree was not shown in -Xprint output. In reality, the completer just always happened to run before the addSynthetics loop and unlinked the symbol from its scope in the test cases I came up with (including the 2.11 community build). Thankfully, the 2.12 community build caught my mistake, and lrytz provided a good analysis and review. Fix scala/bug#10261
Actually retract clashing synthetic apply/unapply
MathJax CDN update
Merge 2.11.x into 2.12.x [ci: last-only]
and use 2.12.2 as starr also update a copyright date we missed before
upgrade to sbt 0.13.15
see release notes at https://github.com/scala/scala-partest/releases/tag/v1.1.1
bump version to 2.12.3
upgrade to partest 1.1.1
I should have removed the try/catch when I removed the code path that could throw that exception in 131402f.
Avoid excessive IO in classfile parser
Improve performance of the backend
Reduce the overhead of specialization
Create a lambda deserializer per group of target methods, and call these sequentially trapping the particular pattern of exception that is thrown when a target method is absent from the map. Fixes scala/bug#10232 ``` // access flags 0x100A private static synthetic $deserializeLambda$(Ljava/lang/invoke/SerializedLambda;)Ljava/lang/Object; TRYCATCHBLOCK L0 L1 L1 java/lang/IllegalArgumentException L0 ALOAD 0 INVOKEDYNAMIC lambdaDeserialize(Ljava/lang/invoke/SerializedLambda;)Ljava/lang/Object; [ // handle kind 0x6 : INVOKESTATIC scala/runtime/LambdaDeserialize.bootstrap(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;[Ljava/lang/invoke/MethodHandle;)Ljava/lang/invoke/CallSite; // arguments: // handle kind 0x6 : INVOKESTATIC Test$.$anonfun$main$1$adapted(Lscala/Function1;)Ljava/lang/Object;, // handle kind 0x6 : INVOKESTATIC Test$.$anonfun$lambdas$1(Ljava/lang/Object;)Ljava/lang/String;, ... Test$.$anonfun$lambdas$249(Ljava/lang/Object;)Ljava/lang/String;, // handle kind 0x6 : INVOKESTATIC Test$.$anonfun$lambdas$250(Ljava/lang/Object;)Ljava/lang/String; ] ARETURN L1 ALOAD 0 INVOKEDYNAMIC lambdaDeserialize(Ljava/lang/invoke/SerializedLambda;)Ljava/lang/Object; [ // handle kind 0x6 : INVOKESTATIC scala/runtime/LambdaDeserialize.bootstrap(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;[Ljava/lang/invoke/MethodHandle;)Ljava/lang/invoke/CallSite; // arguments: // handle kind 0x6 : INVOKESTATIC Test$.$anonfun$lambdas$251(Ljava/lang/Object;)Ljava/lang/String;, // handle kind 0x6 : INVOKESTATIC Test$.$anonfun$lambdas$252(Ljava/lang/Object;)Ljava/lang/String;, ... // handle kind 0x6 : INVOKESTATIC Test$.$anonfun$lambdas$256(Ljava/lang/Object;)Ljava/lang/String; ] ARETURN MAXSTACK = 2 MAXLOCALS = 1 ```
Fix lambda deserialization in classes with 252+ lambdas
We started checking the error message of this test only recently, in scala#5835. In 7a6dc1a, the backend was 8000 changed to use java.nio, and the error message changed. Its PR was not rebased on the tip of 2.12.x, so the change of error message went unnoticed. Fixes scala/scala-dev#377
Update error message for t5717
…apr-24 trivial conflicts only
|
/nothingtoseehere Scabot got confused (because I initially targeted the wrong branch), but there is a green validate-main run for 775bb11 at https://scala-ci.typesafe.com/job/scala-2.13.x-validate-main/196/console @lrytz ready for review/merge |
lrytz
approved t
A372
hese changes
Apr 24, 2017
|
I double checked to use "Create Merge Commit" :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
four merge conflicts, all trivially resolvable
motive: get the sbt version bump and the MathJax spec fix
onto 2.13.x. performance improvements, too. (note that
the partest version bump was already here.)