summaryrefslogtreecommitdiffstats
path: root/JavaScriptCore/ChangeLog
diff options
context:
space:
mode:
Diffstat (limited to 'JavaScriptCore/ChangeLog')
-rw-r--r--JavaScriptCore/ChangeLog1092
1 files changed, 1092 insertions, 0 deletions
diff --git a/JavaScriptCore/ChangeLog b/JavaScriptCore/ChangeLog
index bf45cd8..7175c5d 100644
--- a/JavaScriptCore/ChangeLog
+++ b/JavaScriptCore/ChangeLog
@@ -1,3 +1,1095 @@
+2010-12-01 Geoffrey Garen <ggaren@apple.com>
+
+ Try to fix the GTK build.
+
+ * GNUmakefile.am: Use a full path to OSAllocator*.cpp.
+
+2010-12-01 Geoffrey Garen <ggaren@apple.com>
+
+ Try to fix the EFL Linux build.
+
+ * CMakeListsEfl.txt: Added OSAllocator to the project.
+
+2010-12-01 Geoffrey Garen <ggaren@apple.com>
+
+ Try to fix the Qt build: Include all OS files for Qt's sake, and then
+ use #ifdefs in the files to exclude things based on OS.
+
+ This is a pretty bad way to manage platforms -- hopefully we can
+ fix the Qt build system and move away from this in the future.
+
+ * wtf/OSAllocatorPosix.cpp:
+ * wtf/OSAllocatorSymbian.cpp:
+ * wtf/OSAllocatorWin.cpp:
+ * wtf/wtf.pri:
+
+2010-12-01 Geoffrey Garen <ggaren@apple.com>
+
+ Try to fix the Chromium build.
+
+ * JavaScriptCore.gypi: This is a Windows build file, so use OSAllocatorWin.cpp.
+
+2010-12-01 Geoffrey Garen <ggaren@apple.com>
+
+ Try to fix the GTK build.
+
+ * GNUmakefile.am: Added OSAllocator to another project.
+
+2010-12-01 Geoffrey Garen <ggaren@apple.com>
+
+ Try to fix the GTK Linux build.
+
+ * JavaScriptCore.gypi: Added OSAllocator to the project.
+
+2010-12-01 Geoffrey Garen <ggaren@apple.com>
+
+ Try to fix the Qt Linux build.
+
+ * wtf/OSAllocatorPosix.cpp: Use the right errno.h.
+
+2010-12-01 Geoffrey Garen <ggaren@apple.com>
+
+ Try to fix Windows build: export some more symbols.
+
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
+
+2010-12-01 Geoffrey Garen <ggaren@apple.com>
+
+ Try to fix the Qt Linux build.
+
+ * wtf/wtf.pri: Use the POSIX OSAllocator for Qt Linux.
+
+2010-12-01 Geoffrey Garen <ggaren@apple.com>
+
+ Windows build fix: commit doesn't have a return value.
+
+ * wtf/OSAllocatorWin.cpp:
+ (WTF::OSAllocator::commit):
+
+2010-12-01 Geoffrey Garen <ggaren@apple.com>
+
+ Build fix: Export some symbols.
+
+ * JavaScriptCore.exp:
+
+2010-12-01 Geoffrey Garen <ggaren@apple.com>
+
+ Build fix.
+
+ * JavaScriptCore.xcodeproj/project.pbxproj: Export OSAllocator.h as private
+ so other projects can see it.
+
+ * wtf/OSAllocatorPosix.cpp: #include UnusedParam.h for UNUSED_PARAM.
+
+2010-12-01 Geoffrey Garen <ggaren@apple.com>
+
+ Reviewed by Sam Weinig.
+
+ Baby step toward a cross-platform virtual memory abstraction: created
+ an all-static OSAllocator class and changed MarkStack to use it.
+
+ * JavaScriptCore.exp: These functions are inlined now.
+
+ * JavaScriptCore.vcproj/WTF/WTF.vcproj: Added OSAllocatorWin.cpp.
+
+ * JavaScriptCore.xcodeproj/project.pbxproj: Added OSAllocatorPosix.cpp.
+
+ * runtime/MarkStack.h:
+ (JSC::MarkStack::allocateStack):
+ (JSC::MarkStack::releaseStack): Use OSAllocator instead of rolling our
+ own platform-specific code.
+
+ * runtime/MarkStackNone.cpp: Removed. Nothing used this.
+
+ * runtime/MarkStackPosix.cpp:
+ * runtime/MarkStackSymbian.cpp:
+ * runtime/MarkStackWin.cpp: Removed custom platform-specific code, since
+ we use the OSAllocator abstraction now.
+
+ * wtf/OSAllocator.h: Added.
+ * wtf/OSAllocatorPosix.cpp: Added.
+ (WTF::OSAllocator::reserve):
+ (WTF::OSAllocator::reserveAndCommit):
+ (WTF::OSAllocator::commit):
+ (WTF::OSAllocator::decommit):
+ (WTF::OSAllocator::release):
+ * wtf/OSAllocatorSymbian.cpp: Added.
+ (WTF::OSAllocator::reserve):
+ (WTF::OSAllocator::reserveAndCommit):
+ (WTF::OSAllocator::commit):
+ (WTF::OSAllocator::decommit):
+ (WTF::OSAllocator::release):
+ * wtf/OSAllocatorWin.cpp: Added.
+ (WTF::OSAllocator::reserve):
+ (WTF::OSAllocator::reserveAndCommit):
+ (WTF::OSAllocator::commit):
+ (WTF::OSAllocator::decommit):
+ (WTF::OSAllocator::release): The new OSAllocator abstraction.
+
+ * wtf/wtf.pri: Added OSAllocatorSymbian.cpp.
+
+2010-12-01 Steve Falkenburg <sfalken@apple.com>
+
+ Reviewed by Adam Roben.
+
+ WinCairo build should not use link-time code generation (LTCG)
+ https://bugs.webkit.org/show_bug.cgi?id=50353
+
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
+ * JavaScriptCore.vcproj/WTF/WTF.vcproj:
+ * JavaScriptCore.vcproj/jsc/jsc.vcproj:
+ * JavaScriptCore.vcproj/testapi/testapi.vcproj:
+
+010-12-01 Steve Falkenburg <sfalken@apple.com>
+
+ Reviewed by Adam Roben.
+
+ vcproj changes can't be applied cleanly by the Windows EWS bot
+ https://bugs.webkit.org/show_bug.cgi?id=50328
+
+ * JavaScriptCore.vcproj/JavaScriptCore.sln: Modified property svn:eol-style.
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: Modified property svn:eol-style.
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCF.vsprops: Added property svn:eol-style.
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCFLite.vsprops: Added property svn:eol-style.
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops: Added property svn:eol-style.
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGenerated.vcproj: Modified property svn:eol-style.
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedCommon.vsprops: Added property svn:eol-style.
+ * JavaScriptCore.vcproj/JavaScriptCoreSubmit.sln: Modified property svn:eol-style.
+ * JavaScriptCore.vcproj/WTF/WTF.vcproj: Modified property svn:eol-style.
+ * JavaScriptCore.vcproj/WTF/WTFCommon.vsprops: Added property svn:eol-style.
+ * JavaScriptCore.vcproj/jsc/jsc.vcproj: Modified property svn:eol-style.
+ * JavaScriptCore.vcproj/jsc/jscCommon.vsprops: Added property svn:eol-style.
+ * JavaScriptCore.vcproj/testapi/testapi.vcproj: Modified property svn:eol-style.
+ * JavaScriptCore.vcproj/testapi/testapiCommon.vsprops: Added property svn:eol-style.
+
+2010-12-01 Gavin Barraclough <barraclough@apple.com>
+
+ Reviewed by Sam Weinig.
+
+ Bug 50298 - /()()()()()()()()()(?:(\10a|b)(X|Y))+/.exec("bXXaYYaY") ASSERTs
+
+ For unmatched subpattens we previously used to set the subpattern end to -1,
+ but now we only set the start value. E.g. consider the following:
+ /a(b)?c/.exec("ac");
+ Previously we would generate an internal results array of:
+ [ 0, 2, -1, -1 ]
+ Since fairly recently we have generated results of:
+ [ 0, 2, -1, ??? ]
+ (With the end index of the subpattern uninitialized).
+
+ Update these ASSERTs to account for this.
+
+ Also, when stripping out self-referencing backreferences, (e.g. /(\1)/) we
+ were checking the wrong property on the pattern term. We should have been
+ looking at term.parentheses.subpatternId, but instead were checking
+ term.subpatternId. The latter is actually only the subpatternId for
+ back reference terms. Rename this to backReferenceSubpatternId.
+
+ * yarr/RegexInterpreter.cpp:
+ (JSC::Yarr::Interpreter::matchBackReference):
+ (JSC::Yarr::Interpreter::backtrackBackReference):
+
+2010-11-30 Gavin Barraclough <barraclough@apple.com>
+
+ Rubber stamped by Sam Weinig.
+
+ Bug 50297 - \s in YARR should match BOMs.
+
+ From section 15.10.2.12 CharacterClassEscape contains:
+
+ The production CharacterClassEscape :: s evaluates by returning the set of characters containing the
+ characters that are on the right-hand side of the WhiteSpace (7.2) or LineTerminator (7.3) productions.
+
+ Table 2 in section 7.2 contains:
+
+ \uFEFF Byte Order Mark <BOM>
+
+ * create_regex_tables:
+ Add BOM to spaces table.
+
+2010-11-30 Gavin Barraclough <barraclough@apple.com>
+
+ Reviewed by Darin Adler.
+
+ Fixed review comments following bug #48101.
+ Mostly typos, plus gave quantifyInfinite a symbolic name.
+
+ * yarr/RegexCompiler.cpp:
+ (JSC::Yarr::RegexPatternConstructor::quantifyAtom):
+ (JSC::Yarr::RegexPatternConstructor::checkForTerminalParentheses):
+ * yarr/RegexInterpreter.cpp:
+ (JSC::Yarr::Interpreter::backtrackParenthesesOnceEnd):
+ (JSC::Yarr::Interpreter::matchParenthesesTerminalBegin):
+ (JSC::Yarr::Interpreter::backtrackParenthesesTerminalBegin):
+ (JSC::Yarr::Interpreter::backtrackParenthesesTerminalEnd):
+ * yarr/RegexJIT.cpp:
+ (JSC::Yarr::RegexGenerator::generatePatternCharacterGreedy):
+ (JSC::Yarr::RegexGenerator::generatePatternCharacterNonGreedy):
+ (JSC::Yarr::RegexGenerator::generateCharacterClassGreedy):
+ * yarr/RegexParser.h:
+ (JSC::Yarr::Parser::parseTokens):
+ (JSC::Yarr::parse):
+
+2010-11-30 Steve Falkenburg <sfalken@apple.com>
+
+ Reviewed by Darin Adler.
+
+ WTF project missing build-stopping code from its pre-build event
+ https://bugs.webkit.org/show_bug.cgi?id=50281
+
+ * JavaScriptCore.vcproj/WTF/WTFPreBuild.cmd:
+
+2010-11-30 Patrick Gansterer <paroga@webkit.org>
+
+ Reviewed by Darin Adler.
+
+ Cleanup UTF8.cpp
+ https://bugs.webkit.org/show_bug.cgi?id=49581
+
+ Use macros and functions instead of range values directly.
+
+ * wtf/unicode/UTF8.cpp:
+ (WTF::Unicode::inlineUTF8SequenceLength):
+ (WTF::Unicode::UTF8SequenceLength):
+ (WTF::Unicode::convertUTF16ToUTF8):
+ (WTF::Unicode::readUTF8Sequence):
+ (WTF::Unicode::convertUTF8ToUTF16):
+ * wtf/unicode/UnicodeMacrosFromICU.h: Added U_IS_SUPPLEMENTARY macro.
+
+2010-11-30 Geoffrey Garen <ggaren@apple.com>
+
+ Reviewed by Gavin Barraclough.
+
+ Fixed a crash seen when using a PageAllocation to store itself.
+
+ * wtf/PageAllocation.h:
+ (WTF::PageAllocation::systemDeallocate): Zero out m_base before unmapping
+ it, in case unmapping m_base unmaps the PageAllocation.
+
+ * wtf/BumpPointerAllocator.h:
+ (WTF::BumpPointerPool::destroy): Now this work-around isn't needed!
+
+2010-11-30 Xan Lopez <xlopez@igalia.com>
+
+ Reviewed by Darin Adler.
+
+ m_hasNonEnumerableProperties is never initialized in Structure
+ https://bugs.webkit.org/show_bug.cgi?id=50266
+
+ * runtime/Structure.cpp:
+ (JSC::Structure::Structure): initialize member variable.
+
+2010-11-29 Steve Falkenburg <sfalken@apple.com>
+
+ Windows build fix (part 1). Use correct environment variable syntax in cmd files.
+
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePostBuild.cmd:
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePreBuild.cmd:
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePreLink.cmd:
+ * JavaScriptCore.vcproj/WTF/WTFPostBuild.cmd:
+ * JavaScriptCore.vcproj/jsc/jscPostBuild.cmd:
+ * JavaScriptCore.vcproj/jsc/jscPreBuild.cmd:
+ * JavaScriptCore.vcproj/jsc/jscPreLink.cmd:
+ * JavaScriptCore.vcproj/testapi/testapiPostBuild.cmd:
+ * JavaScriptCore.vcproj/testapi/testapiPreBuild.cmd:
+ * JavaScriptCore.vcproj/testapi/testapiPreLink.cmd:
+
+2010-11-29 Dan Bernstein <mitz@apple.com>
+
+ Reviewed by Darin Adler.
+
+ WTF support for <rdar://problem/8650085> adding word-prefix search options to the text search API.
+ https://bugs.webkit.org/show_bug.cgi?id=50038
+
+ * wtf/unicode/UnicodeMacrosFromICU.h: Copied additional macros from icu/unicode/utf16.h.
+
+2010-11-29 Steve Falkenburg <sfalken@apple.com>
+
+ Reviewed by Darin Adler.
+
+ JavaScriptCore projects on Windows should use cmd files for build events
+ https://bugs.webkit.org/show_bug.cgi?id=50193
+
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops:
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePostBuild.cmd: Added.
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePreBuild.cmd: Added.
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePreLink.cmd: Added.
+ * JavaScriptCore.vcproj/WTF/WTFPostBuild.cmd: Added property svn:eol-style.
+ * JavaScriptCore.vcproj/WTF/WTFPreBuild.cmd: Added property svn:eol-style.
+ * JavaScriptCore.vcproj/jsc/jscCommon.vsprops:
+ * JavaScriptCore.vcproj/jsc/jscPostBuild.cmd: Added.
+ * JavaScriptCore.vcproj/jsc/jscPreBuild.cmd: Added.
+ * JavaScriptCore.vcproj/jsc/jscPreLink.cmd: Added.
+ * JavaScriptCore.vcproj/testapi/testapiCommon.vsprops:
+ * JavaScriptCore.vcproj/testapi/testapiPostBuild.cmd: Added.
+ * JavaScriptCore.vcproj/testapi/testapiPreBuild.cmd: Added.
+ * JavaScriptCore.vcproj/testapi/testapiPreLink.cmd: Added.
+
+2010-11-29 Dai Mikurube <dmikurube@google.com>
+
+ Reviewed by Kent Tamura.
+
+ when empty, clicking "down" on outer-spin-button returns "max value"
+ https://bugs.webkit.org/show_bug.cgi?id=45491
+
+ It is required to calculate UTC/DST offsets to retrieve the current local milliseconds for
+ date/time type inputs. WTF::currentTimeMS() returns a UTC time, and WTF::getLocalTime()
+ returns a struct tm, not milliseconds.
+
+ Calculating milliseconds from a struct tm is not simple since timegm() cannot be used in all
+ environments. This calculation is already done in calculateUTCOffset(), and complicated.
+ Duplicating this complicated calculation is unreasonable because of maintainability.
+ To achieve this without duplication, we must call calculate{UTC|DST}Offset in some way.
+
+ * JavaScriptCore.exp:
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
+ * wtf/DateMath.cpp: Changed calculateUTCOffset() and calculateDSTOffset() to external functions.
+ (WTF::calculateUTCOffset):
+ (WTF::calculateDSTOffset):
+ * wtf/DateMath.h:
+
+2010-11-29 Chris Rogers <crogers@google.com>
+
+ Reviewed by Kenneth Russell.
+
+ Switch web audio code to use FloatPoint3D instead of Vector3
+ https://bugs.webkit.org/show_bug.cgi?id=50186
+
+ * wtf/Vector3.h: Removed.
+
+2010-11-29 Steve Falkenburg <sfalken@apple.com>
+
+ Reviewed by Adam Roben.
+
+ Add a mechanism for Windows pre-build/pre-link/post-build events to be separated into individual cmd files
+ https://bugs.webkit.org/show_bug.cgi?id=49858
+
+ We're migrating our prebuild/prelink/postbuild steps out of vcproj and vsprops files:
+ - To simplify editing (editing vsprops build steps is confusing).
+ - For more readable diffs.
+
+ * JavaScriptCore.vcproj/WTF/WTFCommon.vsprops:
+ * JavaScriptCore.vcproj/WTF/WTFPostBuild.cmd: Added.
+ * JavaScriptCore.vcproj/WTF/WTFPreBuild.cmd: Added.
+
+2010-11-29 Geoffrey Garen <ggaren@apple.com>
+
+ Reviewed by Gavin Barraclough.
+
+ Improved accuracy of command-line SunSpider.
+
+ * jsc.cpp:
+ (functionRun): Changed the "run" function to run a given test in
+ its own global object. Previously, all tests ran in the same global
+ object, which created name conflicts, and made globals from previous
+ tests artificially survive into later tests.
+
+ Also changed "run" to return the elapsed milliseconds when running a
+ given test, for slightly more accurate numbers.
+
+ (functionCheckSyntax): Ditto on returning elapsed milliseconds.
+
+2010-11-29 Darin Adler <darin@apple.com>
+
+ Reviewed by Andreas Kling.
+
+ Remove a couple unneeded overflow checks
+ https://bugs.webkit.org/show_bug.cgi?id=49816
+
+ * wtf/text/CString.cpp:
+ (WTF::CString::init): Use an ASSERT instead of
+ an overflow check with CRASH.
+
+2010-11-29 Adam Roben <aroben@apple.com>
+
+ Robustify react-to-vsprops-changes.py against changes to its location
+ or the location of the .vsprops files
+
+ Suggested by John Sullivan.
+
+ * JavaScriptCore.vcproj/JavaScriptCore/react-to-vsprops-changes.py:
+ Removed file_modification_times.
+ (main): Use glob.glob to find the .vsprops files and assert that we found some.
+
+2010-11-29 Adam Roben <aroben@apple.com>
+
+ Touch wtf/Platform.h whenever any .vsprops file changes
+
+ This will cause all files to be recompiled, which will make changes to
+ preprocessor macros (e.g., ENABLE_*) actually take effect.
+
+ Fixes <http://webkit.org/b/50167> Windows build fails when ENABLE_*
+ macros are changed (because not enough files are rebuilt)
+
+ Reviewed by John Sullivan.
+
+ * JavaScriptCore.vcproj/JavaScriptCore/react-to-vsprops-changes.py:
+ (main): Touch wtf/Platform.h if it's older than any .vsprops file. Also
+ added some comments and logging to make it clearer what the script is
+ doing and why.
+
+2010-11-29 Adam Roben <aroben@apple.com>
+
+ Update react-to-vsprops-changes.py after r72555
+
+ .vsprops files are no longer accessed relative to $WebKitLibrariesDir.
+
+ Fixes <http://webkit.org/b/50166> REGRESSION (r72555):
+ react-to-vsprops-changes.py no longer works for people with a
+ non-default $WebKitLibrariesDir
+
+ Reviewed by John Sullivan.
+
+ * JavaScriptCore.vcproj/JavaScriptCore/react-to-vsprops-changes.py:
+ (main): Always look in WebKitLibraries/win for .vsprops files, not in
+ $WebKitLibrariesDir.
+
+2010-11-28 Gavin Barraclough <barraclough@apple.com>
+
+ Reviewed by Sam Weinig.
+
+ Bug 48100 - YARR allows what seems like a bogus character-class range
+
+ Per ECMA-262 character classes containing character ranges containing
+ character classes are invalid, eg:
+ /[\d-x]/
+ /[x-\d]/
+ /[\d-\d]/
+ These should throw a syntax error.
+
+ * yarr/RegexParser.h:
+
+2010-11-27 Gavin Barraclough <barraclough@apple.com>
+
+ Reviewed by Sam Weinig.
+
+ Bug 48101 - Yarr gives different results for /(?:a*?){2,}/
+
+ The test cases in the linked mozilla bug demonstrate a couple of
+ problems in subpattern matching. These bugs lie in the optimized
+ cases - for matching parentheses with a quantity count of 1, and
+ for matching greedy quantified parentheses at the end of a regex
+ (which do not backtrack).
+
+ In both of these cases we are failing to correctly handle empty
+ matches. In the case of parentheses-single matches (quantity count
+ one) we are failing to test for empty matches at all. In the case
+ of terminal subpattern matches we do currently check, however there
+ is a subtler bug here too. In the case of an empty match we will
+ presently immediately fall through to the next alternative (or
+ complete the regex match), whereas upon a failed match we should
+ be backtracking into the failing alternative, to give it a chance
+ to match further (e.g. consider /a??b?|a/.exec("ab") - upon first
+ attempting to match the first alternative this will match the empty
+ string - since a?? is non-greedy, however rather than moving on to
+ the second alternative we should be re-matching the first one, at
+ which point the non-greedy a?? will match, and as such the result
+ should be "ab", not "a").
+
+ Terminal subpattern matching contains a second bug, too. The frame
+ location values in the subpattern should be being allocated with
+ the outer disjunction's frame (as we do for the parentheses-single
+ optimization). Consider the following three regexes:
+ /a*(?:b*)*c*/
+ /a*(?:b*)c*/
+ /a*(?:b*)*/
+ Considering only the frame location required by the atoms a,b, and
+ c, (ignoring space associated with the nested subpattern) the first
+ regex (a normal subpattern match) requires a frame size of 2 for
+ the outer disjunction, (to backtrack terms a & c), with each
+ iteration of the subpattern requiring a frame of size 1 (in order
+ to backtrack b). In the case of the second regex (where the
+ parentheses-single optimization will kick in) the outer frame must
+ be set up with a frame size of 3, since the outer frame will also
+ be used when running the nested subpattern. We will currently only
+ allocate a farme of size 1 for the outer disjuntion (to contain a),
+ howver the frame size should be 2 (since the subpattern will be
+ evaluated in the outer frame). In addition to failing to allocate
+ frame space the frame offsets are also presently invalid - in the
+ case of the last regex b's frame location will be set assuming it
+ to be the first term in the frame, whereas in this case b lies
+ after the term a, and should be taking a separate frame location.
+
+ In order to correctly allocate the frame for terminal subpattern
+ matches we must move this optimization back up from the JIT into
+ the compiler (and thus interpreter too), since this is where the
+ frame allocation takes place.
+
+ * yarr/RegexCompiler.cpp:
+ (JSC::Yarr::RegexPatternConstructor::setupAlternativeOffsets):
+ (JSC::Yarr::RegexPatternConstructor::checkForTerminalParentheses):
+ (JSC::Yarr::compileRegex):
+ * yarr/RegexInterpreter.cpp:
+ (JSC::Yarr::Interpreter::matchParenthesesOnceBegin):
+ (JSC::Yarr::Interpreter::matchParenthesesOnceEnd):
+ (JSC::Yarr::Interpreter::backtrackParenthesesOnceBegin):
+ (JSC::Yarr::Interpreter::backtrackParenthesesOnceEnd):
+ (JSC::Yarr::Interpreter::matchParenthesesTerminalBegin):
+ (JSC::Yarr::Interpreter::matchParenthesesTerminalEnd):
+ (JSC::Yarr::Interpreter::backtrackParenthesesTerminalBegin):
+ (JSC::Yarr::Interpreter::backtrackParenthesesTerminalEnd):
+ (JSC::Yarr::Interpreter::matchDisjunction):
+ (JSC::Yarr::ByteCompiler::atomParenthesesOnceBegin):
+ (JSC::Yarr::ByteCompiler::atomParenthesesTerminalBegin):
+ (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternBegin):
+ (JSC::Yarr::ByteCompiler::atomParentheticalAssertionEnd):
+ (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
+ (JSC::Yarr::ByteCompiler::atomParenthesesOnceEnd):
+ (JSC::Yarr::ByteCompiler::atomParenthesesTerminalEnd):
+ (JSC::Yarr::ByteCompiler::emitDisjunction):
+ * yarr/RegexInterpreter.h:
+ * yarr/RegexJIT.cpp:
+ (JSC::Yarr::RegexGenerator::generateParenthesesSingle):
+ (JSC::Yarr::RegexGenerator::generateParenthesesGreedyNoBacktrack):
+ (JSC::Yarr::RegexGenerator::generateTerm):
+ * yarr/RegexPattern.h:
+ (JSC::Yarr::PatternTerm::PatternTerm):
+
+2010-11-24 Patrick Gansterer <paroga@webkit.org>
+
+ Reviewed by Csaba Osztrogonác.
+
+ Remove Bakefile build system files
+ https://bugs.webkit.org/show_bug.cgi?id=49983
+
+ r53757 only removed the content, but not the files.
+ This patch removes that empty files.
+
+ * JavaScriptCoreSources.bkl: Removed.
+ * jscore.bkl: Removed.
+
+2010-11-24 Gabor Loki <loki@webkit.org>
+
+ Reviewed by Csaba Osztrogonác.
+
+ Merge the usage of jumps and calls at ARM-JIT
+ https://bugs.webkit.org/show_bug.cgi?id=50008
+
+ Those JmpSrc objects which represent jumps (not calls) should point to
+ after the jump instruction.
+
+ * assembler/ARMAssembler.h:
+ (JSC::ARMAssembler::blx):
+ (JSC::ARMAssembler::loadBranchTarget):
+ (JSC::ARMAssembler::getAbsoluteJumpAddress):
+ (JSC::ARMAssembler::linkJump):
+ (JSC::ARMAssembler::relinkJump):
+ (JSC::ARMAssembler::linkCall):
+ (JSC::ARMAssembler::relinkCall):
+ (JSC::ARMAssembler::getRelocatedAddress):
+ (JSC::ARMAssembler::getDifferenceBetweenLabels):
+ (JSC::ARMAssembler::getCallReturnOffset):
+ * assembler/MacroAssemblerARM.h:
+ (JSC::MacroAssemblerARM::call):
+
+2010-11-24 Carlos Garcia Campos <cgarcia@igalia.com>
+
+ Reviewed by Xan Lopez.
+
+ [GTK] Optimize foldCase, toLower and toUpper methods in glib unicode backend
+ https://bugs.webkit.org/show_bug.cgi?id=48625
+
+ GLib methods use UTF-8 strings, so we have to convert from UTF-16 to
+ UTF-8 to perform the case operations and then convert back the result to
+ UTF-16. GLib conversion methods return a new allocated string, so we
+ have to memcpy the result into the destination buffer too. Using our
+ own methods to convert between UTF-8 and UTF-16 from wtf/unicode/UTF8.h
+ we don't need such memcpy, since they take an already allocated buffer
+ rather than returning a new one. There's another optimization for the
+ case when the destination buffer is not large enough. In that case,
+ methods should return the expected destination buffer size and are
+ called again with a new buffer. We can avoid the conversion to UTF-16 by
+ pre-calculating the required size for the destination buffer.
+
+ * wtf/unicode/glib/UnicodeGLib.cpp:
+ (WTF::Unicode::getUTF16LengthFromUTF8):
+ (WTF::Unicode::convertCase):
+ (WTF::Unicode::foldCase):
+ (WTF::Unicode::toLower):
+ (WTF::Unicode::toUpper):
+
+2010-11-23 Patrick Gansterer <paroga@webkit.org>
+
+ Reviewed by Sam Weinig.
+
+ Use WTF::StringHasher directly in JavaScriptCore
+ https://bugs.webkit.org/show_bug.cgi?id=49893
+
+ * profiler/CallIdentifier.h:
+ (JSC::CallIdentifier::Hash::hash):
+ * runtime/Identifier.cpp:
+ (JSC::IdentifierCStringTranslator::hash):
+ (JSC::IdentifierUCharBufferTranslator::hash):
+
+2010-11-22 Patrick Gansterer <paroga@webkit.org>
+
+ Reviewed by Sam Weinig.
+
+ Add WTF::FixedArray::size()
+ https://bugs.webkit.org/show_bug.cgi?id=49891
+
+ Add a method to get the size of a FixedArray.
+
+ * wtf/FixedArray.h:
+ (WTF::FixedArray::size):
+
+2010-11-22 Patrick Gansterer <paroga@webkit.org>
+
+ Reviewed by Adam Roben.
+
+ [WINCE] Set correct preprocessor definitions
+ https://bugs.webkit.org/show_bug.cgi?id=49887
+
+ * wtf/Platform.h:
+
+2010-11-22 Adam Roben <aroben@apple.com>
+
+ Use paths relative to $WebKitVSPropsRedirectionDir to access shared .vsprops files
+
+ Apple's Windows build allows placing header files and import libraries for WebKit's
+ dependencies (CoreGraphics, CFNetwork, SQLite, etc.) outside the source tree via the
+ $WebKitLibrariesDir environment variable. This is both required for production builds and
+ convenient for Apple-internal developer builds. Apple's production builds also require that
+ WebKit's shared .vsprops files be accessed relative to $WebKitLibrariesDir. In production
+ builds, the files are copied into that directory tree by the
+ WebKitLibraries/win/tools/WinTools.make file. In Apple-internal developer builds, the
+ copying is done by
+ JavaScriptCore/JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGenerated.make.
+
+ This .vsprops copying is problematic in one very important case: when a developer updates
+ their source tree and then tries to build. Visual Studio only reads .vsprops files when a
+ project is first loaded. So, when Visual Studio is first opened after the .vsprops files are
+ updated, it reads in the old files that were already residing in $WebKitLibrariesDir. When a
+ build is started, JavaScriptCoreGenerated.make copies the new .vsprops files into
+ $WebKitLibrariesDir, but Visual Studio will not pick up the changes. The rest of the build
+ will proceed with out-of-date .vsprops files, which will likely result in a build failure.
+
+ To fix this, we now use normal relative paths to access the .vsprops files in the source
+ tree rather than in $WebKitLibrariesDir, but prefix those paths with a new environment
+ variable, $WebKitVSPropsRedirectionDir. In developer builds, this environment variable is
+ unset, so the normal relative paths are used to read the .vsprops files out of the source
+ tree directly. In production builds, this environment variable is set to a fake directory
+ that will cause the .vsprops files in $WebKitLibrariesDir to be found when the relative path
+ is resolved.
+
+ For example, JavaScriptCore.vcproj uses this path for FeatureDefines.vsprops:
+
+ $(WebKitVSPropsRedirectionDir)..\..\..\WebKitLibraries\win\tools\vsprops\FeatureDefines.vsprops
+
+ In developer builds, where $WebKitVSPropsRedirectionDir is unset, this will point to the
+ files in WebKitLibraries\win\tools\vsprops in the source tree. In production builds,
+ JavaScriptCore.make sets $WebKitVSPropsRedirectionDir to
+ "$(SRCROOT)\AppleInternal\tools\vsprops\OpenSource\1\2\3\", so the full path for
+ FeatureDefines.vsprops becomes:
+
+ $(SRCROOT)\AppleInternal\tools\vsprops\OpenSource\1\2\3\..\..\..\WebKitLibraries\win\tools\vsprops\FeatureDefines.vsprops
+
+ which resolves to:
+
+ $(SRCROOT)\AppleInternal\tools\vsprops\OpenSource\WebKitLibraries\win\tools\vsprops\FeatureDefines.vsprops
+
+ (We rely on the fact that Windows doesn't care whether the directories "1", "2", and "3"
+ actually exist since they are matched by an equal number of ".." path components.)
+
+ Note that Visual Studio still won't pick up changes made to .vsprops files while Visual
+ Studio is open, but that problem hasn't seemed to cause developers many headaches so far.
+
+ Fixes <http://webkit.org/b/49181> Windows build fails mysteriously when .vsprops files are
+ updated
+
+ Reviewed by Dave Hyatt.
+
+ * JavaScriptCore.vcproj/JavaScriptCore.make: Set $WebKitVSPropsRedirectionDir so that
+ production builds can find the .vsprops files.
+
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGenerated.make: Stopy copying the
+ .vsprops files. It isn't needed anymore.
+
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
+ * JavaScriptCore.vcproj/WTF/WTF.vcproj:
+ * JavaScriptCore.vcproj/jsc/jsc.vcproj:
+ * JavaScriptCore.vcproj/testapi/testapi.vcproj:
+ Changed to use paths relative to $WebKitVSPropsRedirectionDir to access shared .vsprops
+ files.
+
+2010-11-19 Peter Varga <pvarga@inf.u-szeged.hu>
+
+ Reviewed by Gavin Barraclough.
+
+ YARR JIT should fallback to YARR Interpreter instead of PCRE.
+ https://bugs.webkit.org/show_bug.cgi?id=46719
+
+ Remove the ENABLE_YARR macro and the option of matching regular
+ expressions with PCRE from JavaScriptCore.
+
+ * runtime/JSGlobalData.h:
+ * runtime/RegExp.cpp:
+ (JSC::RegExp::compile):
+ (JSC::RegExp::match):
+ * tests/mozilla/expected.html:
+ * wtf/Platform.h:
+ * yarr/RegexCompiler.cpp:
+ * yarr/RegexCompiler.h:
+ * yarr/RegexInterpreter.cpp:
+ (JSC::Yarr::byteCompileRegex):
+ * yarr/RegexInterpreter.h:
+ * yarr/RegexJIT.cpp:
+ (JSC::Yarr::jitCompileRegex):
+ * yarr/RegexJIT.h:
+ (JSC::Yarr::RegexCodeBlock::RegexCodeBlock):
+ (JSC::Yarr::RegexCodeBlock::~RegexCodeBlock):
+ (JSC::Yarr::RegexCodeBlock::getFallback):
+ (JSC::Yarr::RegexCodeBlock::isFallback):
+ (JSC::Yarr::RegexCodeBlock::setFallback):
+ (JSC::Yarr::executeRegex):
+ * yarr/RegexParser.h:
+ * yarr/RegexPattern.h:
+
+2010-11-20 Kwang Yul Seo <skyul@company100.net>
+
+ Reviewed by David Kilzer.
+
+ [BREWMP] Replace DBGPRINTF and DBGPRINTF_FATAL with dbg_Message
+ https://bugs.webkit.org/show_bug.cgi?id=49520
+
+ DBGPRINTF and DBGPRINTF_FATAL macros are prohibited in Mod1. Use dbg_Message instead.
+
+ * wtf/Assertions.cpp:
+ * wtf/Assertions.h:
+
+2010-11-20 Gabor Loki <loki@webkit.org>
+
+ Reviewed by Gavin Barraclough.
+
+ Support JIT_OPTIMIZE_MOD on Thumb-2
+ https://bugs.webkit.org/show_bug.cgi?id=49432
+
+ Rewrite the soft modulo operation into macroassembler form, and move it
+ to JSValue32_64 section.
+ Add support for soft modulo on Thumb-2 JIT also.
+
+ * assembler/ARMv7Assembler.h:
+ (JSC::ARMv7Assembler::clz):
+ * assembler/MacroAssemblerARM.h:
+ (JSC::MacroAssemblerARM::countLeadingZeros32):
+ (JSC::MacroAssemblerARM::relativeTableJump):
+ * assembler/MacroAssemblerARMv7.h:
+ (JSC::MacroAssemblerARMv7::countLeadingZeros32):
+ (JSC::MacroAssemblerARMv7::relativeTableJump):
+ * jit/JITArithmetic.cpp:
+ (JSC::JIT::emit_op_mod):
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::privateCompileCTIMachineTrampolines):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::softModulo):
+ * jit/JITStubs.cpp:
+ (JSC::JITThunks::JITThunks):
+ * wtf/Platform.h:
+
+2010-11-20 David Kilzer <ddkilzer@apple.com>
+
+ <http://webkit.org/b/49848> Make it possible to display the last character of a secure text field unobscured
+
+ Reviewed by Darin Adler.
+
+ * JavaScriptCore.exp:
+ * wtf/text/StringImpl.cpp:
+ (WTF::StringImpl::secure): Added argument that controls whether
+ the last character is obscured or not. Implemented behavior.
+ * wtf/text/StringImpl.h:
+ (WTF::StringImpl::LastCharacterBehavior): Added enum.
+ (WTF::StringImpl::secure): Updated method signature.
+
+2010-11-19 William Chan <willchan@chromium.org>
+
+ Reviewed by David Levin.
+
+ Add USE(CHROMIUM_NET)
+
+ Indicates the use of Chromium's network stack. Chromium's network
+ stack performs better when it has full view of all resource requests,
+ so USE(CHROMIUM_NET) can be used to bypass throttles.
+
+ https://bugs.webkit.org/show_bug.cgi?id=49778
+
+ * wtf/Platform.h:
+
+2010-11-19 Steve Falkenburg <sfalken@apple.com>
+
+ Reviewed by Adam Roben.
+
+ Add Debug_Cairo_CFLite and Release_Cairo_CFLite configurations for all vcproj files
+ https://bugs.webkit.org/show_bug.cgi?id=49819
+
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGenerated.vcproj:
+ * JavaScriptCore.vcproj/WTF/WTF.vcproj:
+ * JavaScriptCore.vcproj/WTF/WTFCommon.vsprops:
+ * JavaScriptCore.vcproj/jsc/jsc.vcproj:
+ * JavaScriptCore.vcproj/testapi/testapi.vcproj:
+
+2010-11-19 Oliver Hunt <oliver@apple.com>
+
+ Reviewed by Geoffrey Garen.
+
+ Don't check for constant registers when we can guarantee that the register won't be in the constant pool
+ https://bugs.webkit.org/show_bug.cgi?id=49814
+
+ Add uncheckedR(int) to CallFrame, and replace all the uses of r() with uncheckedR()
+ when we can guarantee that the register is not referring to a constant.
+ This makes the interpreter about 0.5% faster, and makes the CallFrame initialisation
+ logic correct when we're using a faked callframe (as in the case of the globalExec).
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::createActivation):
+ * debugger/DebuggerCallFrame.cpp:
+ (JSC::DebuggerCallFrame::thisObject):
+ * interpreter/CallFrame.h:
+ (JSC::ExecState::uncheckedR):
+ * interpreter/Interpreter.cpp:
+ (JSC::Interpreter::resolve):
+ (JSC::Interpreter::resolveSkip):
+ (JSC::Interpreter::resolveGlobal):
+ (JSC::Interpreter::resolveGlobalDynamic):
+ (JSC::Interpreter::resolveBase):
+ (JSC::Interpreter::resolveBaseAndProperty):
+ (JSC::Interpreter::callEval):
+ (JSC::Interpreter::unwindCallFrame):
+ (JSC::Interpreter::throwException):
+ (JSC::Interpreter::execute):
+ (JSC::Interpreter::executeCall):
+ (JSC::Interpreter::executeConstruct):
+ (JSC::Interpreter::prepareForRepeatCall):
+ (JSC::Interpreter::createExceptionScope):
+ (JSC::Interpreter::privateExecute):
+ * jit/JITStubs.cpp:
+ (JSC::DEFINE_STUB_FUNCTION):
+ * runtime/JSActivation.cpp:
+ (JSC::JSActivation::argumentsGetter):
+
+2010-11-19 Steve Falkenburg <sfalken@apple.com>
+
+ Reviewed by Darin Adler.
+
+ Normalize Cairo/CFLite project/solution configuration names
+ https://bugs.webkit.org/show_bug.cgi?id=49818
+
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
+ * JavaScriptCore.vcproj/jsc/jsc.vcproj:
+ * JavaScriptCore.vcproj/testapi/testapi.vcproj:
+
+2010-11-18 Steve Falkenburg <sfalken@apple.com>
+
+ Reviewed by Adam Roben.
+
+ Windows vcproj configuration names should be normalized across projects
+ https://bugs.webkit.org/show_bug.cgi?id=49776
+
+ * JavaScriptCore.vcproj/JavaScriptCore.sln:
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGenerated.vcproj:
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedCommon.vsprops: Added.
+ * JavaScriptCore.vcproj/JavaScriptCoreSubmit.sln:
+
+2010-11-19 Patrick Gansterer <paroga@webkit.org>
+
+ Unreviewed, build fix after r72360.
+
+ * bytecode/CodeBlock.h:
+ (JSC::CodeBlock::bytecodeOffset):
+
+2010-11-18 Gavin Barraclough <barraclough@apple.com>
+
+ Rubber stamped by Geoff Garen.
+
+ Bug 49577 - Function.prototype should be non-configurable
+
+ Ooops, Function.prototype should not be enumerable!
+
+ * runtime/JSFunction.cpp:
+ (JSC::JSFunction::getOwnPropertySlot):
+
+2010-11-18 Gavin Barraclough <barraclough@apple.com>
+
+ Reviewed by Oliver Hunt.
+
+ Bug 49708 - Stop recompiling functions to regenerate exception info.
+
+ Instead only hold info as necessary – keep divot info is the inspector
+ is enabled, line number info is debugging or profiling, and handler
+ info for functions with try/catch.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpStatistics):
+ (JSC::CodeBlock::CodeBlock):
+ (JSC::CodeBlock::lineNumberForBytecodeOffset):
+ (JSC::CodeBlock::expressionRangeForBytecodeOffset):
+ (JSC::CodeBlock::shrinkToFit):
+ * bytecode/CodeBlock.h:
+ (JSC::CodeBlock::bytecodeOffset):
+ (JSC::CodeBlock::addExpressionInfo):
+ (JSC::CodeBlock::addLineInfo):
+ (JSC::CodeBlock::hasExpressionInfo):
+ (JSC::CodeBlock::hasLineInfo):
+ (JSC::CodeBlock::needsCallReturnIndices):
+ (JSC::CodeBlock::callReturnIndexVector):
+ * bytecode/SamplingTool.cpp:
+ (JSC::SamplingTool::dump):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::generate):
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ * bytecompiler/BytecodeGenerator.h:
+ (JSC::BytecodeGenerator::emitNode):
+ (JSC::BytecodeGenerator::emitNodeInConditionContext):
+ (JSC::BytecodeGenerator::emitExpressionInfo):
+ (JSC::BytecodeGenerator::addLineInfo):
+ * interpreter/Interpreter.cpp:
+ (JSC::Interpreter::unwindCallFrame):
+ (JSC::appendSourceToError):
+ (JSC::Interpreter::throwException):
+ (JSC::Interpreter::privateExecute):
+ (JSC::Interpreter::retrieveLastCaller):
+ * interpreter/Interpreter.h:
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompile):
+ * jit/JITStubs.cpp:
+ (JSC::jitThrow):
+ (JSC::DEFINE_STUB_FUNCTION):
+ * runtime/Collector.cpp:
+ (JSC::Heap::markRoots):
+ * runtime/Executable.cpp:
+ (JSC::EvalExecutable::compileInternal):
+ (JSC::ProgramExecutable::compileInternal):
+ (JSC::FunctionExecutable::compileForCallInternal):
+ (JSC::FunctionExecutable::compileForConstructInternal):
+ * runtime/Executable.h:
+ * runtime/JSGlobalData.cpp:
+ (JSC::JSGlobalData::JSGlobalData):
+ * runtime/JSGlobalData.h:
+ (JSC::JSGlobalData::usingAPI):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::supportsRichSourceInfo):
+ (JSC::JSGlobalObject::globalData):
+
+2010-11-18 Adam Roben <aroben@apple.com>
+
+ Add a script to delete manifest-related files when they are older than
+ any .vsprops file
+
+ Changes to .vsprops files can cause the manifest files to become
+ invalid, and Visual Studio doesn't always figure out that it needs to
+ rebuild them.
+
+ Reviewed by Sam Weinig.
+
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGenerated.make:
+ Call the new script.
+
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGenerated.vcproj:
+ Added the new script.
+
+ * JavaScriptCore.vcproj/JavaScriptCore/react-to-vsprops-changes.py: Added.
+ (file_modification_times): Generator to return the modification time of
+ each file in a directory hierarchy.
+ (main): Get the modification time of the newest vsprops file, then find
+ all manifest-related files in the obj directory. Delete all
+ manifest-related files that are older than the newest vsprops file.
+
+2010-11-18 Mark Rowe <mrowe@apple.com>
+
+ Rubber-stamped by Adam Roben.
+
+ <rdar://problem/8602509&8602717&8602724> Enable compaction support.
+
+ * Configurations/JavaScriptCore.xcconfig:
+
+2010-11-18 Gavin Barraclough <barraclough@apple.com>
+
+ Reviewed by Oliver Hunt.
+
+ Bug 49635 - Profiler implementation is fragile
+
+ The profile presently requires the exception handling mechanism to explicitly
+ remove all stack frames that are exited during the exception unwind mechanism.
+ This is fragile in a number of ways:
+ * We have to change bytecode register allocation when compiling code to run
+ when profiling, to preserve the callee function (this is also required to
+ call did_call after the call has returned).
+ * In the JIT we have to maintain additional data structures
+ (CodeBlock::RareData::m_functionRegisterInfos) to map back to the register
+ containing the callee.
+ * In the interpreter we use 'magic values' to offset into the instruction
+ stream to rediscover the register containing the function.
+
+ Instead, move profiling into the head and tail of functions.
+ * This correctly accounts the cost of the call itself to the caller.
+ * This allows us to access the callee function object from the callframe.
+ * This means that at the point a call is made we can track the stack depth
+ on the ProfileNode.
+ * When unwinding we can simply report the depth at which the exception is
+ being handled - all call frames above this level are freed.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::shrinkToFit):
+ * bytecode/CodeBlock.h:
+ (JSC::CodeBlock::bytecodeOffset):
+ (JSC::CodeBlock::methodCallLinkInfo):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitCall):
+ (JSC::BytecodeGenerator::emitCallVarargs):
+ * interpreter/Interpreter.cpp:
+ (JSC::Interpreter::unwindCallFrame):
+ (JSC::Interpreter::throwException):
+ (JSC::Interpreter::execute):
+ (JSC::Interpreter::executeCall):
+ (JSC::Interpreter::executeConstruct):
+ (JSC::Interpreter::privateExecute):
+ * jit/JITStubs.cpp:
+ (JSC::DEFINE_STUB_FUNCTION):
+ * profiler/Profile.cpp:
+ (JSC::Profile::Profile):
+ * profiler/ProfileGenerator.cpp:
+ (JSC::ProfileGenerator::addParentForConsoleStart):
+ (JSC::ProfileGenerator::willExecute):
+ (JSC::ProfileGenerator::didExecute):
+ (JSC::ProfileGenerator::exceptionUnwind):
+ (JSC::ProfileGenerator::stopProfiling):
+ * profiler/ProfileGenerator.h:
+ * profiler/ProfileNode.cpp:
+ (JSC::ProfileNode::ProfileNode):
+ (JSC::ProfileNode::willExecute):
+ * profiler/ProfileNode.h:
+ (JSC::ProfileNode::create):
+ (JSC::ProfileNode::callerCallFrame):
+ * profiler/Profiler.cpp:
+ (JSC::dispatchFunctionToProfiles):
+ (JSC::Profiler::_willExecute):
+ (JSC::Profiler::_didExecute):
+ (JSC::Profiler::exceptionUnwind):
+ * profiler/Profiler.h:
+
+2010-11-18 Steve Falkenburg <sfalken@apple.com>
+
+ Reviewed by Adam Roben.
+
+ Remove leftover Windows Debug_Internal configurations
+ https://bugs.webkit.org/show_bug.cgi?id=49758
+
+ * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
+ * JavaScriptCore.vcproj/WTF/WTF.vcproj:
+ * JavaScriptCore.vcproj/jsc/jsc.vcproj:
+ * JavaScriptCore.vcproj/testapi/testapi.vcproj:
+
+2010-11-18 Chao-ying Fu <fu@mips.com>
+
+ Reviewed by Csaba Osztrogonác.
+
+ Avoid increasing required alignment of target type warning
+ https://bugs.webkit.org/show_bug.cgi?id=43963
+
+ * runtime/UString.h:
+ (JSC::UStringHash::equal):
+ * wtf/StdLibExtras.h:
+
2010-11-17 Sam Weinig <sam@webkit.org>
Reviewed by Anders Carlsson.