Stack overflow bug

[nathaniel-brough]

I found a bug in the starlark parser using the fuzzing harness in #64. I'm guessing there is some recursive parsing of unary operators and as a result, you can get a stackoverflow if you chain a bunch of unary operators. e.g. attempting to parse;

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++''

Will result in a stackoverflow. It looks like a fairly unlikely scenario, and likely won't impact usage much if at all. But I thought I'd mention it anyway :)

[ndmitchell]

I took a look at this case - the issue is in ExprP::into_map_payload, which uses linear stack space in the size of the expression. I don't think there's much we can easily do to avoid that, without writing this (and probably a bunch of other traverals) as stack-free, which is a fair bit of work and more complexity, so I think we just have to accept it for now.

[ndmitchell]

Going to leave this ticket for all overflows. One day we might want to harden against deep recursion in the AST, but for now I think it's considered expected.