| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The AnyVal types become source files instead of polite 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.
|
| |
|
|
|
|
|
| |
The empty string commit made me hungry to actually know what's in stuff.
Now it prints quotes around a string if it's empty or if either the
first or last character is whitespace. No review.
|
| |
|
|
|
|
| |
Defer a check from the typer to refcheck so the error message makes some
sense. Closes #4174, review by rytz.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Integrated contributed non-recursive implementation of permutations,
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.
|
| |
|
|
|
|
| |
Look even harder for attempts to sneak "this" into superconstructor
arguments, and improve positioning. Closes #4166, no review.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
What is, I think, the only possible solution to bug #4158 given the
current ways of controlling implicits. Let's just be glad there's one
instead of zero. Closes #4158, review by moors.
|
| |
|
|
|
|
| |
Allow box(unbox) elimination for the Null type, plus testing that
specialization tests do not box too much. review by extempore.
|
| | |
|
| | |
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
|
|
| |
Added jdk1.5 version of the instrumented library classes jar.
No review.
|
| |
|
|
|
|
|
|
| |
Added specialized test to ant build, and ported old specialized 'run'
tests to check the number of boxings.
No review.
|
| |
|
|
|
|
|
| |
Adapted specialization tests to track number of boxings.
Review by dragos
|
| |
|
|
|
|
|
|
|
|
| |
Added a new test group - specialized.
Modified partest to add a jar with instrumented classes to classpath when compiling and running tests.
Added a primary version of the instrumented BoxesRuntime, and a script to produce a jar for it.
Added the 'speclib' folder to partest files, which contains the jar with the instrumented classes.
Review by dragos.
|
| |
|
|
|
|
|
| |
This outlaws explicit isInstanceOf tests on value types, which are
nonsense in any case, as long threatened in ticket #1872. Closes #1872,
review by rytz.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a primitive CONCAT and several opcodes, I'm assuming nobody will
oppose this on principle. Given an expression of the exact form "" + x
(that is, the NPE-immune and much less ugly way to call .toString) we
used to get 4x the bytecode and create an unneeded StringBuilder. Now
this:
0: aload_1
1: invokestatic #20; //Method java/lang/String.valueOf:(Ljava/lang/Object;)Ljava/lang/String;
4: areturn
Closes #4160, review by dragos.
|
| |
|
|
|
|
| |
Deleted duplicate test which must have been a real monkey wrench. No
review.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
prejudice and puts the new process code to work instead. There are still
a couple bugs on my short term partest list. If this commit causes some
weird issue which only arises on virtualized windows you can expect to
hear from me next by postcard from st. lucia. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Imported sbt.Process into trunk, in the guise of package
scala.sys.process. It is largely indistinguishable from the version in
sbt, at least from the outside.
Also, I renamed package system to sys. I wanted to do that from the
beginning and the desire has only grown since then. Sometimes a short
identifier is just critical to usability: with a function like error("")
called from hundreds of places, the difference between system.error and
sys.error is too big. sys.error and sys.exit have good vibes (at least
as good as the vibes can be for functions which error and exit.)
Note: this is just the first cut. I need to check this in to finish
fixing partest. I will be going over it with a comb and writing
documentation which will leave you enchanted, as well as removing other
bits which are now redundant or inferior. No review.
|
| |
|
|
|
|
|
|
| |
In r22807 an optimization was added to remove Box(Unbox(x))
combinations. It turns out that without this in place, an expression
like "x".asInstanceOf[Int] will no longer throw an exception. Refined
the optimization. Closes #4148, review by dragos.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
| |
No review.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A pretty severe bug in the recognition of tail call elimination.
It turns out that Tailcalls will perform "partial elimination" in
situations such as:
@annotation.tailrec final def f(x: Int): Int = f(f(x))
The outer call to f1 becomes a jump, but the inner call remains as
it was. I implemented @tailrec under the impression that if the
optimization had taken place, it had gone all the way. So this is now
fixed with a direct examination of the rewritten tree.
While I was in there I threw in some improved error reporting: the error
positioning is now on the call which is not in tail position rather than
the method declaration.
Closes #4135, no review.
|
| |
|
|
|
|
|
|
|
|
|
| |
scala> implicitly[CanBuildFrom[String, Int, List[List[Int]]]]
<console>:10: error: Cannot construct a collection of type
List[List[Int]] with elements of type Int based on a collection of type
List[List[Int]]. implicitly[CanBuildFrom[String, Int, List[List[Int]]]]
^
No review.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Closes #3984 by the most arduous and indirect route imaginable:
abstracts the common code out of the TrieIterators in HashMap and
HashSet. When I raised this flag to find out if anyone would open
fire, all was quiet on the western front. Although I wouldn't want
to write code like this as an everyday thing, I think it serves as a
nice showcase for some of the abstraction challenges we're up against:
performance looks the same and I will never again have to fix the same
bug in two places. Review by rompf.
|
| |
|
|
|
|
| |
Reverting fix for #4047 until I figure out why it is failing on chara
and not on my machine. 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
def isRootOrEmptyPackageClass(s: Symbol) = s.isRoot || s.isEmptyPackageClass
def isRootOrEmpty = (this == EmptyPackageClass) || (this == RootClass)
def isEffectiveRoot = isRoot || isEmptyPackageClass
// last one actually not quite identical
def isUnqualified(n: Name) = n match { case nme.ROOT | nme.EMPTY_PACKAGE_NAME => true ; case _ => false }
I was responsible for at least half of these. Now it's only
isEffectiveRoot.
Also, I have always found it warty that we have to specify Nothing
and Any as upper bounds. I gave the TypeBounds companion object a few
obvious methods:
def empty: TypeBounds = apply(NothingClass.tpe, AnyClass.tpe)
def upper(hi: Type): TypeBounds = apply(NothingClass.tpe, hi)
def lower(lo: Type): TypeBounds = apply(lo, AnyClass.tpe)
It's a lovable patch. No review.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
No review
|
| |
|
|
|
|
|
|
| |
Implemented a (slower) workaround for parallel vectors. Implemented
group by.
No review.
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently my flailing attempts to make things faster earned me the
pity of Tiark, who sent this monster patch which he probably dashed
off before the appetizers had been cleared away. All the steak is his
but I threw in a little sizzle so I could feel like a part of things.
It knocks about a bazillion miniseconds off the time spent in implicit
search.
This is the same patch martin already endorsed, give or take several
hundred lines of diff, so I will say no review, even though I know it
will be hard to look away. I trimmed most of the "speculative code"
(that is, the commented out bits) because it's getting awfully busy
along those sidelines. I will preserve the ideas in some more structured
form.
|
