| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
on pattern matching for updating the tree.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
already does so).
|
|
|
|
|
| |
Use ArrayStack instead of Stack in TreeIterator for slightly increased
performance.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
type parameter A.
|
| |
|
| |
|
|
|
|
|
| |
changes the operation from O(n log n) to O(n) and allows for more
structural sharing.
|
|
|
|
|
|
| |
TreeMap/TreeSet by splitting the underlying RedBlack tree. This
makes the operation O(log n) instead of O(n) and allows more
structural sharing.
|
|
|
|
|
| |
to ensure TreeSet/TreeMap 'range' operations are O(log n) instead
of O(n).
|
| |
|
|
|
|
| |
TreeMap/TreeSet.
|
|
|
|
| |
performance is much better than '++' based iterator.
|
|
|
|
|
|
|
| |
This turns iterator creation from an O(n) operation into an
O(log n) operation. Unfortunately, it halves actual iteration
speed (consuming the iterator fully), probably due to the many
by-name closures that are needed.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The parser through I think a quirk of history would not allow
back to back type applications, like
expr[T1, T2][T3, T4]
Now it does, meaning the only thing it can:
val n0 = Partial[immutable.HashMap][String][Int] ++ Seq(("a", 1))
val n1 = Partial.apply[immutable.HashMap].apply[String].apply[Int] ++ Seq(("a", 1))
assert(n0 == n1)
|
| | | |
| \ | |
| \ | |
| \ | |
| \ | |
| \ | |
| \ | |
| \ | |
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
'kepler/topic/reifyclosuretests', 'kepler/topic/antscalacheck', 'szabolcsberecz/SI-5104', 'kepler/ticket/5334' and 'kepler/topic/miscfixes' into develop
|
| | | | | | | |
|
| | | | |/ / |
|
| | | |/ /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The bug was caused by the inconsistency between j.l.Math.min() and
j.l.Double.compareTo() wrt NaN (j.l.Math.min() considers NaN to be
less than any other value while j.l.Double.compareTo() says it's
greater...)
The fix changes Ordering.{FloatOrdering,DoubleOrdering) to base
it's results on primitive comparisons and math.{min,max} instead
of j.l.{Float,Double}.compareTo()
|
| | | | | |
|
| | |_|/
| |/| | |
|
|/ / /
| | |
| | |
| | | |
during iteration.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Changing NullaryMethodType to be a SimpleTypeProxy because nearly all
its operations forward to its result type was it seems not such a good
idea, because it also meant that calling .underlying returned the result
type rather than the method type. The way this materialized was in
subtype checks of refinement types. A lub is calculated for two nullary
method types in the course of calculating a refinement, and then the
input types are checked against the calculated lub.
However in the lub refinement, the nullary method type has become a bare
typeref, and so the subtype check failed. Closes SI-5317.
This does give me confidence that all the malformed lubs one sees
logged under -Ydebug (and there are still many, especially with type
constructors) are alerting us to real bugs elsewhere in Types.
|
|\ \ \
| |/ /
|/| | |
Addresses a bug in SimpleDateFormatter
|
| |/ |
|
| |
| |
| |
| |
| |
| | |
Working on reducing the now significant amount of both
garbage and retained but duplicated Strings taking place
as Names become Strings and vice versa. Long way to go.
|
| |
| |
| |
| | |
Avoid creating empty array when len == 0.
|
|\ \ |
|
| |\ \
| | | |
| | | |
| | | | |
Improvements to reification and resetAttrs
|
| | | |
| | | |
| | | |
| | | | |
locally erased symbols.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
typecheck error
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
made lambdalift complaint more useful
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1) introduce BodyTreeMaker to get rid of special casing for body
now each case is a list of TreeMakers rather than a pair of such a list and a tree
needed to do this since emitting switches requires access to the untranslated body
2) emitting switches
- alternatives are flattened: each alternative block ends with a jump to the next alternative (if there is one)
- to avoid stack overflow in typedMatch: detect when translateMatch returns a Match
the patch to uncurry would be nicer with an extractor, but that breaks due to a bug in old patmat
made trees into dags again -- NPE in erasure
tree.duplicate seems to break lambdalift because it
does not give fresh symbols (or trees?) to the valdefs
for the arguments of duplicated functions
duplicate enclosing tree, not subtrees
improved propagateSubstitution for AlternativesTreeMaker
- it now propagates to all its alternatives, so we don't have to do that in chainBefore
- by making propagation more regular, a bug in substitution in AlternativesTreeMaker manifested itself
it introduced a new binder, unnecessarily, which then was unbound -- now reusing binder of outer pattern
having removeSubstOnly in propagateSubstitution unveiled a bug: guard treemaker should substitute
move fixerUpper closer to what it fixes up
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
factored out some of the optimizing codegen that had snuck into treemakers (guardtreemaker)
removed `caseResult`, back to just `one`
no longer emitting intermediate `one`s (using guard instead -- when not optimizing)
so uncurry can't accidentally blow them away (it removes the `one` that represents the case's result,
but should leave intermediate computation alone)
still TODO: reusing-treemakers
sharing prefixes of length 1 helps
inlining suffix of alternatives if small enough
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
TreeMakers (esp. CondTreeMakers) are approximated by hash-cons'ed Conds
sharing is detected for prefixes of Conds, and shared conditions are only tested once
their results are stored, and repeated tests branch on the last shared condition,
reusing the results from the first time they were checked
a Test is 1-to-1 with a TreeMaker, but may share its Cond
TODO: clean separation of the two translation strategies:
- naive flatMap/orElse (for virtualization)
- less-naive if-then-else (with CSE etc coming)
sharing trees caused wrong bytecode to be emitted (verifyerror)
tentative explanation:
"because lambdalift uses mutable state to track which variables have been captured
if you refer to the same variable with the same tree twice
it'll get confused"
Sent at 8:27 PM on Thursday
>> grzegorz.kossakowski: so we found a bug in jvm
according to http://java.sun.com/docs/books/jvms/second_edition/html/Instructions2.doc2.html
checkcast should throw a classcastexception
becuase it's a shorthand for if !(x instanceof T) throw ClassCastExcpt
but jvm decided to throw verifyerror
and yeah, the check is wrong
if jvm was not throwing verifyerror it would throw classcast exception
saying that ObjectRef cannot be casted to $colon$colon
...
>> me:
so now where does it come from?
since a ref is involved, i thought LambdaLift
>> grzegorz.kossakowski: yup
or now
I don't think lambalift introduces that kind of low-level casts
but I might be wrong
btw. it's interesting that it unpacks stuff from objectref twice
in your code
and in one place checkcast is correct
and in another is wrong
Sent at 9:33 PM on Thursday
>> grzegorz.kossakowski: also, since it's a verifyerror
I think genjvm should have an assertion
>> grzegorz.kossakowski:
193: getfield #54; //Field scala/runtime/ObjectRef.elem:Ljava/lang/Object;
196: checkcast #8; //class scala/runtime/ObjectRef
199: invokevirtual #95; //Method scala/collection/immutable/$colon$colon.tl$1:()Lscala/collection/immutable/List;
it's this
see
you have checkcast for ObjectRef
and then on that value, you try to call tl() method from List
Sent at 9:56 PM on Thursday
>> me: fixed
sharing trees is bad
very bad
because lambdalift uses mutable state to track which variables have been captured
if you refer to the same variable with the same tree twice
it'll get confused
|