stack overflow dotty.tools.dotc.parsing.JavaParsers$JavaParser.pullOutFirstConstr$1(JavaParsers.scala:119)

[ecrabor8]

Compiler version

compiler version: version 3.6.1

Minimized code

proprietary company code and not narrowed don

Output (click arrow to expand)

[error] java.lang.StackOverflowError
[error] dotty.tools.dotc.parsing.JavaParsers$JavaParser.pullOutFirstConstr$1(JavaParsers.scala:119)
[error] dotty.tools.dotc.parsing.JavaParsers$JavaParser.pullOutFirstConstr$1(JavaParsers.scala:119)
[error] dotty.tools.dotc.parsing.JavaParsers$JavaParser.pullOutFirstConstr$1(JavaParsers.scala:119)
[error] dotty.tools.dotc.parsing.JavaParsers$JavaParser.pullOutFirstConstr$1(JavaParsers.scala:119)
[error] dotty.tools.dotc.parsing.JavaParsers$JavaParser.pullOutFirstConstr$1(JavaParsers.scala:119)
....

[som-snytt]

@ecrabor8 it recurses looking for a constructor, so probably just a sufficiently long class with ctor at the end.

[ecrabor8]

i can see that. Now maybe there is some other problem that made it look like a long class ?? in any case why not something like below (that i tested) changing Int to Tree, and where this would stack overflow for me implemented as in dotty. @tailrec def pullOut(accum: List[Int], stats: List[Int]): (Option[Int], List[Int]) = stats match { case (i: Int) :: rest if i == 500 => (Some(i), accum.reverse ::: rest) case first :: rest => pullOut(first :: accum, rest) case Nil => (None, accum) } val ar = List(500).reverse_:::(Array.fill(50000)(0).toList) val (r, _) = pullOut(Nil, ar) assert(r == Some(500))

…

On Mon, Dec 23, 2024 at 1:19 PM som-snytt ***@***.***> wrote: @ecrabor8 <https://github.com/ecrabor8> it recurses looking for a constructor, so probably just a sufficiently long class with ctor at the end. — Reply to this email directly, view it on GitHub <#22262 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACD2AFAM4SBI4YZRZUQWJGL2HBH2RAVCNFSM6AAAAABUDL24O2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRQGEZDMMRRGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[SethTisue]

does giving the JVM more stack when it starts make the problem go away? or is it an infinite loop that will eventually consume any amount of available stack?

see https://docs.scala-lang.org/tutorials/FAQ/index.html#i-got-a-stackoverflowerror-while-compiling-my-code-is-it-a-compiler-bug

[ecrabor8]

yes it does. learned to use .jvmopts with sbt to add it as otherwise i didnt seem to get the -J-X stuff to work within build.sbt.

…

On Wed, Dec 25, 2024 at 12:51 AM Seth Tisue ***@***.***> wrote: does giving the JVM more stack when it starts make the problem go away? or is it an infinite loop that will eventually consume any amount of available stack? see https://docs.scala-lang.org/tutorials/FAQ/index.html#i-got-a-stackoverflowerror-while-compiling-my-code-is-it-a-compiler-bug — Reply to this email directly, view it on GitHub <#22262 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACD2AFD3DRAZLZ5UROQWSHD2HJBVVAVCNFSM6AAAAABUDL24O2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRRGYZTKMZYHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>