summaryrefslogtreecommitdiff
path: root/test/junit
Commit message (Collapse)AuthorAgeFilesLines
* 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 #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
* | | Merge pull request #4133 from som-snytt/issue/8976Ichoran2015-02-044-6/+113
|\ \ \ | | | | | | | | SI-8976 MutableList.tail.iterator.size is length
| * | | SI-8976 MutableList.tail.iterator.size is lengthSom Snytt2014-12-064-6/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous behavior was to iterate over the mutated list of arbitrary length. The previous iteration of the iterator would also iterate the terminal element of the list without halting. This is fixed by capping the length of iterator. That is OK because mutating the list by adding to it during iteration is not recommended. For good measure, the exhausted iterator does not hold a reference to any remaining tail. A test is added that will no doubt be superseded by the QCC tests. (Quasi-Comprehensive Collections.) The test just checks that the extra tail is not strongly reachable from the iterator. If the garbage collector happens to kick in and determine that the object is weakly reachable, then the check terminates early.
* | | | Merge pull request #4204 from mpociecha/correct-decimal-marks-in-testsGrzegorz Kossakowski2015-02-031-3/+12
|\ \ \ \ | | | | | | | | | | Fix problems with a locale-dependent decimal mark in StringContextTest
| * | | | Fix problems with a locale-dependent decimal mark in StringContextTestmpociecha2014-12-141-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit corrects three tests which were failing for certain locale due to the different decimal marks in the expected value and the result (e.g. 2.50 and 2,50). From now also the expected value is formatted in accordance with the current locale.
* | | | | Silence a feature warning in JUnit test code.Jason Zaugg2015-02-031-0/+1
| | | | |
* | | | | SI-9133 Harden against infinite loop in NoSymbol.ownerJason Zaugg2015-02-031-0/+5
| |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The available evidence gathered in an IDE hang suggests that while editing erronenous code, a call to `Erasure#javaSig` by the IDE's structure builder triggered the `ExplicitOuter` info transformer on a symbol with some sort of incoherent owner chain, which led to an infinite loop in `NoSymbol#outerClass`. This commit hardens that method to work in the same manner as a call to `NoSymbol.owner`: log the error under -Xdev or -Ydebug and return return `NoSymbol` to soldier on without crashing / hanging. I haven't formulated a theory about how we might have ended up with the corrupt owner chain.
* | | | Merge pull request #4259 from mzitnik/2.11.xIchoran2015-01-301-0/+20
|\ \ \ \ | | | | | | | | | | SI-9072 Vector ++ concatenation of parallel collection cause inconsisten...
| * | | | SI-9072 Vector ++ concatenation of parallel collection cause inconsistent ↵Mark Zitnik2015-01-181-0/+20
| | | | | | | | | | | | | | | | | | | | results
* | | | | Merge pull request #4253 from retronym/ticket/9087Grzegorz Kossakowski2015-01-201-0/+61
|\ \ \ \ \ | | | | | | | | | | | | SI-9087 Fix min/max of reversed Double/Float orderings
| * | | | | SI-9087 Fix min/max of reversed Double/Float orderingsJason Zaugg2015-01-201-0/+61
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As diagnosed by the reporter, we needed additional overrides due to the way these orderings are implemented. I've added tests to show other methods and other orderings are working correctly. After writing that, I found a scalacheck test related to NaN handling that also covers `Ordering`. I had to correct the assertion in the tests of `reverse.{min,max}`.
* / / / / Construct ClassBTypes from parsed classfilesLukas Rytz2015-01-162-1/+96
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This infrastructure is required for the inliner: when inlining code from a classfile, the corresponding ClassBType is needed for various things (eg access checks, InnerClass attribute). The test creates two ClassBTypes for the same class: once using the (unpickled) Symbol, once using the parsed ASM ClassNode, and verifies that the two are the same. There's a cleanup to the InnerClass attribute: object T { class Member; def foo = { class Local } } class T For Java compatibility the InnerClass entry for Member says the class is nested in T (not in the module class T$). We now make sure to add that entry only to T, not to T$ (unless Member is actually referenced in the classfile T$, in that case it will be added, as required).
* | | | Merge pull request #4201 from mpociecha/fix-typos-in-docs-and-commentsGrzegorz Kossakowski2015-01-143-6/+6
|\ \ \ \ | | | | | | | | | | Fix many typos in docs and comments
| * | | | Fix many typos in docs and commentsmpociecha2014-12-143-6/+6
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit corrects many typos found in scaladocs, comments and documentation. It should reduce a bit number of PRs which fix one typo. There are no changes in the 'real' code except one corrected name of a JUnit test method and some error messages in exceptions. In the case of typos in other method or field names etc., I just skipped them. Obviously this commit doesn't fix all existing typos. I just generated in IntelliJ the list of potential typos and looked through it quickly.
* | | | SI-9057 - fix `showCode` to put backticks around names including dotsJan Bessai2015-01-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Missing backticks cause the parser to treat names as paths, which is obviously invalid. A unit test is included.
* | | | Add unit tests for Tseitin CNF conversion.Gerard Basler2014-12-291-0/+555
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We compare the results using the Tseitin transformation with the results of a conversion via expansion of the formula (using distributive laws), e.g., ``` +-------+ |Formula| +---+---+ | +-----------+-----------+ | | v v +---------+ +-------+ |Expansion| |Tseitin| +----+----+ +---+---+ | +-----+ | +------->| =?= |<-------+ +-----+ ``` both methods should deliver the same results (i.e., models).
* | | | Merge pull request #4191 from som-snytt/issue/8538Lukas Rytz2014-12-181-0/+86
|\ \ \ \ | |_|_|/ |/| | | SI-8538 Test or example for Source.report
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-02 04:38:33 +0000