Open detextre4 opened 2 months ago
Well, I tried eliminating a large part of the data array, it actually has a limit when compiling
Sorry, just noticed the issue. Can you confirm that it compiles when the array is a more reasonable size? It looks like a stack overflow due to deep recursion on a large array.
If possible, can you do
export OCAMLRUNPARAM=b
and then try to rebuild? This will produce a stack trace when compilation fails and will help us narrow down the issue. Send us the stack trace if you can produce one.
As a possible work-around, you could try to insert a type annotation on the declaration:
public let users_array : [Nat8] = [ ... ]
If lucky, that might avoid the stack-overflow by steering the type-checker down a simpler code path when checking the large array. No guarantees but worth a try.
Ok, never mind trying to produce a stack trace, I've reproduced the failure with a simple example in #4513. FWIW, adding the type annotation doesn't help because the stack overflow already occurs in the parser, not during type checking as I first suspected.
The failure is hard to fix because it occurs in the (generated) parser code. A workaround, if you are generating the large literal using a script (from some wasm code, right?) would be to quote the code as a large blob literal, which the compiler seems to handle ok.
Something like:
...
public let blob = "\00...\FF.."
...
on a very long line seems to work. This way the lexer, not the parser, has to deal with long literal and is fortunately able to do so.
Much better would be if we let users include blob or text values from files as well as in code, but that's another story...
Hey there, i was trying to run the
dfx generate
command using dfx 0.15.0 when I ran into the following error.Previously it had not happened to me but after adding some information to a specific file it started to happen to me.
Maybe the problem could be due to excess data when compiling?