8000 Batch files no longer swallow exit codes by xeno-by · Pull Request #54 · scala/scala · GitHub
[go: up one dir, main page]

Skip to content

Batch files no longer swallow exit codes #54

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 12, 2011

Conversation

xeno-by
Copy link
Contributor
@xeno-by xeno-by commented Dec 9, 2011

Usually scripts like scala.bat and scalac.bat correctly propagate
exit codes from underlying Java invocations. However, if you run these
scripts as follows: "cmd /c scala ...", then errorlevel gets swallowed.
This simple patch fixes the aforementioned problem.

Fixes SI-5295, no review.

Usually scripts like scala.bat and scalac.bat correctly propagate
exit codes from underlying Java invocations. However, if you run these
scripts as follows: "cmd /c scala ...", then errorlevel gets swallowed.
This simple patch fixes the aforementioned problem.

Fixes SI-5295, no review.
@paulp paulp merged commit d718a7c into scala:master Dec 12, 2011
adriaanm pushed a commit to adriaanm/scala that referenced this pull request 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
eed3si9n added a commit to eed3si9n/scala that referenced this pull request May 14, 2019
…hods-before-and-after-erasure-in-extractapi

FPORT: Consider signatures of methods before and after erasure in ExtractAPI
lrytz pushed a commit to lrytz/scala that referenced this pull request Nov 5, 2019
…hods-before-and-after-erasure-in-extractapi

FPORT: Consider signatures of methods before and after erasure in ExtractAPI
Rewritten from sbt/zinc@e7aee52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0