| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) type ClassManifest[T] = ClassTag[T] (solves a problem
with toArray[T: ClassManifest] defined on most of the collections;
if these types weren't aliases, then we won't be able to change
the signature of that method to toArray[T: ClassTag], because
that would break source compatibility for those who override
toArray in their custom collections)
2) Compiler-generated manifests no longer trigger deprecation warnings
(this is implemented by using ClassManifestFactory instead of ClassManifest
and ManifestFactory instead of Manifest)
3) Deprecation messages got improved to reflect the changes
that were introduced in 2.10.0-M4.
|
| |\
| |
| | |
Split @milessabin HasRepr into IsTraversableOnce and IsTraversableLike t...
|
| | |
| |
| |
| | |
class-ish things.
|
| |\ \
| | |
| | | |
Renaming convertTo to to on GenTraversableOnce.
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/library/scala/collection/MapLike.scala
src/library/scala/collection/SortedMapLike.scala
|
| | |\ \ \
| | |/ /
| |/| | |
Fix SI-3326.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The heart of the problem - we want to retain the ordering when
using `++` on sorted maps.
There are 2 `++` overloads - a generic one in traversables and
a map-specific one in `MapLike` - which knows about the ordering.
The problem here is that the expected return type for the expression
in which `++` appears drives the decision of the overload that needs
to be taken.
The `collection.SortedMap` does not have `++` overridden to return
`SortedMap`, but `immutable.Map` instead.
This is why `collection.SortedMap` used to resort to the generic
`TraversableLike.++` which knows nothing about the ordering.
To avoid `collection.SortedMap`s resort to the more generic `TraverableLike.++`,
we override the `MapLike.++` overload in `collection.SortedMap` to return
the proper type `SortedMap`.
|
| | |\ \ \
| | | | |
| | | | | |
Fix SI-5986.
|
| | | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Here we had an issue that RedBlack does not work the same way
for sets - which are not supposed to replace an element if
it is the same (wrt equals) and maps - which should replace
the corresponding values.
Adding an overwrite parameter which decides whether to overwrite
added keys if they are the same in the ordering.
Fix tests.
|
| | |\ \ \
| | |_|/
| |/| | |
Parallelize convertTo in parallel collection.
|
| | | | | |
|
| | |\ \ \
| | | | |
| | | | | |
Fix SI-5971.
|
| | | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When using `AbstractTransformed` abstract inner class in views in order
to force generating bridges, one must take care to push the corresponding
collection trait (such as `Iterable` or `Seq`) as far as possible to the
left in the linearization order -- otherwise, overridden methods from these
traits can override the already overridden methods in view. This was the
case with `takeWhile`.
|
| | |\ \ \
| | | | |
| | | | | |
removes pre-M4 compatibility stubs for the IDE
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
TODO: t5899 should also be refactored, but I couldn't figure out how
I tried the obvious Cake Light pattern with abstract types etc, but that didn't trigger it
there must be something with indirection through paths as well
|
| | | |/ /
| |/| | |
|
| | | | | |
|
| | |\ \ \
| | | | |
| | | | | |
SI-5966 Fix eta expansion for repeated parameters with zero arguments.
|
| | | |/ /
| | | |
| | | |
| | | |
| | | | |
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.
|
| | |\ \ \
| | | | |
| | | | | |
Fix SI-4809.
|
| | | | |/
| | |/| |
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | |\ \
| | | |
| | | | |
improve showRaw
|
| | | | |
| | | |
| | | |
| | | | |
addresses concerns raised in http://groups.google.com/group/scala-user/browse_thread/thread/de5a5be2e083cf8e
|
| | |\ \ \
| | | | |
| | | | | |
Adding copyInto and toVector methods to collections.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* 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.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* Fixed typo
* Renamed copyInto to copyTo
* Added tparam doc.
|
| | | | |/
| | |/|
| | | |
| | | |
| | | | |
* 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.
|
| | |/ /
| | |
| | |
| | |
| | |
| | | |
Override inner classes in `LinkedHashMap` that correspond
to `filterKeys`, `mapValues` and `keys` to retain a proper
ordering of elements when they are transformed.
|
| |/ / |
|
| |/ |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
SI-5652 Mangle names of potentially public lambda lifted methods.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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...
|
| | | |
|
| | |
| |
| |
| |
| | |
This protects everyone from the confusion caused by stuff like this:
https://issues.scala-lang.org/browse/SI-5884
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| |
| | |
This is necessary because toolboxes will no longer be available from the library.
Christopher Vogt will take care of the second reincarnation of DynamicRef.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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].
|
