Re: JS assertions that get optimized away!

2014-06-27 Thread Nicolas B. Pierron
On 06/27/2014 09:02 AM, Boris Zbarsky wrote: On 6/27/14, 11:55 AM, Fitzgerald, Nick wrote: I don't know if it is optimized by SpiderMonkey as well, but in the debugger we have |exports.dbg_assert =function dbg_assert(cond, e) {| This requires evaluation of "cond" and "e" on the caller side,

Re: JS assertions that get optimized away!

2014-06-27 Thread Boris Zbarsky
On 6/27/14, 11:55 AM, Fitzgerald, Nick wrote: I don't know if it is optimized by SpiderMonkey as well, but in the debugger we have |exports.dbg_assert =function dbg_assert(cond, e) {| This requires evaluation of "cond" and "e" on the caller side, unfortunately. That can't be optimized away.

Re: JS assertions that get optimized away!

2014-06-27 Thread Fitzgerald, Nick
On 6/27/14, 8:49 AM, Jason Orendorff wrote: On 06/26/2014 06:59 AM, David Rajchenbach-Teller wrote: I would be interested in adding boundary checks and invariant checks that could be eliminated in opt builds. Is this in the scope of your project? No, I don't think so. S2S could certainly do i

JS assertions that get optimized away! (was: Are you interested in doing dynamic analysis of JS code?)

2014-06-27 Thread Jason Orendorff
On 06/26/2014 06:59 AM, David Rajchenbach-Teller wrote: I would be interested in adding boundary checks and invariant checks that could be eliminated in opt builds. Is this in the scope of your project? No, I don't think so. S2S could certainly do it, but you wouldn't want to use S2S on all b