With the constant evaluation work that has happened with the asc compiler for the float work, there are some testcases that now fail because the compiler is actually generating the correct values while the runtime still has some known bugs for string->number and number->string comparisons.
From: Lars Hansen <email@example.com> Date: Wed, 5 Oct 2011 14:05:15 +0100 Subject: Re: float + asc regressions So I know there were some regressions because constant evaluation can convert number to string and string to number at compile time, but unlike the VM they do so correctly because Java has proper string->number and number->string functionality. When Jeff and I discussed this I made the blanket judgement that this deviation is OK and that we'll just have to correct for it in the test suite. (Eval has the same problem in some regression tests, but for the other reason - being part of the VM, it uses the buggy converter in the VM to convert string to number during compilation to get a less-precise number than ASC, so eval+VM is *worse* than ASC+VM which in turn is *worse* than ASC+CE+VM. Joy.)
Sitting in patch queue as bug-692402.acceptance.diff
ecma3/Expressions/e11_6_3.as ecma3/LexicalConventions/e7_7_3.as ecma3/Number/e15_7_1.as ecma3/Number/e15_7_2.as
changeset: 6809:4a891601ef97 user: Virgil Palanciuc <firstname.lastname@example.org> summary: Bug 692402: adjust testmedia for correct string->number handling in asc.jar http://hg.mozilla.org/tamarin-redux/rev/4a891601ef97
The changes to the string->number testmedia has been reverted since the constant evaluation work in asc.jar will not surface until a later date as float has been put on hold. See attachment #582266 [details] [diff] [review] on bug #711370
changeset: 7146:2550c3baa3d7 user: Brent Baker <email@example.com> summary: Bug 692402, Bug 703512: update the failconfig file for proper bug references http://hg.mozilla.org/tamarin-redux/rev/2550c3baa3d7