summaryrefslogtreecommitdiff
path: root/test/files/run
Commit message (Collapse)AuthorAgeFilesLines
* SI-5914 handle null in classtag extractorAdriaan Moors2012-06-262-0/+10
|
* fix for SI-4935Miguel Garcia2012-06-263-0/+11
|
* Merge pull request #760 from retronym/ticket/5966-3Adriaan Moors2012-06-252-0/+12
|\ | | | | SI-5966 Fix eta expansion for repeated parameters with zero arguments.
| * SI-5966 Fix eta expansion for repeated parameters with zero arguments.Jason Zaugg2012-06-232-0/+12
| | | | | | | | | | Reworks part of e33901 / SI-5610, which was inserting an <empty> tree as an argument in this case, which turns into a null in icode.
* | Merge pull request #756 from axel22/issue/4809Josh Suereth2012-06-221-0/+34
|\ \ | | | | | | Fix SI-4809.
| * | Fix SI-4809.Aleksandar Prokopec2012-06-211-0/+34
| | |
* | | Fix SI-5284.Aleksandar Prokopec2012-06-216-0/+86
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem was the false assumption that methods specialized on their type parameter, such as this one: class Foo[@spec(Int) T](val x: T) { def bar[@spec(Int) S >: T](f: S => S) = f(x) } have their normalized versions (`bar$mIc$sp`) never called from the base specialization class `Foo`. This meant that the implementation of `bar$mIc$sp` in `Foo` simply threw an exception. This assumption is not true, however. See this: object Baz { def apply[T]() = new Foo[T] } Calling `Baz.apply[Int]()` will create an instance of the base specialization class `Foo` at `Int`. Calling `bar` on this instance will be rewritten by specialization to calling `bar$mIc$sp`, hence the error. So, we have to emit a valid implementation for `bar`, obviously. Problem is, such an implementation would have conflicting type bounds in the base specialization class `Foo`, since we don't know if `T` is a subtype of `S = Int`. In other words, we cannot emit: def bar$mIc$sp(f: Int => Int) = f(x) // x: T without typechecking errors. However, notice that the bounds are valid if and only if `T = Int`. In the same time, invocations of `bar$mIc$sp` will only be emitted in callsites where the type bounds hold. This means we can cast the expressions in method applications to the required specialized type bound. The following changes have been made: 1) The decision of whether or not to create a normalized version of the specialized method is not done on the `conflicting` relation anymore. Instead, it's done based on the `satisfiable` relation, which is true if there is possibly an instantiation of the type parameters where the bounds hold. 2) The `satisfiable` method has a new variant called `satisfiableConstraints`, which does unification to figure out how the type parameters should be instantiated in order to satisfy the bounds. 3) The `Duplicators` are changed to transform a tree using the `castType` method which just returns the tree by default. In specialization, the `castType` in `Duplicators` is overridden, and uses a map from type parameters to types. This map is obtained by `satisfiableConstraints` from 2). If the type of the expression is not equal to the expected type, and this map contains a mapping to the expected type, then the tree is cast, as discussed above. Additional tests added. Review by @dragos Review by @VladUreche Conflicts: src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala src/compiler/scala/tools/nsc/typechecker/Duplicators.scala
* | Merge pull request #729 from scalamacros/topic/showrawAdriaan Moors2012-06-1916-0/+107
|\ \ | | | | | | improve showRaw
| * | improves showRawEugene Burmako2012-06-1916-0/+107
| | | | | | | | | | | | addresses concerns raised in http://groups.google.com/group/scala-user/browse_thread/thread/de5a5be2e083cf8e
* | | Merge pull request #739 from jsuereth/feature/collection-conversionsJosh Suereth2012-06-182-0/+164
|\ \ \ | | | | | | | | Adding copyInto and toVector methods to collections.
| * | | Migrate build to @odersky's suggestion of convertTo.Josh Suereth2012-06-181-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | * Move method into TraversableOnce from Iterator and Traversable to make the build pass. * Udpate IDE tests with new collection methods. * Rewire default toXYZ methods to use convertTo.
| * | | Rename copyTo to build based on consensus of 3Josh Suereth2012-06-181-7/+7
| | | |
| * | | Fixes from review.Josh Suereth2012-06-181-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | * Fixed typo * Renamed copyInto to copyTo * Added tparam doc.
| * | | Adding copyInto and toVector methods to collections.Josh Suereth2012-06-182-0/+164
| | |/ | |/| | | | | | | | | | * Added generic copyInto method for collections. For any collection with a CanBuildFrom, can convert a generic collection into it using the builder. * Added specifici toVector method for collections. This is more efficient than copyInto if the collection is a Vector.
* / | Fix SI-4954.Aleksandar Prokopec2012-06-181-0/+45
|/ / | | | | | | | | | | Override inner classes in `LinkedHashMap` that correspond to `filterKeys`, `mapValues` and `keys` to retain a proper ordering of elements when they are transformed.
* / fixes SI-5912Eugene Burmako2012-06-151-0/+6
|/
* SI-5162 Exclude super.foo from the erasure cast of SI-4283Jason Zaugg2012-06-115-0/+51
| | | | | | | | | If the target method is defined in Java, treat the super reference as an error, otherwise allow it in the knowledge that Scala loosens the access restrictions on its generated classes. Moves the test for that bug out of pending-ville. It's sufficient to place Test in the empty package to exercise the right code paths.
* test case, closes SI-5840Eugene Burmako2012-06-091-0/+7
|
* test case, closes SI-5881Eugene Burmako2012-06-092-0/+8
|
* test case, closes SI-5816Eugene Burmako2012-06-092-0/+18
|
* Merge pull request #631 from retronym/ticket/5652-3Adriaan Moors2012-06-088-0/+55
|\ | | | | SI-5652 Mangle names of potentially public lambda lifted methods.
| * SI-5652 Mangle names of potentially public lambda lifted methods.Jason Zaugg2012-05-268-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This can happen if they are accessed from an inner class. If a subclass is happens to lift a public method to the same name, a VerifyError ensues. The enclosed tests: - demonstrate the absense of the VerifyError - show the names generated for the lifted methods (which are unchanged if not called from an inner class, or if lifted into a trait implementation class.) - ensure that the callers are rewritten to call the correct method when multiple with the same name are lifted. It's not ideal that this phase needs a priori knowledge of the later phases to perform this mangling. A better fix would defer this until the point when the methods are publicised, and leave the unmangled private method in place and install an public, mangled forwarder.
* | tests and fixes for the mirror APIEugene Burmako2012-06-0845-33/+372
| |
* | don't warn about abstract types that are checkableAdriaan Moors2012-06-081-0/+1
| |
* | turn unchecked type patterns into checked onesAdriaan Moors2012-06-083-14/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the pattern `(_: T)` is made checkable using (ct: ClassTag[T]).unapply by rewriting it to `ct(_: T)` (if there's a ClassTag[T] available) similarly for extractors: if the formal type of the unapply method is an uncheckable type, wrap in the corresponding classtag extractor (if available) don't trigger rewrite on non-toplevel unchecked types (i.e., only look at type constructor part of T when looking for unchecked types) TODO: find outer match to figure out if we're supposed to be unchecked would like to give users a chance to opt-out from the wrapping, but finding the match to which this pattern belongs turned out to be tricky...
* | fixes some issues with reflectField brought up todayEugene Burmako2012-06-0812-0/+135
| |
* | TypeTag => AbsTypeTag, ConcreteTypeTag => TypeTagEugene Burmako2012-06-0853-243/+215
| | | | | | | | | | This protects everyone from the confusion caused by stuff like this: https://issues.scala-lang.org/browse/SI-5884
* | removes array tagsEugene Burmako2012-06-0817-212/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before 2.10 we had a notion of ClassManifest that could be used to retain erasures of abstract types (type parameters, abstract type members) for being used at runtime. With the advent of ClassManifest (and its subtype Manifest) it became possible to write: def mkGenericArray[T: Manifest] = Array[T]() When compiling array instantiation, scalac would use a ClassManifest implicit parameter from scope (in this case, provided by a context bound) to remember Ts that have been passed to invoke mkGenericArray and use that information to instantiate arrays at runtime (via Java reflection). When redesigning manifests into what is now known as type tags, we decided to explore a notion of ArrayTags that would stand for abstract and pure array creators. Sure, ClassManifests were perfectly fine for this job, but they did too much - technically speaking, one doesn't necessarily need a java.lang.Class to create an array. Depending on a platform, e.g. within JavaScript runtime, one would want to use a different mechanism. As tempting as this idea was, it has also proven to be problematic. First, it created an extra abstraction inside the compiler. Along with class tags and type tags, we had a third flavor of tags - array tags. This has threaded the additional complexity though implicits and typers. Second, consequently, when redesigning tags multiple times over the course of Scala 2.10.0 development, we had to carry this extra abstraction with us, which exacerbated the overall feeling towards array tags. Finally, array tags didn't fit into the naming scheme we had for tags. Both class tags and type tags sound logical, because, they are descriptors for the things they are supposed to tag, according to their names. However array tags are the odd ones, because they don't actually tag any arrays. As funny as it might sound, the naming problem was the last straw that made us do away with the array tags. Hence this commit.
* | repairs the tests after the refactoring spreeEugene Burmako2012-06-08402-1359/+2036
| |
* | preparations: removes DynamicProxyEugene Burmako2012-06-083-93/+0
| | | | | | | | | | This is necessary because toolboxes will no longer be available from the library. Christopher Vogt will take care of the second reincarnation of DynamicRef.
* | macros: refactoring of fast track infrastructureEugene Burmako2012-06-084-0/+25
| | | | | | | | | | | | | | | | | | As a result, hardwired macros don't need implementation stubs. This is very important, because in a few commits scala.reflect.makro.Context will move out from scala-library.jar. Also adding fast track entries doesn't require jumping through hoops with PDTs. It's as simple as defining PartialFunction[Tree, Any].
* | Merge pull request #672 from axel22/issue/5857Adriaan Moors2012-06-081-0/+45
|\ \ | | | | | | Fixes SI-5857. More efficient min and max in Range and NumericRange
| * | Fixes SI-5857.Aleksandar Prokopec2012-06-061-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | Override `min` and `max` in `Range` and `NumericRange` to check if a default `Ordering` for the numeric type in question is used. If so, bypass traversal and compute the minimum or maximum element.
* | | Merge pull request #677 from axel22/feature/util-hashing2Josh Suereth2012-06-072-3/+3
|\ \ \ | | | | | | | | Add the first iteration of the `util.hashing` package.
| * | | Add the first iteration of the `util.hashing` package.Aleksandar Prokopec2012-06-072-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move `MurmurHash3` to `util.hashing`. Make the `class` private and retain a public companion `object`, and put the `MurmurHash3.Hashing` implementations for various types in the companion. Add a method which composes `ByteswapHashing` with some other hashing. Rename `hashOf` to `hash`. Fix chi-square test in a test-case. Review by @jsuereth. Moved a failing test that seems to use some other library version to pending.
* | | | Generate abstract methods in scala.Byte and friends.Paul Phillips2012-06-062-19/+29
|/ / / | | | | | | | | | | | | Rather than stub implementations. This saves over 50K of bytecode. I also added the necessary imports to silence the feature warnings.
* | | Merge pull request #673 from axel22/issue/5880Josh Suereth2012-06-061-0/+41
|\ \ \ | | | | | | | | Fix SI-5880.
| * | | Fix SI-5880.Aleksandar Prokopec2012-06-061-0/+41
| |/ / | | | | | | | | | Add a ChiSquare test for the new hash code.
* | | Merge pull request #671 from axel22/issue/5867Josh Suereth2012-06-062-0/+15
|\ \ \ | | | | | | | | Fix SI-5867.
| * | | Fix SI-5867.Aleksandar Prokopec2012-06-062-0/+15
| |/ / | | | | | | | | | Override clone for unrolled buffer.
* / / Fix SI-5879.Aleksandar Prokopec2012-06-062-0/+90
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a bug where a key in an immutable hash map have the corresponding value different in the iteration than when doing lookup. This use to happen after calling `merge`. Fix the order in which a key-value pair appears in the collision resolution function - the first argument always comes from the `this` hash map. Deprecate `merge` in favour of `merged`, as this is a pure method. As an added benefit, the syntax for invoking `merge` is now nicer.
* | Fix `Hashing`.Aleksandar Prokopec2012-06-011-1/+1
| | | | | | | | | | | | Move `Hashing` to `scala.util.hashing`. Adde `Hashing.Default` to `Hashing` companion object. Change `TrieMap` to autoswitch from `Hashing.Default` to `TrieMap.MangledHashing`.
* | Remove Equality in favour of Equiv.Aleksandar Prokopec2012-06-011-2/+2
| | | | | | | | Make Equiv serializable.
* | Add Hashing and Equality typeclasses.Aleksandar Prokopec2012-06-011-0/+46
| | | | | | | | | | | | Modify TrieMap to use hashing and equality. Modify serialization in TrieMap appropriately.
* | fix t5843Lukas Rytz2012-05-282-0/+24
| |
* | Orphan checkfile remover.Paul Phillips2012-05-2623-963/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Are these -msil checkfiles used in some secret fashion? The level of activity suggest otherwise. Since scala-nightly-msil has been disabled for over a year, it's an easy rm unless someone speaks up. % tools/rm-orphan-checkfiles Scanning for orphan check files... rm 'test/disabled/run/code.check' rm 'test/files/jvm/t1652.check' rm 'test/files/neg/macro-argtype-mismatch.check' rm 'test/files/neg/macro-noncompilertree.check' rm 'test/files/neg/macro-nontree.check' rm 'test/files/run/Course-2002-01-msil.check' rm 'test/files/run/Course-2002-02-msil.check' rm 'test/files/run/Course-2002-03-msil.check' rm 'test/files/run/Course-2002-04-msil.check' rm 'test/files/run/Course-2002-08-msil.check' rm 'test/files/run/Course-2002-09-msil.check' rm 'test/files/run/Course-2002-10-msil.check' rm 'test/files/run/absoverride-msil.check' rm 'test/files/run/bitsets-msil.check' rm 'test/files/run/boolord-msil.check' rm 'test/files/run/bugs-msil.check' rm 'test/files/run/impconvtimes-msil.check' rm 'test/files/run/infix-msil.check' rm 'test/files/run/iq-msil.check' rm 'test/files/run/macro-invalidret-doesnt-conform-to-impl-rettype.check' rm 'test/files/run/macro-rettype-mismatch.check' rm 'test/files/run/misc-msil.check' rm 'test/files/run/promotion-msil.check' rm 'test/files/run/richs-msil.check' rm 'test/files/run/runtime-msil.check' rm 'test/files/run/tuples-msil.check' rm 'test/pending/jvm/t1464.check' rm 'test/pending/run/subarray.check' rm 'test/pending/run/t0446.check' rm 'test/pending/run/t5629.check' Scanning for orphan flags files... rm 'test/files/neg/macro-argtype-mismatch.flags' rm 'test/files/neg/macro-noncompilertree.flags' rm 'test/files/neg/macro-nontree.flags' rm 'test/files/pos/anyval-children.flags' rm 'test/files/pos/t3097.flags' rm 'test/files/run/macro-invalidret-doesnt-conform-to-impl-rettype.flags' rm 'test/files/run/macro-rettype-mismatch.flags'
* | Fixes SI-5428.Aleksandar Prokopec2012-05-242-0/+30
|/
* Usability improvements to Origins.Paul Phillips2012-05-232-2/+2
|
* more tests for SI-3761Lukas Rytz2012-05-232-1/+23
|
* Merge pull request #595 from som-snytt/ticket/3761-overload-byname-onlyLukas Rytz2012-05-232-0/+29
|\ | | | | SI-3761: Overload resolution fails on by-name parameter
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-02 11:37:18 +0000