summaryrefslogtreecommitdiff
path: root/test/junit
Commit message (Collapse)AuthorAgeFilesLines
* 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
| * | | SI-8538 Document extensionSom Snytt2014-12-151-0/+30
| | | | | | | | | | | | | | | | Scaladoc for report extension point.
| * | | SI-8538 Test or example for Source.reportSom Snytt2014-12-121-0/+56
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's possible to supply an arbitrary `Positioner` to a custom `Source` that wants to override `report`. This obviates the need to expose the deprecated `Position` class. The default report method consumes the underlying iterator, which is not desirable and produces unexpected results. The expected outcome is that no one uses or extends the legacy position handling code. In 2.12, use a Reporter instead, perhaps. The current API is used by scala-xml's MarkupParser.
* / / SI-9043 ArrayBuffer.insert and insertAll are very slowDenton Cockburn2014-12-141-0/+36
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | insert and insertAll were slower than their java equivalents by factors of 5 and 10 respectively. Benchmark code was provided here: https://gist.github.com/rklaehn/3e9290118fcf63d1feae We are using a toList to the source Traversable Then doing a length and a copy on that collection. By using an array, we can make use of faster methods. Managed to get the ratios down to 1.5 and 1.5 respectively. In addition to this, I think we should consider breaking insert into 2 separate methods, one for a single item and one for a collection. The varags version is very expensive when a single item is being inserted. @phaller @axel22
* | Merge pull request #4176 from mpociecha/flat-classpath2Grzegorz Kossakowski2014-12-055-5/+538
|\ \ | | | | | | The alternative, flat representation of classpath elements
| * | Add benchmarks to compare recursive and flat cp representationsmpociecha2014-12-051-0/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal of these changes is to add possibility to: - compare an efficiency and a content of both cp implementations (ClassPathImplComparator) - examine the memory consumption by creating a lot of globals using a specified classpath (ClassPathMemoryConsumptionTester) - it can be considered as e.g. some approximation of ScalaPresentationCompilers in Scala IDE when working with many projects ClassPathMemoryConsumptionTester is placed in main (I mean not test) sources so thanks to that it has properly, out of the box configured boot classpath etc. and it's easy to use it, e.g.: scala scala.tools.nsc.ClassPathMemoryConsumptionTester -YclasspathImpl:<implementation_to_test> -cp <some_cp> -sourcepath <some_sp> -requiredInstances 50 SomeFileToCompile.scala At the end it waits for the "exit" command so there can be used some profiler like JProfiler to look how the given implementation behaves. Also flat classpath implementation is set as a default one to test it on Jenkins. This particular change must be reverted when all tests will pass because for now it's not desirable to make it permanently the default representation.
| * | Cleanup and refactoring - semicolons, unused or commented out codempociecha2014-12-052-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit contains some minor changes made by the way when implementing flat classpath. Sample JUnit test that shows that all pieces of JUnit infrastructure work correctly now uses assert method form JUnit as it should do from the beginning. I removed commented out lines which were obvious to me. In the case of less obvious commented out lines I added TODOs as someone should look at such places some day and clean them up. I removed also some unnecessary semicolons and unused imports. Many string concatenations using + have been changed to string interpolation. There's removed unused, private walkIterator method from ZipArchive. It seems that it was unused since this commit: https://github.com/scala/scala/commit/9d4994b96c77d914687433586eb6d1f9e49c520f However, I had to add an exception for the compatibility checker because it was complaining about this change. I made some trivial corrections/optimisations like use 'findClassFile' method instead of 'findClass' in combination with 'binary' to find the class file.
| * | Integrate flat classpath with the compilermpociecha2014-12-051-3/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit integrates with the compiler the whole flat classpath representation build next to the recursive one as an alternative. From now flat classpath really works and can be turned on. There's added flag -YclasspathImpl with two options: recursive (the default one) and flat. It was needed to make the dynamic dispatch to the particular classpath representation according to the chosen type of a classpath representation. There's added PathResolverFactory which is used instead of a concrete implementation of a path resolver. It turned out that only a small subset of path resolvers methods is used outside this class in Scala sources. Therefore, PathResolverFactory returns an instance of a base interface PathResolverResult providing only these used methods. PathResolverFactory in combination with matches in some other places ensures that in all places using classpath we create/get the proper representation. Also the classPath method in Global is modified to use the dynamic dispatch. This is very important change as a return type changed to the base ClassFileLookup providing subset of old ClassPath public methods. It can be problematic if someone was using in his project the explicit ClassPath type or public methods which are not provided via ClassFileLookup. I tested flat classpath with sbt and Scala IDE and there were no problems. Also was looking at sources of some other projects like e.g. Scala plugin for IntelliJ and there shouldn't be problems, I think, but it would be better to check these changes using the community build. Scalap's Main.scala is changed to be able to use both implementations and also to use flags related to the classpath implementation. The classpath invalidation is modified to work properly with the old (recursive) classpath representation after changes made in a Global. In the case of the attempt to use the invalidation for the flat cp it just throws exception with a message that the flat one currently doesn't support the invalidation. And also that's why the partest's test for the invalidation has been changed to use (always) the old implementation. There's added an adequate comment with TODO to this file. There's added partest test generating various dependencies (directories, zips and jars with sources and class files) and testing whether the compilation and further running an application works correctly, when there are these various types of entries specified as -classpath and -sourcepath. It should be a good approximation of real use cases.
| * | Create dedicated path resolver for the flat classpath representationmpociecha2014-11-301-0/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds dedicated FlatClassPathResolver loading classpath entries as FlatClassPath. Most of the common logic from PathResolver for the old classpath has been moved to the base, separate class which isn't dependent on a particular classpath representation. Thanks to that it was possible to reuse it when creating an adequate path resolver for the flat classpath representation. This change doesn't modify the way the compiler works. It also doesn't change nothing from the perspective of someone who already uses PathResolver in some project or even extends it - at least as long as he/she doesn't need to use flat classpath. There are also added JUnit tests inter alia comparing entries created using the old and the new classpath representations (whether the flat one created using the new path resolver returns the same entries as the recursive one).
| * | Add the flat classpath type aggregating flat classpath instancesmpociecha2014-11-301-0/+208
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's added AggregateFlatClassPath - an equivalent of MergedClassPath from the old implementation. It is supposed to group classpath instances handling different files being directories, zips or jars. Unlike in the case of the old (recursive) implementation, there won't be a deep, nested hierarchy of classpath instances - just one root (aggregate) and a flat structure of its children. AggregateFlatClassPath ensures the distinction of classpath entries and merges corresponding entries for class and source files into one entry. This is required as SymbolLoaders class makes use of this kind of ClassRepresentation. There are also added unit tests which check whether AggregateFlatClassPath obtains correct entries from classpath instances specified in a constructor and whether it preserves the ordering in the case of repeated entries. There's added a test type of flat classpath using VirtualFiles so it's easy to check the real behaviour.
* | Merge pull request #4141 from Ichoran/issue/8970Lukas Rytz2014-12-041-0/+6
|\ \ | | | | | | SI-8970 hashCode of BigDecimal and Double do not match
| * | SI-8970 hashCode of BigDecimal and Double do not matchRex Kerr2014-11-211-0/+6
| |/ | | | | | | | | | | Switched isValidDouble (binary equivalence) to isDecimalDouble (decimal expansion equivalence), as people generally do not care about the slew of extra decimal digits off the end of the binary approximation to a decimal fraction (decimal equivalence is the standard now). Added minimal unit test to verify behavior.
* | Merge pull request #4146 from Ichoran/issue/6519Lukas Rytz2014-12-041-3/+15
|\ \ | | | | | | SI-6519 PagedSeq is not lazy enough
| * | SI-6519 PagedSeq is not lazy enoughRex Kerr2014-11-211-3/+15
| |/ | | | | | | | | | | This was actually an issue with `length` of all things--it wasn't stopping scanning when it was past the end of what was requested. It'd just gratuitously read everything. Also fixed an overflow bug with isDefinedAt along the way (start + index > Int.MaxValue would always return true despite never working).
* / SI-8924 don't hold reference to list in iteratorMaxim Valyanskiy2014-11-271-0/+49
|/ | | | | | | | | | Current implementation of LinearSeqLike.iterator holds reference to complete sequence. This prevent garbage collecting of List elements while we keep reference to iterator somewhere. This commit removes reference from Iterator implementation. This allow garbage collection of List while we iterating over its elements (when there is no other references to List in our program).
* Merge pull request #4075 from som-snytt/issue/8835-junitGrzegorz Kossakowski2014-11-172-3/+150
|\ | | | | SI-8835 Iterator tests can be junit
| * SI-8835 Update iterator testsSom Snytt2014-11-131-50/+35
| | | | | | | | | | | | | | | | Addressing feedback from the collections test czar, updated a few of the primitive tests. Avoided testing addition and just asserted. Updated indexOf test to test Iterator.indexOf.
| * SI-8835 Iterator tests can be junitSom Snytt2014-11-112-3/+165
| | | | | | | | | | | | | | | | | | | | Without loss of generality or convenience, but helps reduce the number of files in test/files and may reduce compile times for test suite. This commit includes the fix from #3963 and an extra test of that fix that ensures the stack doesn't grow on chained drops.
* | SI-8932 Fix dropRight/takeRight implementationsRui Gonçalves2014-11-114-0/+73
|/ | | | | | | | I looked up at all the overrides of `IterableLike#takeRight` and `IterableLike#dropRight` and replaced usages of its argument `n` with `math.max(n, 0)` every time it was being used in an index subtraction. Fixes [SI-8932](https://issues.scala-lang.org/browse/SI-8932).
* Merge pull request #4088 from lrytz/opt/cleanupOptimizationsLukas Rytz2014-11-108-68/+554
|\ | | | | GenBCode: cleanup optimizations
| * Address review commentsLukas Rytz2014-11-071-1/+1
| |
| * GenBCode: Compact local variable slotsLukas Rytz2014-11-041-0/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After eliminating unreachable code, there may be unused local varaible slots. Such gaps increase the method's frame size unnecessarily. The optimization does not attempt to re-use the same local variable slot for non-overlapping locals (proper register allocation): def f(b: Boolean) = if (b) { val x = e; x } else { val y = e; y } x and y will not use the same slot, even though they could. This was originally implemented by Miguel in https://github.com/lrytz/scala/commit/09c40359338f8770e4f99d045999af062112973e