| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
Suppresses specialization on a per-method basis.
I would have preferred to call it @nospecialize, but seeing as the
positive form of the annotation is @specialized, that would have sown
unnecessary grammatical confusion. @nospecialized sounds a bit too
caveman for my tastes. "Grog no specialized! Grog generic!"
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The crickets at http://www.scala-lang.org/node/11901 were in
unanimous agreement that I should proceed as suggested.
- No arguments to @specialize gets you 10/10, not 9/10
- Fixed bugs in AnyRef specialization revealed by trying to use it
- Specialized Function1 on AnyRef.
- Changed AnyRef specialization to use OBJECT_TAG, not TVAR_TAG.
- Deprecated SpecializableCompanion in favor of Specializable,
which has the virtue of being public so it can be referenced
from outside the library.
- Cooked up mechanism to group specializable types so we don't
have to repeat ourselves quite so much, and create a few groups
for illustrative purposes. I'm not too serious about those names
but I used up all my name-thinking-up brain for the day.
- Updated genprod and friends since I had to regenerate Function1.
- Put tests for a bunch of remaining specialization bugs in pending.
Closes SI-4740, SI-4770, SI-5267.
|
| |
|
|
|
|
|
| |
Removing the code which has been deprecated since 2.8.0. Contributed by
Simon Ochsenreither, although deleting code is such fun one hesitates to
call it a contribution. Still, we will. Closes SI-4860, no review.
|
| |
|
|
|
|
|
| |
Various addenda to soc's patch: regenerating Product/Tuple/Function
classes and AnyVal sources, making versioning consistent, etc. Closes
#4477, no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Moved unlift to the Function companion object, which might have been
better in the first place. Had to make a minor change to genprod, and
then I couldn't escape that unscathed. Finished the not very complete
undertaking I found there to update the scaladoc. Lots of little changes
to the generated text and code.
I changed genprod to only put a unique stamp on Function0 so we can stop
having a 100 file diff everytime an i is dotted somewhere.
Closes #3825, no review.
|
| | |
|
| |
|
|
|
|
|
| |
Documentation being generated by genprod was pretty busted both in terms
of formatting and correctness. Spruced it up. Eliminated some of the
more distracting HTML entities in compiler source. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An overhaul of the collection-oriented methods in Tuple2/Tuple3 (which
still need to be taken all the way to Tuple5.)
* Zip semantics: zip and zipped now properly terminate when any
collection runs out of elements, even if others are infinite. In
addition, short circuiting methods (exists and forall) will terminate if
the condition is met, even in the presence of infinity.
Example:
scala> val ys = Stream from 1
ys: scala.collection.immutable.Stream[Int] = Stream(1, ?)
scala> (ys, ys).zipped forall ((x, y) => x+y < 100)
res0: Boolean = false
scala> (ys, ys).zipped exists ((x, y) => x+y > 100)
res1: Boolean = true
* There are implicits converting Zipped2/3 to Traversable to expose all
the methods which aren't defined in an arity-specific way in the tuple
classes. I have mixed feelings about putting these in Predef; but if
there is another way to make them visible by default I wasn't able to
find it.
Example putting said implicit to use:
scala> (ys, ys, ys).zipped find { case (x, y, z) => x+y+z > 1000 }
res0: Option[(Int, Int, Int)] = Some((334,334,334))
Already reviewed by moors, so no review.
|
| |
|
|
|
|
|
| |
Proposed implementation of 'unlift' on Function1, the inverse function
of PartialFunction#lift. Review by rytz and other interested parties.
References #3825, but not closing until this is further considered.
|
| |
|
|
|
| |
Removed more than 3400 svn '$Id' keywords and related junk.
|
| |
|
|
|
|
|
| |
to properly specialize on primitive types (scala.Int, instead of
scala.runtime.Int). Now closures should be indeed specialized. No
review.
|
| |
|
|
|
|
|
|
| |
Regenerated tuples, products and (Abstract)Functions. We needed to have
separate files for AbstractFunctionN because the compiler may need their
symbol even before their sourcefile is parsed. In such cases it relies
on finding a source file with the right name.
|
| |
|
|
|
|
|
| |
Adjectified some parts of speech as discussed on the mailing list. The
methods to call on FunctionN are "curried" and "tupled" with "curry"
deprecated and "tuple" gone. Closes #2907. Review by community.
|
| | |
|
| |
|
|
|
|
| |
Built out genprod to create a tuple method for reach function alongside
its curry method. Generated new FunctionNs.
|
| |
|
|
|
|
| |
Newly generated Tuple/Product/Function classes from new genprod, plus a
couple minor tweaks to genprod to keep tests happy.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
FunctionN, where N > 4, many fewer classes are created statically at the
expense of creating more objects dynamically (which seems reasonable
given how common such functions are likely to be). This also allows for
curry in FunctionN for N > 8 without running into the filename length
restriction.
|
| | |
|
| |
|
|
|
| |
No curry for you! (If you are FunctionN, for N < 2 and N > 16)
|
| |
|
|
|
| |
Generalized curry to FunctionN for N >= 2
|
| |
|
|
|
| |
Added uncurry to Function2, swap to Tuple2.
|
| | |
|
| |
|
