Re-enable RedBlack's ScalaCheck test, which was disabled at r21829. #8
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I haven't been able to find any reason for that reversal, but this version is an improved version provided with SI-3796, which never got committed along with the patch. This version generates trees directly instead of using the methods under test. It also puts an upper bound on tree size and, therefore, execution time.
adriaanm
referenced
this pull request
in adriaanm/scala
Dec 24, 2011
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 scala#54; //Field scala/runtime/ObjectRef.elem:Ljava/lang/Object; 196: checkcast #8; //class scala/runtime/ObjectRef 199: invokevirtual scala#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
odersky
added a commit
to odersky/scala
that referenced
this pull request
Jul 14, 2012
Only consider DEFERRED members in 2nd pass.
adriaanm
referenced
this pull request
in adriaanm/scala
Jul 14, 2012
Only consider DEFERRED members in 2nd pass.
retronym
referenced
this pull request
in retronym/scala
Jun 26, 2013
Swathes of important logic are duplicated between `findMember`
and `findMembers` after this run of optimization.
d905558 Variation #10 to optimze findMember
fcb0c01 Attempt #9 to opimize findMember.
71d2ceb Attempt #8 to opimize findMember.
77e5692 Attempty #7 to optimize findMember
275115e Fixing problem that caused fingerprints to fail in reflection. Also fixed test case that failed when moving to findMember
e94252e Attemmpt #6 to optimize findMember
73e61b8 Attempt #5 to optimize findMember.
04f0b65 Attempt #4 to optimize findMember
0e3c70f Attempt #3 to optimize findMember
41f4497 Attempt #2 to optimize findMember
1a73aa0 Attempt #1 to optimize findMember
This commit updates `findMembers` with the bug fixes that `findMember`
has received, and adds flashing warning signs for future maintainers.
A followup commit will address the duplication at the root.
retronym
referenced
this pull request
in retronym/scala
Jan 29, 2014
Exclude them from superclasses in `findMember` and in `OverridingPairs`. The odd logic in `findMember` that considered whether the selector class was owned by the owner of the candidate private symbol dates back to 2007 (bff4268), but does not appear to have any relationship to the spec. Refinement types are still able to inherit private members from all direct parents, as was needed in pos/t2399.scala. More tests are included for this scenario. In short, the logic now: - includes direct parents of refinements, - otherwise, excludes privates after the first class in the base class sequence TODO: Swathes of important logic are duplicated between `findMember` and `findMembers` after this run of optimization. d905558 Variation #10 to optimze findMember fcb0c01 Attempt #9 to opimize findMember. 71d2ceb Attempt #8 to opimize findMember. 77e5692 Attempty #7 to optimize findMember 275115e Fixing problem that caused fingerprints to fail in reflection. Als e94252e Attemmpt #6 to optimize findMember 73e61b8 Attempt #5 to optimize findMember. 04f0b65 Attempt #4 to optimize findMember 0e3c70f Attempt #3 to optimize findMember 41f4497 Attempt #2 to optimize findMember 1a73aa0 Attempt #1 to optimize findMember
retronym
referenced
this pull request
in retronym/scala
Jan 31, 2014
Swathes of important logic are duplicated between `findMember`
and `findMembers` after they separated on grounds of irreconcilable
differences about how fast they should run:
d905558 Variation #10 to optimze findMember
fcb0c01 Attempt #9 to opimize findMember.
71d2ceb Attempt #8 to opimize findMember.
77e5692 Attempty #7 to optimize findMember
275115e Fixing problem that caused fingerprints to fail in
e94252e Attemmpt #6 to optimize findMember
73e61b8 Attempt #5 to optimize findMember.
04f0b65 Attempt #4 to optimize findMember
0e3c70f Attempt #3 to optimize findMember
41f4497 Attempt #2 to optimize findMember
1a73aa0 Attempt #1 to optimize findMember
This didn't actually bear fruit, and the intervening years have
seen the implementations drift.
Now is the time to reunite them under the banner of `FindMemberBase`.
Each has a separate subclass to customise the behaviour. This is
primarily used by `findMember` to cache member types and to assemble
the resulting list of symbols in an low-allocation manner.
While there I have introduced some polymorphic calls, the call sites
are only bi-morphic, and our typical pattern of compilation involves
far more `findMember` calls, so I expect that JIT will keep the
virtual call cost to an absolute minimum.
Test results have been updated now that `findMembers` correctly
excludes constructors and doesn't inherit privates.
Coming up next: we can actually fix SI-7475!
retronym
referenced
this pull request
in retronym/scala
Jan 31, 2014
Swathes of important logic are duplicated between `findMember`
and `findMembers` after they separated on grounds of irreconcilable
differences about how fast they should run:
d905558 Variation #10 to optimze findMember
fcb0c01 Attempt #9 to opimize findMember.
71d2ceb Attempt #8 to opimize findMember.
77e5692 Attempty #7 to optimize findMember
275115e Fixing problem that caused fingerprints to fail in
e94252e Attemmpt #6 to optimize findMember
73e61b8 Attempt #5 to optimize findMember.
04f0b65 Attempt #4 to optimize findMember
0e3c70f Attempt #3 to optimize findMember
41f4497 Attempt #2 to optimize findMember
1a73aa0 Attempt #1 to optimize findMember
This didn't actually bear fruit, and the intervening years have
seen the implementations drift.
Now is the time to reunite them under the banner of `FindMemberBase`.
Each has a separate subclass to customise the behaviour. This is
primarily used by `findMember` to cache member types and to assemble
the resulting list of symbols in an low-allocation manner.
While there I have introduced some polymorphic calls, the call sites
are only bi-morphic, and our typical pattern of compilation involves
far more `findMember` calls, so I expect that JIT will keep the
virtual call cost to an absolute minimum.
Test results have been updated now that `findMembers` correctly
excludes constructors and doesn't inherit privates.
Coming up next: we can actually fix SI-7475!
retronym
referenced
this pull request
in retronym/scala
Jan 31, 2014
Swathes of important logic are duplicated between `findMember`
and `findMembers` after they separated on grounds of irreconcilable
differences about how fast they should run:
d905558 Variation #10 to optimze findMember
fcb0c01 Attempt #9 to opimize findMember.
71d2ceb Attempt #8 to opimize findMember.
77e5692 Attempty #7 to optimize findMember
275115e Fixing problem that caused fingerprints to fail in
e94252e Attemmpt #6 to optimize findMember
73e61b8 Attempt #5 to optimize findMember.
04f0b65 Attempt #4 to optimize findMember
0e3c70f Attempt #3 to optimize findMember
41f4497 Attempt #2 to optimize findMember
1a73aa0 Attempt #1 to optimize findMember
This didn't actually bear fruit, and the intervening years have
seen the implementations drift.
Now is the time to reunite them under the banner of `FindMemberBase`.
Each has a separate subclass to customise the behaviour. This is
primarily used by `findMember` to cache member types and to assemble
the resulting list of symbols in an low-allocation manner.
While there I have introduced some polymorphic calls, the call sites
are only bi-morphic, and our typical pattern of compilation involves
far more `findMember` calls, so I expect that JIT will keep the
virtual call cost to an absolute minimum.
Test results have been updated now that `findMembers` correctly
excludes constructors and doesn't inherit privates.
Coming up next: we can actually fix SI-7475!
retronym
referenced
this pull request
in retronym/scala
Feb 6, 2014
Swathes of important logic are duplicated between `findMember`
and `findMembers` after they separated on grounds of irreconcilable
differences about how fast they should run:
d905558 Variation #10 to optimze findMember
fcb0c01 Attempt #9 to opimize findMember.
71d2ceb Attempt #8 to opimize findMember.
77e5692 Attempty #7 to optimize findMember
275115e Fixing problem that caused fingerprints to fail in
e94252e Attemmpt #6 to optimize findMember
73e61b8 Attempt #5 to optimize findMember.
04f0b65 Attempt #4 to optimize findMember
0e3c70f Attempt #3 to optimize findMember
41f4497 Attempt #2 to optimize findMember
1a73aa0 Attempt #1 to optimize findMember
This didn't actually bear fruit, and the intervening years have
seen the implementations drift.
Now is the time to reunite them under the banner of `FindMemberBase`.
Each has a separate subclass to customise the behaviour. This is
primarily used by `findMember` to cache member types and to assemble
the resulting list of symbols in an low-allocation manner.
While there I have introduced some polymorphic calls, the call sites
are only bi-morphic, and our typical pattern of compilation involves
far more `findMember` calls, so I expect that JIT will keep the
virtual call cost to an absolute minimum.
Test results have been updated now that `findMembers` correctly
excludes constructors and doesn't inherit privates.
Coming up next: we can actually fix SI-7475!
retronym
added a commit
that referenced
this pull request
Feb 12, 2014
Swathes of important logic are duplicated between `findMember`
and `findMembers` after they separated on grounds of irreconcilable
differences about how fast they should run:
d905558 Variation #10 to optimze findMember
fcb0c01 Attempt #9 to opimize findMember.
71d2ceb Attempt #8 to opimize findMember.
77e5692 Attempty #7 to optimize findMember
275115e Fixing problem that caused fingerprints to fail in
e94252e Attemmpt #6 to optimize findMember
73e61b8 Attempt #5 to optimize findMember.
04f0b65 Attempt #4 to optimize findMember
0e3c70f Attempt #3 to optimize findMember
41f4497 Attempt #2 to optimize findMember
1a73aa0 Attempt #1 to optimize findMember
This didn't actually bear fruit, and the intervening years have
seen the implementations drift.
Now is the time to reunite them under the banner of `FindMemberBase`.
Each has a separate subclass to customise the behaviour. This is
primarily used by `findMember` to cache member types and to assemble
the resulting list of symbols in an low-allocation manner.
While there I have introduced some polymorphic calls, the call sites
are only bi-morphic, and our typical pattern of compilation involves
far more `findMember` calls, so I expect that JIT will keep the
virtual call cost to an absolute minimum.
Test results have been updated now that `findMembers` correctly
excludes constructors and doesn't inherit privates.
Coming up next: we can actually fix SI-7475!
retronym
referenced
this pull request
in retronym/scala
May 7, 2014
Bump partest to RC7. Enable Travis CI.
retronym
added a commit
that referenced
this pull request
Dec 23, 2014
Spec update for signature polymorphic methods
losvald
pushed a commit
to losvald/scala
that referenced
this pull request
Nov 20, 2015
Reduce number of errors from 6 to 2; fix >60 exc warnings
nicolasstucki
pushed a commit
to nicolasstucki/scala
that referenced
this pull request
Apr 28, 2017
Minor stdlib changes needed for the tuple PR
da-liii
pushed a commit
to da-liii/scala
that referenced
this pull request
Nov 11, 2018
Fixes a build error, closes scala#8
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I haven't been able to find any reason for that reversal, but
this version is an improved version provided with SI-3796, which
never got committed along with the patch.
This version generates trees directly instead of using the methods
under test. It also puts an upper bound on tree size and, therefore,
execution time.