summaryrefslogtreecommitdiff
path: root/test/junit
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #4415 from Ichoran/issue/9254Adriaan Moors2015-04-221-0/+25
|\ | | | | SI-9254 UnrolledBuffer appends in wrong position
| * SI-9254 UnrolledBuffer appends in wrong positionRex Kerr2015-03-311-0/+25
| | | | | | | | | | | | | | | | | | | | | | Fixed two bugs in insertion (insertAll of Unrolled): 1. Incorrect recursion leading to an inability to insert past the first chunk 2. Incorect repositioning of `lastptr` leading to strange `append` behavior after early insertion Added tests checking that both of these things now work. Also added a comment that "waterlineDelim" is misnamed. But we can't fix it now--it's part of the public API. (Shouldn't be, but it is.)
* | Merge pull request #4416 from Ichoran/issue/9197Adriaan Moors2015-04-221-0/+24
|\ \ | | | | | | SI-9197 Duration.Inf not a singleton when deserialized
| * | SI-9197 Duration.Inf not a singleton when deserializedRex Kerr2015-03-311-0/+24
| |/ | | | | | | | | | | | | | | Made `Duration.Undefined`, `.Inf`, and `.MinusInf` all give back the singleton instance instead of creating a new copy by overriding readResolve. This override can be (and is) private, which at least on Sun's JDK8 doesn't mess with the auto-generated SerialVersionUIDs. Thus, the patch should make things strictly better: if you're on 2.11.7+ on JVMs which pick the same SerialVersionUIDs, you can recover singletons. Everywhere else you were already in trouble anyway.
* | Merge pull request #4462 from som-snytt/issue/badtabAdriaan Moors2015-04-221-0/+20
|\ \ | | | | | | SI-9275 Fix row-first display in REPL
| * | SI-9275 Fix row-first display in REPLSom Snytt2015-04-211-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | A missing range check in case anyone ever wants to use ``` -Dscala.repl.format=across ``` which was observed only because of competition from Ammonite.
* | | Merge pull request #4461 from adriaanm/rebase-4446Adriaan Moors2015-04-221-1/+1
|\ \ \ | | | | | | | | Fix many typos
| * | | Fix many typosMichał Pociecha2015-04-211-1/+1
| |/ / | | | | | | | | | | | | This commit corrects many typos found in scaladocs and comments. There's also fixed the name of a private method in ICodeCheckers.
* / / Remove stdout/stderr output from Junit testsJason Zaugg2015-04-211-1/+0
|/ /
* | Merge pull request #4431 from adriaanm/rebase-4379Adriaan Moors2015-04-131-3/+55
|\ \ | | | | | | Patmat: efficient reasoning about mutual exclusion
| * | Patmat: efficient reasoning about mutual exclusionGerard Basler2015-04-061-3/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Faster analysis of wide (but relatively flat) class hierarchies by using a more efficient encoding of mutual exclusion. The old CNF encoding for mutually exclusive symbols of a domain added a quadratic number of clauses to the formula to satisfy. E.g. if a domain has the symbols `a`, `b` and `c` then the clauses ``` !a \/ !b /\ !a \/ !c /\ !b \/ !c ``` were added. The first line prevents that `a` and `b` are both true at the same time, etc. There's a simple, more efficient encoding that can be used instead: consider a comparator circuit in hardware, that checks that out of `n` signals, at most 1 is true. Such a circuit can be built in the form of a sequential counter and thus requires only 3n-4 additional clauses [1]. A comprehensible comparison of different encodings can be found in [2]. [1]: http://www.carstensinz.de/papers/CP-2005.pdf [2]: http://www.wv.inf.tu-dresden.de/Publications/2013/report-13-04.pdf
* | | Merge pull request #4413 from lrytz/opt/inliningEverythingLukas Rytz2015-04-077-26/+92
|\ \ \ | |/ / |/| | Fixes and Improvements for the new inliner
| * | SI-9139 don't inline across @strictfp modesLukas Rytz2015-04-011-0/+21
| | | | | | | | | | | | Cannot inline if one of the methods is @strictfp, but not the other.
| * | Test case: cannot inline a private call into a different class.Lukas Rytz2015-04-011-0/+27
| | | | | | | | | | | | | | | Invocations of private methods cannot be inlined into a different class, this would cause an IllegalAccessError.
| * | Clean up the way compiler settings are accessed in the backend.Lukas Rytz2015-04-016-26/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many backend components don't have access to the compiler instance holding the settings. Before this change, individual settings required in these parts of the backend were made available as members of trait BTypes, implemented in the subclass BTypesFromSymbols (which has access to global). This change exposes a single value of type ScalaSettings in the super trait BTypes, which gives access to all compiler settings.
| * | Don't try to inline native methodsLukas Rytz2015-04-011-0/+11
| | | | | | | | | | | | Because you can't, really.
| * | Eliminate unreachable code before inlining a methodLukas Rytz2015-04-012-1/+15
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Running an ASM analyzer returns null frames for unreachable instructions in the analyzed method. The inliner (and other components of the optimizer) require unreachable code to be eliminated to avoid null frames. Before this change, unreachable code was eliminated before building the call graph, but not again before inlining: the inliner assumed that methods in the call graph have no unreachable code. This invariant can break when inlining a method. Example: def f = throw e def g = f; println() When building the call graph, both f and g contain no unreachable code. After inlining f, the println() call becomes unreachable. This breaks the inliner's assumption if it tries to inline a call to g. This change intruduces a cache to remember methods that have no unreachable code. This allows invoking DCE every time no dead code is required, and bail out fast. This also simplifies following the control flow in the optimizer (call DCE whenever no dead code is required).
* | Merge pull request #4370 from gbasler/ticket/SI-9181Adriaan Moors2015-04-061-0/+3
|\ \ | |/ |/| SI-9181 Exhaustivity checking does not scale (regression)
| * Add a check to ensure that if the formulas originating from the exhaustivity /Gerard Basler2015-03-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | reachability analysis are too big to be solved in reasonable time, then we skip the analysis. I also cleaned up warnings. Why did `t9181.scala` work fine with 2.11.4, but is now running out of memory? In order to ensure that the scrutinee is associated only with one of the 400 derived classes we add 400*400 / 2 ~ 80k clauses to ensure mutual exclusivity. In 2.11.4 the translation into CNF used to fail, since it would blow up already at this point in memory. This has been fixed in 2.11.5, but now the DPLL solver is the bottleneck. There's a check in the search for all models (exhaustivity) that it would avoid a blow up, but in the search for a model (reachability), such a check is missing.
* | Merge pull request #4318 from soc/topic/remove-deprecation-warningsLukas Rytz2015-03-281-2/+2
|\ \ | | | | | | Remove deprecation warnings
| * | new{Term,Type}Name→{Term,Type}Name, tpename/nme→{type,term}NamesSimon Ochsenreither2015-03-261-2/+2
| | |
* | | SI-9038 fix scaladoc syntax highlightning to leave unicode aloneAntoine Gourlay2015-03-261-0/+22
|/ / | | | | | | | | | | | | | | Syntax highlightning in code blocks used to manipulate the raw bytes of a String, converting them to chars when needed, which breaks Unicode surrogate pairs. Using a char array instead of a byte array will leave them alone.
* | Don't inline methods containing super calls into other classesLukas Rytz2015-03-122-13/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Test case for SI-9111 workaround.Lukas Rytz2015-03-111-1/+42
| |
* | Ensure to re-write only trait method calls of actual trait methodsLukas Rytz2015-03-111-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1111-43/+283
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-111-1/+1
| | | | | | | | | | 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-112-5/+21
| | | | | | | | | | | | | | | | | | | | 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-1110-51/+573
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Don't crash the inliner in mixed compilationLukas Rytz2015-03-113-7/+42
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Looking up the ClassNode for an InternalName returns an OptionLukas Rytz2015-03-113-3/+3
| | | | | | | | | | | | | | 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-112-10/+211
| | | | | | | | | | | | | | | | | | | | | | | | 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-113-6/+157
| | | | | | | | | | | | | | | | | | | | 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-1111-51/+158
| | | | | | | | | | | | | | | | | | | | 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-111-0/+193
| | | | | | | | | | | | | | | | | | 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-112-1/+201
| | | | | | | | | | | | | | Some instructions would cause an IllegalAccessError if they are inlined into a different class. Based on Miguel's implementation in 6efc0528c6.
* | Emit the ScalaInlineInfo attribute under GenASMLukas Rytz2015-03-111-0/+85
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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%)
* SI-9126 Missing .seqs causes problems with parallel GenXsRex Kerr2015-02-202-20/+44
| | | | | | | | Added `.seq` in two essential places so that a parallel collection passed as an argument won't mess up side-effecting sequential computations in `List.flatMap` and `GenericTraversableTemplate.transpose` (thanks to retronym for finding the danger spots). Tests that `.seq` is called by constructing a `GenSeq` whose `.seq` disagrees with anything non-`.seq` (idea & working implementation from retronym). Also updates the `.seq` test for `Vector#++` to use the new more efficient method.
* Merge pull request #4330 from Ichoran/issue/8917Adriaan Moors2015-02-191-0/+9
|\ | | | | SI-8917 collection.mutable.BitSet's &= operator doesn't clear end
| * SI-8917 collection.mutable.BitSet's &= operator doesn't clear endRex Kerr2015-02-131-0/+9
| | | | | | | | Made &= run to the end of its own bitset, ignoring the size of what it's &-ing with (which is exactly what you want for &=).
* | Merge pull request #4329 from adriaanm/followup-4235Adriaan Moors2015-02-181-0/+29
|\ \ | | | | | | Simpler & Scala.js-friendly `ClassTag.unapply`
| * | Use if/then/else to avoid box(unbox(_))Adriaan Moors2015-02-181-0/+29
| | |
* | | Merge pull request #4328 from adriaanm/rework-4230Adriaan Moors2015-02-171-0/+15
|\ \ \ | |_|/ |/| | SI-9059 Random.alphanumeric is inefficient
| * | SI-9059 Random.alphanumeric is inefficientDenton Cockburn2015-02-131-0/+15
| |/ | | | | | | | | | | | | | | | | Generate alphanumeric values by taking random element of string containing all alphanumerics. Instead of generating nextPrintableChar then filtering for alphanumerics, we can just take from a string containing all alphanumerics. This provides a significant performance improvement.
* | Merge pull request #4304 from adriaanm/rebase-4219Adriaan Moors2015-02-132-17/+16
|\ \ | |/ |/| SI-8818 FreshName extractor forgives suffix
| * SI-8818 FreshName extractor forgives suffixSom Snytt2015-02-092-17/+16
| | | | | | | | | | | | The test is corrected (inverted) and the extractor is made more succinct. Succinctness isn't enforced by the test, but I checked it manually.
* | Merge pull request #4280 from kanielc/SI-9095Adriaan Moors2015-02-092-0/+50
|\ \ | | | | | | SI-9095 Memory leak in LinkedHasMap and LinkedHashSet
| * | SI-9095 Memory leak in LinkedHasMap and LinkedHashSetDenton Cockburn2015-01-312-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | The clear() method in scala.collection.mutable.LinkedHashSet and scala.collection.mutable.LinkedHashMap does not set lastEntry to null. In result it holds a reference to an object that was removed from the collection.
* | | Merge pull request #4209 from kanielc/SI-8988Adriaan Moors2015-02-091-0/+37
|\ \ \ | |_|/ |/| | SI-8988 Escaping character in StringLike.split(c) is slow
| * | SI-8988 Escaping character in StringLike.split(c) prevents usage of ↵Denton Cockburn2015-01-091-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | optimized String.split code path Escaping a char when calling split is slow. We end up compiling a Pattern to simply match a character literal. Instead, we just use an loop with indexOf to construct our resulting Array. Current speed up over old behaviour is about 12-1
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-22 16:59:46 +0000