The simplifier would convert strictly-integer strings to their
integer equivalent, and all other strings to zero. This meant
that eg "1.1" became zero, as did "1x". Normally, such strings
are converted at the ast level, so it was hard to expose the bug,
but eg test/quick/cnvInt.php would fail if you turned off
JitEnableRenameFunctions (and its turned off in repo mode, so the
repo mode test was failing).
The same issue was present in ConvStrToDbl, but there was a bug in
StringData::isNumeric causing it to return true for a weakly-numeric string,
where its contract is to return false (and it did return false for an
equivalent, non-static string). Once I fixed that bug, I had to fix the
bug in ConvStrToDbl.
Make the targetcache the one true home for constants,
so we dont need to (also) insert them all into
VMExecutionContext::m_constants (which is now gone).
By also making "non-volatile" constants persistent, we save
initializing most of them at all in RepoAuthoritative mode.
While I was working on the TestCodeRun refactor I found two tests about Tainted code. I looked into it and coulnd't get HHVM to compile with TAINTED=1. Then I checked and none of the extension functions we exposed about tainting were used in WWW. Scratching my head I asked, @srenfro and @jdelong, who thought it was dead. So I killed this zombie.
If you allocate a StringData on the stack, and it escapes,
you're in trouble. Make the destructor assert by default,
and add a StackStringData which does the appropriate
refCounting and checking.
This change is mostly for FB internal organizational reasons.
Building is not effected beyond the fact that the target now
lands in hphp/hhvm/hhvm rather than src/hhvm/hhvm.
Edwin Smith