dfinity / motoko

Simple high-level language for writing Internet Computer canisters
Apache License 2.0
493 stars 97 forks source link

Compiler Error #4496

Open detextre4 opened 2 months ago

detextre4 commented 2 months ago

Hey there, i was trying to run the dfx generate command using dfx 0.15.0 when I ran into the following error.

bug-report-dfx

Previously it had not happened to me but after adding some information to a specific file it started to happen to me.

bug-report-2-dfx

Maybe the problem could be due to excess data when compiling?

detextre4 commented 2 months ago

Well, I tried eliminating a large part of the data array, it actually has a limit when compiling

crusso commented 2 months ago

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.

crusso commented 2 months ago

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...