Uses same workaround for stack sizes in non optimized builds. #1183
Conversation
This works around potential stack size issues in non optimized builds.
|
While this is the same workaround as we used for the oneof cases, since it will apply to more messages I'm wondering if we want any sorta logic on when we do this? i.e. - should it check how many locals there were will and the size of those locals? i.e. - 10 local ints, likely not an issue even with lots of recursion, but 10 messages, all of which didn't use storage so they are potential really large? Then we're likely in the current problem space. |
|
It's just for debug builds, so I'm not too worried unless it causes actual problems for someone. |
I didn't look in detail, I'm hoping the analysis from the other case applies as far as there not really being impact on release builds. Not sure if someone else wants to poke at things to confirm. |
Fixes #1181