Luckily that limit is about to be raised to 50,000 functions.
I upgraded to dfx 0.12.0-beta.2 to see if the limit was raised locally. It may have been, because I’m getting an entirely new but very troubling error: Wasm module of canister rrkah-fqaaa-aaaaa-aaaaq-cai is not valid: Wasm module contains a function that is too complex
What can be done about this? Keep in mind that I’m trying to incorporate a complex software project into the IC that I do not have the most direct control over, RustPython. RustPython compiles to Wasm and just as I’m trying to deploy it to the IC I keep hitting these issues.
@lastmjs this limit was added to protect against situations where Wasmtime would take too long to compile the canister’s Wasm module. I think they’ve since made improvements to the compilation speed so we’ll look into raising the limit.
We’re also pushing out an improvement to the error message so that it reports how much the module exceeds the limit by. If you can share the module you’re currently working with we can also use it to see how much of an increase in the limit would be needed, or if it can be modified in some other way to make your code work.
Okay, so lalrpop is generated a Python parser used by RustPython. Part of the parser has a function that is about 6000 lines long, and it has a match with almost 900 arms.
Is the Wasm function complexity limit just based on the function body, or does it somehow follow the function statements as they call into other functions? I would guess it’s just based on the function body.
I would love the limit to be raised to have this issue just disappear, but I guess I’ll try manually modifying the function to pull pieces out into other functions to see if that works. If I’m headed down the wrong path I’d love some guidance. Thanks!
So the function complexity refers to the Wasm function, not the original Rust function. I’ve seen cases where this error appears after wasm-opt, probably due to function inlining. So lalrpop parser may not be the real cause (Candid parser is also using lalrpop, and it seems to work fine inside the canister).
It is possible that ic-cdk-optimizer is pushing the lalrpop generated code over the limit because of function inlining, and I’d be curious to see if your canister still hits the limit when you don’t run it through ic-cdk-optimizer, but that shouldn’t be our long-term solution.
I’ve reached out to you on Discord and am providing the source code and Wasm binary. Hopefully you can glean what’s going on. Refactoring the match in the __reduce function (the match with over 800 arms) does solve the problem.