Skip to content

tests/run/bridges.scala cannot be compiled by clean compiler #2924

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

Closed
nicolasstucki opened this issue Jul 27, 2017 · 4 comments
Closed

tests/run/bridges.scala cannot be compiled by clean compiler #2924

nicolasstucki opened this issue Jul 27, 2017 · 4 comments

Comments

@nicolasstucki
Copy link
Contributor

nicolasstucki commented Jul 27, 2017

It can be reproduced with:
vulpix tests/run/bridges.scala

but not with
vulpix

@nicolasstucki nicolasstucki changed the title Infinite loop on tests/run/bridges.scala while -Ycheck:all Infinite loop on tests/run/bridges.scala while -Ycheck Jul 27, 2017
@nicolasstucki
Copy link
Contributor Author

This has been happening since it was added in 92fe2a5

@nicolasstucki
Copy link
Contributor Author

There is probably some state left from previous runs in the compiler that allows it to work.

@nicolasstucki nicolasstucki changed the title Infinite loop on tests/run/bridges.scala while -Ycheck tests/run/bridges.scala cannot be compiled by clean compiler Jul 27, 2017
@smarter
Copy link
Member

smarter commented Jul 27, 2017

No idea why it doesn't break usually, but bridges.scala contains a block with 1424 statements which causes withDefinedSyms to blow up with a stackoverflow because foldRightBN is not tail-recursive. This should be easy to fix by replacing foldRightBN by a while loop. But someone should investigate why this doesn't trigger when running all the tests, maybe vulpix forgets to run bridges.scala for some reason?

@DarkDimius
Copy link
Contributor

@smarter @nicolasstucki VM needs different amount of stack in JITed and interpreted mode.
You can have code that does not stackoverflow when compiled but does when interpreted.

nicolasstucki added a commit to biboudis/dotty that referenced this issue Sep 5, 2017
nicolasstucki added a commit to dotty-staging/dotty that referenced this issue Sep 6, 2017
To make the stack shorter we implement foldRightBN with
a foldLeftBN wich allocates only half of the closures.
By doing so we need to eagerly reverse the list which is
in most cases small or empty.
nicolasstucki added a commit to dotty-staging/dotty that referenced this issue Sep 6, 2017
To make the stack shorter we implement foldRightBN with
a foldLeftBN which allocates only half of the closures.
By doing so we need to eagerly reverse the list which is
in most cases small or empty.
allanrenucci pushed a commit to allanrenucci/dotty that referenced this issue Sep 6, 2017
To make the stack shorter we implement foldRightBN with
a foldLeftBN which allocates only half of the closures.
By doing so we need to eagerly reverse the list which is
in most cases small or empty.
nicolasstucki added a commit to dotty-staging/dotty that referenced this issue Sep 6, 2017
Make withDefinedSyms allocate only one nested closure per element of the list
and make it easier for the JVM to optimize.
nicolasstucki added a commit to dotty-staging/dotty that referenced this issue Sep 6, 2017
Make withDefinedSyms allocate only one nested closure per element of the list
and make it easier for the JVM to optimize.
biboudis pushed a commit to biboudis/dotty that referenced this issue Sep 8, 2017
nicolasstucki added a commit that referenced this issue Sep 11, 2017
Fix #2924: make TreeChecker.typedBlock iterative
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants