compiler fictions.
!! You'll need a serious "ant all.clean" now. !!
As of this commit the system is fully bootstrapped and the
synthetic code eliminated: only the source files remain.
The sort-of-AnyVal-companions in scala.runtime.* have all
been eliminated because the actual companions can do everything;
deprecated vals in the scala.runtime package object point to
the companions. This left AnyValCompanion as the only AnyVal
related thing in the runtime package: that made little sense,
so I deprecated and moved it as well.
Starr is based on r24066 plus this commit. Closes#4121.
Review by rytz, odersky.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@24068 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
genprod get any more creaky. This code generates the AnyVal
source files (but those are not included here.) No review.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@24066 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
Closes#4067.
Numbers 1-72:
Problem: Primitive types appearing in generic bounds.
Response: Use the boxed types.
Numbers 73-105:
Problem: Doubly nested classes can become Outer<T>.Inner.Inner2
Response: Don't allow dots except immediately following angle brackets.
Number 106:
Problem: Array may be being used as a higher kinded type,
and in such cases should not receive the special Array treatment.
Solution: args.nonEmpty
Observe my claim is that 106/106 signatures have been made
"valid", not "correct" or even "more nearly correct." As to that
I would like a second opinion. And.... review by moors!
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@24063 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
at https://bugs.eclipse.org/bugs/show_bug.cgi?id=332423 I have
turned on generic signature validation for all builds and when
an invalid signature is encountered I suppress it completely.
The -Yverify-generics option still exists, but now it only means
to echo a message for every bad signature.
It would obviously be better not to generate them in the first
place, but we should never be generating broken bytecode like
this. Review by odersky.
I transitioned the jline build from maven to sbt, and this commit
includes the first sbt-built binary. Review by jsuereth.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@24055 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
stuff. Now it prints quotes around a string if it's empty or if either
the first or last character is whitespace. No review.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@24048 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
combinations, subsets, by EastSun. Also gave mutable Seqs an
in-place transform method like the one Map has. And couldn't
resist slightly reformulating a few set methods, because how can we
settle for "forall(that.contains)" when we could have "this forall that".
(Which is also what normal people hear when we talk about sets.)
Closes#4060, #3644, review by moors.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@24042 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
This after being misled one too many times by a variation of this:
scala> List[String]()
res1: List[String] = List()
scala> List[String]("")
res2: List[String] = List()
No review.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@24041 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
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
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@24029 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
git backwaters. I think he is still working with the main code pieces
but I didn't want to lose a couple comments/clarifications. No review.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@24020 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
dragos