Skip to content
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

Compiler Error #4496

Open
detextre4 opened this issue Apr 11, 2024 · 3 comments
Open

Compiler Error #4496

detextre4 opened this issue Apr 11, 2024 · 3 comments

Comments

@detextre4
Copy link

detextre4 commented Apr 11, 2024

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
Copy link
Author

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

@crusso
Copy link
Contributor

crusso commented Apr 22, 2024

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 added a commit that referenced this issue Apr 22, 2024
@crusso
Copy link
Contributor

crusso commented Apr 22, 2024

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

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

No branches or pull requests

2 participants