summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Removed warningsEECOLOR2015-03-2635-48/+55
| | | | | | | | | | | | | | | | | | | | | - 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-2618-37/+38
|
* Deprecations: Use of isPackage, hasSymbol, getter, setter...Simon Ochsenreither2015-03-2617-52/+50
| | | | ... replaced by hasPackageFlag, hasSymbolIn, getterIn, setterIn.
* Merge pull request #4310 from som-snytt/issue/9127-bLukas Rytz2015-03-251-7/+4
|\ | | | | SI-9127 Xlint doesn't think spaces are significant
| * SI-9127 Xlint doesn't think spaces are significantSom Snytt2015-02-211-7/+4
| | | | | | | | | | | | | | | | | | | | | | For purposes of warning about missing interpolators, such as `"$greeting"` when the intended code was `s"$greeting"`, spaces are no longer significant. The heuristic was previously intended to allow compileresque strings, where the dollar sign is a common prefix. Currently, the Xlint warning can be selectively disabled.
* | Merge pull request #4397 from retronym/topic/icode-diagnosticGrzegorz Kossakowski2015-03-241-7/+9
|\ \ | | | | | | Improve diagnostic error on failed genLoadIdent
| * | Improve diagnostic error on failed genLoadIdentJason Zaugg2015-03-241-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This error has been haunting us recently, firstly on Greg's machine when compiling the compiler using the new SBT build, and more recently during PR validation in #4316. This commit will output an error like: symbol value c#16812 does not exist in Macro.impl, which contains locals value a#16810, value b#16811 I've included symbol IDs in the hope that they will prove useful. It seems that synthetic identifiers generated by the pattern matcher are often seen in the vicinity of this bug.
* | | Merge pull request #4380 from retronym/ticket/9020Jason Zaugg2015-03-241-2/+2
|\ \ \ | | | | | | | | SI-9020 Avoid spurious value discarding warning post-typer
| * | | SI-9020 Avoid spurious value discarding warning post-typerJason Zaugg2015-03-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Typechecking during the specialization phase was emitting a bogus warning about value discarding. Such warnings in the typer should be guarded by `!isPastTyper` to restrict the analysis to the code the user originally wrote, rather than the results of later typechecking. I've made this change to the value discarding warning. I've also changed a numeric widening warning in the vicinity, although I do not have a test case for that.
* | | | Merge pull request #4364 from som-snytt/issue/sessiontestJason Zaugg2015-03-243-15/+48
|\ \ \ \ | | | | | | | | | | SI-9170 More flexible SessionTest
| * | | | SI-9170 More flexible SessionTestSom Snytt2015-03-033-15/+48
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | SessionTest session text can include line continuations and pasted text. Pasted script (which looks like a double prompt) probably doesn't work. This commit includes @retronym's SI-9170 one-liner.
* | | | Merge pull request #4387 from retronym/ticket/9231Jason Zaugg2015-03-241-1/+1
|\ \ \ \ | | | | | | | | | | SI-9231 Don't attempt implicit search for erroneous parameter
| * | | | SI-9231 Don't attempt implicit search for erroneous parameterJason Zaugg2015-03-171-1/+1
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | If the instantiated type of an implicit parameter is erroneous, we should not attempt the implicit search. This avoids the following useless error message in the enclosed test: error: ambiguous implicit values: ... match expected type M[<error>]
* | | | 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.
* | | | | Merge pull request #4381 from khernyo/issue/9219Jason Zaugg2015-03-241-8/+13
|\ \ \ \ \ | |_|_|_|/ |/| | | | SI-9219 Stream toString returns unexpected result
| * | | | SI-9219 Stream toString returns unexpected resultSzabolcs Berecz2015-03-141-8/+13
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Cursor was not advanced before appending the second element when only the first two elements of the stream were known. - When there is no cycle in the stream, the "scout" (and "cursor") ends up pointing to a stream where tailDefined is false. This means that cursor is either empty, or cursor.tail is not yet evaluated. The former case is handled properly, but in the latter case, one more element (cursor.head) needs to be appended.
* | | | Merge pull request #4338 from Ichoran/opt-SeqLike-2.11.xGrzegorz Kossakowski2015-03-231-25/+50
|\ \ \ \ | | | | | | | | | | Performance optimization - SeqLike
| * | | | Performance optimization - SeqLikeRex Kerr2015-02-201-25/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Big improvements to updated and patch by not creating intermediate collections. Moderate improvement to sorted by not using extra ArraySeq wrapper. Small improvements to diff, intersect, and padTo by watching for duplicate or slow operations a bit more carefully. ``` Performance summary (all timings JDK 1.8.0_25 Linux): method reason =========== =============================================================== diff 1.1x speedup on big seqs - avoid double map lookup intersect 1.1-1.2x speedup - avoid double map lookup padTo avoid multiple calls to length (good if length is slow) patch 2.4-4.0x speedup - avoid intermediate collections sorted 1.2-1.5x speedup - use array directly updated 3.5-9.6x speedup - avoid intermediates (but children override) ```
* | | | | Merge pull request #4312 from lrytz/opt/inliningGrzegorz Kossakowski2015-03-2023-377/+2007
|\ \ \ \ \ | | | | | | | | | | | | Inliner for GenBCode
| * | | | | Don't inline methods containing super calls into other classesLukas Rytz2015-03-121-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Method bodies that contain a super call cannot be inlined into other classes. The same goes for methods containing calls to private methods, but that was already ensured before by accessibility checks. The last case of `invokespecial` instructions is constructor calls. Those can be safely moved into different classes (as long as the constructor is accessible at the new location). Note that scalac never emits methods / constructors as private in bytecode.
| * | | | | Ensure to re-write only trait method calls of actual trait methodsLukas Rytz2015-03-113-34/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The inliner would incorrectly treat trait field accessors like ordinary trait member methods and try to re-write invocations to the corresponding static method in the implementation class. This rewrite usually failed because no method was found in the impl class. However, for lazy val fields, there exists a member in the impl class with the same name, and the rewrite was performed. The result was that every field access would execute the lazy initializer instead of reading the field. This commit checks the traitMethodWithStaticImplementation field of the ScalaInlineInfo classfile attribute and puts an explicit `safeToRewrite` flag to each call site in the call graph. This cleans up the code in the inliner that deals with rewriting trait callsites.
| * | | | | Issue inliner warnings for callsites that cannot be inlinedLukas Rytz2015-03-1118-399/+853
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Issue precise warnings when the inliner fails to inline or analyze a callsite. Inline failures may have various causes, for example because some class cannot be found on the classpath when building the call graph. So we need to store problems that happen early in the optimizer (when building the necessary data structures, call graph, ClassBTypes) to be able to report them later in case the inliner accesses the related data. We use Either to store these warning messages. The commit introduces an implicit class `RightBiasedEither` to make Either easier to use for error propagation. This would be subsumed by a biased either in the standard library (or could use a Validation). The `info` of each ClassBType is now an Either. There are two cases where the info is not available: - The type info should be parsed from a classfile, but the class cannot be found on the classpath - SI-9111, the type of a Java source originating class symbol cannot be completed This means that the operations on ClassBType that query the info now return an Either, too. Each Callsite in the call graph now stores the source position of the call instruction. Since the call graph is built after code generation, we build a map from invocation nodes to positions during code gen and query it when building the call graph. The new inliner can report a large number of precise warnings when a callsite cannot be inlined, or if the inlining metadata cannot be computed precisely, for example due to a missing classfile. The new -Yopt-warnings multi-choice option allows configuring inliner warnings. By default (no option provided), a one-line summary is issued in case there were callsites annotated @inline that could not be inlined.
| * | | | | Limit the size of the ByteCodeRepository cacheLukas Rytz2015-03-113-4/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I observed cases (eg Scaladoc tests) where we end up with 17k+ ClassNodes, which makes 500 MB.
| * | | | | Cast receiver if necessary when rewriting trait calls to impl methodLukas Rytz2015-03-115-16/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The self parameter type may be incompatible with the trait type. trait T { self: S => def foo = 1 } The $self parameter type of T$class.foo is S, which may be unrelated to T. If we re-write a call to T.foo to T$class.foo, we need to cast the receiver to S, otherwise we get a VerifyError.
| * | | | | Inline final methods defined in traitsLukas Rytz2015-03-118-148/+232
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to inline a final trait method, callsites of such methods are first re-written from interface calls to static calls of the trait's implementation class. Then inlining proceeds as ususal. One problem that came up during development was that mixin methods are added to class symbols only for classes being compiled, but not for others. In order to inline a mixin method, we need the InlineInfo, which so far was built using the class (and method) symbols. So we had a problem with separate compilation. Looking up the symbol from a given classfile name was already known to be brittle (it's also one of the weak points of the current inliner), so we changed the strategy. Now the InlineInfo for every class is encoded in a new classfile attribute. This classfile attribute is relatively small, because all strings it references (class internal names, method names, method descriptors) would exist anyway in the constant pool, so it just adds a few references. When building the InlineInfo for a class symbol, we only look at the symbol properties for symbols being compiled in the current run. For unpickled symbols, we build the InlineInfo by reading the classfile attribute. This change also adds delambdafy:method classes to currentRun.symSource. Otherwise, currentRun.compiles(lambdaClass) is false.
| * | | | | Workaround for SI-9111Lukas Rytz2015-03-113-16/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The inliner forces some method symbols to complete that would not be completed otherwise. This triggers SI-9111, in which the completer of a valid Java method definition reports an error in mixed compilation. The workaround disables error reporting while completing lazy method and class symbols in the backend.
| * | | | | Don't crash the inliner in mixed compilationLukas Rytz2015-03-112-37/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In mixed compilation, the bytecode of Java classes is not availalbe: the Scala compiler does not produce any, and there are no classfiles yet. When inlining a (Scala defined) method that contains an invocation to a Java method, we need the Java method's bytecode in order to check whether that invocation can be transplanted to the new location without causing an IllegalAccessError. If the bytecode cannot be found, inlining won't be allowed.
| * | | | | After removing a live handler, need to re-run unreachableCodeLukas Rytz2015-03-112-15/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Building the call graph and running the inliner require all code to be reachable (in terms of ASM's data flow analysis / interpreter). After removing unreachable code, empty exception handlers need to be removed for correctness (see comment in LocalOpt.methodOptimizations). Removing a live exception handler renders its handler unreachable and therefore requires running another round of removing unreachable code.
| * | | | | Looking up the ClassNode for an InternalName returns an OptionLukas Rytz2015-03-116-41/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `ByteCodeRepository.classNode(InternalName)` method now returns an option. Concretely, in mixed compilation, the compiler does not create a ClassNode for Java classes, and they may not exist on the classpath either.
| * | | | | Integrate the inliner into the backend pipelineLukas Rytz2015-03-113-4/+178
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current heuristics are simple: attempt to inline every method annotated `@inline`. Cycles in the inline request graph are broken in a determinisitc manner. Inlining is then performed starting at the leaves of the inline request graph, i.e., with those callsites where the target method has no callsites to inline. This expansion strategy can make a method grow arbitrarily. We will most likely have to add some thresholds and / or other measures to prevent size issues.
| * | | | | Build a call graph for inlining decisionsLukas Rytz2015-03-119-131/+396
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Inlining decisions will be taken by analyzing the ASM bytecode. This commit adds tools to build a call graph representation that can be used for these decisions. The call graph is currently built by considering method descriptors of callsite instructions. It will become more precise by using data flow analyses.
| * | | | | 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.
| * | | | | Tools to perform inlining.Lukas Rytz2015-03-1111-52/+341
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The method Inliner.inline clones the bytecode of a method and copies the new instructions to the callsite with the necessary modifications. See comments in the code. More tests are added in a later commit which integrates the inliner into the backend - tests are easier to write after that.
| * | | | | Find instructions that would cause an IllegalAccessError when inlinedLukas Rytz2015-03-115-8/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some instructions would cause an IllegalAccessError if they are inlined into a different class. Based on Miguel's implementation in 6efc0528c6.
* | | | | | Fix typo in brutallyResetAttrs commentRobertZK2015-03-181-1/+1
| | | | | |
* | | | | | Merge pull request #4388 from retronym/ticket/9223Grzegorz Kossakowski2015-03-171-1/+1
|\ \ \ \ \ \ | | | | | | | | | | | | | | SI-9223 By-name constructor params should not be aliased
| * | | | | | SI-9223 By-name constructor params should not be aliasedJason Zaugg2015-03-171-1/+1
| | |_|/ / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Usually, the compiler tries avoids creating a field in a subclass for a constructor parameter that is known to be stored in a field in one of its superclasses. However, in the enclosed test `run/t9223.scala`, this mechanism confuses `=> A` with `A`, which results in a runtime `ClassCastException`. This commit avoids using param aliases for by-name parameters. I have also added a test for something close the opposite case, where the subclass has a strict parameter and the superclass has a by-name parameter. This was working correctly before this patch.
* | | | | | Merge pull request #4383 from lrytz/upgrade-asm-squashedGrzegorz Kossakowski2015-03-177-34/+279
|\ \ \ \ \ \ | | | | | | | | | | | | | | Upgrade ASM to 5.0.3
| * | | | | | Upgrade ASM to 5.0.3Lukas Rytz2015-03-147-32/+270
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit is a squashed version of all commits in PR #4382. For the next upgrade, consult the src/asm/README and check the commits in https://github.com/scala/scala/pull/4382/commits.
| * | | | | | Clarifications to src/asm/READMELukas Rytz2015-03-141-2/+9
| |/ / / / /
* / / / / / 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.
* | | / / Merge pull request #4377 from lrytz/opt/scalaInlineInfoGrzegorz Kossakowski2015-03-117-4/+301
|\| | | | | |_|/ / |/| | | Emit the ScalaInlineInfo attribute under GenASM
| * | | Emit the ScalaInlineInfo attribute under GenASMLukas Rytz2015-03-117-4/+301
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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%)
* | | Merge pull request #4357 from retronym/merge/2.10.x-to-2.11.x-20150224v2.11.6Adriaan Moors2015-02-241-4/+1
|\ \ \ | | | | | | | | Merge 2.10.x to 2.11.x
| * \ \ Merge commit 'ad845ff' into merge/2.10.x-to-2.11.x-20150224Jason Zaugg2015-02-241-4/+1
| |\ \ \ | | |_|/ | |/| | | | | | | | | | | | | | Conflicts: src/library/scala/concurrent/Promise.scala test/files/jvm/future-spec/PromiseTests.scala
| | * | Merge pull request #4289 from retronym/ticket/8689Grzegorz Kossakowski2015-02-151-5/+2
| | |\ \ | | | | | | | | | | SI-8689 Avoid internal error in Promise after sequence of completions
| | | * | SI-8689 Avoid internal error in Promise after sequence of completionsViktor Klang2015-02-041-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calling `completeWith` when the `DefaultPromise` is already completed, leads to callbacks not being properly executed. This happened because `Future.InternalCallbackExecutor` extends `BatchingExecutor`[1] which assumes `unbatchedExecute` to be async, when in this case it is sync, and if there is an exception thrown by executing the batch, it creates a new batch with the remaining items from the current batch and submits that to `unbatchedExecute` and then rethrows, but if you have a sync `unbatchedExecute`, it will fail since it is not reentrant, as witnessed by the failed `require` as reported in this issue. This commit avoids problem by delegating `completeWith` to `tryComplete`, which has the effect of using `onComplete` + `tryComplete` i.s.o. `complete`, which means that when it fails (because of a benign race condition between completers) it won't throw an exception. It has been tested by the minimized reproducer. [1] Actually, in the 2.10.x branch where this patch is starting out, "The BatchingExecutor trait had to be inlined into InternalCallbackExecutor for binary compatibility.". This comment will be more literally correct in the context of 2.11.x and beyond
| | * | | Backported fix for SI-7753 to 2.10.x.Miles Sabin2015-02-091-34/+55
| | |/ /