| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- clarify the intent of tests
- Consolidate stripExistentialsAndTypeVars with similar logic in
mergePrefixAndArgs
- Refactor special cases in maybeRewrap
The name isn't great, but I'm struggling to come up with
a pithy way to describe the rogue band of types.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ASF was failing to recognize the correspondence between a
prefix if it has an abstract type symbol, even if it is bounded by
the currently considered class.
Distilling the test cases, this led to incorrect typechecking of the
RHS of `G` in:
```
trait T {
type A
trait HasH { type H[U] <: U }
type F[N <: HasH] = N#H[T]
type G[N <: HasH] = F[N]#A // RHS was incorrectly reduced to T.this.A
}
```
In the fuller examples (included as test cases), this meant that
type level functions written as members of `HList` could not be
implemented in terms of each other, e.g. defining `Apply[N]` as
`Drop[N]#Head` had the wrong semantics.
This commit checks checks if the prefix has the candidate class
as a base type, rather than checking if its type symbol has this
as a base class. The latter formulation discarded information about
the instantation of the abstract type.
Using the example above:
```
scala> val F = typeOf[T].member(TypeName("F")).info
F: $r.intp.global.Type = [N <: T.this.HasH]N#H[T]
scala> F.resultType.typeSymbol.baseClasses // old approach
res14: List[$r.intp.global.Symbol] = List(class Any)
scala> F.resultType.baseClasses // new approach
res13: List[$r.intp.global.Symbol] = List(trait T, class Object, class Any)
```
It is worth noting that dotty rejects some of these programs,
as it introduces the rule that:
> // A type T is a legal prefix in a type selection T#A if
> // T is stable or T contains no abstract types except possibly A.
> final def isLegalPrefixFor(selector: Name)(implicit ctx: Context)
However, typechecking the program above in this comment in dotty
yields:
<trait> trait T() extends Object {
type A
<trait> trait HasH() extends Object {
type H <: [HK$0] => <: HK$0
}
type F = [HK$0] => HK$0#H{HK$0 = T}#Apply
type G = [HK$0] => HK$0#H{HK$0 = T}#Apply#A
}
As the equivalent code [1] in dotc's `asSeenFrom` already looks for a base type
of the prefix, rather than looking for a superclass of the prefix's
type symbol.
[1] https://github.com/lampepfl/dotty/blob/d2c96d02fccef3a82b88ee1ff31253b6ef17f900/src/dotty/tools/dotc/core/TypeOps.scala#L62
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lazy base type seq elements are encoded as a refined type with
an empty scope and a list of type refs over some common type
symbol that will be merged when `BaseTypeSeq#apply` is called.
The first change in this commit is to mark the creation and consumption
of such elements with calls to `[is]IntersectionTypeForBaseTypeSeq`. They
are distinguished by using the actual type symbol rather than a refinement
class symbol, which in turn simplifies the code in
`BaseTypeSeq#typeSymbol`.
I have also made `lub` aware of this encoding: it is now able to "see through"
to the parents of such refined types and merge them with other base types
of the same class symbol (even other refined types representing lazy BTS
elements.)
To make this fix work, I also had to fix a bug in LUBs of multiple with
existential types. Because of the way the recursion was structured in
`mergePrefixAndArgs`, the order of list of types being merged changed
behaviour: quantified varialbles of existential types were being rewrapped
around the resultting type, but only if we hadn't encountered the first
regular `TypeRef`.
This can be seen with the following before/after shot:
```
// 2.11.8
scala> val ts = typeOf[Set[Any]] :: typeOf[Set[X] forSome { type X <: Y; type Y <: Int}] :: Nil; def merge(ts: List[Type]) = mergePrefixAndArgs(ts, Variance.Contravariant, lubDepth(ts)); val merged1 = merge(ts); val merged2 = merge(ts.reverse); (ts.forall(_ <:< merged1), ts.forall(_ <:< merged2))
ts: List[$r.intp.global.Type] = List(Set[Any], Set[_ <: Int])
merge: (ts: List[$r.intp.global.Type])$r.intp.global.Type
merged1: $r.intp.global.Type = scala.collection.immutable.Set[_ >: Int]
merged2: $r.intp.global.Type = scala.collection.immutable.Set[_53] forSome { type X <: Int; type _53 >: X }
res0: (Boolean, Boolean) = (false,true)
// HEAD
...
merged1: $r.intp.global.Type = scala.collection.immutable.Set[_10] forSome { type X <: Int; type _10 >: X }
merged2: $r.intp.global.Type = scala.collection.immutable.Set[_11] forSome { type X <: Int; type _11 >: X }
res0: (Boolean, Boolean) = (true,true)
```
Furthermore, I have fixed the computation of the base type sequences of
existential types over refinement types, in order to maintain the invariant
that each slot of the base type sequence of a existential has the same
type symbol as that of its underlying type. Before, what I've now called
a `RefinementTypeRef` was transformed into a `RefinedType` during
rewrapping in the existential, which led to it being wrongly considered as
a lazy element of the base type sequence. The first change above should
also be sufficient to avoid the bug, but I felt it was worth cleaning up
`maybeRewrap` as an extra line of defence.
Finally, I have added another special case to `BaseTypeSeq#apply` to
be able to lazily compute elements that have been wrapped in an existential.
The unit test cases in `TypesTest` rely on these changes. A subsequent commit
will build on this foundation to make a fix to `asSeenFrom`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Usually, `contains` should not look into class symbol infos.
For instance, we expect that:
```
scala> trait C { def foo: Int }; typeOf[C].contains(IntClass)
defined trait C
res1: Boolean = false
```
We do, however, look at the decls of a `RefinedType` in contains:
```
scala> typeOf[{ def foo: Int }].contains(IntClass)
res2: Boolean = true
```
Things get a little vague, however, when we consider a type ref
to the refinement class symbol of a refined type.
```
scala> TypeRef(NoPrefix, typeOf[{ def foo: Int }].typeSymbol, Nil)
res3: $r.intp.global.Type = AnyRef{def foo: Int}
scala> .contains(IntClass)
res4: Boolean = false
```
These show up in the first element of the base type seq of a refined
type, e.g:
```
scala> typeOf[{ def foo: Int }].typeSymbol.tpe_*
res5: $r.intp.global.Type = AnyRef{def foo: Int}
scala> typeOf[{ def foo: Int }].baseTypeSeq(0).getClass
res7: Class[_ <: $r.intp.global.Type] = class scala.reflect.internal.Types$RefinementTypeRef
scala> typeOf[{ def foo: Int }].typeSymbol.tpe_*.getClass
res6: Class[_ <: $r.intp.global.Type] = class scala.reflect.internal.Types$RefinementTypeRef
```
This commit takes the opinion that a `RefinementTypeRef` should be
transparent with respect to `contains`. This paves the way for fixing
the base type sequences of existential types over refinement types.
The implementation of `ContainsCollector` was already calling
`normalize`, which goes from `RefinementTypeRef` to `RefinedType`.
This commit maps over the result, which looks in the parents and
decls.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Linux, the directory listing is not automatically sorted on Mac.
This leads to non-determistic ids of Symbols of the classes in a
directory, which in turn leads to instability of the ordering of
parents within inferred refinement types.
Notable, with this patch, we will stably infer:
```
scala> case class C(); case class D(); List(C(), D()).head
defined class C
defined class D
res0: Product with Serializable = C()
```
rather than sometimes getting `Serializable with Product` on
Linux. As such, I've removed the workarounds for this instability
in two test cases.
|
|\
| |
| | |
Fix typos in syntax
|
|/ |
|
|\
| |
| | |
SD-192 Change scheme for trait super accessors
|
| |
| |
| |
| |
| |
| | |
Rather than putting the code of a trait method body into a static method,
leave it in the default method. The static method (needed as the target
of the super calls) now uses `invokespecial` to exactly call that method.
|
|\ \
| | |
| | | |
SI-9847 Nuance pure expr statement warning
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Clarify the current warning, which means that an expression
split over multiple lines may not be parsed as naively expected.
When typing a block, attempt minor nuance. For instance, a
single expression is not in need of parens. Try to avoid
duplicate warnings for expressions that were adapted away
from result position.
|
|\ \ \
| |_|/
|/| | |
SD-182 compiler option -Xgen-mixin-forwarders
|
| | |
| | |
| | |
| | |
| | | |
Introduce a compiler option -Xgen-mixin-forwarders to always generate
mixin forwarder methods.
|
|\ \ \
| | | |
| | | | |
Improve log output of the `testAll` task
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We’ve seen several OOM failures in “run” tests lately. Maybe going back
to more separate partest calls will help. Now that everything is
launched from the same sbt instance and test results are always
accumulated, this should not have any negative impact on build
performance or usability.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It’s a lot of code for little benefit but makes the output more useful
when test tasks fail. Unfortunately there doesn’t seem to be any way to
get the `summary` reported by a test framework at this point. The
arguments of `toTask` for InputTasks with applied arguments have also
been lost, so we keep track of the commands separately.
|
|\ \ \ \
| | | | |
| | | | | |
Propagate overloaded function type to expected arg type
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Infer missing parameter types for function literals passed
to higher-order overloaded methods by deriving the
expected argument type from the function types in the
overloaded method type's argument types.
This eases the pain caused by methods becoming overloaded
because SAM types and function types are compatible,
which used to disable parameter type inference because
for overload resolution arguments are typed without
expected type, while typedFunction needs the expected
type to infer missing parameter types for function literals.
It also aligns us with dotty. The special case for
function literals seems reasonable, as it has precedent,
and it just enables the special case in typing function
literals (derive the param types from the expected type).
Since this does change type inference, you can opt out
using the Scala 2.11 source level.
Fix scala/scala-dev#157
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Fixes to Java source support in Scaladoc
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- fix initialization NPE in doc headers
- fix assertion errors for java fields
- ignore comments when deciding where to put interface methods
- consider DocDefs when checking for constructors
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
[Jakob Odersky <jodersky@gmail.com>: remove obsolete comments and fix tests]
|
|\ \ \ \ \ \
| |/ / / / /
|/| | | | | |
SD-128 fix override checks for default methods
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The check for inheriting two conflicting members was wrong for default
methods, leading to a missing error message.
We were also not issuing "needs `override' modifier" when overriding a
default method.
Removes two methods:
- `isDeferredOrJavaDefault` had a single use that is removed in this commit.
- `isDeferredNotJavaDefault` is redundant with `isDeferred`, because
no default method has the `DEFERRED` flag:
- For symbols originating in the classfile parser this was the case
from day one: default methods don't receive the `DEFERRED` flag.
Only abstract interface methods do, as they have the `JAVA_ACC_ABSTRACT`
flag in bytecode, which the classfile parser translates to `DEFERRED`.
- For symbols created by the Java source parser, we don't add the
`DEFERRED` to default methods anymore since 373db1e.
Fixes scala/scala-dev#128
|
|\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | | |
SD-20 Inlcude static methods in the InlineInfo in mixed compilation
Fixes scala/scala-dev#20
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In mixed compilation, the InlineInfo for a Java-defined class is created
using the class symbol (vs in separate compilation, where the info is
created by looking at the classfile and its methods). The scala compiler
puts static java methods into the companion symbol, and we forgot to
include them in the list of methods in the InlineInfo.
|
|\ \ \ \ \ \
| |_|/ / / /
|/| | | | | |
SD-193 Lock down lambda deserialization
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- Remove unused references to "addTargetMethods"
- Require that `targetMethodMap` is provided
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The old design allowed a forged `SerializedLambda` to be
deserialized into a lambda that could call any private method
in the host class.
This commit passes through the list of all lambda impl methods
to the bootstrap method and verifies that you are deserializing
one of these.
The new test case shows that a forged lambda can no longer call
the private method, and that the new encoding is okay with a large
number of lambdas in a file.
We already have method handle constants in the constant pool
to support the invokedynamic through LambdaMetafactory, so
the only additional cost will be referring to these in
the boostrap args for `LambdaDeserialize`, 2 bytes per lambda.
I checked this with an example:
https://gist.github.com/retronym/e343d211f7536d06f1fef4b499a0a177
Fixes SD-193
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-7838 Document the multi-threading semantics of List and Vector
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Making them completely thread-safe would be too expensive (in terms
of performance of single-threaded use cases).
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-8576 Minimal changes for `-Xcheckinit` compatibility
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
As explained in https://issues.scala-lang.org/browse/SI-8576, I expect
serialization compatibility between builds with and without
`-Xcheckinit` to be unattainable. This commit contains some minor fixes
for issues discovered while running builds with `-Xcheckinit`:
- Add `@SerialVersionUID` to `scala.collection.immutable.Vector`, as
requested in SI-8576. Note that this does not make `Vector`
serialization compatible.
- Use lazy initialization for `global` in `PresentationCompilation`. It
used to access the uninitialized `self` variable (which seems to be
inconsequential in practice and only fails under `-Xcheckinit`).
We should consider using `Externalizable` instead of `Serializable` for
collections in 2.13 to make collection classes serialization compatible.
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
SI-8434 Make generic Set operations build the same kind of Set
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
When building from a `Set` implementation that was statically seen as
a `collection.GenSet` or `collection.Set`, we used to build a default
`Set` implementation determined by `GenSetFactory.setCanBuildFrom`.
This change modifies `setCanBuildFrom` to determine the correct
implementation at runtime by asking the source `Set`’s companion object
for the `Builder`.
Tests are in `NewBuilderTest.mapPreservesCollectionType`, including lots
of disabled tests for which I believe there is no solution under the
current collection library design.
`Map` suffers from the same problem as `Set`. This *can* be fixed in the
same way as for `Set` with some non-trivial changes (see the note in
`NewBuilderTest`), so it is probably best left for Scala 2.13.
|
|\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
SI-9019 TraversableLike stringPrefix broken for inner classes
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
This version preserves outer class and object names but discards
any part of the name after a `$` that does not start with an upper-case
letter. When an integer literal occurs after a `$`, the prefix up to
that point is dropped so that classes defined within methods appear as
top-level.
|
|\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | | |
SI-6881 Detect reference equality when comparing streams
|
| |/ / / / / / / / /
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
`==` already covers this case. We override `equals` in `Stream` to do
the same when `equals` is called directly. This takes care of identical
streams.
To support short-circuiting equality checks on elements prepended to
identical streams we also override `sameElements` in `Cons` to treat
the case where both sides are `Cons` separately.
Tests in StreamTest.test_reference_equality.
|
|\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | | |
SI-9585 hide auto-implicit conversions from scaladoc
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
This hides implicits conversions (and potential members obtained through
it) that converts a type into itself, because these conversions are
usually non-sensical. They are not completely removed, just placed behind
`-doc-implicits-show-all`, like other implicits deemed probably useless.
---
Consider the scaladoc for the following class:
```
object Box {
implicit def anyToBox[T](t: T): Box[T] = new Box(t)
}
class Box[T](val t: T)
```
When looking for implicits members to add to class `Box`, it finds the
implicit conversion `anyToBox`, and applies it to itself to have an
implicit conversion to Box[Box[T]], which brings a useless implicit
member `t: Box[T]`.
This commit makes scaladoc ignore any conversion from a type to itself
(even if type parameters differ) by default.
Using the (very useful) `tools/scaladoc-diff` script, I found that this
change removes the following conversion from the library doc:
```
Ensuring[A] to Ensuring[Ensuring[A]]
anytostringadd[A] to any2stringadd[anytostringadd[A]]
ArrowAssoc[A] to ArrowAssoc[ArrowAssoc[A]]
=:=[From,To] to =:=[From,To]
SearchImpl[A,Repr] to SearchImpl[A,SearchImpl[A,Repr]]
CollectionsHaveToParArray[C, T] to CollectionsHaveToParArray[CollectionsHaveToParArray[C, T], T]
Ordered[A] to Ordered[Ordered[A]]
StringFormat[A] to StringFormat[StringFormat[A]]
```
|
|\ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | |
| | | | | | | | | | | | |
SI-8339 remove deprecated rewrite of withFilter -> filter
|
| | |_|_|_|_|_|_|/ / /
| |/| | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
You must implement the `withFilter` method to use
`if`-guards in a `for`-comprehension.
(Drop pos/t7239.scala because it relied on this rewrite.)
|
|\ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | |
| | | | | | | | | | | | |
Introducing: the fields phase [ci: last-only]
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
No longer making trait methods not-protected.
(The backend only does public/private because of the poor
mapping between visibility from Scala to the JVM).
Note that protected trait members will not receive static forwarders
in module classes (when mixed into objects).
Historic note: we used to `makeNotPrivate` during explicitouter,
now we do it later, which means more private methods must be excluded
(e.g., lambdaLIFTED ones).
|