compiler crashes with integer overflow when evaluating expressions about closure-templates HOT 4 OPEN

also, would you accept a patch to fix this?

from closure-templates.

We are evaluating the expression because it is part of our tree simplifying pass where we 'preevaluate' constant expressions

the runtime error is a bit weird, soy does most of its calculations on integers using java longs, but at various points we assert that it isn't 'too big' I believe the goal is all about server/client consistency. We don't want a server rendered template to give different results because it has higher precision integers (64 vs. 52 bits). imho it is a bit misguided, but I also didn't add these checks so i am not entirely sure about the motivation.

@Ubehebe any opinion on this?

from closure-templates.

ok, just took a quicker look at the specific code in question and there are additional bits of weirdness.

apparently soy only allows integer constants to be declared if they fit in 32 bits. as a work around you should be able to add a '.0' suffix to any one of those numbers and flip into double math.

imho we should probably just switch all soy integer math to use 'long's instead of ints. There are a few places where we need 'int's (like indexing into collections), but unchecked downcasts should be fine in those places.

from closure-templates.

fwiw, there's already an exception catch that tells the simplifier to back off and leave the expression alone.

I was going to suggest that we move the convertPrimitiveDataToExpr call into the exception block. That fixes the obvious problem without turning this into a referendum on how soy represents numbers, or on the whole SimplifyExpr enterprise.

from closure-templates.