| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
Prevent a divergent implicit from terminating implicit search, so that
there can still be a winner, as endorsed by martin over a cheese plate.
Closes #3883, review by dmharrah.
|
| |
|
|
|
| |
extempore. References #4305, no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Removed long deprecated and obscure CloneableCollection. Discovered
we have a scala.collection.mutable.Cloneable which does not extend
java.lang.Cloneable, which is why Array is not considered cloneable.
That seems wrong, but to be conservative I gave Array the Cloneable
interface without altering the scala trait.
Also, if @serializable is deprecated in favor of Serializable,
should not @cloneable be deprecated analogously? Closes #4307, and a
commit-question review by rytz.
|
| |
|
|
|
|
|
| |
infix implicits to Integral and Fractional. As a bonus this patch
knocked 10,000 long boxings off a specialized test. Who knew. Closes
#4308, #4321, review by community.
|
| |
|
|
|
| |
Reenabled the commented out bits of the test for #1642. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Leveraged having a place to put some useful implicits which we sensibly
are reluctant to introduce in the default scope. The test case pretty
much sums it up.
import Ordering.Implicits._
import Numeric.Implicits._
def f1[T: Numeric](x: T, y: T, z: T) = x + y + z
def f2[T: Ordering](x: T, y: T, z: T) = if (x < y) (z > y) else (x < z)
No review.
|
| |
|
|
|
|
| |
One last build break and unbreak so I can be fondly remembered as that
guy who kept breaking the build. No review.
|
| |
|
|
|
|
|
| |
More signature fixes and tests and generally being more sophisticated
about our primitive squashing. These signatures belong in world-class
museums but we are their shepherds for now. Closes #4317, no review.
|
| |
|
|
|
|
|
|
| |
Another corner involving generic signatures and java interop flushed out
by seth tisue. Keep that detector fired up seth or the rebel alliance
will surely be crushed. (In fact, I nominate you to write a test suite!)
Closes #4317, no review.
|
| |
|
|
|
|
| |
Closes #4202 and removes empty TreeHashMap (superseded by HashMap
implementation). No review
|
| | |
|
| |
|
|
|
|
|
|
| |
Fixed a bug where newly introduced type parameters didn't have all the
substitutions done correctly. Fixes #4266.
No review.
|
| |
|
|
|
|
|
|
| |
Observed that some historical issues with package objects no longer seem
so issuey. In the interests of keeping the arbitrary limitations to a
minimum, re-enabled case classes in package objects (see #2130, #3437.)
Closes #3437, review by odersky.
|
| | |
|
| | |
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
| |
No review.
|
| | |
|
| |
|
|
|
|
|
|
| |
It seems to arise from the changes to inner objects which make them look
like lazy vals. I am not sure this is the right change but at least
it's only about a six character diff to review. Closes #4188, review by
odersky.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Is this symbol defined in the same scope
and compilation unit as `that' symbol?
But "same scope" was never checked, only "same compilation unit."
Presumably other layers of logic kept this from being noticed until now,
but it has been crashing sbt. Added check to isCoDefinedWith. Closes
#4220, review by odersky.
|
| |
|
|
|
|
| |
Re-enabled test spec-traits (removed the swing dependent part, since all
it tested was call-by-name parameters). no review.
|
| |
|
|
|
|
|
|
| |
I found more situations where primitive types were appearing in
signatures. I hacked in a flag which says boxing is or is not allowed.
The code is getting hideous: foortunately I have it mostly rewritten,
but I wanted to fix this bug now. No review.
|
| |
|
|
|
|
| |
Fixed some generic signature bugs I found thanks to the compiler telling
me it was buggy. Thanks compiler. No review.
|
| |
|
|
|
|
| |
Conflicts:
src/library/scala/concurrent/SyncVar.scala
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
closes #2741, #4079: pickling now ensures that a local type param with
a non-local owner, which will thus get a localized owner, will only get
a class as its localized owner if its old owner was a class (otherwise,
NoSymbol) this ensures that asSeenFrom does not treat typerefs to this
symbol differently after pickling.
todo: should we pro-actively set the owner of these type params to
something else than the type alias that they originate from? see notes
in typeFunAnon
review by odersky
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
introduce NullaryMethodType to disambiguate PolyType
motivation:
given `def foo[T]: (T, T)` and `type Foo[T] = (T, T)`,
`foo.info` and `TypeRef(_, Foo, Nil).normalize` are both
`PolyType(List(T), Pair[T, T])`
uncurry has been relying on an ugly hack to distinguish these
cases based on ad-hoc kind inference without this distinction,
the type alias's info (a type function) would be transformed to
`PolyType(List(T), MethodType(Nil, Pair[T, T]))`
anonymous type functions are being used more often (see #2741, #4017,
#4079, #3443, #3106), which makes a proper treatment of PolyTypes more
pressing
change to type representation:
PolyType(Nil, tp) -> NullaryMethodType(tp)
PolyType(tps, tp) -> PolyType(tps, NullaryMethodType(tp)) (if the polytype denoted a polymorphic nullary method)
PolyType(Nil, tp) is now invalid
the kind of a PolyType is * iff its resulttype is a NullaryMethodType or a MethodType (i.e., it's a polymorphic value)
in all other cases a PolyType now denotes a type constructor
NullaryMethodType is eliminated during uncurry
pickling:
for backwards compatibility, a NullaryMethodType(tp) is still pickled as a PolyType(Nil, tp),
unpickling rewrites pre-2.9-pickled PolyTypes according to the expected kind of the unpickled type (similar to what we used to do in uncurry)
a pickled PolyType(Nil, restpe) is unpickled to NullaryMethodType(restpe)
a pickled PolyType(tps, restpe) is unpickled to PolyType(tps, NullaryMethodType(restpe)) when the type is expected to have kind *
the rewrite probably isn't complete, but was validated by compiling
against the old scalacheck jar (which has plenty of polymorphic nullary
methods) nevertheless, this commit includes a new scalacheck jar
summary of the refactoring:
* PolyType(List(), tp) or PolyType(Nil, tp) or PolyType(parms, tp) if params.isEmpty ==> NullaryMethodType(tp)
* whenever there was a case PolyType(tps, tp) (irrespective of tps isEmpty), now need to consider the
case PolyType(tps, NullaryMethodType(tp)); just add a case NullaryMethodType(tp), since usually:
- there already is a PolyType case that recurses on the result type,
- the polytype case applied to empty and non-empty type parameter lists alike
* tp.resultType, where tp was assumed to be a PolyType that represents a polymorphic nullary method type
before, tp == PolyType(tps, res), now tp == PolyType(tps, NullaryMethodType(res))
* got bitten again (last time was dependent-method types refactoring)
by a TypeMap not being the identity when dropNonConstraintAnnotations
is true (despite having an identity apply method). Since asSeenFrom
is skipped when isTrivial, the annotations aren't dropped. The
cps plugin relies on asSeenFrom dropping these annotations for
trivial types though. Therefore, NullaryMethodType pretends to
never be trivial. Better fix(?) in AsSeenFromMap: `if(tp.isTrivial)
dropNonContraintAnnotations(tp) else ...`
TODO: scalap and eclipse
review by odersky, rytz
|
| | |
|
| |
|
|
|
|
|
|
| |
Some modifications to @elidable: for reasons lost to me now it had a
default value such that annotated methods might be elided even if the
option wasn't given. It now does nothing in that situation. Closes
#4051, #4151, no review.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
I had closed #2441 as a duplicate of that, but unfortunately #4114 did
not bring #2441 along with it. Then I realized I'm a programmer, not a
helpless trac watcher. As is often the case with thes things, fixing
that revealed a bug in the library. Closes #2441 for real, review by
odersky.
|
| | |
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
|
|
|
|
| |
Override checks and self-types still needed some work (ticket #2808.)
I believe this is the right change. The modifications in parallel and
actors were a result of the files failing to compile after the change to
allOverriddenSymbols. (I am taking the position that that aspect is a
feature.) Review by malayeri, odersky.
|
| | |
|
| |
|
|
|
| |
small, very focused taste of Ordering contravariance. No review.
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
|
| |
again: relax access boundry check for overriding protected java members.
review by eugenevigdorchik.
|
| | |
|
| |
|
|
|
| |
This reverts commit 99652fe553a1a5b0c551950e8178e867943a088f.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TermName and TypeName are exposed throughout the compiler based on what
kind of name a given abstraction ought to have. (There remain places
where one needs to create a name without knowing yet what it will be,
and those will always be Names.)
The nme object in the compiler now holds only term names. To reference a
known type name, use tpnme:
nme.List == ("List": TermName)
tpnme.List == ("List": TypeName)
The contents of nme and tpname are defined in traits, many of which
are shared, so if a name should exist only as a Type and not a
Term, it should be defined in CompilerTypeNames, but otherwise in
CompilerTermNames or CompilerCommonNames. This is partially complete but
I'm sure there are still many shared which should pick a side.
Usage of .toTermName and .toTypeName is strongly discouraged. After the
dust has settled, there will be very few places where it will make sense
to hop between namespaces like that.
There are some implicits to smooth everything out, most of which should
be removable eventually.
// these two are in no hurry to go anywhere
String => TermName
String => TypeName
// but not String => Name: def view in the compiler is no longer implicit
// these two are temporary, and can log when they kick off to help us
flush // out remaining issues of "name migration" Name => TermName
Name => TypeName
There is more work to be done before we're properly protected from
naming errors, but I will not allow another eight hour tragedy to befall
lukas or anyone else!
Review by rytz. (Formality.)
|
