| 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.
|
|\
| |
| | |
SI-5489 Avoid accidentally adding members to Object in erasure.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`Symbol#classBound` assumed that `refinedType` would return a
a type based on new refinement class symbol; but that isn't so
during erasure. Instead, it returns the first super class, into
which we entered new members. Needless to say, the next run of the
resident compiler didn't take kindly to these hijinks.
To remedy the situation, I've added (yet another) condition
on `phase.erasedTypes`.
|
|\ \
| | |
| | | |
SI-4176 A repeat dose of repeated parameter type sanitization.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- During eta expansion, treat parameters of type A* as Seq[A]
- Do the same for method/class parameters as referred to by an Ident.
Also fixes SI-5967, which shows up during pattern matching.
|
| |/
|/|
| |
| | |
Errs on the side of avoiding false positives.
|
|\ \
| | |
| | | |
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`.
|
| |\ \ \ \
| | | | | |
| | | | | | |
Revert pull request #720 (CPS: enable return expressions in CPS code if ...
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
are in tail position)
Reverts commit 0ada0706746c9c603bf5bc8a0e6780e5783297cf.
Reverts commit 51c92f02229098d0b402a65a72267f7a17984022.
Reverts commit cdfbe8e39fbbec00c969cd74f117ae410b98b40b.
Reverts commit 796024c7429a03e974a7d8e1dc5c80b84f82467d.
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
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`.
|
| |\ \ \ \
| | | | | |
| | | | | | |
Test that closes SI-5839. Bug itself most probably fixed by #602
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
removes pre-M4 compatibility stubs for the IDE
|
| | | | | | | |
|
| |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Fix range positions when applying anonymous classes.
|
| | | |/ / / /
| | |/| | | |
| | | | | | |
| | | | | | | |
@odersky
|
| |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
patmat bugfixes and minor clean ups
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
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
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | |_|/ / /
| | |/| | | | |
|
| |\ \ \ \ \ \
| | |/ / / / /
| |/| | | | | |
Closes SI-5148.
|
| | |/ / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Unfortunately we have to wrap transform to catch all
the MissingRequirementErrors exceptions (wrapped in TypeErrors).
This is because we force the info of the symbol in a couple of
places and we would have to catch all/some of them
(and remove the duplicates as well which really becomes messy).
Review by @axel22.
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
Added test for SI-5761.
|
| | |/ / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Seems that my cleanup of SI-4842 also fixed that one.
Review by @paulp or @retronym.
|
| |/ / / / |
|
| |\ \ \ \
| | | | | |
| | | | | | |
Minor followup on SI-4842: remove awkward condition. Review by @retronym
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
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.
|
| |\ \ \ \ \ \
| | |_|_|_|_|/
| |/| | | | | |
SI-5968 Eliminate spurious exhaustiveness warning with singleton types.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
A singleton type is a type ripe for enumeration.
|
| |\ \ \ \ \ \
| | |/ / / / /
| |/| | | | | |
SI-4989 Reject super.x if an intermediate class declares x abstract.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This is in line with Java's treatment. Without this, an AbstractMethodError
is thrown at runtime.
|
| |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Fix SI-4809.
|
| | | |_|_|_|/
| | |/| | | | |
|
| |\ \ \ \ \ \
| | |_|_|_|/ /
| |/| | | | | |
Fix SI-5284.
|
| | | |_|_|/
| | |/| | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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
|