ChangeLog-2015-07-23   [plain text]


2015-07-20  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r186819. rdar://problem/21729083

    2015-07-14  Matthew Mirman  <mmirman@apple.com>

            Repatch. Makes compileArithSub in the DFG ensure that the constant is an int32.
            https://bugs.webkit.org/show_bug.cgi?id=146910
            rdar://problem/21729083

            Reviewed by Filip Pizlo.

            Also fixes the debug build problem where all edges are assumed to
            have UntypedUse before the fixup phase.

            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::compileArithSub):
            * dfg/DFGValidate.cpp:
            (JSC::DFG::Validate::validateEdgeWithDoubleResultIfNecessary):
            * tests/stress/arith-add-with-constants.js: Added some tests for this case.
            (arithAdd42WrittenAsInteger):
            (testArithAdd42WrittenAsInteger):
            (arithSub42WrittenAsDouble):
            (testArithSub42WrittenAsDouble):
            (doubleConstant):
            (testDoubleConstant): Added test for the case of +0.0 and Math.min(0.0)
            (arithAdd42WrittenAsDouble): Deleted.
            (testArithAdd42WrittenAsDouble): Deleted.

2015-07-20  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r187028. rdar://problem/21869970

    2015-07-18  Filip Pizlo  <fpizlo@apple.com>

            REGRESSION(186691): OSR entry is broken on loop headers that have no live variables
            https://bugs.webkit.org/show_bug.cgi?id=147074
            rdar://problem/21869970

            Reviewed by Michael Saboff.

            The OSR entry must-handle block/value widening introduced in r186691 would cause the
            CFA to reexecute if it caused any live local variables to change value. But this fails
            if the must-handle block has no live local variables, and the entry block otherwise
            appears to be unreachable.

            This fixes the bug by having the change detection include whether the block hadn't been
            visited in addition to whether any local variable values got widened.

            This is a ~4% speed-up on SunSpider in browser.

            * dfg/DFGCFAPhase.cpp:
            (JSC::DFG::CFAPhase::run):

2015-07-16  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r186920. rdar://problem/21764196

    2015-07-16  Mark Lam  <mark.lam@apple.com>

            RegExp::match() should set m_state to ByteCode if compilation fails.
            https://bugs.webkit.org/show_bug.cgi?id=147023

            Reviewed by Michael Saboff.

            A RegExp has a YarrCodeBlock that has 4 MacroAssemblerCodeRefs for compiled code.
            If one of these compilations succeeds, RegExp::m_state will be set to JITCode.
            Subsequently, if RegExp tries to compile another one of these but fails, m_state
            will be left untouched i.e. it still says JITCode.  As a result, when
            RegExp::match() later tries to execute the non-existant compiled code, it will
            crash.

            The fix is to downgrade m_state to ByteCode if RegExp ever fails to compile.
            This failure should be rare.  We'll do the minimal work here to fix the issue and
            keep an eye on the perf bots.  If perf regresses, we can do some optimization work then.

            This issue is difficult to test for since it either requires a low memory condition
            to trigger a failed RegExp compilation at the right moment, or for the RegExp to
            succeed compilation in the MatchedOnly mode but fail in IncludeSubpatterns mode.
            Instead, I manually tested it by instrumenting RegExp::compile() to fail once in every
            10 compilation attempts.

            * runtime/RegExp.cpp:
            (JSC::RegExp::compile):
            (JSC::RegExp::compileMatchOnly):

2015-07-15  Lucas Forschler  <lforschler@apple.com>

        Merge r186826

    2015-07-14  Anders Carlsson  <andersca@apple.com>

            Assertions.h should include ExportMacros.h
            https://bugs.webkit.org/show_bug.cgi?id=146948

            Reviewed by Tim Horton.

            Remove now unneeded WTF_EXPORT_PRIVATE define.

            * API/JSBase.h:

2015-07-13  Babak Shafiei  <bshafiei@apple.com>

        Merge r186777.

    2015-07-13  Anders Carlsson  <andersca@apple.com>

            Apps linked with a deployment target of iOS 7.x or earlier crash when using modern WebKit API
            https://bugs.webkit.org/show_bug.cgi?id=146913
            rdar://problem/21789252

            Reviewed by Dan Bernstein.

            Make a top-level symlink from /System/Library/PrivateFrameworks/JavaScriptCore.framework to
            /System/Library/Frameworks/JavaScriptCore.framework.

            * JavaScriptCore.xcodeproj/project.pbxproj:

2015-07-12  Babak Shafiei  <bshafiei@apple.com>

        Merge r186702.

    2015-07-10  Filip Pizlo  <fpizlo@apple.com>

            AI folding of IsObjectOrNull is broken for non-object types that may be null
            https://bugs.webkit.org/show_bug.cgi?id=146867

            Reviewed by Ryosuke Niwa.

            * dfg/DFGAbstractInterpreterInlines.h:
            (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Fix the bug and add some text describing what is going on.
            * tests/stress/misc-is-object-or-null.js: Added. Test for the bug.
            (foo):
            * tests/stress/other-is-object-or-null.js: Added. Test for a bug I almost introduced.
            (foo):

2015-07-12  Babak Shafiei  <bshafiei@apple.com>

        Merge r186691.

    2015-07-04  Filip Pizlo  <fpizlo@apple.com>

            DFG fragile frozen values are fundamentally broken
            https://bugs.webkit.org/show_bug.cgi?id=146602

            Reviewed by Mark Lam.

            This change gets rid of the FragileValue value strength, because it was fundamentally
            broken.

            FragileValue was a value known to the compiler but not tracked by the GC in any way -
            it wasn't marked and it wasn't weak. This was used to support AI bootstrap for OSR
            must-handle values. The philosophy was that if the compiler did use the value for
            optimization, it would have been strengthened to a weak value (or maybe even a strong
            value, though we probably won't do that). But this was too much of a pipe dream. I've
            found at least one case where the compiler did use the value, but never strengthened
            it: it would happen if the value ended up in an OSR entry data expected value. Then if
            we GCed, we might have killed the value, but OSR entry would still try to use it for
            validation. That might have sort of just worked, but it's clearly shady.

            The reason why we made must-handle values fragile and not weak is that most of the time
            the values disappear from the abstract state: they are LUBed to a non-constant. If we
            kept them around as weak, we'd have too many cases of the GC killing the code because
            it thought that the value was somehow meaningful to the code when it was only used as a
            temporary artifact of optimization.

            So, it's true that it's very important for must-handle values not to automatically be
            weak or strong. It's also true that the values are necessary for AI bootstrap because
            we need to know what values OSR entry will require. But we shouldn't accomplish these
            goals by having the compiler hold onto what are essentially dangling pointers.

            This implements a better solution: instead of having InPlaceAbstractState bootstrap the
            AI with must-handle values at the beginning, we now widen the valuesAtHead of the
            must-handle block after AI converges. This widening is done in CFAPhase. This allows us
            to see if the must-handle values are necessary at all. In most cases, the widening
            takes a non-constant abstract value and simply amends something to its type based on
            the type of the must-handle value, and so the must-handle value never actually shows up
            in either the IR or any abstract value. In the unlikely event that the value at head is
            bottom, we freeze the must-handle value. This change removes FragileValue, and this
            freezing uses WeakValue as the strength. That makes sense: since the abstract value was
            bottom, the must-handle value becomes integral to the IR and so it makes no sense for
            the GC to keep the resulting CodeBlock alive if that must-handle value dies. This will
            sometimes happen for example if you have a very long-running loop whose pre-header
            allocates some object, but that pre-header appears to always exit to the optimizing JIT
            because it was only profiled once in the LLInt and that profiling appears insufficient
            to the DFG. In that case, we'll effectively constant-fold the references to the object
            inside the loop, which is both efficient (yay constant folding!) and necessary
            (otherwise we wouldn't know what the type of the variable should have been).

            Testing and debugging this is complicated. So, this adds some new capabilities:

            - DFG IR dumps also dump all of the FrozenValues that point to the heap along with
              their strengths, so that it's easy to see what GC objects the DFG feels are necessary
              for the compilation.

            - DFG OSR entry preparation prints out the OSR entry data structures, so that it's easy
              to see what GC pointers (and other things) are used for OSR entry validation. The
              printouts are quite detailed, and should also help other kinds of OSR entry
              debugging.

            - DFG::Plan now validates whether all of the GC pointers planted in the various JITCode
              data structures are also properly registered as either weak or strong pointers in the
              CodeBlock. This validation check previously failed due to fragile values ending up in
              the OSR entry data structures, both in the newly added test (dead-osr-entry-value.js)
              and in some pre-existing tests (like earley-boyer and 3d-raytrace).

            * CMakeLists.txt:
            * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
            * JavaScriptCore.xcodeproj/project.pbxproj:
            * bytecode/CodeBlock.cpp:
            (JSC::CodeBlock::stronglyVisitStrongReferences):
            * bytecode/CodeOrigin.cpp:
            (JSC::InlineCallFrame::visitAggregate):
            * bytecode/Operands.h:
            (JSC::Operands::operand):
            (JSC::Operands::hasOperand):
            * bytecode/StructureSet.cpp:
            (JSC::StructureSet::dump):
            (JSC::StructureSet::validateReferences):
            * bytecode/StructureSet.h:
            * bytecode/TrackedReferences.cpp: Added.
            (JSC::TrackedReferences::TrackedReferences):
            (JSC::TrackedReferences::~TrackedReferences):
            (JSC::TrackedReferences::add):
            (JSC::TrackedReferences::check):
            (JSC::TrackedReferences::dump):
            * bytecode/TrackedReferences.h: Added.
            * dfg/DFGAbstractValue.cpp:
            (JSC::DFG::AbstractValue::observeTransitions):
            (JSC::DFG::AbstractValue::set):
            (JSC::DFG::AbstractValue::fixTypeForRepresentation):
            (JSC::DFG::AbstractValue::mergeOSREntryValue):
            (JSC::DFG::AbstractValue::filter):
            (JSC::DFG::AbstractValue::dumpInContext):
            (JSC::DFG::AbstractValue::validateReferences):
            (JSC::DFG::AbstractValue::setOSREntryValue): Deleted.
            * dfg/DFGAbstractValue.h:
            (JSC::DFG::AbstractValue::fullTop):
            (JSC::DFG::AbstractValue::merge):
            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
            * dfg/DFGCFAPhase.cpp:
            (JSC::DFG::CFAPhase::run):
            * dfg/DFGCommonData.cpp:
            (JSC::DFG::CommonData::invalidate):
            (JSC::DFG::CommonData::validateReferences):
            * dfg/DFGCommonData.h:
            (JSC::DFG::CommonData::requiredRegisterCountForExecutionAndExit):
            * dfg/DFGFrozenValue.h:
            (JSC::DFG::FrozenValue::FrozenValue):
            (JSC::DFG::FrozenValue::strengthenTo):
            (JSC::DFG::FrozenValue::pointsToHeap):
            (JSC::DFG::FrozenValue::strength):
            (JSC::DFG::FrozenValue::freeze):
            * dfg/DFGGraph.cpp:
            (JSC::DFG::Graph::Graph):
            (JSC::DFG::Graph::dump):
            (JSC::DFG::Graph::registerFrozenValues):
            (JSC::DFG::Graph::visitChildren):
            (JSC::DFG::Graph::freeze):
            (JSC::DFG::Graph::freezeStrong):
            (JSC::DFG::Graph::freezeFragile): Deleted.
            * dfg/DFGGraph.h:
            * dfg/DFGInPlaceAbstractState.cpp:
            (JSC::DFG::InPlaceAbstractState::initialize):
            * dfg/DFGJITCode.cpp:
            (JSC::DFG::JITCode::setOptimizationThresholdBasedOnCompilationResult):
            (JSC::DFG::JITCode::validateReferences):
            * dfg/DFGJITCode.h:
            * dfg/DFGJITCompiler.cpp:
            (JSC::DFG::JITCompiler::addressOfDoubleConstant):
            (JSC::DFG::JITCompiler::noticeOSREntry):
            * dfg/DFGJITCompiler.h:
            (JSC::DFG::JITCompiler::branchStructurePtr):
            (JSC::DFG::JITCompiler::jitCode):
            (JSC::DFG::JITCompiler::noticeOSREntry): Deleted.
            * dfg/DFGMinifiedGraph.cpp: Added.
            (JSC::DFG::MinifiedGraph::prepareAndShrink):
            (JSC::DFG::MinifiedGraph::validateReferences):
            * dfg/DFGMinifiedGraph.h:
            (JSC::DFG::MinifiedGraph::append):
            (JSC::DFG::MinifiedGraph::prepareAndShrink): Deleted.
            * dfg/DFGOSREntry.cpp:
            (JSC::DFG::OSREntryData::dumpInContext):
            (JSC::DFG::OSREntryData::dump):
            (JSC::DFG::prepareOSREntry):
            * dfg/DFGOSREntry.h:
            (JSC::DFG::getOSREntryDataBytecodeIndex):
            * dfg/DFGPlan.cpp:
            (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::linkOSREntries):
            (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
            * dfg/DFGStructureAbstractValue.cpp:
            (JSC::DFG::StructureAbstractValue::dump):
            (JSC::DFG::StructureAbstractValue::validateReferences):
            * dfg/DFGStructureAbstractValue.h:
            * dfg/DFGValidate.cpp:
            (JSC::DFG::Validate::validate):
            * dfg/DFGValueStrength.cpp:
            (WTF::printInternal):
            * dfg/DFGValueStrength.h:
            (JSC::DFG::merge):
            * ftl/FTLExitPropertyValue.cpp:
            (JSC::FTL::ExitPropertyValue::dump):
            (JSC::FTL::ExitPropertyValue::validateReferences):
            * ftl/FTLExitPropertyValue.h:
            * ftl/FTLExitTimeObjectMaterialization.cpp:
            (JSC::FTL::ExitTimeObjectMaterialization::dump):
            (JSC::FTL::ExitTimeObjectMaterialization::validateReferences):
            * ftl/FTLExitTimeObjectMaterialization.h:
            * ftl/FTLExitValue.cpp:
            (JSC::FTL::ExitValue::dump):
            (JSC::FTL::ExitValue::validateReferences):
            * ftl/FTLExitValue.h:
            * ftl/FTLJITCode.cpp:
            (JSC::FTL::JITCode::dfgCommon):
            (JSC::FTL::JITCode::validateReferences):
            * ftl/FTLJITCode.h:
            (JSC::FTL::JITCode::handles):
            (JSC::FTL::JITCode::dataSections):
            * ftl/FTLOSRExit.cpp:
            (JSC::FTL::OSRExit::codeLocationForRepatch):
            (JSC::FTL::OSRExit::validateReferences):
            * ftl/FTLOSRExit.h:
            (JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
            * jit/JITCode.cpp:
            (JSC::JITCode::typeName):
            (JSC::JITCode::validateReferences):
            (JSC::JITCode::execute):
            * jit/JITCode.h:
            (JSC::JITCode::start):
            * tests/stress/dead-osr-entry-value.js: Added.
            (foo):

2015-07-10  Matthew Hanson  <matthew_hanson@apple.com>

        Disable non-shipping features.

        * Configurations/FeatureDefines.xcconfig:

2015-07-09  Mark Lam  <mark.lam@apple.com>

        SymbolTable::entryFor() should do a bounds check before indexing into the localToEntry vector.
        https://bugs.webkit.org/show_bug.cgi?id=146807

        Reviewed by Filip Pizlo.

        When we capture an argument by name and we use "arguments", we put all of the
        arguments into the scope.  But destructured arguments are put into the scope
        anonymously i.e. the SymbolTable knows that the scope offset is in use via
        SymbolTable::m_maxScopeOffset, but that ScopeOffset won't appear in
        SymbolTable::m_map.

        The SymbolTable's m_localToEntry vector is synthesized from its m_map, and will
        have a size which is based on the largest ScopeOffset in the m_map.  If we have a
        scenario where the anonymous argument is at a higher ScopeOffset than all the
        named arguments, then the m_localsToEntry vector will not have an entry for it
        i.e. the m_localsToEntry vector will have a size that is <= the ScopeOffset of
        the anonymous argument.

        Hence, SymbolTable::entryFor() should ensure that the requested ScopeOffset is
        within the bounds of the m_localToEntry vector before indexing into it.

        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::entryFor):

2015-07-09  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r180248): Repro Crash: com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::createRangeError + 20
        https://bugs.webkit.org/show_bug.cgi?id=146767

        Reviewed by Geoffrey Garen.

        If the stack check fails at the top most frame, we must use that frame to
        generate the exception.  Reverted the code to always use the current frame to
        throw an out of stack exception.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):

2015-07-03  Filip Pizlo  <fpizlo@apple.com>

        OSR exit fuzzing should allow us to select a static exit site
        https://bugs.webkit.org/show_bug.cgi?id=146601

        Reviewed by Geoffrey Garen.
        
        The original implementation of the fuzzer allows us to trigger an exit based on its index
        in the dynamic sequence of exit sites encountered. But there are usually millions of
        dynamically encountered exit sites, even if the program only has thousands of static exit
        sites. That means that we would at best be able to do a random sampling of exits, and
        those would be biased to the hottest exit sites.
        
        This change allows us to also select exit sites based on their index in the static
        sequence of exit sites that the compiler compiled. Then, once that static exit site is
        selected, we can select which dynamic exit at that exit site we should trigger. Since the
        number of static exit sites is usually smallish (it's bounded by program size), we can do
        an exhaustive search over all exit sites in most programs.

        * dfg/DFGOSRExitFuzz.cpp:
        (JSC::numberOfStaticOSRExitFuzzChecks):
        (JSC::numberOfOSRExitFuzzChecks):
        * dfg/DFGOSRExitFuzz.h:
        (JSC::DFG::doOSRExitFuzzing):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitOSRExitFuzzCheck):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        * jsc.cpp:
        (jscmain):
        * runtime/Options.h:
        * runtime/TestRunnerUtils.h:

2015-07-08  Joseph Pecoraro  <pecoraro@apple.com>

        Fix grammar issue in TypeError attempting to change an unconfigurable property
        https://bugs.webkit.org/show_bug.cgi?id=146774

        Reviewed by Brent Fulgham.

        * runtime/JSFunction.cpp:
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSObject.cpp:
        (JSC::JSObject::defineOwnNonIndexProperty):
        * runtime/StringObject.cpp:
        (JSC::StringObject::defineOwnProperty):

2015-07-06  Csaba Osztrogonác  <ossy@webkit.org>

        Remove the unused HeapBlock.h
        https://bugs.webkit.org/show_bug.cgi?id=146580

        Reviewed by Andreas Kling.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/CopiedBlock.h:
        * heap/CopiedSpace.h:
        * heap/CopiedSpaceInlines.h:
        * heap/HandleBlock.h:
        * heap/HeapBlock.h: Removed.
        * heap/MarkedBlock.h:

2015-07-06  Saam barati  <saambarati1@gmail.com>

        JSC's parser should follow the ES6 spec with respect to parsing Declarations
        https://bugs.webkit.org/show_bug.cgi?id=146621

        Reviewed by Mark Lam.

        There were a few locations where JSC would allow declaration statements
        in incorrect ways. JSC didn't distinguish between 'Statement' and
        'StatementListItem' grammar productions. The relevant grammar is here:
        http://www.ecma-international.org/ecma-262/6.0/index.html#sec-statements

        From the ECMA Script 6.0 spec:
        1. Section 13.6 The if Statement (http://www.ecma-international.org/ecma-262/6.0/index.html#sec-if-statement) 
         says that IfStatements only takes Statements for the "then-else" clauses, not StatementListItems.
         (Same with 'while/for/do-while' loop bodies).
        2. Section 13 ECMAScript Language: Statements and Declarations 
         (http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ecmascript-language-statements-and-declarations)
         defines the syntax of Statements, and they do not include ClassDeclarations and LexicalDeclarations 
         (const, let, see 13.3.1 Let and Const Declarations).
         Declarations can only be in the “then-else” clauses when embedded in a StatementListItem in a BlockStatement (see 13.2).

        Hence, the following style of declarations are no longer allowed:
            'if/for/while (condition) const x = 40;'
            'if/for/while (condition) class C { }'

        Instead, we mandate such declaration constructs are within a StatementList 
       (which is the production that JSC's Parser::parseSourceElements function parses):
           'if/for/while (condition) { const x = 40; }'
           'if/for/while (condition) { class C { } }'

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseSourceElements):
        (JSC::Parser<LexerType>::parseStatementListItem):
        (JSC::Parser<LexerType>::parseVarDeclaration):
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::Parser<LexerType>::parseExpressionStatement):
        * parser/Parser.h:
        (JSC::Parser::getLabel):

2015-07-06  Alex Christensen  <achristensen@webkit.org>

        Unreviewed debug build fix after r186358.

        * runtime/JSArray.cpp:
        (JSC::JSArray::fastConcatWith):
        Pass vm parameter to fastConcatType.

2015-07-06  Ryosuke Niwa  <rniwa@webkit.org>

        Array.concat should be fast for integer or double arrays
        https://bugs.webkit.org/show_bug.cgi?id=146260

        Reviewed by Darin Adler.

        Added a fast path to Array.prototype.concat. When concatenating two Int32, Double, or Contiguous
        arrays, simply memcopy the arrays into a new uninitialized buffer.

        This improves huffman encoding in CompressionBench by 3.7x on a Mid 2014 MacBookPro.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncConcat):
        * runtime/JSArray.cpp:
        (JSC::JSArray::fastConcatWith): Added.
        * runtime/JSArray.h:
        (JSC::JSArray::fastConcatType): Added. Returns the resultant array's indexing type if we can use
        the fact path. Returns NonArray otherwise.

2015-07-06  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        [Streams API] Remove ReadableStream custom constructor
        https://bugs.webkit.org/show_bug.cgi?id=146547

        Reviewed by Darin Adler.

        Adding helper function to throw range errors.

        * runtime/Error.h:
        (JSC::throwRangeError):
        (JSC::throwVMRangeError):

2015-07-05  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement the latest Promise spec in JS
        https://bugs.webkit.org/show_bug.cgi?id=146229

        Reviewed by Sam Weinig.

        Updated the Promise implementation to meet to the ES6 spec.
        This patch
        1. Implement ES6 Promise and related abstract operations in builtins JS
        2. Expose @enqueueJob private function to JS world to post the microtask

        Updated implementation has one-on-one correspondence to the ES6 spec description.
        And keep the JSPromiseDeferred because it is the interface used from the WebCore.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/Array.prototype.js:
        (reduce):
        (reduceRight):
        (every):
        (forEach):
        (filter):
        (map):
        (some):
        (fill):
        (find):
        (findIndex):
        (includes):
        (copyWithin):
        ToInteger / ToLength are renamed to toInteger and toLength.
        * builtins/ArrayConstructor.js:
        (from):
        ToInteger / ToLength are renamed to toInteger and toLength.
        * builtins/GlobalObject.js:
        (toInteger):
        (toLength):
        (isObject):
        (ToInteger): Deleted.
        (ToLength): Deleted.
        ToInteger / ToLength are renamed to toInteger and toLength.
        Add new abstract operation, isObject.
        * builtins/Operations.Promise.js: Added.
        (isPromise):
        (newPromiseReaction):
        (newPromiseDeferred):
        (newPromiseCapability.executor):
        (newPromiseCapability):
        (triggerPromiseReactions):
        (rejectPromise):
        (fulfillPromise):
        (createResolvingFunctions.resolve):
        (createResolvingFunctions.reject):
        (createResolvingFunctions):
        (promiseReactionJob):
        (promiseResolveThenableJob):
        (initializePromise):
        Added Promise related abstract operations.
        * builtins/Promise.prototype.js:
        (catch):
        (.onFulfilled):
        (.onRejected):
        (then):
        Promise#then implementation in JS.
        * builtins/PromiseConstructor.js: Added.
        (all.newResolveElement):
        (all):
        (race):
        (reject):
        (resolve):
        Promise static functions implementations in JS.
        * builtins/StringConstructor.js:
        (raw):
        ToInteger / ToLength are renamed to toInteger and toLength.
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::enqueueJob):
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::initializePromiseFunction):
        (JSC::JSGlobalObject::newPromiseDeferredFunction):
        * runtime/JSJob.cpp: Renamed from Source/JavaScriptCore/runtime/JSPromiseReaction.h.
        (JSC::createJSJob):
        (JSC::JSJobMicrotask::run):
        * runtime/JSJob.h: Renamed from Source/JavaScriptCore/runtime/JSPromiseFunctions.h.
        * runtime/JSPromise.cpp:
        (JSC::JSPromise::create):
        (JSC::JSPromise::JSPromise):
        (JSC::JSPromise::finishCreation):
        (JSC::JSPromise::result):
        (JSC::JSPromise::destroy): Deleted.
        (JSC::JSPromise::visitChildren): Deleted.
        (JSC::JSPromise::reject): Deleted.
        (JSC::JSPromise::resolve): Deleted.
        (JSC::JSPromise::appendResolveReaction): Deleted.
        (JSC::JSPromise::appendRejectReaction): Deleted.
        (JSC::triggerPromiseReactions): Deleted.
        * runtime/JSPromise.h:
        (JSC::JSPromise::status): Deleted.
        (JSC::JSPromise::result): Deleted.
        (JSC::JSPromise::constructor): Deleted.
        * runtime/JSPromiseConstructor.cpp:
        (JSC::constructPromise):
        (JSC::JSPromiseConstructorFuncResolve): Deleted.
        (JSC::JSPromiseConstructorFuncReject): Deleted.
        (JSC::performPromiseRaceLoop): Deleted.
        (JSC::JSPromiseConstructorFuncRace): Deleted.
        (JSC::performPromiseAll): Deleted.
        (JSC::JSPromiseConstructorFuncAll): Deleted.
        * runtime/JSPromiseDeferred.cpp:
        (JSC::JSPromiseDeferred::create):
        (JSC::createJSPromiseDeferredFromConstructor): Deleted.
        (JSC::updateDeferredFromPotentialThenable): Deleted.
        (JSC::performDeferredResolve): Deleted.
        (JSC::performDeferredReject): Deleted.
        (JSC::abruptRejection): Deleted.
        * runtime/JSPromiseDeferred.h:
        * runtime/JSPromiseFunctions.cpp: Removed.
        (JSC::deferredConstructionFunction): Deleted.
        (JSC::createDeferredConstructionFunction): Deleted.
        (JSC::identifyFunction): Deleted.
        (JSC::createIdentifyFunction): Deleted.
        (JSC::promiseAllCountdownFunction): Deleted.
        (JSC::createPromiseAllCountdownFunction): Deleted.
        (JSC::promiseResolutionHandlerFunction): Deleted.
        (JSC::createPromiseResolutionHandlerFunction): Deleted.
        (JSC::rejectPromiseFunction): Deleted.
        (JSC::createRejectPromiseFunction): Deleted.
        (JSC::resolvePromiseFunction): Deleted.
        (JSC::createResolvePromiseFunction): Deleted.
        (JSC::throwerFunction): Deleted.
        (JSC::createThrowerFunction): Deleted.
        * runtime/JSPromisePrototype.cpp:
        (JSC::JSPromisePrototypeFuncThen): Deleted.
        * runtime/JSPromiseReaction.cpp: Removed.
        (JSC::createExecutePromiseReactionMicrotask): Deleted.
        (JSC::ExecutePromiseReactionMicrotask::run): Deleted.
        (JSC::JSPromiseReaction::create): Deleted.
        (JSC::JSPromiseReaction::JSPromiseReaction): Deleted.
        (JSC::JSPromiseReaction::finishCreation): Deleted.
        (JSC::JSPromiseReaction::visitChildren): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM): Deleted.
        * runtime/VM.h:

2015-07-04  Chris Dumez  <cdumez@apple.com>

        Drop RefPtr::clear() method
        https://bugs.webkit.org/show_bug.cgi?id=146556

        Reviewed by Brady Eidson.

        Drop RefPtr::clear() method in favor of "= nullptr;" pattern.

2015-07-03  Dan Bernstein  <mitz@apple.com>

        Just give up on -Wunreachable-code in JavaScriptCore.

        * Configurations/Base.xcconfig:
        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoop::execute):

2015-07-03  Dan Bernstein  <mitz@apple.com>

        Fixed the LLINT CLoop build.

        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoop::execute):

2015-07-03  Dan Bernstein  <mitz@apple.com>

        [Xcode] Update some build settings as recommended by Xcode 7
        https://bugs.webkit.org/show_bug.cgi?id=146597

        Reviewed by Sam Weinig.

        * Configurations/Base.xcconfig: Enabled CLANG_WARN_UNREACHABLE_CODE and
        GCC_NO_COMMON_BLOCKS. Removed GCC_MODEL_TUNING.

        * JavaScriptCore.xcodeproj/project.pbxproj: Updated LastUpgradeCheck.

        * dfg/DFGGraph.h: Tweaked the definition of DFG_CRASH to suppress unreachable code warnings.

2015-07-03  Yusuke Suzuki  <utatane.tea@gmail.com>

        Relax builtin JS restriction about try-catch
        https://bugs.webkit.org/show_bug.cgi?id=146555

        Reviewed by Sam Weinig.

        When retrieving the captured variables from the full activated scope,
        it swapped the given vector with the stored declared variables vector.
        This is because retrieving the captured variables are executed in the
        last sequence of the parser, so declared variables are no longer used.
        However, in builtins functions case, after retrieving the captured
        variables, we check the variables by using declared variables vector.
        So at that time, the declared variables vector becomes empty and it
        raises assertion failures when the builtins function contains the full
        activated scope. try-catch's catch scope requires the upper scope full
        activated, so JS code in the builtins cannot use the try-catch.

        This patch relaxes this restriction. When retrieving the captured
        variables from the scope, just copy to the given vector.

        * parser/Parser.h:
        (JSC::Scope::getCapturedVariables):

2015-07-02  Filip Pizlo  <fpizlo@apple.com>

        DFG and FTL should have an OSR exit fuzzer
        https://bugs.webkit.org/show_bug.cgi?id=146562

        Reviewed by Benjamin Poulain.
        
        Adds a basic OSR exit fuzzer to JSC. This isn't hooked into any test harnesses yet, but I
        spot-checked it on v8-earley-boyer.js and so far found no bugs. I'd like to figure out how
        to harness this after I land it.
        
        Since it's turned off by default, it should have no effect on behavior.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGOSRExitFuzz.cpp: Added.
        (JSC::numberOfOSRExitFuzzChecks):
        * dfg/DFGOSRExitFuzz.h: Added.
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitGetArgumentStart):
        (JSC::DFG::SpeculativeJIT::emitOSRExitFuzzCheck):
        (JSC::DFG::SpeculativeJIT::speculationCheck):
        * dfg/DFGSpeculativeJIT.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        * jsc.cpp:
        (jscmain):
        * runtime/Options.h:
        * runtime/TestRunnerUtils.h:

2015-07-02  Saam barati  <saambarati1@gmail.com>

        Rename "Deconstruction" to "Destructuring" throughout JSC
        https://bugs.webkit.org/show_bug.cgi?id=146100

        Reviewed by Mark Lam.

        It is good to use the same naming conventions as the ES6 
        spec because it is the de facto way of speaking about these 
        language features. This also has the benefit of improving JSC's
        hackability because it improves code readability for newcomers 
        to JSC or newcomers to this part of the code base.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeNextParameter):
        (JSC::BytecodeGenerator::visibleNameForParameter):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::registerFor):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForInNode::tryGetBoundLocal):
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForOfNode::emitBytecode):
        (JSC::ClassExprNode::emitBytecode):
        (JSC::DestructuringAssignmentNode::emitBytecode):
        (JSC::DestructuringPatternNode::~DestructuringPatternNode):
        (JSC::ArrayPatternNode::collectBoundIdentifiers):
        (JSC::DeconstructingAssignmentNode::emitBytecode): Deleted.
        (JSC::DeconstructionPatternNode::~DeconstructionPatternNode): Deleted.
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createElementList):
        (JSC::ASTBuilder::createFormalParameterList):
        (JSC::ASTBuilder::createClause):
        (JSC::ASTBuilder::createClauseList):
        (JSC::ASTBuilder::createForInLoop):
        (JSC::ASTBuilder::createForOfLoop):
        (JSC::ASTBuilder::isBindingNode):
        (JSC::ASTBuilder::isResolve):
        (JSC::ASTBuilder::createDestructuringAssignment):
        (JSC::ASTBuilder::createArrayPattern):
        (JSC::ASTBuilder::appendArrayPatternSkipEntry):
        (JSC::ASTBuilder::appendArrayPatternEntry):
        (JSC::ASTBuilder::appendArrayPatternRestEntry):
        (JSC::ASTBuilder::createObjectPattern):
        (JSC::ASTBuilder::appendObjectPatternEntry):
        (JSC::ASTBuilder::createDeconstructingAssignment): Deleted.
        * parser/NodeConstructors.h:
        (JSC::TryNode::TryNode):
        (JSC::ParameterNode::ParameterNode):
        (JSC::ForOfNode::ForOfNode):
        (JSC::DestructuringPatternNode::DestructuringPatternNode):
        (JSC::ArrayPatternNode::ArrayPatternNode):
        (JSC::ArrayPatternNode::create):
        (JSC::ObjectPatternNode::ObjectPatternNode):
        (JSC::BindingNode::create):
        (JSC::BindingNode::BindingNode):
        (JSC::DestructuringAssignmentNode::DestructuringAssignmentNode):
        (JSC::DeconstructionPatternNode::DeconstructionPatternNode): Deleted.
        (JSC::DeconstructingAssignmentNode::DeconstructingAssignmentNode): Deleted.
        * parser/Nodes.cpp:
        (JSC::FunctionParameters::create):
        * parser/Nodes.h:
        (JSC::ExpressionNode::isResolveNode):
        (JSC::ExpressionNode::isBracketAccessorNode):
        (JSC::ExpressionNode::isDotAccessorNode):
        (JSC::ExpressionNode::isDestructuringNode):
        (JSC::ExpressionNode::isFuncExprNode):
        (JSC::ExpressionNode::isCommaNode):
        (JSC::ExpressionNode::isSimpleArray):
        (JSC::ParameterNode::pattern):
        (JSC::ParameterNode::nextParam):
        (JSC::FunctionParameters::size):
        (JSC::FunctionParameters::at):
        (JSC::FunctionParameters::patterns):
        (JSC::DestructuringPatternNode::isBindingNode):
        (JSC::DestructuringPatternNode::emitDirectBinding):
        (JSC::ArrayPatternNode::appendIndex):
        (JSC::ObjectPatternNode::appendEntry):
        (JSC::BindingNode::boundProperty):
        (JSC::DestructuringAssignmentNode::bindings):
        (JSC::ExpressionNode::isDeconstructionNode): Deleted.
        (JSC::DeconstructionPatternNode::isBindingNode): Deleted.
        (JSC::DeconstructionPatternNode::emitDirectBinding): Deleted.
        (JSC::DeconstructingAssignmentNode::bindings): Deleted.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseVarDeclaration):
        (JSC::Parser<LexerType>::parseWhileStatement):
        (JSC::Parser<LexerType>::parseVarDeclarationList):
        (JSC::Parser<LexerType>::createBindingPattern):
        (JSC::Parser<LexerType>::tryParseDestructuringPatternExpression):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        (JSC::Parser<LexerType>::parseDefaultValueForDestructuringPattern):
        (JSC::Parser<LexerType>::parseForStatement):
        (JSC::Parser<LexerType>::parseFormalParameters):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::tryParseDeconstructionPatternExpression): Deleted.
        (JSC::Parser<LexerType>::parseDeconstructionPattern): Deleted.
        (JSC::Parser<LexerType>::parseDefaultValueForDeconstructionPattern): Deleted.
        * parser/Parser.h:
        (JSC::isEvalNode):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createPropertyList):
        (JSC::SyntaxChecker::createElementList):
        (JSC::SyntaxChecker::createFormalParameterList):
        (JSC::SyntaxChecker::createClause):
        (JSC::SyntaxChecker::createClauseList):
        (JSC::SyntaxChecker::operatorStackPop):
        * tests/stress/reserved-word-with-escape.js:
        * tests/stress/rest-elements.js:

2015-07-02  Mark Lam  <mark.lam@apple.com>

        Build fix for Win EWS bot.
        https://bugs.webkit.org/show_bug.cgi?id=146551

        Not reviewed.

        * tools/JSDollarVMPrototype.cpp:
        (JSC::functionCrash):

2015-07-02  Dan Bernstein  <mitz@apple.com>

        <rdar://problem/21429613> [iOS] Stop making symlinks from PrivateFrameworks to Frameworks
        https://bugs.webkit.org/show_bug.cgi?id=146542

        Reviewed by Sam Weinig.

        * JavaScriptCore.xcodeproj/project.pbxproj: Removed the build phase that makes the symlink.

2015-07-01  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Aggregate profile call information on the backend to drastically reduce profile sizes
        https://bugs.webkit.org/show_bug.cgi?id=146536

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Timeline.json:
        Change a CPUProfile from sending a required "calls" param to sending a required
        "callInfo" param which includes aggregated information about the calls.

2015-06-30  Filip Pizlo  <fpizlo@apple.com>

        DFG::freezeFragile should register the frozen value's structure
        https://bugs.webkit.org/show_bug.cgi?id=136055
        rdar://problem/21042120

        Reviewed by Mark Lam and Geoffrey Garen.
        
        This fixes weird concurrency bugs where the constant folding phase tries to convert
        something to a constant but then crashes because the constant's structure wasn't
        registered. The AI was registering the structure of any value it saw, but constant folding
        wasn't - and that's fine so long as there ain't no concurrency.
        
        The best fix is to just make it impossible to introduce a constant into the IR without
        registering its structure. That's what this change does. This is not only a great
        concurrency fix - it also makes the compiler somewhat easier to hack on because it's one
        less case of structure registering that you have to remember about.
        
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::setOSREntryValue): No need to register.
        (JSC::DFG::AbstractValue::set): We still call register, but just to get the watchpoint state.
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::freezeFragile): Register the structure.
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run): Assert that these are all registered.

2015-07-01  Matthew Mirman  <mmirman@apple.com>

        Unreviewed, rolling out r185889
        https://bugs.webkit.org/show_bug.cgi?id=146528
        rdar://problem/21573959

        Patch breaks chromeexperiments.com
        
        Reverted changeset:
        
        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/InjectedScriptSource.js:
        (.):
        * runtime/JSBoundSlotBaseFunction.cpp: Removed.
        * runtime/JSBoundSlotBaseFunction.h: Removed.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Deleted.
        (JSC::JSGlobalObject::visitChildren): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::boundSlotBaseFunctionStructure): Deleted.
        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnPropertyDescriptor):
        (JSC::getBoundSlotBaseFunctionForGetterSetter): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM): Deleted.
        * runtime/VM.h:

2015-07-01  Dean Jackson  <dino@apple.com>

        Disable the experimental WebGL2 implementation
        https://bugs.webkit.org/show_bug.cgi?id=146526
        <rdar://problem/21641235>

        Reviewed by Myles Maxfield.

        Add (and disable) an ENABLE_WEBGL2 flag.

        * Configurations/FeatureDefines.xcconfig:

2015-07-01  Matthew Daiter  <mdaiter@apple.com>

        Enable MEDIA_STREAM flag
        https://bugs.webkit.org/show_bug.cgi?id=145947
        <rdar://problem/21365829>

        Reviewed by Eric Carlson.

        * Configurations/FeatureDefines.xcconfig: Added MEDIA_STREAM flag

2015-06-30  Andy VanWagoner  <thetalecrafter@gmail.com>

        Implement ECMAScript Internationalization API
        https://bugs.webkit.org/show_bug.cgi?id=90906

        Reviewed by Benjamin Poulain.

        * CMakeLists.txt: add IntlObject.cpp
        * Configurations/FeatureDefines.xcconfig: add ENABLE_INTL flag
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: add IntlObject
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: add IntlObject
        * JavaScriptCore.xcodeproj/project.pbxproj: add IntlObject
        * runtime/CommonIdentifiers.h: add "Intl" name
        * runtime/IntlObject.cpp: Added.
        (JSC::IntlObject::IntlObject):
        (JSC::IntlObject::create):
        (JSC::IntlObject::finishCreation):
        (JSC::IntlObject::createStructure):
        * runtime/IntlObject.h: Added.
        * runtime/JSGlobalObject.cpp: Add global Intl
        (JSC::JSGlobalObject::init):

2015-06-30  Basile Clement  <basile_clement@apple.com>

        Allow object allocation sinking through GetScope, GetExecutable and SkipScope nodes
        https://bugs.webkit.org/show_bug.cgi?id=146431

        Reviewed by Filip Pizlo.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::isFunctionAllocation):
        (JSC::DFG::Node::isPhantomFunctionAllocation):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        * dfg/DFGPromoteHeapAccess.h:
        (JSC::DFG::promoteHeapAccess):

2015-06-30  Matt Baker  <mattbaker@apple.com>

        Web Inspector: Reduce rendering frames "Other" time by instrumenting compositing
        https://bugs.webkit.org/show_bug.cgi?id=146168

        Reviewed by Brian Burg.

        * inspector/protocol/Timeline.json:
        New timeline record type for compositing events.

2015-06-29  Dean Jackson  <dino@apple.com>

        Temporarily disable PICTURE_SIZES
        https://bugs.webkit.org/show_bug.cgi?id=146435
        <rdar://problem/21087013>

        Reviewed by Tim Horton.

        Temporarily disable PICTURE_SIZES because it causes problems with out
        of date <picture> polyfills.

        * Configurations/FeatureDefines.xcconfig:

2015-06-29  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        Binding generator should allow using JSC::Value for "any" parameter in lieu of ScriptValue
        https://bugs.webkit.org/show_bug.cgi?id=146403

        Reviewed by Darin Adler.

        * bindings/ScriptValue.h: Added implicit conversion to JSC::JSValue.

2015-06-28 Aleksandr Skachkov   <gskachkov@gmail.com>

        [ES6] Implement ES6 arrow function syntax. No Line terminator between function parameters and =>
        https://bugs.webkit.org/show_bug.cgi?id=146394

        Reviewed by Yusuke Suzuki.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):

2015-06-27  Darin Adler  <darin@apple.com>

        Make converting JSString to StringView idiomatically safe
        https://bugs.webkit.org/show_bug.cgi?id=146387

        Reviewed by Anders Carlsson.

        * jsc.cpp:
        (functionPrint): Add explicit call to SafeView::get, needed since there
        is no StringView temporary.
        (functionDebug): Ditto.

        * runtime/ArrayPrototype.cpp:
        (JSC::holesMustForwardToPrototype): Refactored into helper function.
        (JSC::join): Refactored so that StringView is a function argument, making
        the lifetime simpler.
        (JSC::arrayProtoFuncJoin): Ditto.
        (JSC::arrayProtoFuncReverse): Use new holesMustForwardToPrototype helper.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::encode): Add explicit call to SafeView::get.

        * runtime/JSString.h: Moved declarations of functions to the top of the
        file instead of mixing them in with the function definitions. Changed
        return type of the view function to return a JSString::SafeView so that
        the JSString's lifetime will last as long as the StringView does in
        typical coding idioms.
        (JSC::JSString::getIndex): Use unsafeView so we can index into the
        view; could also have used view.get but here in this class this seems fine.
        (JSC::JSRopeString::unsafeView): Renamed existing view function to this.
        (JSC::JSString::unsafeView): Ditto.
        (JSC::JSString::SafeView::SafeView): Contains reference to an ExecState
        and a JSString. The ExecState is needed to create the StringView, and the
        JSString needs to be kept alive as long as the StringView is.
        (JSC::JSString::SafeView::operator StringView): Call unsafeView.
        (JSC::JSString::SafeView::get): Convenience for when we want to call
        StringView member functions.
        (JSC::JSString::view): Added. Returns a SafeView.

        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncIndexOf): Add explicit call to SafeView::get.

2015-06-26  Csaba Osztrogonác  <ossy@webkit.org>

        Remove ARMv7Assembler.cpp
        https://bugs.webkit.org/show_bug.cgi?id=146340

        Reviewed by Filip Pizlo.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/ARMv7Assembler.cpp: Removed.

2015-06-26  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the !ENABLE(ES6_ARROWFUNCTION_SYNTAX) build after r185989
        https://bugs.webkit.org/show_bug.cgi?id=146344

        Reviewed by Yusuke Suzuki.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseSourceElements):

2015-06-26 Aleksandr Skachkov  <gskachkov@gmail.com>

         [ES6] Implement ES6 arrow function syntax. Parser of arrow function with execution as common function. 
         https://bugs.webkit.org/show_bug.cgi?id=144955

         Reviewed by Yusuke Suzuki.

         Added support of ES6 arrow function. Changes were made according to following spec http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax. Patch does not include any arrow function specific behavior e.g. lexical bind this, arguments and etc.     
        This patch implements the simplest cases of arrow function declaration:
           parameters             () => 10 + 20
           parameter               x => x + 20
           parameters         (x, y) => x + y
           function with block     x => { return x*10; }

        Not implemented:
           bind of the this, arguments, super and etc.
           exception in case of trying to use 'new' with arrow function

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFunctionExpr):
        (JSC::ASTBuilder::createArrowFunctionExpr):
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createFuncDeclStatement):
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::setTokenPosition):
        (JSC::Lexer<T>::lex):
        * parser/Lexer.h:
        (JSC::Lexer::lastTokenLocation):
        (JSC::Lexer::setTerminator):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseSourceElements):
        (JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBody):
        (JSC::Parser<LexerType>::parseSwitchClauses):
        (JSC::Parser<LexerType>::parseSwitchDefaultClause):
        (JSC::Parser<LexerType>::parseBlockStatement):
        (JSC::Parser<LexerType>::parseFunctionBody):
        (JSC::stringForFunctionMode):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parseGetterSetter):
        (JSC::Parser<LexerType>::parseArrowFunctionExpression):
        * parser/Parser.h:
        (JSC::Parser::locationBeforeLastToken):
        (JSC::Parser::isEndOfArrowFunction):
        (JSC::Parser::isArrowFunctionParamters):
        (JSC::Parser::setEndOfStatement):
        * parser/ParserFunctionInfo.h:
        * parser/ParserTokens.h:
        * parser/SourceCode.h:
        (JSC::SourceCode::subArrowExpression):
        * parser/SourceProviderCacheItem.h:
        (JSC::SourceProviderCacheItem::endFunctionToken):
        (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createArrowFunctionExpr):
        (JSC::SyntaxChecker::setFunctionNameStart):

2015-06-25  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Support rest element in destructuring assignments
        https://bugs.webkit.org/show_bug.cgi?id=146206

        Reviewed by Oliver Hunt.

        This patch enables rest element (...rest) in array binding patterns.
        It generates array from the iterables.
        In variable declarations and parameters, `[...identifier]` form is only allowed,
        while expressions can take `[...[...rest]]` pattern.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::emitIteratorNext):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrayPatternNode::bindValue):
        (JSC::ArrayPatternNode::toString):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::appendArrayPatternSkipEntry):
        (JSC::ASTBuilder::appendArrayPatternEntry):
        (JSC::ASTBuilder::appendArrayPatternRestEntry):
        * parser/Nodes.h:
        (JSC::ArrayPatternNode::appendIndex):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseDeconstructionPattern):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::operatorStackPop):
        * tests/stress/rest-elements.js: Added.
        (shouldBe):
        (shouldThrow):

2015-06-25  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r185956.
        https://bugs.webkit.org/show_bug.cgi?id=146321

        Causes massive crashes on test bots (Requested by bfulgham on
        #webkit).

        Reverted changeset:

        "Enabling MEDIA_STREAM"
        https://bugs.webkit.org/show_bug.cgi?id=145947
        http://trac.webkit.org/changeset/185956

2015-06-25  Michael Saboff  <msaboff@apple.com>

        Minor fix to idx bounds check after 185954

        Rubber Stamped by Ryosuke Niwa.

        Changed "idx > 1" to "idx > 0" in two places.

        * runtime/ExceptionHelpers.cpp:
        (JSC::functionCallBase):

2015-06-25  Keith Miller  <keith_miller@apple.com>

        Address Sanitizer does not play well with memcpy in JSC::MachineThreads::tryCopyOtherThreadStack.
        https://bugs.webkit.org/show_bug.cgi?id=146297

        Reviewed by Filip Pizlo.

        Since we cannot blacklist the system memcpy we must use our own naive implementation,
        copyMemory. This is not a significant performance loss as tryCopyOtherThreadStack is
        only called as part of an O(heapsize) operation. As the heap is generally much larger
        than the stack the performance hit is minimal.

        * heap/MachineStackMarker.cpp:
        (JSC::copyMemory):
        (JSC::MachineThreads::tryCopyOtherThreadStack):
        (JSC::asanUnsafeMemcpy): Deleted.

2015-06-25  Matthew Daiter  <mdaiter@apple.com>

        Enabling MEDIA_STREAM
        https://bugs.webkit.org/show_bug.cgi?id=145947
        <rdar://problem/21365829>

        Reviewed by Brent Fulgham.

        * Configurations/FeatureDefines.xcconfig:

2015-06-25  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r181889): basspro.com hangs on load under JSC::ErrorInstance::finishCreation(JSC::ExecState*, JSC::VM&, WTF::String const&, bool) + 2801 (JavaScriptCore + 3560689)
        https://bugs.webkit.org/show_bug.cgi?id=146298

        Reviewed by Mark Lam.

        We were underflowing in ExceptionHelpers.cpp::functionCallBase() with a right to left
        string index.  Added checks that idx stays within the string.  Also added a termination
        condition when idx is 0.

        * runtime/ExceptionHelpers.cpp:
        (JSC::functionCallBase):

2015-06-24  Chris Dumez  <cdumez@apple.com>

        Unreviewed, speculative build fix after r185942.

        Add missing include for StrongInlines.h.

        * runtime/ArrayPrototype.cpp:

2015-06-24  Darin Adler  <darin@apple.com>

        Optimize Array.join and Array.reverse for high speed array types
        https://bugs.webkit.org/show_bug.cgi?id=146275

        Reviewed by Mark Lam.

        This seems to yield another 17% speed improvement in the array
        test from the Peacekeeper benchmark.

        * runtime/ArrayPrototype.cpp:
        (JSC::isHole): Added. Helper to check for holes.
        (JSC::containsHole): Ditto.
        (JSC::arrayProtoFuncJoin): Added special cases for the various types
        of arrays that could be in a butterfly.
        (JSC::arrayProtoFuncReverse): Ditto.

        * runtime/JSStringJoiner.h: Made appendEmptyString public so we can
        call it from the new parts of Array.join.

2015-06-24  Filip Pizlo  <fpizlo@apple.com>

        DFG::SpeculativeJIT shouldn't use filter==Contradiction when it meant isClear
        https://bugs.webkit.org/show_bug.cgi?id=146291
        rdar://problem/21435366

        Reviewed by Michael Saboff.
        
        The filter() method returns Contradiction only when a value *becomes* clear. This is
        necessary for supporting the convention that non-JSValue nodes have a bottom proved
        type. (We should fix that convention eventually, but for now let's just be consistent
        about it.)
        
        * dfg/DFGFiltrationResult.h: Document the issue.
        * dfg/DFGSpeculativeJIT32_64.cpp: Work around the issue.
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
        * dfg/DFGSpeculativeJIT64.cpp: Work around the issue.
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):

2015-06-24  Michael Saboff  <msaboff@apple.com>

        Crash on gog.com due to PolymorphicCallNode's having stale references to CallLinkInfo
        https://bugs.webkit.org/show_bug.cgi?id=146285

        Reviewed by Filip Pizlo.

        CallLinkInfo's contain a RefPtr to a PolymorphicCallStubRoutine, named stub, which contains
        a collection of PolymorphicCallNode.  Those PolymorphicCallNodes have a reference back to the
        CallLinkInfo.  When a CallLinkInfo replaces or clears "stub", the ref count of the
        PolymorphicCallStubRoutine is decremented as expected, but since it inherits from
        GCAwareJITStubRoutine, it isn't actually deleted until GC.  In the mean time, the original
        CallLinkInfo can go away.  If PolymorphicCallNode::unlink() is called at that point,
        it will try to unlink a now deleted CallLinkInfo and crash as a result.

        The fix is to clear the CallLinkInfo references from any PolymorphicCallNode objects when
        when we set a new stub or clear an existing stub for a CallLinkInfo.  This is done by
        calling PolymorphicCallNode::clearCallNodesFor() on the old stub.

        The prior code would only call clearCallNodesFor() from the CallLinkInfo destructor.
        This only took care of the last PolymorphicCallStubRoutine held in the CallLinkInfo.
        Any prior PolymorphicCallStubRoutine would still have a, now bad, reference to the CallLinkInfo.

        In the process I refactored CallLinkInfo from a struct to a class with proper accessors and
        made all the data elements private.

        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::clearStub): Updated to call PolymorphicCallStubRoutine::clearCallNodesFor()
        to clear the back references to this CallLinkInfo.
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::~CallLinkInfo): Moved clearCallNodesFor() call to clearStub().
        (JSC::CallLinkInfo::setStub): Clear any prior stub before changing to the new stub.

2015-06-24  Michael Saboff  <msaboff@apple.com>

        Refactor CallLinkInfo from a struct to a class
        https://bugs.webkit.org/show_bug.cgi?id=146292

        Rubber stamped by Filip Pizlo.

        Refactored CallLinkInfo from a struct to a class with proper accessors and made all the
        data elements private.

        Done in preparation for fixing https://bugs.webkit.org/show_bug.cgi?id=146285.

        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::clearStub):
        (JSC::CallLinkInfo::unlink):
        (JSC::CallLinkInfo::visitWeak):
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::callTypeFor):
        (JSC::CallLinkInfo::CallLinkInfo):
        (JSC::CallLinkInfo::~CallLinkInfo):
        (JSC::CallLinkInfo::specializationKindFor):
        (JSC::CallLinkInfo::specializationKind):
        (JSC::CallLinkInfo::isLinked):
        (JSC::CallLinkInfo::setUpCall):
        (JSC::CallLinkInfo::setCallLocations):
        (JSC::CallLinkInfo::setUpCallFromFTL):
        (JSC::CallLinkInfo::callReturnLocation):
        (JSC::CallLinkInfo::hotPathBegin):
        (JSC::CallLinkInfo::hotPathOther):
        (JSC::CallLinkInfo::setCallee):
        (JSC::CallLinkInfo::clearCallee):
        (JSC::CallLinkInfo::callee):
        (JSC::CallLinkInfo::setLastSeenCallee):
        (JSC::CallLinkInfo::clearLastSeenCallee):
        (JSC::CallLinkInfo::lastSeenCallee):
        (JSC::CallLinkInfo::haveLastSeenCallee):
        (JSC::CallLinkInfo::setStub):
        (JSC::CallLinkInfo::stub):
        (JSC::CallLinkInfo::seenOnce):
        (JSC::CallLinkInfo::clearSeen):
        (JSC::CallLinkInfo::setSeen):
        (JSC::CallLinkInfo::hasSeenClosure):
        (JSC::CallLinkInfo::setHasSeenClosure):
        (JSC::CallLinkInfo::clearedByGC):
        (JSC::CallLinkInfo::setCallType):
        (JSC::CallLinkInfo::callType):
        (JSC::CallLinkInfo::addressOfMaxNumArguments):
        (JSC::CallLinkInfo::maxNumArguments):
        (JSC::CallLinkInfo::offsetOfSlowPathCount):
        (JSC::CallLinkInfo::setCalleeGPR):
        (JSC::CallLinkInfo::calleeGPR):
        (JSC::CallLinkInfo::slowPathCount):
        (JSC::CallLinkInfo::setCodeOrigin):
        (JSC::CallLinkInfo::codeOrigin):
        (JSC::getCallLinkInfoCodeOrigin):
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFor):
        (JSC::CallLinkStatus::computeFromCallLinkInfo):
        (JSC::CallLinkStatus::computeDFGStatuses):
        * bytecode/CallLinkStatus.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printCallOp):
        (JSC::CodeBlock::getCallLinkInfoForBytecodeIndex):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * ftl/FTLJSCallBase.cpp:
        (JSC::FTL::JSCallBase::link):
        * jit/AccessorCallJITStubRoutine.h:
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        (JSC::JIT::compileOpCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        (JSC::JIT::compileOpCall):
        * jit/JITOperations.cpp:
        * jit/PolymorphicCallStubRoutine.cpp:
        (JSC::PolymorphicCallNode::unlink):
        (JSC::PolymorphicCallNode::clearCallLinkInfo):
        * jit/PolymorphicCallStubRoutine.h:
        * jit/Repatch.cpp:
        (JSC::generateByIdStub):
        (JSC::linkSlowFor):
        (JSC::linkFor):
        (JSC::revertCall):
        (JSC::unlinkFor):
        (JSC::linkPolymorphicCall):
        * jit/ThunkGenerators.cpp:
        (JSC::virtualForThunkGenerator):

2015-06-24  Doug Russell  <d_russell@apple.com>

        Bug 146177 - AX: AXObjectCache should try to use an unignored accessibilityObject 
        when posting a selection notification when on the border between two accessibilityObjects
        https://bugs.webkit.org/show_bug.cgi?id=146177

        Add an adopt() function to simplify JSRetainPtr<JSStringRef> { Adopt, string } to adopt(string).

        Reviewed by Darin Adler.

        * API/JSRetainPtr.h:
        (adopt):

2015-06-24  Keith Miller  <keith_miller@apple.com>

        Strict Equality on objects should only check that one of the two sides is an object.
        https://bugs.webkit.org/show_bug.cgi?id=145992

        This patch adds a new optimization for checking strict equality on objects.
        If we speculate that a strict equality comparison has an object on one side
        we only need to type check that side. Equality is then determined by a pointer
        comparison between the two values (although in the 32-bit case we must also check
        that the other side is a cell). Once LICM hoists type checks out of a loop we
        can be cleverer about how we choose the operand we type check if both are
        speculated to be objects.

        For testing I added the addressOf function, which returns the address
        of a Cell to the runtime.

        Reviewed by Mark Lam.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileStrictEq):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileObjectStrictEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectStrictEquality):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileObjectStrictEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectStrictEquality):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareStrictEq):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionAddressOf):
        * tests/stress/equality-type-checking.js: Added.
        (Foo):
        (checkStrictEq):
        (checkStrictEqOther):

2015-06-24  Mark Lam  <mark.lam@apple.com>

        Fixed assertion in JSStringJoiner::join() (regression from r185899).

        Not reviewed.

        JSStringJoiner did not account for the case where the array being joined can
        have null or undefined elements.  As a result, its size may be less than
        its initially reserved capacity (which was estimated based on the array length).

        * runtime/JSStringJoiner.cpp:
        (JSC::JSStringJoiner::join):

2015-06-24  Darin Adler  <darin@apple.com>

        Fix Array.concat with RuntimeArray (regression from my last patch)

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncConcat): Use getLength instead of JSArray::length.

        * runtime/JSArray.cpp:
        (JSC::JSArray::defineOwnProperty): Added comment about use of
        JSArray::length here that is incorrect (in a really non-obvious way).
        (JSC::JSArray::fillArgList): Ditto.
        (JSC::JSArray::copyToArguments): Ditto.

        * runtime/JSArray.h: Added a comment explaining that it is not always
        safe to use JSArray::length.

2015-06-23  Mark Lam  <mark.lam@apple.com>

        Gardening: Fixing 2 bad asserts from r185889.
        https://bugs.webkit.org/show_bug.cgi?id=140575

        Not reviewed.

        * runtime/JSBoundSlotBaseFunction.cpp:
        (JSC::JSBoundSlotBaseFunction::finishCreation):

2015-06-23  Dan Bernstein  <mitz@apple.com>

        Fixed iOS production builds.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2015-06-22  Darin Adler  <darin@apple.com>

        Make Array.join work directly on substrings without reifying them
        https://bugs.webkit.org/show_bug.cgi?id=146191

        Reviewed by Andreas Kling.

        Besides the Array.join change, this has other optimizations based on
        profiling the Peacekeeper array benchmark.

        I measured a 14% speed improvement in the Peacekeeper array benchmark.

        Still a lot of low hanging fruit in that test because so many of functions
        on the array prototype are not optimizing for simple cases. For example,
        the reverse function does individual get and put calls even when the array
        is entirely made up of integers in contiguous storage.

        * runtime/ArrayPrototype.cpp:
        (JSC::getProperty): Use tryGetIndexQuickly first before getPropertySlot.
        (JSC::argumentClampedIndexFromStartOrEnd): Marked inline.
        (JSC::shift): Use the getProperty helper in this file instead of using
        getPropertySlot. Use putByIndexInline instead of calling putByIndex directly.
        In both cases this can yield a faster code path.
        (JSC::unshift): Ditto.
        (JSC::arrayProtoFuncToString): Updated to use the new JSStringJoiner
        interface. Changed local variable name to thisArray since it's not a
        JSObject*. Changed loop index to i instead of k.
        (JSC::arrayProtoFuncToLocaleString): Updated to use the new JSStringJoiner
        interface. Renamed thisObj to thisObject. Added a missing exception check
        after the toLocaleString function is called, but before toString is called
        the result of that function.
        (JSC::arrayProtoFuncJoin): Updated to use the new JSStringJointer interface.
        Added a missing exception check after calling toString on the separator
        but before calling get to get the first element in the array-like object
        being joined. Changed loop index to i instead of k. Added missing exception
        check after calling toString on each string from the array before calling
        get for the next element.
        (JSC::arrayProtoFuncConcat): Use JSArray::length instead of using the
        getLength function.
        (JSC::arrayProtoFuncReverse): Ditto. Also use putByIndexInline.
        (JSC::arrayProtoFuncShift): Ditto.
        (JSC::arrayProtoFuncSplice): Use getIndex instead of get, which includes some
        additional optimizations.
        (JSC::getOrHole): Deleted. Unused function.
        (JSC::arrayProtoFuncUnShift): Use putByIndexInline.

        * runtime/ExceptionHelpers.cpp:
        (JSC::errorDescriptionForValue): Removed the duplicate copy of the the logic
        from JSValue::toString.

        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::toStringSlowCase): Improved the performance when converting a
        small integer to a single character string.
        (JSC::JSValue::toWTFStringSlowCase): Moved the contents of the
        inlineJSValueNotStringtoString function here.
        * runtime/JSCJSValue.h: Removed no longer used toWTFStringInline and fixed
        a comment with a typo.

        * runtime/JSObject.h:
        (JSC::JSObject::putByIndexInline): Marked ALWAYS_INLINE because this was not
        getting inlined at some call sites.
        (JSC::JSObject::indexingData): Deleted. Unused function.
        (JSC::JSObject::currentIndexingData): Deleted. Unused function.
        (JSC::JSObject::getHolyIndexQuickly): Deleted. Unused function.
        (JSC::JSObject::relevantLength): Deleted. Unused function.
        (JSC::JSObject::currentRelevantLength): Deleted. Unused function.

        * runtime/JSString.h: Added the StringViewWithUnderlyingString struct and
        the viewWithUnderlyingString function. Removed the inlineJSValueNotStringtoString
        and toWTFStringInline functions.

        * runtime/JSStringJoiner.cpp:
        (JSC::appendStringToData): Changed this to be a template instead of writing
        it out, since StringView::getCharactersWithUpconvert does almsot exactly what
        this function was trying to do.
        (JSC::joinStrings): Rewrote this to use StringView.
        (JSC::JSStringJoiner::joinedLength): Added. Factored out from the join function.
        (JSC::JSStringJoiner::join): Rewrote to make it a bit simpler. Added an assertion
        that we entirely filled capacity, since we are now reserving capacity and using
        uncheckedAppend. Use String instead of RefPtr<StringImpl> because there was no
        particular value to using the impl directly.

        * runtime/JSStringJoiner.h: Changed the interface to the class to use StringView.
        Also changed this class so it now has the responsibility to convert each JSValue
        into a string. This let us share more code between toString and join, and also
        lets us use the new viewWithUnderlyingString function, which could be confusing at
        all the call sites, but is easier to understand here.

2015-06-23  Matthew Mirman  <mmirman@apple.com>

        Completes native binding descriptors with native getters and potentially setters.
        https://bugs.webkit.org/show_bug.cgi?id=140575
        rdar://problem/19506502

        Reviewed by Mark Lam.

        * CMakeLists.txt:  Added JSBoundSlotBaseFunction.cpp
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/InjectedScriptSource.js: Added case for descriptor having a native getter.
        * runtime/JSBoundSlotBaseFunction.cpp: Added.
        (JSC::boundSlotBaseFunctionCall):
        (JSC::JSBoundSlotBaseFunction::JSBoundSlotBaseFunction):  
        Necessary wrapper for custom getters and setters as objects.
        (JSC::JSBoundSlotBaseFunction::create):
        (JSC::JSBoundSlotBaseFunction::visitChildren):
        (JSC::JSBoundSlotBaseFunction::finishCreation):
        * runtime/JSBoundSlotBaseFunction.h: Added.
        (JSC::JSBoundSlotBaseFunction::createStructure):
        (JSC::JSBoundSlotBaseFunction::boundSlotBase):
        (JSC::JSBoundSlotBaseFunction::customGetterSetter):
        (JSC::JSBoundSlotBaseFunction::isGetter):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Added a globally initialized structure for JSBoundSlotBaseFunction
        (JSC::JSGlobalObject::visitChildren): visits that structure
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::boundSlotBaseFunctionStructure): added a getter for that structure
        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnPropertyDescriptor): extends the case for CustomGetterSetter to 
        actually include GetterSetter as a JSBoundSlotBaseFunction
        * runtime/VM.cpp: Added initializer for customGetterSetterFunctionMap
        * runtime/VM.h: Added cache for JSBoundSlotBaseFunction

2015-06-22  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Allow trailing comma in ArrayBindingPattern and ObjectBindingPattern
        https://bugs.webkit.org/show_bug.cgi?id=146192

        Reviewed by Darin Adler.

        According to the ES6 spec, trailing comma in ArrayBindingPattern and ObjectBindingPattern is allowed.
        And empty ArrayBindingPattern and ObjectBindingPattern is also allowed.

        This patch allows trailing comma and empty binding patterns.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrayPatternNode::bindValue):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseDeconstructionPattern):
        * tests/stress/trailing-comma-in-patterns.js: Added.
        (shouldBe):
        (iterator):

2015-06-20  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Destructuring assignment need to accept iterables
        https://bugs.webkit.org/show_bug.cgi?id=144111

        Reviewed by Darin Adler.

        This patch makes that destructuring assignments to array binding patterns accept iterables.
        Previously, it just access the indexed properties.
        After this patch, it iterates the given value by using ES6 iterator protocol.

        The iteration becomes different from the for-of case.
        1. Since there's no break/continue case, finally scope is not necessary.
        2. When the error is raised, the close status of the iterator becomes true. So IteratorClose is not called for that.
        3. Since the array binding patterns requires a limited count of iterations (if there is no rest(...rest) case), IteratorClose is called when the iteration does not consume the all values of the iterator.
        4. Since the array binding patterns requires a specified count of iterations, iterator's next call is skipped when iterator becomes closed.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitIteratorClose):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrayPatternNode::bindValue):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::finishArrayPattern):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseDeconstructionPattern):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::operatorStackPop):
        * tests/stress/destructuring-assignment-accepts-iterables.js: Added.
        (shouldBe):
        (shouldThrow):
        (.set shouldThrow):

2015-06-19  Devin Rousso  <drousso@apple.com>

        Web Inspector: Highlight currently edited CSS selector
        https://bugs.webkit.org/show_bug.cgi?id=145658

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/DOM.json: Added highlightSelector to show highlight over multiple nodes.

2015-06-19  Mark Lam  <mark.lam@apple.com>

        Gardening: fix build for EWS bots.

        Not reviewed.

        * runtime/JSArray.cpp:
        (JSC::JSArray::setLengthWithArrayStorage):

2015-06-19  Michael Saboff  <msaboff@apple.com>

        Crash in com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::FTL::fixFunctionBasedOnStackMaps + 17225
        https://bugs.webkit.org/show_bug.cgi?id=146133

        Reviewed by Geoffrey Garen.

        When generating code to put in inline caching areas, if there isn't enough space,
        then create and link to an out of line area.  We connect the inline code to this
        out of line code area by planting a jump from the inline area to the out of line
        code and appending a jump at the end of the out of line code bck to the instruction
        following the inline area.  We fill the unused inline area with nops, primarily to 
        ensure the disassembler doesn't get confused.

        * ftl/FTLCompile.cpp:
        (generateInlineIfPossibleOutOfLineIfNot): New function that determines if there is enough space
        in the inline code area for the code to link.  If so, it links inline, otherwise it links the
        code out of line and plants appropriate jumps to/from the out of line code.
        (generateICFastPath):
        (generateCheckInICFastPath):
        (fixFunctionBasedOnStackMaps):
        Use generateInlineIfPossibleOutOfLineIfNot() to link code intended for inline cache space.

        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * ftl/FTLJITFinalizer.h:
        (JSC::FTL::OutOfLineCodeInfo::OutOfLineCodeInfo):
        Added code to finalize any out of line LinkBuffer created by generateInlineIfPossibleOutOfLineIfNot().

2015-06-19  Geoffrey Garen  <ggaren@apple.com>

        WebKit crash while loading nytimes at JavaScriptCore: JSC::ExecutableAllocator::allocate + 276
        https://bugs.webkit.org/show_bug.cgi?id=146163
        <rdar://problem/20392986>

        Reviewed by Michael Saboff.

        There's no good way to test this in our test harness because we don't
        have a way to simulate executable memory pressure, and doing so would
        cause the cases that still use JITCompilationMustSucceed to crash.

        Instead, I tested by manually forcing all regexp JIT compilation to
        fail and running the JavaScriptCore tests.

        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::compile): Allow compilation to fail. We can
        fall back to the regexp interpreter if we need to.

2015-06-19  Mark Lam  <mark.lam@apple.com>

        Employ explicit operator bool() instead of using the UnspecifiedBoolType workaround.
        https://bugs.webkit.org/show_bug.cgi?id=146154

        Reviewed by Darin Adler.

        * assembler/MacroAssemblerCodeRef.h:
        (JSC::MacroAssemblerCodePtr::dataLocation):
        (JSC::MacroAssemblerCodePtr::operator bool):
        (JSC::MacroAssemblerCodePtr::operator==):
        (JSC::MacroAssemblerCodeRef::tryToDisassemble):
        (JSC::MacroAssemblerCodeRef::operator bool):
        (JSC::MacroAssemblerCodeRef::dump):
        (JSC::MacroAssemblerCodePtr::operator UnspecifiedBoolType*): Deleted.
        (JSC::MacroAssemblerCodeRef::operator UnspecifiedBoolType*): Deleted.

        * bytecode/CodeOrigin.cpp:
        (JSC::CodeOrigin::isApproximatelyEqualTo):
        - Fixed a bug here where we were expecting to compare Executable pointers, but
          ended up comparing a (UnspecifiedBoolType*)1 with another
          (UnspecifiedBoolType*)1.

        * bytecode/LLIntCallLinkInfo.h:
        (JSC::LLIntCallLinkInfo::~LLIntCallLinkInfo):
        (JSC::LLIntCallLinkInfo::isLinked):
        (JSC::LLIntCallLinkInfo::unlink):
        * dfg/DFGBlockWorklist.h:
        (JSC::DFG::BlockWith::BlockWith):
        (JSC::DFG::BlockWith::operator bool):
        (JSC::DFG::BlockWithOrder::BlockWithOrder):
        (JSC::DFG::BlockWithOrder::operator bool):
        (JSC::DFG::BlockWith::operator UnspecifiedBoolType*): Deleted.
        (JSC::DFG::BlockWithOrder::operator UnspecifiedBoolType*): Deleted.
        * dfg/DFGIntegerRangeOptimizationPhase.cpp:
        * dfg/DFGLazyNode.h:
        (JSC::DFG::LazyNode::operator!):
        (JSC::DFG::LazyNode::operator bool):
        (JSC::DFG::LazyNode::operator UnspecifiedBoolType*): Deleted.
        * heap/CopyWriteBarrier.h:
        (JSC::CopyWriteBarrier::operator!):
        (JSC::CopyWriteBarrier::operator bool):
        (JSC::CopyWriteBarrier::get):
        (JSC::CopyWriteBarrier::operator UnspecifiedBoolType*): Deleted.
        * heap/Handle.h:
        (JSC::HandleBase::operator!):
        (JSC::HandleBase::operator bool):
        (JSC::HandleBase::slot):
        (JSC::HandleBase::operator UnspecifiedBoolType*): Deleted.
        * heap/Strong.h:
        (JSC::Strong::operator!):
        (JSC::Strong::operator bool):
        (JSC::Strong::swap):
        (JSC::Strong::operator UnspecifiedBoolType*): Deleted.
        * jit/JITWriteBarrier.h:
        (JSC::JITWriteBarrierBase::operator bool):
        (JSC::JITWriteBarrierBase::operator!):
        (JSC::JITWriteBarrierBase::setFlagOnBarrier):
        (JSC::JITWriteBarrierBase::operator UnspecifiedBoolType*): Deleted.
        * runtime/JSArray.cpp:
        (JSC::JSArray::setLengthWithArrayStorage):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::JSValue):
        (JSC::JSValue::operator bool):
        (JSC::JSValue::operator==):
        (JSC::JSValue::operator UnspecifiedBoolType*): Deleted.
        * runtime/JSObject.h:
        (JSC::JSObject::hasSparseMap):
        * runtime/PropertyDescriptor.h:
        (JSC::PropertyDescriptor::writablePresent):
        (JSC::PropertyDescriptor::enumerablePresent):
        (JSC::PropertyDescriptor::configurablePresent):
        (JSC::PropertyDescriptor::setterPresent):
        (JSC::PropertyDescriptor::getterPresent):
        * runtime/WriteBarrier.h:
        (JSC::WriteBarrierBase::slot):
        (JSC::WriteBarrierBase::operator bool):
        (JSC::WriteBarrierBase::operator!):
        (JSC::WriteBarrierBase<Unknown>::tagPointer):
        (JSC::WriteBarrierBase<Unknown>::payloadPointer):
        (JSC::WriteBarrierBase<Unknown>::operator bool):
        (JSC::WriteBarrierBase<Unknown>::operator!):
        (JSC::WriteBarrierBase::operator UnspecifiedBoolType*): Deleted.
        (JSC::WriteBarrierBase<Unknown>::operator UnspecifiedBoolType*): Deleted.

2015-06-19  Anders Carlsson  <andersca@apple.com>

        Add a JSC symlink in /System/Library/PrivateFrameworks
        https://bugs.webkit.org/show_bug.cgi?id=146158
        rdar://problem/21465968

        Reviewed by Dan Bernstein.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2015-06-19  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Avoid getOwnPropertyNames/Symbols on very large lists
        https://bugs.webkit.org/show_bug.cgi?id=146141

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype._propertyDescriptors):
        Avoid calling getOwnPropertyNames/Symbols on very large lists. Instead
        just generate property descriptors for the first 100 indexes. Note
        this would behave poorly for sparse arrays with a length > 100, but
        general support for lists with more than 100 elements is poor. See:
        <https://webkit.org/b/143589> Web Inspector: Better handling for large collections in Object Trees

2015-06-18  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG] Avoid OSR exit in the middle of string concatenation
        https://bugs.webkit.org/show_bug.cgi?id=145820

        Reviewed by Filip Pizlo.

        DFG attempt to compile ValueAdd with String type into MakeRope(left, ToString(ToPrimitive(right))).

        So when right is speculated as SpecObject, ToPrimitive(SpecObject) is speculated as SpecString.
        It leads ToString to become Identity with a speculated type check.

        However, ToPrimitive and ToString are originated from the same bytecode. And ToPrimitive may have
        an observable side effect when the given parameter is an object (calling object.{toString,valueOf}).

        So when object.toString() returns a number (it is allowed in the ES spec), ToPrimitive performs
        observable `object.toString()` calling. But ToString is converted into a speculated type check for
        SpecString and it raises OSR exit. And we exit to the original ValueAdd's bytecode position and
        it redundantly performs an observable ToPrimitive execution.

        To fix this, this patch avoid fixing up for newly introduced ToString node.
        Since fix up phase is not iterated repeatedly, by avoiding fixing up when generating the node,
        we can avoid conversion from ToString to Check.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
        * tests/stress/toprimitive-speculated-types.js: Added.
        (shouldBe):
        (raw):
        (Counter):

2015-06-18  Brian J. Burg  <burg@cs.washington.edu>

        Web Inspector: improve generated types for objects passed to backend commands
        https://bugs.webkit.org/show_bug.cgi?id=146091

        Reviewed by Joseph Pecoraro.

        The main change is that objects passed in will have a type like const T& or const T*,
        rather than const RefPtr<T>&&. These protocol objects are owned by the generated dispatcher
        methods and only exist to pass data to backend command implementations. So, there is no
        reason for callees to add a reference or take ownership of these inputs.

        Some small improvements were made in the code generator to standardize how these
        expressions are generated for parameters. Optional in parameters are now prefixed with
        'opt_in_' to make the generated method signatures and implementations clearer.

        * inspector/InspectorValues.cpp:
        (Inspector::InspectorArrayBase::get): Add const qualifier.
        * inspector/InspectorValues.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
        (Inspector::parseLocation):
        (Inspector::InspectorDebuggerAgent::setBreakpoint):
        (Inspector::InspectorDebuggerAgent::continueToLocation):
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::callFunctionOn):
        (Inspector::InspectorRuntimeAgent::saveResult):
        (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
        * inspector/agents/InspectorRuntimeAgent.h:

        * inspector/scripts/codegen/cpp_generator.py: Always generate PrimitiveType('array').
        (CppGenerator.cpp_type_for_unchecked_formal_in_parameter): Alter the type signature
        for an unchecked input to use pointers or references.

        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
        (CppBackendDispatcherHeaderGenerator._generate_handler_declaration_for_command):
        (CppBackendDispatcherHeaderGenerator._generate_async_handler_declaration_for_command):
        Local variables for optional parameters now have the 'opt_' prefix.

        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
        (CppBackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain):
        (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
        Local variables for optional parameters now have the 'opt_' prefix.
        Split parameterName and parameterKey into two separate template variables to avoid mixups.

        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:

2015-06-18  Joseph Pecoraro  <pecoraro@apple.com>

        Unreviewed. Rollout r185670 as it caused some tests to be flakey.

        * debugger/Debugger.cpp:

2015-06-17  Alex Christensen  <achristensen@webkit.org>

        [Content Extensions] Log blocked loads to the WebInspector console
        https://bugs.webkit.org/show_bug.cgi?id=146089

        Reviewed by Joseph Pecoraro.

        * inspector/ConsoleMessage.cpp:
        (Inspector::messageSourceValue):
        * inspector/protocol/Console.json:
        * runtime/ConsoleTypes.h:
        Add content blocker message source.

2015-06-18  Saam Barati  <saambarati1@gmail.com>

        [ES6] support default values in deconstruction parameter nodes
        https://bugs.webkit.org/show_bug.cgi?id=142679

        Reviewed by Darin Adler.

        ES6 destructuring allows destructuring properties to assign 
        default values. A link to the spec: 
        https://people.mozilla.org/~jorendorff/es6-draft.html#sec-destructuring-binding-patterns

        This patch implements default values for all places where deconstruction
        is allowed besides function parameters. This is because function
        parameters are parsed in a separate parser arena than the function
        body itself and ExpresionNode's which are default values for
        deconstruction parameters will be deallocated by the time we parse the body
        of the function. I have opened a bug to address this problem:
        https://bugs.webkit.org/show_bug.cgi?id=145995

        * bytecompiler/NodesCodegen.cpp:
        (JSC::DeconstructionPatternNode::~DeconstructionPatternNode):
        (JSC::assignDefaultValueIfUndefined):
        (JSC::ArrayPatternNode::bindValue):
        (JSC::ArrayPatternNode::emitDirectBinding):
        (JSC::ArrayPatternNode::toString):
        (JSC::ArrayPatternNode::collectBoundIdentifiers):
        (JSC::ObjectPatternNode::bindValue):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::appendArrayPatternSkipEntry):
        (JSC::ASTBuilder::appendArrayPatternEntry):
        (JSC::ASTBuilder::createObjectPattern):
        (JSC::ASTBuilder::appendObjectPatternEntry):
        (JSC::ASTBuilder::createBindingLocation):
        * parser/Nodes.h:
        (JSC::ArrayPatternNode::appendIndex):
        (JSC::ObjectPatternNode::appendEntry):
        (JSC::ObjectPatternNode::Entry::Entry): Deleted.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseDeconstructionPattern):
        (JSC::Parser<LexerType>::parseDefaultValueForDeconstructionPattern):
        (JSC::Parser<LexerType>::parseConstDeclarationList):
        * parser/Parser.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::operatorStackPop):

2015-06-17  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Do not show JavaScriptCore builtins in inspector
        https://bugs.webkit.org/show_bug.cgi?id=146049

        Reviewed by Timothy Hatcher.

        * debugger/Debugger.cpp:

2015-06-17  Andreas Kling  <akling@apple.com>

        [JSC] jsSubstring() should have a fast path for 0..baseLength "substrings."
        <https://webkit.org/b/146051>

        Reviewed by Anders Carlsson.

        If asked to make a substring that actually spans the entire base string,
        have jsSubstring() just return the base instead of allocating a new JSString.

        3% speed-up on Octane/regexp.

        * runtime/JSString.h:
        (JSC::jsSubstring):

2015-06-16  Alex Christensen  <achristensen@webkit.org>

        32-bit build fix after r185640.

        * dfg/DFGIntegerRangeOptimizationPhase.cpp:
        Explicitly cast clamped int64_t to an int.

2015-06-09  Filip Pizlo  <fpizlo@apple.com>

        FTL should eliminate array bounds checks in loops
        https://bugs.webkit.org/show_bug.cgi?id=145768

        Reviewed by Benjamin Poulain.
        
        This adds a phase that does forward propagation of integer inequalities. This allows us
        to do the algebraic reasoning we need to eliminate array bounds checks in loops. It
        also eliminates overflow checks on ArithAdd with a constant.
        
        The phase's analysis produces results that are powerful enough to do speculative bounds
        check hoisting, but this phase currently only does elimination. We can implement
        hoisting later.
        
        On programs that just loop over an array like:
        
            for (var i = 0; i < array.length; ++i)
                thingy += array[i]
        
        This change is a 60% speed-up.
        
        This is also a ~3% speed-up on Kraken, and it shows various speed-ups on individual
        tests in Octane.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGIntegerRangeOptimizationPhase.cpp: Added.
        (JSC::DFG::performIntegerRangeOptimization):
        * dfg/DFGIntegerRangeOptimizationPhase.h: Added.
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * tests/stress/add-overflows-after-not-equal.js: Added.
        * tests/stress/no-abc-skippy-loop.js: Added.
        * tests/stress/no-abc-skippy-paired-loop.js: Added.
        * tests/stress/sub-overflows-after-not-equal.js: Added.

2015-06-16  Andreas Kling  <akling@apple.com>

        Remove unused template parameter InlineCapacity from SegmentedVector.
        <https://webkit.org/b/146044>

        Reviewed by Anders Carlsson.

        * bytecode/ArrayProfile.h:
        * dfg/DFGCommonData.h:

2015-06-16  Michael Saboff  <msaboff@apple.com>

        Inlining in the DFG trashes ByteCodeParser::m_currentInstruction for the calling function
        https://bugs.webkit.org/show_bug.cgi?id=146029

        Reviewed by Benjamin Poulain.

        Save and restore m_currentInstruction around call to ByteCodeParser::inlineCall() as it will
        use m_currentInstruction during its own parsing.  This happens because inlineCall() parses the
        inlined callee's bytecodes by calling parseCodeBlock() which calls parseBlock() on each block.
        It is in parseBlock() that we set m_currentInstruction to an instruction before we parse it.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::parseBlock): Added an ASSERT to catch this issue.

2015-06-16  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, roll out unintended JSC change from https://trac.webkit.org/changeset/185425.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::hasExitSite):
        (JSC::CodeBlock::exitProfile):
        (JSC::CodeBlock::numberOfExitSites): Deleted.
        * bytecode/DFGExitProfile.cpp:
        (JSC::DFG::ExitProfile::add):
        * bytecode/DFGExitProfile.h:
        (JSC::DFG::ExitProfile::hasExitSite):
        (JSC::DFG::ExitProfile::size): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::inliningCost):
        * runtime/Options.h:

2015-06-16  Mark Lam  <mark.lam@apple.com>

        Use NakedPtr<Exception>& to return exception results.
        https://bugs.webkit.org/show_bug.cgi?id=145870

        Reviewed by Anders Carlsson and Filip Pizlo.

        Before r185259, calls into the VM takes a JSValue* exception result argument for
        returning any uncaught exception that may have been thrown while executing JS code.
        As a result, clients of the VM functions will declare a local JSValue exception
        result which is automatically initialized to a null value (i.e. the empty value,
        not the JS null value).

        With r185259, the VM functions were changed to take an Exception*& exception result
        instead, and the VM functions are responsible for initializing the exception result
        to null if no exception is thrown.

        This introduces 2 issues:

        1. the VM functions are vulnerable to modifications that may add early returns
           before the exception result is nullified.  This can result in the exception
           result being used without initialization.

        2. Previously, a client could technically use the same exception result for more
           than one calls into the VM functions.  If an earlier call sets it to a thrown
           value, the thrown value will stick unless a subsequent call throws a different
           exception.

           With the new Exception*& exception result, the VM functions will always clear
           the exception result before proceeding.  As a result, the client's exception
           result will be null after the second call even though the first call saw an
           exception thrown.  This is a change in the expected behavior.

        To fix these issues, we'll introduce a NakedPtr smart pointer whose sole purpose
        is to guarantee that the pointer is initialized.  The VM functions will now take
        a NakedPtr<Exception>& instead of the Exception*&.  This ensures that the
        exception result is initialized.

        The VM functions be also reverted to only set the exception result if a new
        exception is thrown.

        * API/JSBase.cpp:
        (JSEvaluateScript):
        * API/JSScriptRef.cpp:
        * bindings/ScriptFunctionCall.cpp:
        (Deprecated::ScriptFunctionCall::call):
        * bindings/ScriptFunctionCall.h:
        * debugger/Debugger.cpp:
        (JSC::Debugger::hasBreakpoint):
        * debugger/Debugger.h:
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::thisValue):
        (JSC::DebuggerCallFrame::evaluate):
        * debugger/DebuggerCallFrame.h:
        (JSC::DebuggerCallFrame::isValid):
        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::createInjectedScript):
        * inspector/InspectorEnvironment.h:
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::evaluate):
        * inspector/JavaScriptCallFrame.h:
        (Inspector::JavaScriptCallFrame::vmEntryGlobalObject):
        (Inspector::JavaScriptCallFrame::thisValue):
        (Inspector::JavaScriptCallFrame::evaluate):
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::evaluateBreakpointAction):
        * jsc.cpp:
        (functionRun):
        (functionLoad):
        (runWithScripts):
        (runInteractive):
        * runtime/CallData.cpp:
        (JSC::call):
        * runtime/CallData.h:
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        (JSC::evaluate):
        * runtime/Completion.h:
        (JSC::evaluate):

2015-06-15  Filip Pizlo  <fpizlo@apple.com>

        FTL boolify() UntypedUse is wrong in the masquerades-as-undefined case
        https://bugs.webkit.org/show_bug.cgi?id=146002

        Reviewed by Darin Adler.

        * ftl/FTLLowerDFGToLLVM.cpp: Put this in an anonymous namespace. We should have done that all along. It makes it easier to add debug code.
        (JSC::FTL::DFG::LowerDFGToLLVM::boolify): Fix the bug.
        * tests/stress/logical-not-masquerades.js: Added. This test creates a masquerader so that the watchpoint is invalid. Previously this would fail for the normal object cases.
        (foo):

2015-06-16  Andreas Kling  <akling@apple.com>

        [JSC] Pre-bake final Structure for RegExp matches arrays.
        <https://webkit.org/b/146006>

        Reviewed by Darin Adler.

        Since we always add the "index" and "input" fields to RegExp matches arrays,
        cache a finished structure on the global object so we can create these arrays without
        starting from scratch with a bare array every time.

        10% progression on Octane/regexp (on my MBP.)

        * runtime/JSArray.h:
        (JSC::JSArray::create):
        (JSC::JSArray::tryCreateUninitialized):
        (JSC::JSArray::createWithButterfly): Factored out JSArray construction into a helper
        so we can call this from RegExpMatchesArray.cpp.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::regExpMatchesArrayStructure): Add a cached Structure for RegExp
        subpattern matches arrays.

        * runtime/JSObject.h:
        (JSC::JSNonFinalObject::finishCreation): Tweak assertion that used to check that
        JSNonFinalObjects always start out with zero capacity. Since RegExp matches arrays now
        start out with capacity for 2 properties, that won't work. Change it to check that we
        don't have inline storage instead, since that should only be used by final objects.

        * runtime/RegExpMatchesArray.h:
        * runtime/RegExpMatchesArray.cpp:
        (JSC::tryCreateUninitializedRegExpMatchesArray): Helper to construct a JSArray with
        the cached Structure and a Butterfly with 2 slots of property storage.

        (JSC::createRegExpMatchesArray):
        (JSC::createRegExpMatchesArrayStructure): Creates the array Structure that gets cached
        by the JSGlobalObject.

2015-06-16  Saam Barati  <saambarati1@gmail.com>

        LLInt's code path for get_from_scope with case GlobalVarWithVarInjectionChecks has dead code
        https://bugs.webkit.org/show_bug.cgi?id=144268

        Reviewed by Darin Adler.

        The call to loadVariable(.) both for 32bit and 64bit is unnecessary. 
        It grabs a value that is immediately overwritten by a call to getGlobalVar(). 

        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2015-06-14  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Introduce %IteratorPrototype% and drop all XXXIteratorConstructor
        https://bugs.webkit.org/show_bug.cgi?id=145963

        Reviewed by Darin Adler.

        ES6 iterators inherit %IteratorPrototype%.
        And these prototype objects of derived iterators don't have @@iterator methods.
        Instead they use the %IteratorPrototype%[@@iterator] method.

        To encourage inlining in for-of statement, we define this method in JS builtins.

        And these iterator prototype objects don't have any constructor function.
        This patch drops them (like StringIteratorConstructor).

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/Iterator.prototype.js: Renamed from Source/JavaScriptCore/runtime/StringIteratorConstructor.cpp.
        (SymbolIterator):
        * runtime/ArrayIteratorConstructor.cpp:
        (JSC::ArrayIteratorConstructor::finishCreation): Deleted.
        * runtime/ArrayIteratorConstructor.h: Removed.
        (JSC::ArrayIteratorConstructor::create): Deleted.
        (JSC::ArrayIteratorConstructor::createStructure): Deleted.
        (JSC::ArrayIteratorConstructor::ArrayIteratorConstructor): Deleted.
        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation):
        (JSC::arrayIteratorProtoFuncIterator): Deleted.
        * runtime/IteratorPrototype.cpp: Renamed from Source/JavaScriptCore/runtime/ArrayIteratorConstructor.cpp.
        (JSC::IteratorPrototype::finishCreation):
        * runtime/IteratorPrototype.h: Renamed from Source/JavaScriptCore/runtime/SetIteratorConstructor.h.
        (JSC::IteratorPrototype::create):
        (JSC::IteratorPrototype::createStructure):
        (JSC::IteratorPrototype::IteratorPrototype):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::createBuiltinFunction):
        * runtime/JSFunction.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::iteratorPrototype):
        * runtime/MapIteratorConstructor.cpp: Removed.
        (JSC::MapIteratorConstructor::finishCreation): Deleted.
        * runtime/MapIteratorConstructor.h: Removed.
        (JSC::MapIteratorConstructor::create): Deleted.
        (JSC::MapIteratorConstructor::createStructure): Deleted.
        (JSC::MapIteratorConstructor::MapIteratorConstructor): Deleted.
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototype::finishCreation): Deleted.
        (JSC::MapIteratorPrototypeFuncIterator): Deleted.
        * runtime/SetIteratorConstructor.cpp: Removed.
        (JSC::SetIteratorConstructor::finishCreation): Deleted.
        * runtime/SetIteratorConstructor.h:
        (JSC::SetIteratorConstructor::create): Deleted.
        (JSC::SetIteratorConstructor::createStructure): Deleted.
        (JSC::SetIteratorConstructor::SetIteratorConstructor): Deleted.
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototype::finishCreation): Deleted.
        (JSC::SetIteratorPrototypeFuncIterator): Deleted.
        * runtime/StringIteratorConstructor.cpp:
        (JSC::StringIteratorConstructor::finishCreation): Deleted.
        * runtime/StringIteratorConstructor.h: Removed.
        (JSC::StringIteratorConstructor::create): Deleted.
        (JSC::StringIteratorConstructor::createStructure): Deleted.
        (JSC::StringIteratorConstructor::StringIteratorConstructor): Deleted.
        * runtime/StringIteratorPrototype.cpp:
        (JSC::StringIteratorPrototype::finishCreation):
        (JSC::stringIteratorPrototypeIterator): Deleted.
        * tests/stress/iterator-prototype.js: Added.
        (shouldBe):
        (inheritIteratorPrototype):
        (testChain):

2015-06-15  Michael Saboff  <msaboff@apple.com>

        JIT bug - fails when inspector closed, works when open
        https://bugs.webkit.org/show_bug.cgi?id=145243

        Reviewed by Oliver Hunt.

        We need to provide the Arguments object as the base when creating the HeapLocation for
        GetFromArguments and PutToArguments.  Otherwise we endup creating a HeapLocation for
        any arguments object, not the one we need.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):

2015-06-13  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: console.table() with a list of objects no longer works
        https://bugs.webkit.org/show_bug.cgi?id=145952

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.RemoteObject.prototype._generatePreview):
        Calling generatePreview again was actually starting with a preview
        of the current object instead of the sub-value. Go down the other
        path that correctly generates sub-previews. Leave filtering on the
        backend unimplemented, which we were already ignoring.

2015-06-13  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        [Streams API] ReadableJSStream should handle promises returned by JS source start callback
        https://bugs.webkit.org/show_bug.cgi?id=145792

        Reviewed by Darin Adler.

        Added support for JSFunction implemented by std::function.

        * runtime/JSFunction.cpp:
        (JSC::getNativeExecutable): Refactored code to share it with the two JSFunction::create
        (JSC::JSFunction::create):
        (JSC::runStdFunction):
        * runtime/JSFunction.h: Added std::function based JSFunction::create prototype.
        * runtime.JSPromise.h:

2015-06-12  Gyuyoung Kim  <gyuyoung.kim@webkit.org>

        Purge PassRefPtr in JavaScriptCore - 2
        https://bugs.webkit.org/show_bug.cgi?id=145834

        Reviewed by Darin Adler.

        As a step to remove PassRefPtr, this patch cleans up PassRefPtr as much as possible
        in JavaScriptCore.

        * API/JSClassRef.cpp:
        (OpaqueJSClass::create):
        * API/JSClassRef.h:
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::callerFrame):
        * debugger/DebuggerCallFrame.h:
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::jitCode):
        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::createScriptCallStack):
        (Inspector::createScriptCallStackForConsole):
        (Inspector::createScriptCallStackFromException):
        (Inspector::createScriptArguments):
        * inspector/ScriptCallStackFactory.h:
        * jit/ExecutableAllocator.cpp:
        (JSC::ExecutableAllocator::allocate):
        * jit/ExecutableAllocator.h:
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC::ExecutableAllocator::allocate):
        * profiler/LegacyProfiler.cpp:
        (JSC::LegacyProfiler::stopProfiling):
        * profiler/LegacyProfiler.h:
        * runtime/DateInstanceCache.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        * runtime/Executable.h:
        * runtime/GenericTypedArrayView.h:
        * runtime/GenericTypedArrayViewInlines.h:
        (JSC::GenericTypedArrayView<Adaptor>::create):
        (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):

2015-06-12  Darin Adler  <darin@apple.com>

        Fix minor ES6 compliance issue in RegExp.prototype.toString and optimize performance a little
        https://bugs.webkit.org/show_bug.cgi?id=145935

        Reviewed by Anders Carlsson.

        Test: js/regexp-toString.html

        * runtime/RegExpPrototype.cpp:
        (JSC::getFlags): Avoid memory allocation for the flags string by returning it in a character
        buffer instead of constructing a WTF::String for it.
        (JSC::regExpProtoFuncToString): Require only that the this value be an object; don't require
        that it is actually a regular expression object. This is covered in the ES6 specification.
        Also removed comment about the "/(?:)/" trick since that is now the repsonsibility of the
        getter for the "source" property. Updated to use getFlags so we do one less memory allocation.
        (JSC::regExpProtoGetterFlags): Chagned to use getFlags instead of the old flagsString.

2015-06-12  Basile Clement  <basile_clement@apple.com>

        DFG Object Allocation Sinking should not consider GetClosureVar as escapes
        https://bugs.webkit.org/show_bug.cgi?id=145904

        Reviewed by Filip Pizlo.

        The object allocation sinking phase is currently able to sink
        CreateActivation nodes, but will consider any GetClosureVar node as
        escaping.

        This is not problematic in general as most of the GetClosureVar nodes
        we would have been able to sink over will have been eliminated by CSE
        anyway. Still, this is an oversight that we should fix since the
        machinery is already in place.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        * dfg/DFGPromoteHeapAccess.h:
        (JSC::DFG::promoteHeapAccess):

2015-06-11  Mark Lam  <mark.lam@apple.com>

        WebCore::reportException() needs to be able to accept a raw thrown value in addition to Exception objects.
        https://bugs.webkit.org/show_bug.cgi?id=145872

        Reviewed by Michael Saboff.

        In r185259, we changed exception handling code inside the VM to work with
        Exception objects instead of the thrown JSValue.  The handling code will get the
        exception stack trace from the Exception object.

        However, there is some code that cannot be updated to pass the Exception object.
        An example of this are the ObjC API functions.  Those functions are specified to
        return any thrown exception JSValue in a JSValueRef.  Since these APIs are
        public, we cannot arbitrarily change them to use the Exception object.

        There are client code that calls these APIs and then passes the returned exception
        JSValue to WebCore::reportException() to be reported.  WebCore::reportException()
        previously relied on the VM::exceptionStackTrace() to provide a cache of the
        stack trace of the last thrown exception.  VM::exceptionStackTrace() no longer
        exists in the current code.

        To restore this functionality, we will introduce VM::lastException() which
        caches the last thrown Exception object.  With this, if the exception passed to
        WebCore::reportException() to be reported isn't an Exception object (which has its
        own stack trace), reportException() can again use the cached exception stack trace
        which is available from VM::lastException().

        * heap/Heap.cpp:
        (JSC::Heap::visitException):
        - visit VM::m_lastException on GCs.

        * interpreter/CallFrame.h:
        (JSC::ExecState::lastException):
        (JSC::ExecState::clearLastException):
        - convenience functions to get and clear the last exception.

        * runtime/Exception.cpp:
        (JSC::Exception::create):
        (JSC::Exception::finishCreation):
        - add support to create an Exception object without capturing the JS stack trace.
          This is needed for making an Exception object to wrap a thrown value that does
          not have a stack trace.
          Currently, this is only used by WebCore::reportException() when there is no
          Exception object and no last exception available to provide a stack trace.

        * runtime/Exception.h:
        (JSC::Exception::cast): Deleted.  No longer needed.

        * runtime/VM.h:
        (JSC::VM::clearLastException):
        (JSC::VM::setException):
        (JSC::VM::lastException):
        (JSC::VM::addressOfLastException):
        - Added support for VM::m_lastException.
          VM::m_lastException serves to cache the exception stack of the most recently
          thrown exception like VM::exceptionStackTrace() used to before r185259.

        * runtime/VMEntryScope.cpp:
        (JSC::VMEntryScope::VMEntryScope):
        - Clear VM::m_lastException when we re-enter the VM.  Exceptions should have been
          handled before we re-enter the VM anyway.  So, this is a good place to release
          the cached last exception.

          NOTE: this is also where the old code before r185259 clears the last exception
          stack trace.  So, we're just restoring the previous behavior here in terms of
          the lifecycle of the last exception stack.

2015-06-11  Andreas Kling  <akling@apple.com>

        jsSubstring() should support creating substrings from substrings.
        <https://webkit.org/b/145427>

        Reviewed by Geoffrey Garen

        Tweak jsSubstring() to support base strings that are themselves substrings.
        They will now share the same grandparent base. This avoids creating a new StringImpl.

        * runtime/JSString.h:
        (JSC::jsSubstring): Don't force rope resolution here. Instead do that in finishCreation()
        if the base string is a non-substring rope. Note that resolveRope() is the very last thing
        called, since it may allocate and the JSRopeString needs to be ready for marking.

        (JSC::JSString::isSubstring): Added a helper to find out if a JSString is
        a substring. This is just for internal use, so you don't have to cast to
        JSRopeString for the real substringness flag.

2015-06-11  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r185465.
        https://bugs.webkit.org/show_bug.cgi?id=145893

        "This patch is breaking 32bit mac build" (Requested by youenn
        on #webkit).

        Reverted changeset:

        "[Streams API] ReadableJSStream should handle promises
        returned by JS source start callback"
        https://bugs.webkit.org/show_bug.cgi?id=145792
        http://trac.webkit.org/changeset/185465

2015-06-11  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        [Streams API] ReadableJSStream should handle promises returned by JS source start callback
        https://bugs.webkit.org/show_bug.cgi?id=145792

        Reviewed by Darin Adler.

        Added support for JSFunction implemented by std::function.

        * runtime/JSFunction.cpp:
        (JSC::getNativeExecutable): Refactored code to share it with the two JSFunction::create
        (JSC::JSFunction::create):
        (JSC::runStdFunction):
        * runtime/JSFunction.h: Added std::function based JSFunction::create prototype.
        * runtime.JSPromise.h:

2015-06-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        ASSERTION FAILED: s.length() > 1 on LayoutTests/js/regexp-flags.html
        https://bugs.webkit.org/show_bug.cgi?id=145599

        Unreviewed, simple follow up patch.

        use jsString instead of jsMakeNontrivialString
        since the flag string may be trivial (0 or 1 length).

        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoGetterFlags):

2015-06-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        JavaScript: Drop the “escaped reserved words as identifiers” compatibility measure
        https://bugs.webkit.org/show_bug.cgi?id=90678

        Reviewed by Darin Adler.

        After ES6, escaped reserved words in identifiers are prohibited.
        After parsing Identifier, we should perform `m_buffer16.shrink(0)`.

        * parser/Lexer.cpp:
        (JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
        * tests/mozilla/ecma_3/Unicode/uc-003.js:
        (test): Deleted.
        * tests/stress/reserved-word-with-escape.js: Added.
        (testSyntax):
        (testSyntaxError):

2015-06-10  Jordan Harband  <ljharb@gmail.com>

        Implement RegExp.prototype.flags
        https://bugs.webkit.org/show_bug.cgi?id=145599

        Reviewed by Geoffrey Garen.
        Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-get-regexp.prototype.flags

        * runtime/CommonIdentifiers.h:
        * runtime/RegExpPrototype.cpp:
        (JSC::flagsString):
        (JSC::regExpProtoFuncToString):
        (JSC::regExpProtoGetterFlags):
        * tests/stress/static-getter-in-names.js:

2015-06-10  Filip Pizlo  <fpizlo@apple.com>

        DFG ASSERTION FAILED: !iterate() on stress/singleton-scope-then-overwrite.js.ftl-eager
        https://bugs.webkit.org/show_bug.cgi?id=145853

        Unreviewed, remove the assertion.

        * dfg/DFGCSEPhase.cpp:

2015-06-10  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r185414.
        https://bugs.webkit.org/show_bug.cgi?id=145844

        broke debug and jsc tests (Requested by alexchristensen on
        #webkit).

        Reverted changeset:

        "JavaScript: Drop the “escaped reserved words as identifiers”
        compatibility measure"
        https://bugs.webkit.org/show_bug.cgi?id=90678
        http://trac.webkit.org/changeset/185414

2015-06-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        JavaScript: Drop the “escaped reserved words as identifiers” compatibility measure
        https://bugs.webkit.org/show_bug.cgi?id=90678

        Reviewed by Darin Adler.

        After ES6, escaped reserved words in identifiers are prohibited.

        * parser/Lexer.cpp:
        (JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
        * tests/stress/reserved-word-with-escape.js: Added.
        (testSyntax):
        (testSyntaxError):

2015-06-10  Andreas Kling  <akling@apple.com>

        [JSC] InlineCallFrame::arguments should be sized-to-fit.
        <https://webkit.org/b/145782>

        Reviewed by Darin Adler.

        I spotted this Vector<ValueRecovery> looking a bit chubby in Instruments,
        with 354 kB of memory allocated on cnet.com.

        Use resizeToFit() instead of resize() since we know the final size up front.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):

2015-06-09  Chris Dumez  <cdumez@apple.com>

        Allow one sync GC per gcTimer interval on critical memory pressure warning
        https://bugs.webkit.org/show_bug.cgi?id=145773

        Reviewed by Geoffrey Garen.

        On critical memory pressure warning, we were calling GCController::garbageCollectSoon(),
        which does not offer any guarantee on when the garbage collection will actually take
        place.

        On critical memory pressure, we need to free up memory as soon as possible to avoid
        getting killed so this is an issue. Also, the fact that we clear the PageCache on
        critical memory pressure means a GC would likely be useful, even if the last
        collection did not free much memory.

        This patch adds a new GCController::garbageCollectNowIfNotDoneRecently() API that allows
        one synchronous GC per gcTimer interval on critical memory pressure warning. This makes
        us more responsive to critical memory pressure and avoids doing synchronous GCs too
        often.

        * heap/FullGCActivityCallback.cpp:
        (JSC::FullGCActivityCallback::doCollection):
        * heap/FullGCActivityCallback.h:
        (JSC::GCActivityCallback::createFullTimer):
        * heap/GCActivityCallback.h:
        * heap/Heap.cpp:
        (JSC::Heap::collectAllGarbageIfNotDoneRecently):
        * heap/Heap.h:

        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::doWork): Deleted.
        * heap/IncrementalSweeper.h:

        Drop fullSweep() API as it no longer seems useful. garbageCollectNow()
        already does a sweep after the full collection.

2015-06-09  Andreas Kling  <akling@apple.com>

        [JSC] CodeBlock::m_constantRegisters should be sized-to-fit.
        <https://webkit.org/b/145784>

        Reviewed by Darin Adler.

        Spotted this Vector looking chubby on cnet.com, with 1.23 MB of memory
        allocated below CodeBlock::setConstantRegisters().

        Use resizeToFit() instead since we know the final size up front.
        Also removed some unused functions that operated on this constants vector
        and the corresponding one in UnlinkedCodeBlock.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::addOrFindConstant): Deleted.
        (JSC::CodeBlock::findConstant): Deleted.
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setConstantRegisters):
        (JSC::CodeBlock::numberOfConstantRegisters): Deleted.
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::addOrFindConstant): Deleted.
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::numberOfConstantRegisters): Deleted.
        (JSC::UnlinkedCodeBlock::getConstant): Deleted.

2015-06-09  Andreas Kling  <akling@apple.com>

        [JSC] Polymorphic{Get,Put}ByIdList::addAccess() should optimize for size, not speed.
        <https://webkit.org/b/145786>

        Reviewed by Darin Adler.

        These functions already contained comments saying they optimize for size over speed,
        but they were using Vector::resize() which adds the usual slack for faster append().

        Switch them over to using Vector::resizeToFit() instead, which makes the Vector
        allocate a perfectly sized backing store.

        Spotted 670 kB of the GetById ones, and 165 kB of PutById on cnet.com, so these
        Vectors are definitely worth shrink-wrapping.

        * bytecode/PolymorphicGetByIdList.cpp:
        (JSC::PolymorphicGetByIdList::addAccess):
        * bytecode/PolymorphicPutByIdList.cpp:
        (JSC::PolymorphicPutByIdList::addAccess):

2015-06-09  Andreas Kling  <akling@apple.com>

        [JSC] JSPropertyNameEnumerator's property name vector should be sized-to-fit.
        <https://webkit.org/b/145787>

        Reviewed by Darin Adler.

        Saw 108 kB worth of JSPropertyNameEnumerator backing store Vectors on cnet.com.
        Use Vector::resizeToFit() since we know the perfect size up front.

        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::finishCreation):

2015-06-09  Andreas Kling  <akling@apple.com>

        FunctionExecutable::isCompiling() is weird and wrong.
        <https://webkit.org/b/145689>

        Reviewed by Geoffrey Garen.

        Remove FunctionExecutable::isCompiling() and the clearCodeIfNotCompiling() style
        functions that called it before throwing away code.

        isCompiling() would consider the executable to be "compiling" if it had a CodeBlock
        but no JITCode. In practice, every executable gets a JITCode at the same time as it
        gets a CodeBlock, by way of prepareForExecutionImpl().

        * debugger/Debugger.cpp:
        * heap/Heap.cpp:
        (JSC::Heap::deleteAllCompiledCode):
        (JSC::Heap::deleteAllUnlinkedFunctionCode):
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::TypeRecompiler::visit):
        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilation):
        (JSC::FunctionExecutable::clearCodeIfNotCompiling): Deleted.
        (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilationIfNotCompiling): Deleted.
        * runtime/Executable.h:
        * runtime/VM.cpp:
        (JSC::StackPreservingRecompiler::visit):

2015-06-09  Yusuke Suzuki  <utatane.tea@gmail.com>

        Introduce getter definition into static hash tables and use it for getters in RegExp.prototype.
        https://bugs.webkit.org/show_bug.cgi?id=145705

        Reviewed by Darin Adler.

        In this patch, we introduce Accessor type into property tables.
        With Accessor type, create_hash_table creates a static getter property.
        This getter property is reified as the same to the static functions.

        In the mean time, we only support getter because `putEntry` and `lookupPut`
        only work with null setter currently. However, in the spec, there's
        no need to add static setter properties. So we will add it if it becomes
        necessary in the future.

        And at the same time, this patch fixes the issue 145738. Before this patch,
        `putEntry` in `JSObject::deleteProperty` adds `undefined` property if
        `isValidOffset(...)` is false (deleted). As the result, deleting twice
        revives the property with `undefined` value.

        If the static functions are reified and the entry is
        `BuiltinOrFunctionOrAccessor`, there's no need to execute `putEntry` with
        static hash table entry. They should be handled in the normal structure's
        looking up because they should be already reified. So added guard for this.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * create_hash_table:
        * runtime/JSObject.cpp:
        (JSC::getClassPropertyNames):
        (JSC::JSObject::put):
        (JSC::JSObject::deleteProperty):
        (JSC::JSObject::reifyStaticFunctionsForDelete):
        * runtime/Lookup.cpp:
        (JSC::reifyStaticAccessor):
        (JSC::setUpStaticFunctionSlot):
        * runtime/Lookup.h:
        (JSC::HashTableValue::propertyGetter):
        (JSC::HashTableValue::propertyPutter):
        (JSC::HashTableValue::accessorGetter):
        (JSC::HashTableValue::accessorSetter):
        (JSC::getStaticPropertySlot):
        (JSC::getStaticValueSlot):
        (JSC::putEntry):
        (JSC::reifyStaticProperties):
        * runtime/PropertySlot.h:
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::getOwnPropertySlot):
        (JSC::regExpObjectGlobal): Deleted.
        (JSC::regExpObjectIgnoreCase): Deleted.
        (JSC::regExpObjectMultiline): Deleted.
        (JSC::appendLineTerminatorEscape<LChar>): Deleted.
        (JSC::appendLineTerminatorEscape<UChar>): Deleted.
        (JSC::regExpObjectSourceInternal): Deleted.
        (JSC::regExpObjectSource): Deleted.
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::getOwnPropertySlot):
        (JSC::regExpProtoGetterGlobal):
        (JSC::regExpProtoGetterIgnoreCase):
        (JSC::regExpProtoGetterMultiline):
        (JSC::appendLineTerminatorEscape<LChar>):
        (JSC::appendLineTerminatorEscape<UChar>):
        (JSC::regExpProtoGetterSourceInternal):
        (JSC::regExpProtoGetterSource):
        * tests/stress/static-function-delete.js: Added.
        (shouldBe):
        * tests/stress/static-function-put.js: Added.
        (shouldBe):
        * tests/stress/static-getter-delete.js: Added.
        (shouldBe):
        (shouldThrow):
        * tests/stress/static-getter-descriptors.js: Added.
        (shouldBe):
        * tests/stress/static-getter-enumeration.js: Added.
        (shouldBe):
        * tests/stress/static-getter-get.js: Added.
        (shouldBe):
        * tests/stress/static-getter-in-names.js: Added.
        (shouldBe):
        * tests/stress/static-getter-names.js: Added.
        (shouldBe):
        * tests/stress/static-getter-put.js: Added.
        (shouldBe):
        (shouldThrow):

2015-06-09  Andreas Kling  <akling@apple.com>

        [JSC] JSString::getIndex() should avoid reifying substrings.
        <https://webkit.org/b/145803>

        Reviewed by Darin Adler.

        Implement getIndex() using JSString::view(), which cuts it down to a one-liner
        and also avoids reifying substrings.

        I saw 178 kB of reified substrings below operationGetByVal -> getIndex()
        on cnet.com, so this should help.

        * runtime/JSString.cpp:
        (JSC::JSRopeString::getIndexSlowCase): Deleted.
        * runtime/JSString.h:
        (JSC::JSString::getIndex):

2015-06-09  Andreas Kling  <akling@apple.com>

        [JSC] String.prototype.indexOf() should use StringView.
        <https://webkit.org/b/145351>

        Reviewed by Darin Adler.

        Use StringView::find() to implement String.prototype.indexOf().
        This avoids reifying the needle and haystack JSStrings in case they
        are substrings.

        Reduces malloc memory by ~190 kB on cnet.com.

        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncIndexOf):

2015-06-09  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] Fix the style issues in cmake project files
        https://bugs.webkit.org/show_bug.cgi?id=145755

        Reviewed by Darin Adler.

        * CMakeLists.txt:

2015-06-08  Gyuyoung Kim  <gyuyoung.kim@webkit.org>

        Purge PassRefPtr in JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=145750

        As a step to purge PassRefPtr, this patch replaces PassRefPtr with Ref or RefPtr.

        Reviewed by Darin Adler.

        * API/JSClassRef.cpp:
        (OpaqueJSClass::createNoAutomaticPrototype):
        * API/JSClassRef.h:
        * API/JSContextRef.cpp:
        * API/JSScriptRef.cpp:
        (OpaqueJSScript::create):
        * API/JSStringRef.cpp:
        (JSStringCreateWithCharacters):
        (JSStringCreateWithUTF8CString):
        * API/OpaqueJSString.cpp:
        (OpaqueJSString::create):
        * API/OpaqueJSString.h:
        (OpaqueJSString::create):
        * bytecompiler/StaticPropertyAnalysis.h:
        (JSC::StaticPropertyAnalysis::create):
        * debugger/DebuggerCallFrame.h:
        (JSC::DebuggerCallFrame::create):
        * dfg/DFGToFTLDeferredCompilationCallback.cpp:
        (JSC::DFG::ToFTLDeferredCompilationCallback::create):
        * dfg/DFGToFTLDeferredCompilationCallback.h:
        * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
        (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::create): Deleted.
        * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::create):
        (JSC::DFG::ensureGlobalDFGWorklist):
        (JSC::DFG::ensureGlobalFTLWorklist):
        * dfg/DFGWorklist.h:
        * heap/EdenGCActivityCallback.h:
        (JSC::GCActivityCallback::createEdenTimer):
        * heap/FullGCActivityCallback.h:
        (JSC::GCActivityCallback::createFullTimer):
        * heap/GCActivityCallback.h:
        * inspector/InjectedScriptHost.h:
        * inspector/JavaScriptCallFrame.h:
        (Inspector::JavaScriptCallFrame::create):
        * inspector/ScriptArguments.cpp:
        (Inspector::ScriptArguments::create):
        * inspector/ScriptArguments.h:
        * jit/JITStubRoutine.h:
        (JSC::JITStubRoutine::createSelfManagedRoutine):
        * jit/JITToDFGDeferredCompilationCallback.cpp:
        (JSC::JITToDFGDeferredCompilationCallback::create):
        * jit/JITToDFGDeferredCompilationCallback.h:
        * jsc.cpp:
        (jscmain):
        * parser/NodeConstructors.h:
        (JSC::ArrayPatternNode::create):
        (JSC::ObjectPatternNode::create):
        (JSC::BindingNode::create):
        * parser/Nodes.cpp:
        (JSC::FunctionParameters::create):
        * parser/Nodes.h:
        * parser/SourceProvider.h:
        (JSC::StringSourceProvider::create):
        * profiler/Profile.cpp:
        (JSC::Profile::create):
        * profiler/Profile.h:
        * profiler/ProfileGenerator.cpp:
        (JSC::ProfileGenerator::create):
        * profiler/ProfileGenerator.h:
        * profiler/ProfileNode.h:
        (JSC::ProfileNode::create):
        * runtime/DataView.cpp:
        (JSC::DataView::create):
        * runtime/DataView.h:
        * runtime/DateInstanceCache.h:
        (JSC::DateInstanceData::create):
        * runtime/JSPromiseReaction.cpp:
        (JSC::createExecutePromiseReactionMicrotask):
        * runtime/JSPromiseReaction.h:
        * runtime/PropertyNameArray.h:
        (JSC::PropertyNameArrayData::create):
        * runtime/TypeSet.h:
        (JSC::StructureShape::create):
        (JSC::TypeSet::create):
        * runtime/TypedArrayBase.h:
        (JSC::TypedArrayBase::create):
        (JSC::TypedArrayBase::createUninitialized):
        (JSC::TypedArrayBase::subarrayImpl):
        * runtime/VM.cpp:
        (JSC::VM::createContextGroup):
        (JSC::VM::create):
        (JSC::VM::createLeaked):
        * runtime/VM.h:
        * yarr/RegularExpression.cpp:
        (JSC::Yarr::RegularExpression::Private::create):

2015-06-08  Filip Pizlo  <fpizlo@apple.com>

        It should be possible to hoist all constants in DFG SSA
        https://bugs.webkit.org/show_bug.cgi?id=145769

        Reviewed by Geoffrey Garen.
        
        It's sometimes somewhat more efficient, and convenient, to have all constants at the
        top of the root block. We don't require this as an IR invariant because too many phases
        want to be able to insert constants in weird places. But, this phase will be great for
        preparing for https://bugs.webkit.org/show_bug.cgi?id=145768.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGConstantHoistingPhase.cpp: Added.
        (JSC::DFG::performConstantHoisting):
        * dfg/DFGConstantHoistingPhase.h: Added.
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):

2015-06-07  Filip Pizlo  <fpizlo@apple.com>

        The tiny set magic in StructureSet should be available in WTF
        https://bugs.webkit.org/show_bug.cgi?id=145722

        Reviewed by Geoffrey Garen.
        
        I moved the generic logic of small sets of pointers and moved it into WTF. Now,
        StructureSet is a subclass of TinyPtrSet<Structure*>. There shouldn't be any functional
        change.

        * bytecode/StructureSet.cpp:
        (JSC::StructureSet::filter):
        (JSC::StructureSet::filterArrayModes):
        (JSC::StructureSet::speculationFromStructures):
        (JSC::StructureSet::arrayModesFromStructures):
        (JSC::StructureSet::dumpInContext):
        (JSC::StructureSet::dump):
        (JSC::StructureSet::clear): Deleted.
        (JSC::StructureSet::add): Deleted.
        (JSC::StructureSet::remove): Deleted.
        (JSC::StructureSet::contains): Deleted.
        (JSC::StructureSet::merge): Deleted.
        (JSC::StructureSet::exclude): Deleted.
        (JSC::StructureSet::isSubsetOf): Deleted.
        (JSC::StructureSet::overlaps): Deleted.
        (JSC::StructureSet::operator==): Deleted.
        (JSC::StructureSet::addOutOfLine): Deleted.
        (JSC::StructureSet::containsOutOfLine): Deleted.
        (JSC::StructureSet::copyFromOutOfLine): Deleted.
        (JSC::StructureSet::OutOfLineList::create): Deleted.
        (JSC::StructureSet::OutOfLineList::destroy): Deleted.
        * bytecode/StructureSet.h:
        (JSC::StructureSet::onlyStructure):
        (JSC::StructureSet::StructureSet): Deleted.
        (JSC::StructureSet::operator=): Deleted.
        (JSC::StructureSet::~StructureSet): Deleted.
        (JSC::StructureSet::isEmpty): Deleted.
        (JSC::StructureSet::genericFilter): Deleted.
        (JSC::StructureSet::isSupersetOf): Deleted.
        (JSC::StructureSet::size): Deleted.
        (JSC::StructureSet::at): Deleted.
        (JSC::StructureSet::operator[]): Deleted.
        (JSC::StructureSet::last): Deleted.
        (JSC::StructureSet::iterator::iterator): Deleted.
        (JSC::StructureSet::iterator::operator*): Deleted.
        (JSC::StructureSet::iterator::operator++): Deleted.
        (JSC::StructureSet::iterator::operator==): Deleted.
        (JSC::StructureSet::iterator::operator!=): Deleted.
        (JSC::StructureSet::begin): Deleted.
        (JSC::StructureSet::end): Deleted.
        (JSC::StructureSet::ContainsOutOfLine::ContainsOutOfLine): Deleted.
        (JSC::StructureSet::ContainsOutOfLine::operator()): Deleted.
        (JSC::StructureSet::copyFrom): Deleted.
        (JSC::StructureSet::OutOfLineList::list): Deleted.
        (JSC::StructureSet::OutOfLineList::OutOfLineList): Deleted.
        (JSC::StructureSet::deleteStructureListIfNecessary): Deleted.
        (JSC::StructureSet::isThin): Deleted.
        (JSC::StructureSet::pointer): Deleted.
        (JSC::StructureSet::singleStructure): Deleted.
        (JSC::StructureSet::structureList): Deleted.
        (JSC::StructureSet::set): Deleted.
        (JSC::StructureSet::setEmpty): Deleted.
        (JSC::StructureSet::getReservedFlag): Deleted.
        (JSC::StructureSet::setReservedFlag): Deleted.
        * dfg/DFGStructureAbstractValue.cpp:
        (JSC::DFG::StructureAbstractValue::clobber):
        (JSC::DFG::StructureAbstractValue::filter):
        (JSC::DFG::StructureAbstractValue::filterSlow):
        (JSC::DFG::StructureAbstractValue::contains):
        * dfg/DFGStructureAbstractValue.h:
        (JSC::DFG::StructureAbstractValue::makeTop):

2015-06-08  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Add the missing setupArgumentsWithExecState functions after r185240
        https://bugs.webkit.org/show_bug.cgi?id=145754

        Reviewed by Benjamin Poulain.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):

2015-06-08  Brady Eidson  <beidson@apple.com>

        Completely remove all IDB properties/constructors when it is disabled at runtime.
        rdar://problem/18429374 and https://bugs.webkit.org/show_bug.cgi?id=137034

        Reviewed by Geoffrey Garen.

        * runtime/CommonIdentifiers.h:

2015-06-06  Mark Lam  <mark.lam@apple.com>

        Returned Exception* values need to be initialized to nullptr when no exceptions are thrown.
        https://bugs.webkit.org/show_bug.cgi?id=145720

        Reviewed by Dan Bernstein.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluate):

2015-06-05  Mark Lam  <mark.lam@apple.com>

        Subclasses of JSNonFinalObject with gc'able children need to implement visitChildren().
        https://bugs.webkit.org/show_bug.cgi?id=145709

        Reviewed by Geoffrey Garen.

        * jsc.cpp:
        (functionSetElementRoot):
        - The Element class has a member of type Root which extends JSDestructibleObject.
          It should be stored in a WriteBarrier, and visited by visitChildren().  

        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::materializeSpecialsIfNecessary):
        (JSC::ClonedArguments::visitChildren):
        * runtime/ClonedArguments.h:
        - Add missing visitChildren().

        * tests/stress/cloned-arguments-should-visit-callee-during-gc.js: Added.
        (makeTransientFunction.transientFunc):
        (makeTransientFunction):

2015-06-05  Geoffrey Garen  <ggaren@apple.com>

        DropAllLocks RELEASE_ASSERT on iOS
        https://bugs.webkit.org/show_bug.cgi?id=139654

        Reviewed by Mark Lam.

        * runtime/JSLock.cpp:
        (JSC::JSLock::dropAllLocks): Removed a comment because it duplicated
        the code beneath it. Removed a FIXME because we can't ASSERT that
        we're holding the lock. WebKit1 on iOS drops the lock before calling to
        delegates, not knowing whether it holds the lock or not.

        (JSC::JSLock::DropAllLocks::DropAllLocks): Only ASSERT that we are not
        GC'ing if we hold the lock. If we do not hold the lock, it is perfectly
        valid for some other thread, which does hold the lock, to be GC'ing.
        What is not valid is to drop the lock in the middle of GC, since GC
        must be atomic.

2015-06-05  Filip Pizlo  <fpizlo@apple.com>

        speculateRealNumber() should early exit if you're already a real number, not if you're already a real double.

        Rubber stamped by Mark Lam.
        
        This was causing: https://build.webkit.org/results/Apple%20Yosemite%20Debug%20WK1%20(Tests)/r185261%20(5180)/webaudio/note-grain-on-timing-crash-log.txt

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculateRealNumber):

2015-06-05  Mark Lam  <mark.lam@apple.com>

        finally blocks should not set the exception stack trace when re-throwing the exception.
        https://bugs.webkit.org/show_bug.cgi?id=145525

        Reviewed by Geoffrey Garen.

        How exceptions presently work:
        =============================
        1. op_throw can throw any JSValue.
        2. the VM tries to capture the stack at the throw point and propagate that as needed.
        3. finally blocks are implemented using op_catch to catch the thrown value, and throws it again using op_throw.

        What's wrong with how it presently works:
        ========================================
        1. finally's makes for bad exception throw line numbers in the Inspector console.

           The op_throw in finally will throw the value anew i.e. it captures a stack from the re-throw point.
           As a result, the Inspector sees the finally block as the throw point.  The original stack is lost.

        2. finally's breaks the Inspector's "Breaks on Uncaught Exception"

           This is because finally blocks are indistinguishable from catch blocks.  As a result, a try-finally,
           which should break in the Inspector on the throw, does not because the Inspector thought the
           exception was "caught".

        3. finally's yields confusing break points when the Inspector "Breaks on All Exceptions"

           a. In a try-finally scenario, the Inspector breaks 2 times: 1 at the throw, 1 at the finally.
           b. In a for-of loop (which has synthesized finallys), the Inspector will do another break.
              Similarly for other cases of JS code which synthesize finallys.
           c. At VM re-entry boundaries (e.g. js throws & returns to native code, which returns to js),
              the Inspector will do another break if there's an uncaught exception.

        How this patch fixes the issues:
        ===============================
        1. We introduce an Exception object that wraps the thrown value and the exception stack.

           When throwing an exception, the VM will check if the thrown value is an Exception
           object or not.  If it is not an Exception object, then we must be throwing a new
           exception.  The VM will create an Exception object to wrap the thrown value and
           capture the current stack for it.

           If the thrown value is already an Exception object, then the requested throw operation
           must be a re-throw.  The VM will not capture a new stack for it.

        2. op_catch will now populate 2 locals: 1 for the Exception, 1 for the thrown JSValue.

           The VM is aware of the Exception object and uses it for rethrows in finally blocks.
           JS source code is never aware of the Exception object.

           JS code is aware of the thrown value.  If it throws the caught thrown value, that
           constitutes a new throw, and a new Exception object will be created for it.

        3. The VM no longer tracks the thrown JSValue and the exception stack.  It will only
           track a m_exception field which is an Exception*.

        4. The BytecodeGenerator has already been updated in a prior patch to distinguish
           between Catch, Finally, and SynthesizedFinally blocks.  The interpreter runtime will
           now report to the debugger whether we have a Catch handler, not just any handlers.

           The debugger will use this detail to determine whether to break or not.  "Break on
           uncaught exceptions" will only break if no Catch handler was found.

           This solves the issue of the debugger breaking at finally blocks, and for-of statements.

        5. The Exception object will also have a flag to indicate whether the debugger has been
           notified of the Exception being thrown.  Once the Interpreter notifies the debugger
           of the Exception object, it will mark this flag and not repeat the notify the debugger
           again of the same Exception.

           This solves the issue of the debugger breaking at VM re-entry points due to uncaught
           exceptions.

        6. The life-cycle of the captured exception stack trace will now follow the life-cycle
           of the Exception object.

        Other changes:
        7. Change all clients of the VM::exception() to expect an Exception* instead of JSValue.

        8. Fixed a few bugs where thrown exceptions are not cleared before exiting the VM.

        9. Also renamed some variables and classes to better describe what they are.

        * API/JSBase.cpp:
        (JSEvaluateScript):
        (JSCheckScriptSyntax):

        * API/JSObjectRef.cpp:
        (handleExceptionIfNeeded):
        - The functions below all do the same exception check.  Added this helper
          to simplify the code.
        (JSClassCreate):
        (JSObjectMakeFunction):
        (JSObjectMakeArray):
        (JSObjectMakeDate):
        (JSObjectMakeError):
        (JSObjectMakeRegExp):
        (JSObjectGetProperty):
        (JSObjectSetProperty):
        (JSObjectGetPropertyAtIndex):
        (JSObjectSetPropertyAtIndex):
        (JSObjectDeleteProperty):
        (JSObjectCallAsFunction):
        (JSObjectCallAsConstructor):

        * API/JSScriptRef.cpp:
        * API/JSValue.mm:
        (JSContainerConvertor::take):
        (reportExceptionToInspector):

        * API/JSValueRef.cpp:
        (handleExceptionIfNeeded):
        - The functions below all do the same exception check.  Added this helper
          to simplify the code.
        (evernoteHackNeeded):
        (JSValueIsEqual):
        (JSValueIsInstanceOfConstructor):
        (JSValueCreateJSONString):
        (JSValueToNumber):
        (JSValueToStringCopy):
        (JSValueToObject):

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        - Added new files Exception.h and Exception.cpp.

        * bindings/ScriptFunctionCall.cpp:
        (Deprecated::ScriptFunctionCall::call):
        * bindings/ScriptFunctionCall.h:

        * bytecode/BytecodeList.json:
        - op_catch now had 2 operands: the exception register, and the thrown value register.

        * bytecode/BytecodeUseDef.h:
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::handlerForBytecodeOffset):
        * bytecode/CodeBlock.h:
        - handlerForBytecodeOffset() now can look for just Catch handlers only.

        * bytecode/HandlerInfo.h:
        - Cleaned up some white space I accidentally added in a previous patch.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::pushTry):
        (JSC::BytecodeGenerator::popTryAndEmitCatch):
        (JSC::BytecodeGenerator::emitThrowReferenceError):
        (JSC::BytecodeGenerator::emitEnumeration):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitThrow):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::TryNode::emitBytecode):
        - Adding support for op_catch's 2 operands.

        * debugger/Debugger.cpp:
        (JSC::Debugger::hasBreakpoint):
        (JSC::Debugger::pauseIfNeeded):
        (JSC::Debugger::exception):
        * debugger/Debugger.h:
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::thisValue):
        (JSC::DebuggerCallFrame::evaluate):
        * debugger/DebuggerCallFrame.h:
        (JSC::DebuggerCallFrame::isValid):
        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::createInjectedScript):
        * inspector/InspectorEnvironment.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
        (Inspector::JSGlobalObjectInspectorController::reportAPIException):
        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/JSGlobalObjectScriptDebugServer.h:
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::evaluate):
        * inspector/JavaScriptCallFrame.h:
        (Inspector::JavaScriptCallFrame::vmEntryGlobalObject):
        (Inspector::JavaScriptCallFrame::thisValue):
        (Inspector::JavaScriptCallFrame::evaluate):
        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::extractSourceInformationFromException):
        (Inspector::createScriptCallStackFromException):
        * inspector/ScriptCallStackFactory.h:
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::evaluateBreakpointAction):
        (Inspector::ScriptDebugServer::handleBreakpointHit):
        (Inspector::ScriptDebugServer::handleExceptionInBreakpointCondition):
        * inspector/ScriptDebugServer.h:
        * interpreter/CallFrame.h:
        (JSC::ExecState::clearException):
        (JSC::ExecState::exception):
        (JSC::ExecState::hadException):
        (JSC::ExecState::atomicStringTable):
        (JSC::ExecState::propertyNames):
        (JSC::ExecState::clearSupplementaryExceptionInfo): Deleted.

        * interpreter/Interpreter.cpp:
        (JSC::unwindCallFrame):
        (JSC::Interpreter::stackTraceAsString):
        (JSC::GetCatchHandlerFunctor::GetCatchHandlerFunctor):
        (JSC::GetCatchHandlerFunctor::operator()):
        (JSC::Interpreter::unwind):
        - Added a check for didNotifyInspectorOfThrow() here to prevent duplicate reports
          of the same Exception to the debugger.

        (JSC::GetExceptionHandlerFunctor::GetExceptionHandlerFunctor): Deleted.
        (JSC::GetExceptionHandlerFunctor::operator()): Deleted.
        - Renamed GetExceptionHandlerFunctor to GetCatchHandlerFunctor since the debugger
          is only interested in knowing whether we have Catch handlers.

        * interpreter/Interpreter.h:
        (JSC::SuspendExceptionScope::SuspendExceptionScope):
        (JSC::SuspendExceptionScope::~SuspendExceptionScope):
        (JSC::Interpreter::sampler):
        (JSC::ClearExceptionScope::ClearExceptionScope): Deleted.
        (JSC::ClearExceptionScope::~ClearExceptionScope): Deleted.
        - Renamed ClearExceptionScope to SuspendExceptionScope because "clear" implies that
          we're purging the exception.  Instead, we're merely suspending any handling of
          that exception for a period defined by the scope.

        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitExceptionCheck):

        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        - Removed the exception argument.  It is always the value in VM::exception() anyway.
          genericUnwind() can just get it from the VM, and save everyone some work.

        * jit/JITExceptions.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileCTINativeCall):
        (JSC::JIT::emit_op_catch):
        - Add support for the new op_catch operands.

        * jit/JITOperations.cpp:
        * jit/ThunkGenerators.cpp:
        (JSC::nativeForGenerator):
        * jsc.cpp:
        (functionRun):
        (functionLoad):
        (runWithScripts):
        (runInteractive):
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):

        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        - Add support for the new op_catch operands.  Also update the code to handle
          VM::m_exception being an Exception pointer, not a JSValue.

        * parser/NodeConstructors.h:
        (JSC::TryNode::TryNode):
        * parser/Nodes.h:
        * runtime/CallData.cpp:
        (JSC::call):
        * runtime/CallData.h:

        * runtime/Completion.cpp:
        (JSC::evaluate):
        * runtime/Completion.h:
        (JSC::evaluate):
        - Change evaluate() to take a reference to the returned exception value instead
          of a pointer.  In all but 2 or 3 cases, we want the returned exception anyway.
          Might as well simplify the code by requiring the reference.

        * runtime/Error.h:
        (JSC::throwVMError):
        (JSC::throwVMTypeError):

        * runtime/Exception.cpp: Added.
        (JSC::Exception::create):
        (JSC::Exception::destroy):
        (JSC::Exception::createStructure):
        (JSC::Exception::visitChildren):
        (JSC::Exception::Exception):
        (JSC::Exception::~Exception):
        * runtime/Exception.h: Added.
        (JSC::Exception::valueOffset):
        (JSC::Exception::cast):
        (JSC::Exception::value):
        (JSC::Exception::stack):
        (JSC::Exception::didNotifyInspectorOfThrow):
        (JSC::Exception::setDidNotifyInspectorOfThrow):

        * runtime/ExceptionHelpers.cpp:
        (JSC::createTerminatedExecutionException):
        (JSC::isTerminatedExecutionException):
        (JSC::createStackOverflowError):
        * runtime/ExceptionHelpers.h:
        * runtime/GetterSetter.cpp:
        (JSC::callGetter):
        * runtime/IteratorOperations.cpp:
        (JSC::iteratorClose):
        * runtime/JSObject.cpp:
        * runtime/JSPromiseConstructor.cpp:
        (JSC::constructPromise):
        * runtime/JSPromiseDeferred.cpp:
        (JSC::updateDeferredFromPotentialThenable):
        (JSC::abruptRejection):
        * runtime/JSPromiseReaction.cpp:
        (JSC::ExecutePromiseReactionMicrotask::run):

        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::releaseExecutableMemory):
        (JSC::VM::throwException):
        (JSC::VM::setStackPointerAtVMEntry):
        (JSC::VM::getExceptionInfo): Deleted.
        (JSC::VM::setExceptionInfo): Deleted.
        (JSC::VM::clearException): Deleted.
        (JSC::clearExceptionStack): Deleted.
        * runtime/VM.h:
        (JSC::VM::targetMachinePCForThrowOffset):
        (JSC::VM::clearException):
        (JSC::VM::setException):
        (JSC::VM::exception):
        (JSC::VM::addressOfException):
        (JSC::VM::exceptionStack): Deleted.
        * runtime/VMEntryScope.cpp:
        (JSC::VMEntryScope::VMEntryScope):
        (JSC::VMEntryScope::setEntryScopeDidPopListener):

2015-06-04  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Always track out-of-bounds array access explicitly instead of relying on the slow case
        https://bugs.webkit.org/show_bug.cgi?id=145673

        Reviewed by Geoffrey Garen.

        Previously, we were deciding to use out-of-bounds speculation based on two informations:
        -Explicitly detected out-of-bounds accesses tracked on ArrayProfile.
        -The number of time we took the slow cases in the baseline JIT.

        The heuristic based on slow cases was a little too fragile.

        In some cases, we were running into that limit just because the indexing type changes between
        two values (typically Int32Array and DoubleArray). Sometimes we were just unlucky on what
        we used for the inline cache.

        In Kraken, this was hurting us on "audio-beat-detection" and "audio-fft". The array types we see
        change between Int32 and Double. We run into the slow path a bit but never hit
        out-of-bounds.

        By the time we compile in DFG, we have stable Double Arrays but we speculate out-of-bounds based
        on the number of slow cases we took. Because of that, we start boxing the double on GetByVal,
        using DoubleRep, etc. adding a ton of overhead over otherwise very simple operations.

        WebXPRT was also suffering from this problem but the other way arround: we were missing
        the out-of-bounds accesses due to changes in indexing types, we were below the threshold
        of slow-path access, thus we predicted in-bounds accesses for code that was doing plenty
        of out-of-bands.


        This patch fixes the problem by tracking the out-of-bounds access explicitly any time we go
        into the slow path in baseline JIT. Since we no longer miss any out-of-bounds, we can remove
        the slow-path heuristic.

        There is new additional special case in the C code regarding out-of-bounds: Arguments access.
        Mispredicting out-of-bounds accesses on arguments is a disaster for performance, so those are
        tracked in the way DFG expect it.


        There are a few important cases that are still not covered optimally:
        -PutByVal on Arguments.
        -Get/Put ByVal on TypedArray.
        Those are simply not used by DFG in any way. TypedArrays should probably be looked at in the future.

        * bytecode/ArrayProfile.cpp:
        (JSC::ArrayProfile::computeUpdatedPrediction):
        The inline-cache repatch cases now update the ArrayProfile information. This has no value in baseline
        JIT but it helps avoiding one recompile in DFG for the missing ArrayProfile information.

        * bytecode/ArrayProfile.h:
        (JSC::ArrayProfile::setOutOfBounds):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getArrayMode):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::getArrayModeConsideringSlowPath): Deleted.
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitSlow_op_has_indexed_property):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emitSlow_op_has_indexed_property):
        * jit/JITOperations.cpp:
        (JSC::canUseFastArgumentAccess):
        This is not my favorite part of this patch.

        I tried having JSObject::canGetIndexQuickly() handle arguments which would put everything
        on the generic path. Unfortunately, that code is very performance sensitive and some benchmarks were
        impacted by over 10%

        I left JSObject::canGetIndexQuickly() alone, and I added the canUseFastArgumentAccess() mirroring
        how DFG uses out-of-bounds for Arguments.

        (JSC::getByVal):
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::emitSlow_op_put_by_val):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::emitSlow_op_put_by_val):
        * runtime/JSPromiseFunctions.cpp:
        * tests/stress/get-by-val-out-of-bounds-basics.js: Added.
        (opaqueGetByValOnInt32ArrayEarlyOutOfBounds):
        (testInt32ArrayEarlyOutOfBounds):
        (testIndexingTypeChangesOnInt32Array):
        (opaqueGetByValOnStringArrayHotOutOfBounds):
        (testStringArrayHotOutOfBounds):
        (testIndexingTypeChangesOnStringArray):
        (opaqueGetByValOnStringAndInt32ArrayHotOutOfBounds):
        (testStringAndInt32ArrayHotOutOfBounds):
        (opaqueGetByValOnDoubleArrayHotOutOfBounds):
        * tests/stress/put-by-val-out-of-bounds-basics.js: Added.
        (opaquePutByValOnInt32ArrayEarlyOutOfBounds):
        (testInt32ArrayEarlyOutOfBounds):
        (opaquePutByValOnStringArrayHotOutOfBounds):
        (testStringArrayHotOutOfBounds):

2015-06-03  Filip Pizlo  <fpizlo@apple.com>

        Simplify unboxing of double JSValues known to be not NaN and not Int32
        https://bugs.webkit.org/show_bug.cgi?id=145618

        Reviewed by Geoffrey Garen.
        
        In many cases we know that we most likely loaded a non-NaN double value from the heap.
        Prior to this patch, we would do two branches before unboxing the double. This patch
        reduces this to one branch in the common case. Before:
        
            if (is int32)
                unbox int32 and convert to double
            else if (is number)
                unbox double
            else
                exit
        
        After:

            tmp = unbox double
            if (tmp == tmp)
                done
            else if (is int32)
                unbox int32 and convert to double
            else
                exit
        
        We only use the new style if we have profiling that tells us that we are unlikely to see
        either Int32 or NaN - since we will now exit on NaN and int32 requires an extra branch.
        
        This is a 8% speed-up on Octane/box2d. On one microbenchmark this is a 25% speed-up.
        
        Rolling this back in after I made DFG::SpeculativeJIT call a new version of unboxDouble()
        that doesn't assert that the JSValue is a double, since we are intentionally using it
        before doing the "is a double" test. This wasn't a problem on 32-bit since unboxDouble()
        does no such assertion on 32-bit.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::observeUseKindOnNode):
        (JSC::DFG::FixupPhase::fixEdgeRepresentation):
        (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::shouldSpeculateDouble):
        (JSC::DFG::Node::shouldSpeculateDoubleReal):
        (JSC::DFG::Node::shouldSpeculateNumber):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::operator()):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileDoubleRep):
        (JSC::DFG::SpeculativeJIT::speculateNumber):
        (JSC::DFG::SpeculativeJIT::speculateRealNumber):
        (JSC::DFG::SpeculativeJIT::speculateDoubleRepReal):
        (JSC::DFG::SpeculativeJIT::speculate):
        (JSC::DFG::SpeculativeJIT::speculateDoubleReal): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        (JSC::DFG::isNumerical):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
        (JSC::FTL::LowerDFGToLLVM::boxDouble):
        (JSC::FTL::LowerDFGToLLVM::jsValueToStrictInt52):
        (JSC::FTL::LowerDFGToLLVM::speculate):
        (JSC::FTL::LowerDFGToLLVM::speculateNumber):
        (JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
        (JSC::FTL::LowerDFGToLLVM::speculateDoubleRepReal):
        (JSC::FTL::LowerDFGToLLVM::jsValueToDouble): Deleted.
        (JSC::FTL::LowerDFGToLLVM::speculateDoubleReal): Deleted.
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfNotOther):
        (JSC::AssemblyHelpers::branchIfInt32):
        (JSC::AssemblyHelpers::branchIfNotInt32):
        (JSC::AssemblyHelpers::branchIfNumber):

2015-06-04  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Class constructor appearing as Object Tree property does not include parameters
        https://bugs.webkit.org/show_bug.cgi?id=145661

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype._classPreview):
        (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
        The string we will return for previews of class constructor functions.

        (InjectedScript.RemoteObject):
        (InjectedScript.RemoteObject.prototype._describe):
        No longer return the class name as the description string.
        Instead return the class name for the RemoteObject.className.

2015-06-04  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r185216.
        https://bugs.webkit.org/show_bug.cgi?id=145666

        it caused a bunch of debug crashes (Requested by pizlo on
        #webkit).

        Reverted changeset:

        "Simplify unboxing of double JSValues known to be not NaN and
        not Int32"
        https://bugs.webkit.org/show_bug.cgi?id=145618
        http://trac.webkit.org/changeset/185216

2015-06-03  Filip Pizlo  <fpizlo@apple.com>

        Simplify unboxing of double JSValues known to be not NaN and not Int32
        https://bugs.webkit.org/show_bug.cgi?id=145618

        Reviewed by Geoffrey Garen.
        
        In many cases we know that we most likely loaded a non-NaN double value from the heap.
        Prior to this patch, we would do two branches before unboxing the double. This patch
        reduces this to one branch in the common case. Before:
        
            if (is int32)
                unbox int32 and convert to double
            else if (is number)
                unbox double
            else
                exit
        
        After:

            tmp = unbox double
            if (tmp == tmp)
                done
            else if (is int32)
                unbox int32 and convert to double
            else
                exit
        
        We only use the new style if we have profiling that tells us that we are unlikely to see
        either Int32 or NaN - since we will now exit on NaN and int32 requires an extra branch.
        
        This is a 8% speed-up on Octane/box2d. On one microbenchmark this is a 25% speed-up.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::observeUseKindOnNode):
        (JSC::DFG::FixupPhase::fixEdgeRepresentation):
        (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::shouldSpeculateDouble):
        (JSC::DFG::Node::shouldSpeculateDoubleReal):
        (JSC::DFG::Node::shouldSpeculateNumber):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::operator()):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileDoubleRep):
        (JSC::DFG::SpeculativeJIT::speculateNumber):
        (JSC::DFG::SpeculativeJIT::speculateRealNumber):
        (JSC::DFG::SpeculativeJIT::speculateDoubleRepReal):
        (JSC::DFG::SpeculativeJIT::speculate):
        (JSC::DFG::SpeculativeJIT::speculateDoubleReal): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        (JSC::DFG::isNumerical):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
        (JSC::FTL::LowerDFGToLLVM::boxDouble):
        (JSC::FTL::LowerDFGToLLVM::jsValueToStrictInt52):
        (JSC::FTL::LowerDFGToLLVM::speculate):
        (JSC::FTL::LowerDFGToLLVM::speculateNumber):
        (JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
        (JSC::FTL::LowerDFGToLLVM::speculateDoubleRepReal):
        (JSC::FTL::LowerDFGToLLVM::jsValueToDouble): Deleted.
        (JSC::FTL::LowerDFGToLLVM::speculateDoubleReal): Deleted.
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfNotOther):
        (JSC::AssemblyHelpers::branchIfInt32):
        (JSC::AssemblyHelpers::branchIfNotInt32):
        (JSC::AssemblyHelpers::branchIfNumber):

2015-06-04  Filip Pizlo  <fpizlo@apple.com>

        SideState should be a distinct abstract heap from Heap and Stack
        https://bugs.webkit.org/show_bug.cgi?id=145653

        Reviewed by Geoffrey Garen.
        
        Before, SideState fit into the hierarchy like so:
        
        World
           |
           +-- Stack
           |
           +-- Heap
                 |
                 +-- SideState
        
        Now we will have:
        
        World
           |
           +-- Stack
           |
           +-- Heap
           |
           +-- SideState
        
        This makes it easy to ask if a writing operation wrote to anything that is observable even
        if we don't exit. SideState is only observable if we exit.

        * dfg/DFGAbstractHeap.h:
        (JSC::DFG::AbstractHeap::AbstractHeap):
        (JSC::DFG::AbstractHeap::supertype):

2015-06-04  Chris Dumez  <cdumez@apple.com>

        [WK2] Prune more resources from the MemoryCache before process suspension
        https://bugs.webkit.org/show_bug.cgi?id=145633

        Reviewed by Andreas Kling.

        No longer move protect IncrementalSweeper::fullSweep() behind
        USE(CF) so we don't need #ifdefs at call sites, similarly to what is
        done for the rest of the IncrementalSweeper API.

        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::fullSweep):
        * heap/IncrementalSweeper.h:

2015-06-01  Filip Pizlo  <fpizlo@apple.com>

        CallLinkStatus should return takesSlowPath if the GC often cleared the IC
        https://bugs.webkit.org/show_bug.cgi?id=145502

        Reviewed by Geoffrey Garen.
        
        CallLinkInfo now remembers when it has been cleared by GC. This has some safeguards for when
        a call gets cleared by GC only because we hadn't converted it into a closure call; in that
        case the GC will just tell us that it should be a closure call. The DFG will not optimize
        a call that was cleared by GC, and the DFG will always prefer a closure call if the GC told
        us that the specific callee was dead but the executable wasn't.
        
        This guards us from some scenarios that came up in Speedometer. It's neutral on the pure JS
        benchmarks, most likely just because those benchmarks aren't real enough to have interesting
        GC of code.

        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::visitWeak):
        (JSC::CallLinkInfo::dummy):
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::CallLinkInfo):
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFromCallLinkInfo):

2015-06-02  Filip Pizlo  <fpizlo@apple.com>

        GetById and PutById profiling should be more precise about it takes slow path
        https://bugs.webkit.org/show_bug.cgi?id=145590

        Reviewed by Geoffrey Garen.
        
        If a ById access ever takes slow path, we want the DFG and FTL to know this. Previously we
        were relying on slow path counts, which conflate slow paths taken due to a megamorphic
        access and slow paths taken due to IC building.

        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFor):
        (JSC::GetByIdStatus::computeForStubInfo):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        (JSC::PutByIdStatus::computeForStubInfo):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::StructureStubInfo):
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileGetById):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:

2015-06-03  Michael Saboff  <msaboff@apple.com>

        Improve test coverage for changes made in 145527
        https://bugs.webkit.org/show_bug.cgi?id=145578

        Reviewed by Geoffrey Garen.

        Added more complexity to poly-setter-combo.js stress test to create more turmoil in the
        polymorphic get-by-id / put-by-id with getters and setters to exercise the code change in
        https://bugs.webkit.org/show_bug.cgi?id=145527.  By changing the objects that the main test
        function sees, we are able to test those paths.  Verified with temporary logging code.

        * tests/stress/poly-setter-combo.js:
        (Cons2):
        (Cons3):
        (Cons4):
        (foo):
        (test):
        (runTestWithConstructors):

2015-06-02  Mark Lam  <mark.lam@apple.com>

        Gardening: fix broken CLoop build.

        Not reviewed.

        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeExitSiteData):

2015-06-02  Keith Miller  <keith_miller@apple.com>

        JavaScriptCore: JSExport protocol with an NSInteger property converts negative values to 18446744073709552000
        https://bugs.webkit.org/show_bug.cgi?id=145563

        Reviewed by Darin Adler.

        The Objective-C bindings were improperly converting negative
        long long/NSIntegers to 18446744073709552000 because they
        were converted to unsigned numbers.

        * API/ObjcRuntimeExtras.h:
        (parseObjCType):
        * API/tests/testapi.mm:
        (testObjectiveCAPIMain):
        (checkNegativeNSIntegers):
        (testObjectiveCAPI):

2015-06-02  Yusuke Suzuki  <utatane.tea@gmail.com>

        Heap-use-after-free read of size 4 in JavaScriptCore: WTF::StringImpl::isSymbol() (StringImpl.h:496)
        https://bugs.webkit.org/show_bug.cgi?id=145532

        Reviewed by Geoffrey Garen.

        AtomicStringImpl::lookUp returns AtomicStringImpl*,
        it doesn't give any ownership to the caller.
        Originally, this is ok because the ownership is taken
        by AtomicStringImpl's table (& the register side).

        But if we would like to use this returned AtomicStringImpl*,
        we should take its ownership immediately.
        Because if the register side releases its ownership (ref count),
        it will be destroyed.

        In JSString::toExistingAtomicString, it returns AtomicStringImpl*.
        But it's not appropriate.
        If the owner of AtomicStringImpl* is always JSString*, it is ok.
        But it looks up the table-registered AtomicStringImpl* from
        the AtomicStringImpl table. So JSString* may not have the ownership
        of the returned AtomicStringImpl*.

        The failure situation is the following.

        1. A creates AtomicStringImpl. A has its ownership.
           And A registers it to AtomicStringImpl table.
        2. JSString looks up the AtomicStringImpl from the table.
           It gets AtomicStringImpl*. And JSString doesn't have its ownership.
           It returns the raw pointer immediately to the users
        3. A is released. There's no owner for AtomicStringImpl*.
           So it's also destroyed.
        4. Use looked up AtomicStringImpl in (2). It becomes use-after-free.

        This patch fixes it by the following changes.

        1. Change the signature of `AtomicStringImpl* AtomicStringImpl::lookUp(...)`
           to `RefPtr<AtomicStringImpl> AtomicStringImpl::lookUp(..)`.
           Use `RefPtr` because it may return `nullptr`.
        2. Change the signature of `AtomicStringImpl* JSString::toExistingAtomicString(...)`
           to `RefPtr<AtomicStringImpl> JSString::toExistingAtomicString(...)`.
           Using `RefPtr` is the same reason.
        3. Receive the result with `RefPtr<AtomicStringImpl>` in the caller side.

        * dfg/DFGOperations.cpp:
        * jit/JITOperations.cpp:
        (JSC::getByVal):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::getByVal):
        * runtime/JSString.cpp:
        (JSC::JSRopeString::resolveRopeToExistingAtomicString):
        * runtime/JSString.h:
        (JSC::JSString::toExistingAtomicString):

2015-05-30  Filip Pizlo  <fpizlo@apple.com>

        Any exit from any JIT due to profiling for an inline cache should force all future compilations to be wary
        https://bugs.webkit.org/show_bug.cgi?id=145496

        Reviewed by Geoffrey Garen.
        
        This pessimizes compilation a bit, but it reduces the likelihood of exiting from FTL. I
        couldn't find any convincing reason not to do this, and we know from Speedometer that this
        change is necessary for weirder code.

        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFor):
        (JSC::CallLinkStatus::computeExitSiteData):
        (JSC::CallLinkStatus::computeDFGStatuses):
        * bytecode/CallLinkStatus.h:
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::appendVariant):
        (JSC::GetByIdStatus::hasExitSite):
        (JSC::GetByIdStatus::computeFor):
        * bytecode/GetByIdStatus.h:
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::appendVariant):
        (JSC::PutByIdStatus::hasExitSite):
        (JSC::PutByIdStatus::computeFor):
        * bytecode/PutByIdStatus.h:

2015-05-31  Filip Pizlo  <fpizlo@apple.com>

        If a call has ever taken the virtual slow path, make sure that the DFG knows this
        https://bugs.webkit.org/show_bug.cgi?id=145501

        Reviewed by Geoffrey Garen.
        
        Now now return higher fidelity information in the case of no polymorphic call stub. If the
        virtual slow path was ever taken, we note this, and we note either zero or one call variant
        based on the IC's last callee.

        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFromCallLinkInfo):
        (JSC::CallLinkStatus::computeFor):

2015-06-01  Michael Saboff  <msaboff@apple.com>

        Crash in com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::revertCall + 24
        https://bugs.webkit.org/show_bug.cgi?id=145527

        Reviewed by Filip Pizlo.

        If a CallLinkInfo is GC'ed, we need to notify any PolymorphicCallNode's that reference it.
        Added plumbling to clear the m_callLinkInfo of a PolymorphicCallNode when that CallLinkInfo
        is going away.

        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::~CallLinkInfo):
        * jit/PolymorphicCallStubRoutine.cpp:
        (JSC::PolymorphicCallNode::unlink):
        (JSC::PolymorphicCallNode::clearCallLinkInfo):
        (JSC::PolymorphicCallCase::dump):
        (JSC::PolymorphicCallStubRoutine::edges):
        (JSC::PolymorphicCallStubRoutine::clearCallNodesFor):
        (JSC::PolymorphicCallStubRoutine::visitWeak):
        * jit/PolymorphicCallStubRoutine.h:
        (JSC::PolymorphicCallNode::hasCallLinkInfo):

2015-06-01  Mark Lam  <mark.lam@apple.com>

        Add the ability to tell between Catch and Finally blocks.
        https://bugs.webkit.org/show_bug.cgi?id=145524 

        Reviewed by Michael Saboff.

        ... and also SynthesizedFinally blocks too.  A SynthesizedFinally block
        is a finally block that is synthesized by the bytecode generator but
        does not actually correspond to any exception handling construct at the
        JS source code level.  An example of this is the "for ... of" statement
        where it needs to do some "final" clean up before passing on the
        exception.

        Manually tested by inspecting the bytecode dump of functions with
        try-catch-finally blocks as well as for of statements which have
        synthesized finally blocks.  The bytecode dumps contains the exception
        handlers table which has these blocks labelled with their newly added
        types.  No automatic test because this type info is not visible to JS
        code.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/HandlerInfo.h:
        (JSC::HandlerInfoBase::type):
        (JSC::HandlerInfoBase::setType):
        (JSC::HandlerInfoBase::typeName):
        (JSC::HandlerInfoBase::isCatchHandler):
        (JSC::UnlinkedHandlerInfo::UnlinkedHandlerInfo):
        (JSC::HandlerInfo::initialize):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::pushTry):
        (JSC::BytecodeGenerator::popTryAndEmitCatch):
        (JSC::BytecodeGenerator::emitEnumeration):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitThrow):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::TryNode::emitBytecode):

2015-05-29  Geoffrey Garen  <ggaren@apple.com>

        REGRESSION: These sorting idioms used by Peacekeeper and Browsermark are ~20X slower
        https://bugs.webkit.org/show_bug.cgi?id=145412

        Reviewed by Darin Adler.

        Moar speedup.

        Added a bucket sort for string sorting.

        * builtins/Array.prototype.js:
        (sort.compactSparse):
        (sort.compactSlow):
        (sort.compact): Split out a compaction fast path for dense arrays. Without
        it, compaction can increase sort time by 2X for simple sorts.

        (sort.bucketSort):
        (sort.stringSort): Use a bucket sorting algorithm if we know we're sorting
        strings. This makes average case string sorting O(N) with O(N) additional
        memory use.

        The worst case bucket sort can require O(M * N) additional
        space. We avoid this by falling back to merge sort when things are
        simple or overly duplicative. These are the two cases that accumulate
        excessive -- and potentially pathological -- bucketing overhead.

2015-06-01  Mark Lam  <mark.lam@apple.com>

        HandlerInfo::initialize() should not assume that CodeLocationLabel is available.
        https://bugs.webkit.org/show_bug.cgi?id=145515

        Reviewed by Csaba Osztrogonác.

        CodeLocationLabel is only defined for ENABLE(ASSEMBLER) builds.  r185022's
        attempt at simplifying code to increase readability failed to take this into
        account.  This patch fixes it.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * bytecode/HandlerInfo.h:
        (JSC::HandlerInfo::initialize):

2015-05-31  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=145503.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::inliningCost):

2015-05-31  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Drop WeakMap#clear
        https://bugs.webkit.org/show_bug.cgi?id=145489

        Reviewed by Mark Lam.

        ES6 spec intentionally drops the WeakMap#clear
        to allow engine to implement WeakMap as a per-object table.

        This patch drops WeakMap.prototype.clear.

        * runtime/WeakMapPrototype.cpp:
        (JSC::WeakMapPrototype::finishCreation): Deleted.
        (JSC::protoFuncWeakMapClear): Deleted.

2015-05-31  Jordan Harband  <ljharb@gmail.com>

        Array#reduce and reduceRight don't follow ToLength
        https://bugs.webkit.org/show_bug.cgi?id=145364
        Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-tolength

        Reviewed by Yusuke Suzuki.

        * builtins/Array.prototype.js:
        (reduce):
        (reduceRight):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::arrayProtoFuncReduce): Deleted.
        (JSC::arrayProtoFuncReduceRight): Deleted.

2015-05-29  Filip Pizlo  <fpizlo@apple.com>

        FTL codegen for MultiGetByOffset and MultiPutByOffset where the structure set is already proved should have an unreachable default case instead of an exit
        https://bugs.webkit.org/show_bug.cgi?id=145469

        Reviewed by Geoffrey Garen.
        
        Omitting the speculation on the fail path when the speculation is guaranteed not to be
        taken hints to LLVM that the default case is impossible. This enables some useful
        optimizations.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileMultiGetByOffset):
        (JSC::FTL::LowerDFGToLLVM::compileMultiPutByOffset):

2015-05-29  Mark Lam  <mark.lam@apple.com>

        Refactoring HandlerInfo and UnlinkedHandlerInfo.
        https://bugs.webkit.org/show_bug.cgi?id=145480

        Reviewed by Benjamin Poulain.

        HandlerInfo and UnlinkedHandlerInfo have common parts, but are not currently
        expressed as 2 unrelated structs that happen to have near identical fields.
        We can refactor them to better express their relationship.  We can also add
        some convenience functions to make the code that uses them a little more
        readable.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::handlerForBytecodeOffset):
        * bytecode/HandlerInfo.h:
        (JSC::UnlinkedHandlerInfo::UnlinkedHandlerInfo):
        (JSC::HandlerInfo::initialize):
        - I chose to include CodeLocationLabel arg even though it is unused by
          by non-JIT builds.  This makes the call site cleaner to read.

        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedSimpleJumpTable::add):
        (JSC::UnlinkedInstruction::UnlinkedInstruction):
        (JSC::UnlinkedCodeBlock::numberOfExceptionHandlers):
        (JSC::UnlinkedCodeBlock::addExceptionHandler):
        (JSC::UnlinkedCodeBlock::exceptionHandler):
        (JSC::UnlinkedCodeBlock::symbolTable):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):

2015-05-28  Filip Pizlo  <fpizlo@apple.com>

        Non-speculative Branch should be fast in the FTL
        https://bugs.webkit.org/show_bug.cgi?id=145452

        Reviewed by Andreas Kling.
        
        Inlines the code for convertJSValueToBoolean into the FTL. This also includes some other
        clean-ups that I found along the way.
        
        I found this by looking at the hottest functions in DeltaBlue. Despite having so many
        Branch specializations, apparently there was still a hot one that we missed that was going
        down the untyped path. It was either Int32 or Other. Maybe we could specialize for that
        combo, but it makes so much sense to just make all of this nonsense fast.

        * dfg/DFGWatchpointCollectionPhase.cpp:
        (JSC::DFG::WatchpointCollectionPhase::handle): Need to watch the masquerades watchpoint on UntypedUse: forms of Branch now.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::boolify): The actual fix.
        (JSC::FTL::LowerDFGToLLVM::int52ToStrictInt52):
        (JSC::FTL::LowerDFGToLLVM::isInt32):
        (JSC::FTL::LowerDFGToLLVM::isNotInt32):
        (JSC::FTL::LowerDFGToLLVM::unboxInt32):
        * runtime/JSCellInlines.h:
        (JSC::JSCell::toBoolean): Symbol is always true.
        (JSC::JSCell::pureToBoolean): Symbol is always true.
        * runtime/JSString.cpp:
        (JSC::JSString::getPrimitiveNumber):
        (JSC::JSString::toNumber):
        (JSC::JSString::toBoolean): Deleted. This is a tiny method. It doesn't need to be out-of-line.
        * runtime/JSString.h:
        (JSC::JSString::length):
        (JSC::JSString::toBoolean): This method shouldbe inline.
        * runtime/Symbol.cpp:
        (JSC::Symbol::toPrimitive):
        (JSC::Symbol::getPrimitiveNumber):
        (JSC::Symbol::toBoolean): Deleted. A Symbol is always true, so we don't need a method for this.
        * runtime/Symbol.h:

2015-05-29  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r184860.
        https://bugs.webkit.org/show_bug.cgi?id=145456

        May have caused ~1% Octane regression (Requested by kling on
        #webkit).

        Reverted changeset:

        "Try to use StringView when comparing JSStrings for equality."
        https://bugs.webkit.org/show_bug.cgi?id=145379
        http://trac.webkit.org/changeset/184860

2015-05-28  Michael Saboff  <msaboff@apple.com>

        mozilla/js1_5/Array/regress-154338.js test causes ARM 32 bit iOS devices to run out of memory
        https://bugs.webkit.org/show_bug.cgi?id=145444

        Reviewed by Geoffrey Garen.

        Disabled mozilla/js1_5/Array/regress-154338.js when run on iOS ARM 32 bit devices and
        the --memory-limited option is passed to run-jsc-stress-tests.

        * tests/mozilla/mozilla-tests.yaml:

2015-05-28  Benjamin Poulain  <benjamin@webkit.org>

        [iOS8][ARMv7(s)] Optimized Object.create in 'use strict' context sometimes breaks.
        https://bugs.webkit.org/show_bug.cgi?id=138038

        Reviewed by Michael Saboff.

        TL;DR: sometimes the baseline JIT could accidentally nuke the tag before calling
               to C++, making put_by_id behave erratically.

        The bug was that put_by_id would randomly not work correctly in 32bits. It happened
        in the baseline JIT if we were unlucky enough:
        -The code get hot enough and the structure is stable so we get a fast path for
         put_by_id.
        -We repatch the fast-path branch with a stub generated by
         emitPutTransitionStubAndGetOldStructure().
        -In emitPutTransitionStubAndGetOldStructure(), we only preserve the payload of the base
         register, the tag register is ignored.
        -emitPutTransitionStubAndGetOldStructure() allocate 2 to 3 registers. Any of those
         could be the one used for the base's tag before the fast path and the value is trashed.
        -If we hit one of the failure case, we fallback to the slow path, but we destroyed
         the tag pointer.
        -We now have unrelated bits in the tag, the most likely value type is now "double"
         and we fail the put_by_id because we try to set a property on a number.

        The most obvious solution would be to change emitPutTransitionStubAndGetOldStructure()
        to preserve the tag register in addition to the value register.
        I decided against that option because of the added complexity. The DFG does not need
        that case, so I would have to add branches everywhere to distinguish the cases
        were we need to preserve the tag or not.

        Instead, I just load the tag back from memory in the slow path. The function in the slow
        path is several order of magnitude slower than a load, it is not worth eliminating it,
        especially in baseline JIT.

        I also discovered 4 useless loads in the fast path, so even with my extra load, this patch
        makes the baseline faster :)

        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitSlow_op_put_by_id):
        (JSC::JIT::emit_op_put_by_id): Deleted.
        * tests/stress/put-by-id-on-new-object-after-prototype-transition-non-strict.js: Added.
        (opaqueNewObject):
        (putValueOnNewObject):
        * tests/stress/put-by-id-on-new-object-after-prototype-transition-strict.js: Added.
        (string_appeared_here.opaqueNewObject):
        (putValueOnNewObject):

2015-05-28  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] reduction the iteration count of the DoubleRep stress tests

        Once again, I used big numbers for manual testing and I forgot to fix them before landing.

        * tests/stress/double-rep-with-non-cell.js:
        * tests/stress/double-rep-with-null.js:
        * tests/stress/double-rep-with-undefined.js:

2015-05-28  Basile Clement  <basile_clement@apple.com>

        Add debug mode assertions for accessors casting JSC::DFG::Node.m_opInfo
        https://bugs.webkit.org/show_bug.cgi?id=145441

        Reviewed by Filip Pizlo.

        Most accessor functions casting m_opInfo in JSC::DFG::Node are
        performing debug checks that they are only accessed for node types that
        should have them. This patch adds similar checks for the accessors that
        were missing them.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::watchpointSet):
        (JSC::DFG::Node::storagePointer):
        (JSC::DFG::Node::multiGetByOffsetData):
        (JSC::DFG::Node::multiPutByOffsetData):
        (JSC::DFG::Node::hasTypeLocation):
        (JSC::DFG::Node::typeLocation):
        (JSC::DFG::Node::hasBasicBlockLocation):
        (JSC::DFG::Node::basicBlockLocation):

2015-05-28  Matt Rajca  <mrajca@apple.com>

        Add ENABLE_MEDIA_SESSION feature flag (which is off by default).
        https://bugs.webkit.org/show_bug.cgi?id=145415

        Reviewed by Eric Carlson.

        * Configurations/FeatureDefines.xcconfig:

2015-05-27  Jordan Harband  <ljharb@gmail.com>

        Array.of should work with other constructors
        https://bugs.webkit.org/show_bug.cgi?id=145365
        Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.of
        step 4

        Reviewed by Yusuke Suzuki.

        * builtins/ArrayConstructor.js:
        (of):
        * runtime/ArrayConstructor.cpp:
        (JSC::arrayConstructorOf): Deleted.

2015-05-27  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add undefined->double conversion to DoubleRep
        https://bugs.webkit.org/show_bug.cgi?id=145293

        Reviewed by Filip Pizlo.

        This patch adds undefined to double conversion to the DoubleRep
        node for the cases were we speculate "undefined" as part of the types
        processed.

        The use case is doing math with accidental out-of-bounds access. For example,
        something like:
            for (var i = 0; i <= length; ++i)
                ouptput += array[i];

        would cause us to OSR exit every time i === length.

        When hitting one of those cases, we would already speculate double math,
        but the DoubleRep node was unable to convert the undefined and would exit.

        With this patch the use kind NotCellUse cover this conversion for DoubleRep.
        I have been quite conservative so in general we will not find "undefined"
        until a few recompile but being optimistic seems better since this is a corner case.

        This patch is a 80% progression on WebXPRT's DNA Sequencing test.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::sawUndefined):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::operator()):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileDoubleRep):
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
        (JSC::FTL::LowerDFGToLLVM::jsValueToDouble):
        * tests/stress/double-rep-with-undefined.js: Added.
        (addArgsNumberAndUndefined):
        (addArgsInt32AndUndefined):
        (testFallbackWithDouble):
        (addArgsDoubleAndUndefined):
        (testFallbackWithObject.):
        (testFallbackWithObject):
        (addArgsOnlyUndefined):
        (testFallbackWithString):

2015-05-27  Dean Jackson  <dino@apple.com>

        img.currentSrc problem in strict mode with old picturefill
        https://bugs.webkit.org/show_bug.cgi?id=144095
        <rdar://problem/21087013>

        Reviewed by Simon Fraser.

        Add a PICTURE_SIZES flag.

        * Configurations/FeatureDefines.xcconfig:

2015-05-27  Basile Clement  <basile_clement@apple.com>

        LazyNode comparison can return incorrect results when comparing an empty value
        https://bugs.webkit.org/show_bug.cgi?id=145421

        Reviewed by Geoffrey Garen.

        When comparing a LazyNode to another, we compare the value pointers if
        we have one, and otherwise compare the nodes.
        We should be comparing value pointers if the other LazyNode has one as
        well, otherwise we risk an incoherency when we are a empty LazyNode
        being compared to a FrozenValue without node.

        Note that this is not a problem in any other case because if we don't
        have a FrozenValue and we are not an empty LazyNode, we are a
        non-constant node, and comparing the node pointers is correct.

        * dfg/DFGLazyNode.h:
        (JSC::DFG::LazyNode::operator==):

2015-05-27  Geoffrey Garen  <ggaren@apple.com>

        REGRESSION: These sorting idioms used by Peacekeeper and Browsermark are ~20X slower
        https://bugs.webkit.org/show_bug.cgi?id=145412

        Reviewed by Benjamin Poulain.

        Cache strings when doing a string-converting sort.

        This is a 21% speedup.

        * builtins/Array.prototype.js:
        (sort.stringComparator): Use subtraction instead of branching because
        it's slightly faster.

        (sort.comparatorSort):
        (sort.stringSort):
        (sort): Add a special case for string sorting to avoid redundant string
        conversion.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::createBindingPattern): Names can be empty if
        they are private names.

2015-05-26  Filip Pizlo  <fpizlo@apple.com>

        JIT-generated store barrier code should assume the buffer pointer and capacity to be compile-time constants
        https://bugs.webkit.org/show_bug.cgi?id=145404

        Reviewed by Andreas Kling.
        
        We never change the capacity of a write barrier buffer. We never repoint the buffer
        pointer. So, the JIT shouldn't load those from memory; it should take advantage of the
        fact that these are compile-time constants.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::emitStoreBarrier):
        * heap/WriteBarrierBuffer.h:
        (JSC::WriteBarrierBuffer::currentIndexAddress):
        (JSC::WriteBarrierBuffer::capacity):
        (JSC::WriteBarrierBuffer::buffer):
        (JSC::WriteBarrierBuffer::currentIndexOffset): Deleted.
        (JSC::WriteBarrierBuffer::capacityOffset): Deleted.
        (JSC::WriteBarrierBuffer::bufferOffset): Deleted.
        * jit/Repatch.cpp:
        (JSC::emitPutTransitionStubAndGetOldStructure):

2015-05-27  Geoffrey Garen  <ggaren@apple.com>

        REGRESSION: These sorting idioms used by Peacekeeper and Browsermark are ~20X slower
        https://bugs.webkit.org/show_bug.cgi?id=145412

        Reviewed by Darin Adler.

        Use @toString instead of the String constructor because calls to the
        String constructor are never optimized. (See
        https://bugs.webkit.org/show_bug.cgi?id=144458.)

        This is a ~2X speedup.

        * builtins/Array.prototype.js:
        (sort.stringComparator):

2015-05-27  Dan Bernstein  <mitz@apple.com>

        Remove JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080
        https://bugs.webkit.org/show_bug.cgi?id=145403

        Reviewed by Anders Carlsson.

        JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080 was used to enable the JavaScriptCore Objective-C API
        for WebKit and Safari projects building with JavaScriptCore targeting OS X 10.8. We don’t
        need it anymore.

        * API/JSBase.h:
        * API/JSContext.h:
        * API/JSManagedValue.h:
        * API/JSValue.h:
        * API/JSVirtualMachine.h:
        * Configurations/Base.xcconfig:
        * postprocess-headers.sh:

2015-05-26  Geoffrey Garen  <ggaren@apple.com>

        Photo Booth hangs under JSC::MachineThreads::tryCopyOtherThreadStacks
        https://bugs.webkit.org/show_bug.cgi?id=145395

        Reviewed by Mark Hahnenberg.

        No test case because we already have --threaded mode, which runs lots of
        parallel GC, but it (and the original in-app test case) can't reproduce
        this bug.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::tryCopyOtherThreadStacks): Use a lock to prevent
        two threads from mutually suspending each other.

2015-05-26  Yusuke Suzuki  <utatane.tea@gmail.com>

        Add Array.prototype.copyWithin to JSC features.json
        https://bugs.webkit.org/show_bug.cgi?id=145387

        Reviewed by Darin Adler.

        * features.json:

2015-05-26  Yusuke Suzuki  <utatane.tea@gmail.com>

        Reflect nits for r184863
        https://bugs.webkit.org/show_bug.cgi?id=145107

        Reviewed by Darin Adler.

        1. Added the copyright line.
        2. Added an optional argument (/*, end */). To do so, fixed generate-js-builtins.
        3. Dropped the unnecessary variable `thisValue`.
        4. Fix the type error messages. This is also found in StringIterator.prototype.js.
        5. Added tests for 0 arguments.

        * builtins/Array.prototype.js:
        (copyWithin):
        * builtins/StringIterator.prototype.js:
        (next):
        * generate-js-builtins:
        * tests/stress/array-copywithin.js:
        * tests/stress/string-iterators.js:

2015-05-26  Yusuke Suzuki  <utatane.tea@gmail.com>

        Inline @Array / @Object callsites
        https://bugs.webkit.org/show_bug.cgi?id=145382

        Reviewed by Geoffrey Garen.

        As the same to Array/Object callsite inlining, @Array/@Object also
        should be inlined in bytecode level.
        While `new @Object` style is not encouraged in the builtins,
        `@Array(len)` is already used at least in Array.from code.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::expectedFunctionForIdentifier):

2015-05-26  Andreas Kling  <akling@apple.com>

        String.prototype.charCodeAt() should use StringView.
        <https://webkit.org/b/145353>

        Reviewed by Darin Adler.

        Use JSString::view() in charCodeAt() to avoid reifying the JSString if it's
        a substring. This avoids StringImpl allocation in some cases and ref churn
        in all cases.

        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncCharCodeAt):

2015-05-26  Andreas Kling  <akling@apple.com>

        String.prototype.charAt() should use StringView.
        <https://webkit.org/b/145352>

        Reviewed by Darin Adler.

        Remove the jsSingleCharacterSubstring() function since it's actually completely
        counter-productive: it could create a single-character string that would retain
        a much larger string for the duration of its lifetime.

        This made sense before StringImpl learned to put its characters at the tail end
        of its own allocation. Now that it does, it's far better to just create a new
        single-character StringImpl.

        With that out of the way, we can make String.prototype.charAt() use StringView
        to avoid reifying substring JSStrings (and avoid some ref churn too.)

        * runtime/JSString.cpp:
        (JSC::JSRopeString::getIndexSlowCase):
        * runtime/JSString.h:
        (JSC::JSString::getIndex):
        (JSC::jsSingleCharacterSubstring): Deleted.
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncCharAt):
        (JSC::stringProtoFuncSplit):

2015-05-26  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement Array.prototype.copyWithin
        https://bugs.webkit.org/show_bug.cgi?id=145107

        Reviewed by Darin Adler.

        This patch implements ES6 Array.prototype.copyWithin.
        It is intended to be used for copying the region to the other region
        in the callee array itself safely (like memmove, not memcpy).
        This function is proposed in the context of WebGL.

        * builtins/Array.prototype.js:
        (.maxWithPositives):
        (.minWithMaybeNegativeZeroAndPositive):
        (copyWithin):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        * tests/stress/array-copywithin.js: Added.
        (shouldBe):
        (shouldBeArray):
        (shouldThrow):
        (arrayToObject):
        (valueOf):

2015-05-26  Dan Bernstein  <mitz@apple.com>

        <rdar://problem/21104551> Update build settings

        Reviewed by Anders Carlsson.

        * Configurations/DebugRelease.xcconfig:
        * Configurations/FeatureDefines.xcconfig:
        * Configurations/Version.xcconfig:

2015-05-26  Andreas Kling  <akling@apple.com>

        Try to use StringView when comparing JSStrings for equality.
        <https://webkit.org/b/145379>

        Reviewed by Darin Adler.

        Use JSString::view() when sending two JSStrings to WTF::equal()
        for comparison. This avoids creating new objects in the case where
        the strings are actually substrings.

        * jit/JITOperations.cpp:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::equalSlowCaseInline):
        (JSC::JSValue::strictEqualSlowCaseInline):

2015-05-26  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Generate put_by_val_direct for indexed identifiers instead of put_by_id with direct postfix
        https://bugs.webkit.org/show_bug.cgi?id=145360

        Reviewed by Darin Adler.

        JSObject::putDirect only accepts non-indexed properties.
        So when generating put_by_id (with direct postfix) for indexed property,
        we should generate put_by_val_direct instead.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitDirectPutById):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitPutConstantProperty):
        * tests/stress/put-by-id-direct-should-be-done-for-non-index-property.js: Added.

2015-05-24  Jordan Harband  <ljharb@gmail.com>

        Array#findIndex/find should not skip holes
        https://bugs.webkit.org/show_bug.cgi?id=145361
        per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.findindex
        and https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.find

        Reviewed by Yusuke Suzuki.

        * builtins/Array.prototype.js:
        (find): Deleted.
        (findIndex): Deleted.

2015-05-24  Brian J. Burg  <burg@cs.washington.edu>

        Web Inspector: Uncaught exception when using Inspect tool on SVG elements
        https://bugs.webkit.org/show_bug.cgi?id=145363

        Reviewed by Joseph Pecoraro.

        The injected script failed by chaining a call to String.prototype.trim to the result of
        SVG*Element.className, which is an SVGAnimatedString and lacks useful methods. So, obtain
        the class name using Node.getAttribute, which always returns a DOMString.

        * inspector/InjectedScriptSource.js:
        (InjectedScriptSource.prototype._getDescription): use getAttribute instead of className.

2015-05-23  Dan Bernstein  <mitz@apple.com>

        Remove unused definitions of WEBKIT_VERSION_MIN_REQUIRED
        https://bugs.webkit.org/show_bug.cgi?id=145345

        Reviewed by Sam Weinig.

        * Configurations/Base.xcconfig: Also changed to use $(inherited).

2015-05-23  Yusuke Suzuki  <utatane.tea@gmail.com>

        Introduce UniquedStringImpl and SymbolImpl to separate symbolic strings from AtomicStringImpl
        https://bugs.webkit.org/show_bug.cgi?id=144848

        Reviewed by Darin Adler.

        Use UniquedStringImpl, SymbolImpl and AtomicStringImpl.

        * API/JSCallbackObject.h:
        * builtins/BuiltinNames.h:
        (JSC::BuiltinNames::isPrivateName):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * bytecode/ComplexGetStatus.cpp:
        (JSC::ComplexGetStatus::computeFor):
        * bytecode/ComplexGetStatus.h:
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        (JSC::GetByIdStatus::computeFor):
        (JSC::GetByIdStatus::computeForStubInfo):
        * bytecode/GetByIdStatus.h:
        * bytecode/Instruction.h:
        (JSC::Instruction::Instruction):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        (JSC::PutByIdStatus::computeFor):
        (JSC::PutByIdStatus::computeForStubInfo):
        * bytecode/PutByIdStatus.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::visibleNameForParameter):
        (JSC::BytecodeGenerator::hasConstant):
        (JSC::BytecodeGenerator::addConstant):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGDesiredIdentifiers.cpp:
        (JSC::DFG::DesiredIdentifiers::addLazily):
        (JSC::DFG::DesiredIdentifiers::at):
        (JSC::DFG::DesiredIdentifiers::reallyAdd):
        * dfg/DFGDesiredIdentifiers.h:
        (JSC::DFG::DesiredIdentifiers::operator[]):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileIn):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::identifierUID):
        (JSC::DFG::SpeculativeJIT::callOperation):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLInlineCacheDescriptor.h:
        (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
        (JSC::FTL::InlineCacheDescriptor::uid):
        (JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
        (JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
        (JSC::FTL::CheckInDescriptor::CheckInDescriptor):
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compilePutById):
        (JSC::FTL::LowerDFGToLLVM::compileIn):
        (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
        (JSC::FTL::LowerDFGToLLVM::getById):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * ftl/FTLSlowPathCall.cpp:
        (JSC::FTL::callOperation):
        * ftl/FTLSlowPathCall.h:
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * parser/Nodes.cpp:
        (JSC::ProgramNode::setClosedVariables):
        * parser/Nodes.h:
        (JSC::ScopeNode::captures):
        (JSC::ScopeNode::setClosedVariables):
        (JSC::ProgramNode::closedVariables):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::didFinishParsing):
        (JSC::Parser<LexerType>::parseContinueStatement):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::pushLabel):
        (JSC::Scope::getLabel):
        (JSC::Scope::declareCallee):
        (JSC::Scope::declareVariable):
        (JSC::Scope::declareParameter):
        (JSC::Scope::declareBoundParameter):
        (JSC::Scope::useVariable):
        (JSC::Scope::copyCapturedVariablesToVector):
        (JSC::Parser::closedVariables):
        (JSC::ScopeLabelInfo::ScopeLabelInfo): Deleted.
        * parser/SourceProviderCacheItem.h:
        (JSC::SourceProviderCacheItem::usedVariables):
        (JSC::SourceProviderCacheItem::writtenVariables):
        (JSC::SourceProviderCacheItem::create):
        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::isPrivateName):
        * runtime/CommonIdentifiers.h:
        * runtime/Identifier.h:
        (JSC::Identifier::impl):
        (JSC::Identifier::Identifier):
        (JSC::parseIndex):
        (JSC::IdentifierRepHash::hash):
        * runtime/IdentifierInlines.h:
        (JSC::Identifier::fromUid):
        * runtime/IntendedStructureChain.cpp:
        (JSC::IntendedStructureChain::mayInterceptStoreTo):
        * runtime/IntendedStructureChain.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/Lookup.h:
        (JSC::HashTable::entry):
        * runtime/MapData.h:
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetOwnPropertySymbols):
        * runtime/PrivateName.h:
        (JSC::PrivateName::PrivateName):
        (JSC::PrivateName::uid):
        * runtime/PropertyMapHashTable.h:
        * runtime/PropertyName.h:
        (JSC::PropertyName::PropertyName):
        (JSC::PropertyName::uid):
        (JSC::PropertyName::publicName):
        (JSC::parseIndex):
        * runtime/PropertyNameArray.h:
        (JSC::PropertyNameArray::addKnownUnique):
        (JSC::PropertyNameArray::add):
        * runtime/Structure.cpp:
        (JSC::StructureTransitionTable::contains):
        (JSC::StructureTransitionTable::get):
        (JSC::StructureTransitionTable::add):
        (JSC::Structure::addPropertyTransitionToExistingStructureImpl):
        (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
        (JSC::Structure::getConcurrently):
        (JSC::Structure::add):
        (JSC::Structure::remove):
        (JSC::Structure::toStructureShape):
        * runtime/Structure.h:
        (JSC::PropertyMapEntry::PropertyMapEntry):
        * runtime/StructureInlines.h:
        (JSC::Structure::getConcurrently):
        * runtime/StructureTransitionTable.h:
        (JSC::StructureTransitionTable::Hash::hash):
        * runtime/Symbol.cpp:
        (JSC::Symbol::Symbol):
        * runtime/Symbol.h:
        * runtime/SymbolConstructor.cpp:
        (JSC::symbolConstructorFor):
        (JSC::symbolConstructorKeyFor):
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::uniqueIDForVariable):
        (JSC::SymbolTable::globalTypeSetForVariable):
        * runtime/SymbolTable.h:
        * runtime/TypeSet.cpp:
        (JSC::StructureShape::addProperty):
        (JSC::StructureShape::propertyHash):
        * runtime/TypeSet.h:

2015-05-21  Filip Pizlo  <fpizlo@apple.com>

        Arguments elimination phase mishandles arity check failure in its reduction of LoadVarargs to GetStack/PutStacks
        https://bugs.webkit.org/show_bug.cgi?id=145298

        Reviewed by Geoffrey Garen.

        * dfg/DFGArgumentsEliminationPhase.cpp: Fix the bug. I restructured the loop to make it more obvious that we're initializing everything that we're supposed to initialize.
        * dfg/DFGNode.h: Add a comment to clarify something I was confused about while writing this code.
        * dfg/DFGPutStackSinkingPhase.cpp: Hacking on PutStacks made me think deep thoughts, and I added some FIXMEs.
        * tests/stress/fold-load-varargs-arity-check-fail-barely.js: Added. This test crashes or fails before this patch.
        * tests/stress/fold-load-varargs-arity-check-fail.js: Added. This is even more sure to crash or fail.
        * tests/stress/simplify-varargs-mandatory-minimum-smaller-than-limit.js: Added. Not sure if we had coverage for this case before.

2015-05-22  Basile Clement  <basile_clement@apple.com>

        Allow DFGClobberize to return non-node constants that must be later created
        https://bugs.webkit.org/show_bug.cgi?id=145272

        Reviewed by Filip Pizlo.

        This adds a new LazyNode class in DFG that represents either a Node*,
        or a FrozenValue* with a way to convert it to a Node* provided a block
        to insert it into. DFGClobberize is converted to use LazyNode instead
        of Node* when def()'ing values, which allows to now define the array's
        length as well as the value of its various fields in NewArray and
        NewArrayBuffer nodes.

        We also introduce a Vector<uint32_t> in DFG::Graph to collect all the
        values that can be used as index, in order to avoid def()'ing too many
        values at once for big NewArrayBuffers.

        HeapLocation had to be updated to use a LazyNode as its index to be
        able to define array values.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGCSEPhase.cpp:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        (JSC::DFG::DefMethodClobberize::operator()):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::freezeFragile):
        * dfg/DFGGraph.h:
        * dfg/DFGHeapLocation.h:
        (JSC::DFG::HeapLocation::HeapLocation):
        (JSC::DFG::HeapLocation::index):
        (JSC::DFG::HeapLocation::hash):
        * dfg/DFGLazyNode.cpp: Added.
        (JSC::DFG::LazyNode::dump):
        * dfg/DFGLazyNode.h: Added.
        (JSC::DFG::LazyNode::LazyNode):
        (JSC::DFG::LazyNode::setNode):
        (JSC::DFG::LazyNode::isHashTableDeletedValue):
        (JSC::DFG::LazyNode::isNode):
        (JSC::DFG::LazyNode::op):
        (JSC::DFG::LazyNode::asNode):
        (JSC::DFG::LazyNode::asValue):
        (JSC::DFG::LazyNode::hash):
        (JSC::DFG::LazyNode::operator==):
        (JSC::DFG::LazyNode::operator!=):
        (JSC::DFG::LazyNode::ensureIsNode):
        (JSC::DFG::LazyNode::operator->):
        (JSC::DFG::LazyNode::operator*):
        (JSC::DFG::LazyNode::operator!):
        (JSC::DFG::LazyNode::operator UnspecifiedBoolType*):
        (JSC::DFG::LazyNode::setFrozenValue):
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::def):
        * dfg/DFGPutStackSinkingPhase.cpp:

2015-05-22  Andreas Kling  <akling@apple.com>

        [JSC] Speed up new array construction in Array.prototype.splice().
        <https://webkit.org/b/145303>

        Reviewed by Benjamin Poulain.

        Give splice() a fast path just like slice(), for indexing types where the backing
        store can be memcpy'd. I generalized JSArray::fastSlice() a little bit so it works
        for this optimization as well.

        7% progression on Kraken/stanford-crypto-pbkdf2.

        * runtime/JSArray.h:
        * runtime/JSArray.cpp:
        (JSC::JSArray::fastSlice): Tweak this to return JSArray*, and don't bother throwing
        out-of-memory exceptions. Let the caller worry about that.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSlice): Update for fastSlice() changes.
        (JSC::arrayProtoFuncSplice): If the object we're splicing out of is a bona fide
        JSArray, use fastSlice() to create the returned array instead of doing a generic
        get/put loop.

2015-05-21  Filip Pizlo  <fpizlo@apple.com>

        CPS rethreading should really get rid of GetLocals
        https://bugs.webkit.org/show_bug.cgi?id=145290

        Reviewed by Benjamin Poulain.
        
        CPS rethreading is intended to get rid of redundant GetLocals. CSE can also do it, but
        the idea is that you should be able to disable CSE and everything would still work. This
        fixes a bug in CPS rethreading's GetLocal elimination: we should be calling replaceWith
        rather than setReplacement, since setReplacement still leaves the original node.

        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor): Fix the bug.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): Eliminating GetLocals means that they turn into Check. We should handle Checks that have zero inputs.
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validateCPS): Add a validation for what a GetLocal should look like in ThreadedCPS.
        * tests/stress/get-local-elimination.js: Added.
        (foo):

2015-05-21  Saam Barati  <saambarati1@gmail.com>

        Object allocation sinking phase should explicitly create bottom values for CreateActivation sink candidates and CreateActivation should have SymbolTable as a child node
        https://bugs.webkit.org/show_bug.cgi?id=145192

        Reviewed by Filip Pizlo.

        When we sink CreateActivation and generate MaterializeCreateActivation
        in the object allocation sinking phase, we now explictly add PutHints for 
        all variables on the activation setting those variables to their default value 
        (undefined for Function activations and soon to be JS Empty Value for block scope activations). 
        This allows us to remove code that fills FTL fast activation allocations with Undefined.

        This patch also adds the constant SymbolTable as an OpInfo of CreateActivation and MaterializeCreateActivation
        nodes. This is in preparation for ES6 block scoping which will introduce a new 
        op code that gets lowered to CreateActivation.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasCellOperand):
        (JSC::DFG::Node::cellOperand):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
        (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
        * dfg/DFGPromotedHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGPromotedHeapLocation.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCreateActivation):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileCreateActivation):
        (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * tests/stress/activation-sink-default-value.js: Added.
        (bar):
        * tests/stress/activation-sink-osrexit-default-value.js: Added.
        (foo.set result):

2015-05-21  Per Arne Vollan  <peavo@outlook.com>

        MSVC internal compiler error when compiling TemplateRegistryKey class.
        https://bugs.webkit.org/show_bug.cgi?id=145259

        Reviewed by Alex Christensen.

        MSVC is not able to handle the brace initialization of a class member in this case.

        * runtime/TemplateRegistryKey.h:

2015-05-21  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the !ENABLE(ES6_TEMPLATE_LITERAL_SYNTAX) build after r184337
        https://bugs.webkit.org/show_bug.cgi?id=145248

        Reviewed by Yusuke Suzuki.

        * bytecompiler/BytecodeGenerator.cpp:
        * bytecompiler/BytecodeGenerator.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseMemberExpression):

2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: array previews should have a much smaller cap on values
        https://bugs.webkit.org/show_bug.cgi?id=145195

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.RemoteObject.prototype._generatePreview):
        Reduce the indexes threshold for previews.

2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Use native Arguments detection instead of using toString
        https://bugs.webkit.org/show_bug.cgi?id=145235

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype._subtype):
        Deleted the old string code.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        Replaced with a stricter, more accurate check.

2015-05-20  Andreas Kling  <akling@apple.com>

        Remove unused MarkedBlock::m_rememberedSet.
        <https://webkit.org/b/145224>

        Reviewed by Mark Hahnenberg.

        The MarkedBlock had a copy of the remembered bit for each of its cells,
        and we were maintaining that bitmap despite no one actually ever consulting it.

        This patch removes MarkedBlock::m_rememberedSet, freeing up 128 bytes in each
        block and making write barriers a little faster.

        * heap/Heap.cpp:
        (JSC::Heap::clearRememberedSet):
        (JSC::Heap::addToRememberedSet):
        * heap/HeapInlines.h:
        (JSC::Heap::isRemembered):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::clearRememberedSet): Deleted.
        (JSC::MarkedBlock::clearMarksWithCollectionType):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::setRemembered): Deleted.
        (JSC::MarkedBlock::clearRemembered): Deleted.
        (JSC::MarkedBlock::atomicClearRemembered): Deleted.
        (JSC::MarkedBlock::isRemembered): Deleted.
        * heap/MarkedSpace.h:
        (JSC::ClearRememberedSet::operator()): Deleted.
        (JSC::MarkedSpace::clearRememberedSet): Deleted.

2015-05-20  Andreas Kling  <akling@apple.com>

        Eden collections should extend the IncrementalSweeper work list, not replace it.
        <https://webkit.org/b/145213>
        <rdar://problem/21002666>

        Reviewed by Geoffrey Garen.

        After an eden collection, the garbage collector was adding all MarkedBlocks containing
        new objects to the IncrementalSweeper's work list, to make sure they didn't have to
        wait until the next full collection before getting swept.

        Or at least, that's what it thought it was doing. It turns out that IncrementalSweeper's
        internal work list is really just a reference to Heap::m_blockSnapshot. I didn't realize
        this when writing the post-eden sweep code, and instead made eden collections cancel
        all pending sweeps and *replace* them with the list of blocks with new objects.

        This made it so that rapidly occurring eden collections could prevent large numbers of
        heap blocks from ever getting swept. This would manifest as accumulation of MarkedBlocks
        when a system under heavy load was also allocating short lived objects at a high rate.
        Things would eventually get cleaned up when there was a lull and a full collection was
        allowed to run its heap sweep to completion.

        Fix this by moving all management of the block snapshot to Heap. snapshotMarkedSpace()
        now handles eden collections by merging the list of blocks with new objects into the
        existing block snapshot.

        * heap/Heap.cpp:
        (JSC::Heap::snapshotMarkedSpace):
        (JSC::Heap::notifyIncrementalSweeper):
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::startSweeping):
        (JSC::IncrementalSweeper::addBlocksAndContinueSweeping): Deleted.
        * heap/IncrementalSweeper.h:

2015-05-20  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        AudioContext resume/close/suspend should reject promises with a DOM exception in lieu of throwing exceptions
        https://bugs.webkit.org/show_bug.cgi?id=145064

        Reviewed by Darin Adler.

        Added default message for TypeError.

        * runtime/Error.cpp:
        (JSC::throwTypeError):
        * runtime/Error.h:

2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>

        No LLInt Test Failure: jsc-layout-tests.yaml/js/script-tests/object-literal-duplicate-properties.js.layout-no-llint
        https://bugs.webkit.org/show_bug.cgi?id=145219

        Reviewed by Mark Lam.

        * jit/JITOperations.cpp:
        Throw the error we just got, instead of a stack overflow exception.
        This matches other error handling for callers of prepareForExecution.

2015-05-19  Filip Pizlo  <fpizlo@apple.com>

        Add some assertions about the CFG in the loop pre-header creation phase
        https://bugs.webkit.org/show_bug.cgi?id=145205

        Reviewed by Geoffrey Garen.
        
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::currentNodeOrigin): Add a FIXME.
        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::run): Add a FIXME.
        * dfg/DFGLoopPreHeaderCreationPhase.cpp:
        (JSC::DFG::LoopPreHeaderCreationPhase::run): Add the assertions.

2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>

        ES6: Implement Object.setPrototypeOf
        https://bugs.webkit.org/show_bug.cgi?id=145202

        Reviewed by Darin Adler.

        * runtime/JSGlobalObjectFunctions.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoSetter):
        (JSC::checkProtoSetterAccessAllowed):
        Extract a helper to share this code between __proto__ setter and setPrototypeOf.

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorSetPrototypeOf):
        Implementation is very similiar to __proto__ setter.

2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>

        ES6: Should not allow duplicate basic __proto__ properties in Object Literals
        https://bugs.webkit.org/show_bug.cgi?id=145138

        Reviewed by Darin Adler.

        Implement ES6 Annex B.3.1, which disallows duplicate basic __proto__
        properties in object literals. This doesn't affect computed properties,
        shorthand properties, or getters/setters all of which avoid setting
        the actual prototype of the object anyway.

        * interpreter/Interpreter.cpp:
        (JSC::eval):
        Remove out of date comment. Duplicate property names are allowed
        now in ES6, they were not in ES5 strict mode.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::getName):
        (JSC::ASTBuilder::getType):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::getName):
        Add back getName to get the property name depending on the tree builder.
        Also tighten up the parameter types.

        * runtime/LiteralParser.cpp:
        (JSC::LiteralParser<CharType>::parse):
        In quick JSON literal parsing for eval, we actually need to evaluate
        the __proto__ property assignment, instead of just building up a list
        of direct properties. Only do this when not doing a strict JSON parse.

        * parser/Nodes.h:
        Add "Shorthand" to the list of PropertyNode types to allow it to
        be distinguished without relying on other information.

        * parser/Parser.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseProperty):
        Add the Shorthand type when parsing a shorthand property.

        (JSC::Parser<LexerType>::shouldCheckPropertyForUnderscoreProtoDuplicate):
        (JSC::Parser<LexerType>::parseObjectLiteral):
        (JSC::Parser<LexerType>::parseStrictObjectLiteral):
        Check for duplicate __proto__ properties, and throw a SyntaxError
        if that was the case.

2015-05-20  Csaba Osztrogonác  <ossy@webkit.org>

        [JSC] Add missing copyrights and licenses for some scripts
        https://bugs.webkit.org/show_bug.cgi?id=145044

        Reviewed by Darin Adler.

        * build-symbol-table-index.py:
        * create-llvm-ir-from-source-file.py:
        * create-symbol-table-index.py:

2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Slightly better node previews in arrays
        https://bugs.webkit.org/show_bug.cgi?id=145188

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype._nodeDescription):
        (InjectedScript.prototype._nodePreview):
        Different stringified representations for a basic object description or in a preview.

        (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
        Use the node preview string representation inside previews.

2015-05-19  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r184613 and r184614.
        https://bugs.webkit.org/show_bug.cgi?id=145206

        Broke 10 tests :| (Requested by kling on #webkit).

        Reverted changesets:

        "[JSC] Speed up URL encode/decode by using bitmaps instead of
        strchr()."
        https://bugs.webkit.org/show_bug.cgi?id=145115
        http://trac.webkit.org/changeset/184613

        "[JSC] Speed up URL encode/decode by using bitmaps instead of
        strchr()."
        https://bugs.webkit.org/show_bug.cgi?id=145115
        http://trac.webkit.org/changeset/184614

2015-05-19  Andreas Kling  <akling@apple.com>

        Give StringView a utf8() API.
        <https://webkit.org/b/145201>

        Reviewed by Anders Carlsson.

        Use JSString::view() in a few places where we couldn't before due to StringView
        lacking a utf8() API. This is a minor speed-up on Kraken's crypto subtests,
        which like to call encode() with substring JSStrings.

        * jsc.cpp:
        (functionPrint):
        (functionDebug):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::encode):

2015-05-19  Andreas Kling  <akling@apple.com>

        [JSC] Speed up URL encode/decode by using bitmaps instead of strchr().
        <https://webkit.org/b/145115>

        Incorporate review feedback from Darin, removing some unnecessary zero checks.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::encode):
        (JSC::decode):
        (JSC::globalFuncEscape):

2015-05-19  Yusuke Suzuki  <utatane.tea@gmail.com>

        Move AtomicStringImpl table related operations from AtomicString to AtomicStringImpl
        https://bugs.webkit.org/show_bug.cgi?id=145109

        Reviewed by Darin Adler.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::nameForRegister):
        * runtime/Identifier.cpp:
        (JSC::Identifier::add):
        (JSC::Identifier::add8):
        * runtime/Identifier.h:
        (JSC::Identifier::add):
        * runtime/IdentifierInlines.h:
        (JSC::Identifier::Identifier):
        (JSC::Identifier::add):
        * runtime/JSString.cpp:
        (JSC::JSRopeString::resolveRopeToExistingAtomicString):
        * runtime/JSString.h:
        (JSC::JSString::toExistingAtomicString):
        * runtime/SmallStrings.cpp:
        (JSC::SmallStringsStorage::SmallStringsStorage):
        * runtime/TypeSet.cpp:
        (JSC::StructureShape::propertyHash):

2015-05-19  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Improve Preview for NodeList / array like collections
        https://bugs.webkit.org/show_bug.cgi?id=145177

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
        For "array" like object previews skip over non-index properties.
        We are not marking the object as lossless by choice, but we
        may return to this decision later.

2015-05-19  Michael Saboff  <msaboff@apple.com>

        REGRESSION(183787): JIT is enabled for all builds
        https://bugs.webkit.org/show_bug.cgi?id=145179

        Reviewed by Geoffrey Garen.

        Eliminated the setting of ENABLE_JIT, as wtf/Platform.h has appropriate logic to
        set it depending on OS and CPU type.

        * Configurations/FeatureDefines.xcconfig:

2015-05-19  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        Rename createIterResultObject as createIteratorResultObject
        https://bugs.webkit.org/show_bug.cgi?id=145116

        Reviewed by Darin Adler.

        Renamed createIterResultObject as createIteratorResultObject.
        Made this function exportable for future use by streams API.

        * runtime/IteratorOperations.cpp:
        (JSC::createIteratorResultObject):
        * runtime/IteratorOperations.h:
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototypeFuncNext):
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototypeFuncNext):

2015-05-19  Yusuke Suzuki  <utatane.tea@gmail.com>

        Array.prototype methods must use ToLength
        https://bugs.webkit.org/show_bug.cgi?id=144128

        Reviewed by Oliver Hunt.

        Patch by Jordan Harband  <ljharb@gmail.com> and Yusuke Suzuki <utatane.tea@gmail.com>

        Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-tolength

        This patch introduces ToLength and ToInteger JS implementation to encourage the DFG/FTL's inlining.
        These implementations are located in GlobalObject.js.
        And set to the JSGlobalObject with the private symbols @ToLength and @ToInteger manually.

        * builtins/Array.prototype.js:
        (every):
        (forEach):
        (filter):
        (map):
        (some):
        (fill):
        (find):
        (findIndex):
        (includes):
        * builtins/ArrayConstructor.js:
        (from):
        * builtins/GlobalObject.js: Copied from Source/JavaScriptCore/builtins/StringConstructor.js.
        (ToInteger):
        (ToLength):
        * builtins/StringConstructor.js:
        (raw):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObjectFunctions.h:

2015-05-19  Mark Lam  <mark.lam@apple.com>

        Fix the build of a universal binary with ARMv7k of JavaScriptCore.
        https://bugs.webkit.org/show_bug.cgi?id=145143

        Reviewed by Geoffrey Garen.

        The offlineasm works in 3 phases:

        Phase 1:
           Parse the llint asm files for config options and desired offsets.
           Let's say the offlineasm discovers C unique options and O unique offsets.
           The offlineasm will then generate a LLIntDesiredOffsets.h file with
           C x C build configurations, each with a set of O offsets.

           Each of these build configurations is given a unique configuration index number.

        Phase 2: 
           Compile the LLIntDesiredOffsets.h file into a JSCLLIntOffsetsExtractor binary.

           If we're building a fat binary with 2 configurations: armv7, and armv7k,
           then the fat binary will contain 2 blobs of offsets, one for each of these
           build configurations.

        Phase 3:
           Parse the llint asm files and emit asm code using the offsets that are
           extracted from the JSCLLIntOffsetsExtractor binary for the corresponding
           configuration index number.

        In the pre-existing code, there are no "if ARMv7k" statements in the llint asm
        source.  As a result, OFFLINE_ASM_ARMv7k is not one of the config options in
        the set of C unique options.

        For armv7k builds, OFFLINE_ASM_ARMv7 is also true.  As a result, for an armv7k
        target, we will end up building armv7 source.  In general, this is fine except:

        1. armv7k has different alignment requirements from armv7.  Hence, their offset
           values (in JSCLLIntOffsetsExtractor) will be different.

        2. The offlineasm was never told that it needed to make a different configuration
           for armv7k builds.  Hence, the armv7k build of LLIntDesiredOffsets.h will
           build the armv7 configuration, and consequently, the armv7k blob of offsets in
           JSCLLIntOffsetsExtractor will have the same configuration index number as
           the armv7 blob of offsets.

        In phase 3, when the offlineasm parses the JSCLLIntOffsetsExtractor fat binary
        looking for the armv7 build's configuration index number, it discovers the
        armv7k blob which has the same configuration number.  As a result, it
        erroneously thinks the armv7k offsets are appropriate for emitting armv7 code.
        Needless to say, armv7 code using armv7k offsets will lead to incorrect behavior
        and all round badness.

        The fix is to add a simple "if ARMv7k" statement to the llint asm files.  While
        the if statement has no body, it does make the offlineasm aware of the need for
        ARMv7k as a configuration option.  As a result, it will generate an armv7k
        variant configuration in the LLIntDesiredOffsets.h file with its own unique
        configuration index number.  With that, the JSCLLIntOffsetsExtractor fat binary
        will no longer have duplicate configuration index numbers for the armv7 and
        armv7k blobs of offsets, and the issue is resolved.

        * llint/LLIntOfflineAsmConfig.h:
        * llint/LowLevelInterpreter.asm:

2015-05-19  Andreas Kling  <akling@apple.com>

        Give JSString a StringView getter and start using it.
        <https://webkit.org/b/145131>

        Reviewed by Anders Carlsson.

        When JSString is a substring internally, calling value(ExecState*) on it
        will reify the baseString/start/length tuple into a new StringImpl.

        For clients that only want to look at the characters of a JSString, but
        don't actually need a reffable StringImpl, adding a light-weight StringView
        getter lets them avoid constructing anything.

        This patch adds JSString::view(ExecState*) and uses it in a few places.
        There are many more opportunities to use this API, but let's do a few things
        at a time.

        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::decode):
        (JSC::parseInt):
        (JSC::jsToNumber):
        (JSC::parseFloat):
        (JSC::globalFuncParseInt):
        (JSC::globalFuncParseFloat):
        (JSC::globalFuncEscape):
        (JSC::globalFuncUnescape):
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/JSONObject.cpp:
        (JSC::JSONProtoFuncParse):
        * runtime/JSString.cpp:
        (JSC::JSString::getPrimitiveNumber):
        (JSC::JSString::toNumber):
        * runtime/JSString.h:
        (JSC::JSRopeString::view):
        (JSC::JSString::view):

2015-05-18  Filip Pizlo  <fpizlo@apple.com>

        Better optimize 'if' with ternaries conditional tests.
        https://bugs.webkit.org/show_bug.cgi?id=144136

        Reviewed by Benjamin Poulain.
        
        This is the last fix I'll do for this for now. BooleanToNumber(Untyped:) where the input
        is proved to be either BoolInt32 or Boolean should be optimized to just masking the
        lowest bit.
        
        This is another 37% speed-up on JSRegress/slow-ternaries.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):

2015-05-18  Benjamin Poulain  <bpoulain@apple.com>

        <rdar://problem/21003555> cloberrize() is wrong for ArithRound because it doesn't account for the arith mode
        https://bugs.webkit.org/show_bug.cgi?id=145147

        Reviewed by Filip Pizlo.

        Really stupid bug: ArithRound nodes with different rounding modes
        were not distinguished and CSE would happily unify with a node of
        a different rounding mode.

        DFG::clobberize() already support additional data but I was not using it.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * tests/stress/math-round-arith-rounding-mode.js: Added.
        (firstCareAboutZeroSecondDoesNot):
        (firstDoNotCareAboutZeroSecondDoes):
        (warmup):
        (verifyNegativeZeroIsPreserved):

2015-05-18  Filip Pizlo  <fpizlo@apple.com>

        Add SpecBoolInt32 type that means "I'm an int and I'm either 0 or 1"
        https://bugs.webkit.org/show_bug.cgi?id=145137

        Reviewed by Benjamin Poulain.
        
        It's super useful to know if an integer value could be either zero or one. We have an
        immediate need for this because of Int32|Boolean uses, where knowing that the Int32 is
        either 0 or 1 means that there is no actual polymorphism if you just look at the low bit
        (1 behaves like true, 0 behaves like false, and the low bit of 1|true is 1, and the low
        bit of 0|false is 0).
        
        We do this by splitting the SpecInt32 type into SpecBoolInt32 and SpecNonBoolInt32. This
        change doesn't have any effect on behavior, yet. But it does give us the ability to
        predict and prove when values are SpecBoolInt32; it's just we don't leverage this yet.
        
        This is perf-neutral.

        * bytecode/SpeculatedType.cpp:
        (JSC::dumpSpeculation):
        (JSC::speculationToAbbreviatedString):
        (JSC::speculationFromValue):
        * bytecode/SpeculatedType.h:
        (JSC::isStringOrStringObjectSpeculation):
        (JSC::isBoolInt32Speculation):
        (JSC::isInt32Speculation):
        (JSC::isInt32OrBooleanSpeculation):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2015-05-18  Michael Catanzaro  <mcatanzaro@igalia.com>

        [CMake] Ignore warnings in system headers
        https://bugs.webkit.org/show_bug.cgi?id=144747

        Reviewed by Darin Adler.

        Separate include directories into WebKit project includes and system includes. Suppress all
        warnings from headers in system include directories using the SYSTEM argument to
        the include_directories command.

        * CMakeLists.txt:
        * PlatformGTK.cmake:

2015-05-18  Skachkov Alexandr  <gskachkov@gmail.com>

        [ES6] Arrow function syntax. Feature flag for arrow function
        https://bugs.webkit.org/show_bug.cgi?id=145108

        Reviewed by Ryosuke Niwa.

        Added feature flag ENABLE_ES6_ARROWFUNCTION_SYNTAX for arrow function

        * Configurations/FeatureDefines.xcconfig:
        
2015-05-18  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] When entering a CheckTierUp without OSREntry, force the CheckTierUp for the outer loops with OSR Entry
        https://bugs.webkit.org/show_bug.cgi?id=145092

        Reviewed by Filip Pizlo.

        When we have a hot loop without OSR Entry inside a slower loop that support OSR Entry,
        we get the inside loop driving the tierUpCounter and we have very little chance of
        doing a CheckTierUp on the outer loop. In turn, this give almost no opportunity to tier
        up in the outer loop and OSR Enter there.

        This patches changes CheckTierUp to force its outer loops to do a CheckTierUp themselves.

        To do that, CheckTierUp sets a flag "nestedTriggerIsSet" to force the outer loop to
        enter their CheckTierUp regardless of the tier-up counter.

        * bytecode/ExecutionCounter.cpp:
        (JSC::ExecutionCounter<countingVariant>::setThreshold):
        This is somewhat unrelated. This assertion is incorrect because it relies on
        m_counter, which changes on an other thread.

        I have hit it a couple of times with this patch because we are a bit more aggressive
        on CheckTierUp. What happens is:
        1) ExecutionCounter<countingVariant>::checkIfThresholdCrossedAndSet() first checks
           hasCrossedThreshold(), and it is false.
        2) On the main thread, the hot loops keeps running and the counter becomes large
           enough to cross the threshold.
        3) ExecutionCounter<countingVariant>::checkIfThresholdCrossedAndSet() runs the next
           test, setThreshold(), where the assertion is. Since the counter is now large enough,
           the assertion fails.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

        * dfg/DFGJITCode.h:
        I used a uint8_t instead of a boolean to make the code generation clearer
        in DFGSpeculativeJIT64.

        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:

        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        This is a bit annoying: we have the NaturalLoops analysis that provides us
        everything we need to know about loops, but the TierUpCheck are conservative
        and set on LoopHint.

        To make the two work together, we first find all the CheckTierUp that cannot
        OSR enter and we keep a list of all the natural loops containing them.

        Then we do a second pass over the LoopHints, get their NaturalLoop, and check
        if it contains a loop that cannot OSR enter.

        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        (JSC::DFG::TierUpCheckInjectionPhase::canOSREnterAtLoopHint):

2015-05-18  Filip Pizlo  <fpizlo@apple.com>

        Add a Int-or-Boolean speculation to Branch
        https://bugs.webkit.org/show_bug.cgi?id=145134

        Reviewed by Benjamin Poulain.
        
        After https://bugs.webkit.org/show_bug.cgi?id=126778 we no longer have a reason not to do the
        int-or-boolean optimization that we already do everywhere else.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

2015-05-18  Andreas Kling  <akling@apple.com>

        [JSC] Speed up URL encode/decode by using bitmaps instead of strchr().
        <https://webkit.org/b/145115>

        Reviewed by Anders Carlsson.

        We were calling strchr() for every character when doing URL encoding/decoding and it stood out
        like a sore O(n) thumb in Instruments. Optimize this by using a Bitmap<256> instead.

        5.5% progression on Kraken/stanford-crypto-sha256-iterative.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::makeCharacterBitmap):
        (JSC::encode):
        (JSC::decode):
        (JSC::globalFuncDecodeURI):
        (JSC::globalFuncDecodeURIComponent):
        (JSC::globalFuncEncodeURI):
        (JSC::globalFuncEncodeURIComponent):
        (JSC::globalFuncEscape):

2015-05-17  Benjamin Poulain  <benjamin@webkit.org>

        Do not use fastMallocGoodSize anywhere
        https://bugs.webkit.org/show_bug.cgi?id=145103

        Reviewed by Michael Saboff.

        * assembler/AssemblerBuffer.h:
        (JSC::AssemblerData::AssemblerData):
        (JSC::AssemblerData::grow):

2015-05-17  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Make StringRecursionChecker faster in the simple cases without any recursion
        https://bugs.webkit.org/show_bug.cgi?id=145102

        Reviewed by Darin Adler.

        In general, the array targeted by Array.toString() or Array.join() are pretty
        simple. In those simple cases, we spend as much time in StringRecursionChecker
        as we do on the actual operation.

        The reason for this is the HashSet stringRecursionCheckVisitedObjects used
        to detect recursion. We are constantly adding and removing objects which
        dirty buckets and force constant rehash.

        This patch adds a simple shortcut for those simple case: in addition to the HashSet,
        we keep a pointer to the root object of the recursion.
        In the vast majority of cases, we no longer touch the HashSet at all.

        This patch is a 12% progression on the overall score of ArrayWeighted.

        * runtime/StringRecursionChecker.h:
        (JSC::StringRecursionChecker::performCheck):
        (JSC::StringRecursionChecker::~StringRecursionChecker):
        * runtime/VM.h:

2015-05-17  Filip Pizlo  <fpizlo@apple.com>

        Insert store barriers late so that IR transformations don't have to worry about them
        https://bugs.webkit.org/show_bug.cgi?id=145015

        Reviewed by Geoffrey Garen.
        
        We have had three kinds of bugs with store barriers. For the sake of discussion we say
        that a store barrier is needed when we have something like:
        
            base.field = value
        
        - We sometimes fail to realize that we could remove a barrier when value is a non-cell.
          This might happen if we prove value to be a non-cell even though in the FixupPhase it
          wasn't predicted non-cell.
        
        - We sometimes have a barrier in the wrong place after object allocation sinking. We
          might sink an allocation to just above the store, but that puts it just after the
          StoreBarrier that FixupPhase inserted.
        
        - We don't remove redundant barriers across basic blocks.
        
        This comprehensively fixes these issues by doing store barrier insertion late, and
        removing the store barrier elision phase. Store barrier insertion uses an epoch-based
        algorithm to determine when stores need barriers. Briefly, a barrier is not needed if
        base is in the current GC epoch (i.e. was the last object that we allocated or had a
        barrier since last GC) or if base has a newer GC epoch than value (i.e. value would have
        always been allocated before base). We do conservative things when merging epoch state
        between basic blocks, and we only do such inter-block removal in the FTL. FTL also
        queries AI to determine what type we've proved about value, and avoids barriers when
        value is not a cell. FixupPhase still inserts type checks on some stores, to maximize
        the likelihood that this AI-based removal is effective.
        
        Rolling back in after fixing some debug build test failures.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGBlockMap.h:
        (JSC::DFG::BlockMap::at):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
        * dfg/DFGEpoch.h:
        (JSC::DFG::Epoch::operator<):
        (JSC::DFG::Epoch::operator>):
        (JSC::DFG::Epoch::operator<=):
        (JSC::DFG::Epoch::operator>=):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::speculateForBarrier):
        (JSC::DFG::FixupPhase::insertStoreBarrier): Deleted.
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGStoreBarrierElisionPhase.cpp: Removed.
        * dfg/DFGStoreBarrierElisionPhase.h: Removed.
        * dfg/DFGStoreBarrierInsertionPhase.cpp: Added.
        (JSC::DFG::performFastStoreBarrierInsertion):
        (JSC::DFG::performGlobalStoreBarrierInsertion):
        * dfg/DFGStoreBarrierInsertionPhase.h: Added.
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR): Fix an unrelated debug-only bug.
        * tests/stress/load-varargs-then-inlined-call-and-exit.js: Test for that debug-only bug.
        * tests/stress/load-varargs-then-inlined-call-and-exit-strict.js: Strict version of that test.

2015-05-16  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r184415.
        https://bugs.webkit.org/show_bug.cgi?id=145096

        Broke several tests (Requested by msaboff on #webkit).

        Reverted changeset:

        "Insert store barriers late so that IR transformations don't
        have to worry about them"
        https://bugs.webkit.org/show_bug.cgi?id=145015
        http://trac.webkit.org/changeset/184415

2015-05-14  Filip Pizlo  <fpizlo@apple.com>

        Insert store barriers late so that IR transformations don't have to worry about them
        https://bugs.webkit.org/show_bug.cgi?id=145015

        Reviewed by Geoffrey Garen.
        
        We have had three kinds of bugs with store barriers. For the sake of discussion we say
        that a store barrier is needed when we have something like:
        
            base.field = value
        
        - We sometimes fail to realize that we could remove a barrier when value is a non-cell.
          This might happen if we prove value to be a non-cell even though in the FixupPhase it
          wasn't predicted non-cell.
        
        - We sometimes have a barrier in the wrong place after object allocation sinking. We
          might sink an allocation to just above the store, but that puts it just after the
          StoreBarrier that FixupPhase inserted.
        
        - We don't remove redundant barriers across basic blocks.
        
        This comprehensively fixes these issues by doing store barrier insertion late, and
        removing the store barrier elision phase. Store barrier insertion uses an epoch-based
        algorithm to determine when stores need barriers. Briefly, a barrier is not needed if
        base is in the current GC epoch (i.e. was the last object that we allocated or had a
        barrier since last GC) or if base has a newer GC epoch than value (i.e. value would have
        always been allocated before base). We do conservative things when merging epoch state
        between basic blocks, and we only do such inter-block removal in the FTL. FTL also
        queries AI to determine what type we've proved about value, and avoids barriers when
        value is not a cell. FixupPhase still inserts type checks on some stores, to maximize
        the likelihood that this AI-based removal is effective.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGBlockMap.h:
        (JSC::DFG::BlockMap::at):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
        * dfg/DFGEpoch.h:
        (JSC::DFG::Epoch::operator<):
        (JSC::DFG::Epoch::operator>):
        (JSC::DFG::Epoch::operator<=):
        (JSC::DFG::Epoch::operator>=):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::speculateForBarrier):
        (JSC::DFG::FixupPhase::insertStoreBarrier): Deleted.
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGStoreBarrierElisionPhase.cpp: Removed.
        * dfg/DFGStoreBarrierElisionPhase.h: Removed.
        * dfg/DFGStoreBarrierInsertionPhase.cpp: Added.
        (JSC::DFG::performFastStoreBarrierInsertion):
        (JSC::DFG::performGlobalStoreBarrierInsertion):
        * dfg/DFGStoreBarrierInsertionPhase.h: Added.

2015-05-15  Benjamin Poulain  <bpoulain@apple.com>

        [ARM64] Do not fail branchConvertDoubleToInt32 when the result is zero and not negative zero
        https://bugs.webkit.org/show_bug.cgi?id=144976

        Reviewed by Michael Saboff.

        Failing the conversion on zero is pretty dangerous as we discovered on x86.

        This patch does not really impact performance significantly because
        r184220 removed the zero checks from Kraken. This patch is just to be
        on the safe side for cases not covered by existing benchmarks.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::branchConvertDoubleToInt32):

2015-05-15  Sungmann Cho  <sungmann.cho@navercorp.com>

        Remove unnecessary forward declarations in PropertyNameArray.h.
        https://bugs.webkit.org/show_bug.cgi?id=145058

        Reviewed by Andreas Kling.

        No new tests, no behavior change.

        * runtime/PropertyNameArray.h:

2015-05-15  Mark Lam  <mark.lam@apple.com>

        JSArray::setLength() should reallocate instead of zero-filling if the reallocation would be small enough.
        https://bugs.webkit.org/show_bug.cgi?id=144622

        Reviewed by Geoffrey Garen.

        When setting the array to a new length that is shorter, we now check if it is worth
        just making a new butterfly instead of clearing out the slots in the old butterfly
        that resides beyond the new length.  If so, we will make a new butterfly instead.

        There is no perf differences in the benchmark results.  However, this does benefit
        the perf of pathological cases where we need to shorten the length of a very large
        array, as is the case in tests/mozilla/js1_5/Array/regress-101964.js.  With this
        patch, we can expect that test to complete in a short time again.

        * runtime/JSArray.cpp:
        (JSC::JSArray::setLength):
        * runtime/JSObject.cpp:
        (JSC::JSObject::reallocateAndShrinkButterfly):
        - makes a new butterfly with a new shorter length.
        * runtime/JSObject.h:
        * tests/mozilla/js1_5/Array/regress-101964.js:
        - Undo this test change since this patch will prevent us from spending a lot of time
          clearing a large butterfly.

2015-05-15  Basile Clement  <basile_clement@apple.com>

        DFGLICMPhase shouldn't create NodeOrigins with forExit but without semantic
        https://bugs.webkit.org/show_bug.cgi?id=145062

        Reviewed by Filip Pizlo.

        We assert in various places (including NodeOrigin::isSet()) that a
        NodeOrigin's semantic and forExit must be either both set, or both
        unset.  However, LICM'ing a node with unset NodeOrigin would only set
        forExit, and leave semantic unset. This can for instance happen when a
        Phi node is constant-folded into a JSConstant, which in turn gets
        LICM'd.

        This patch changes DFGLICMPhase to set the NodeOrigin's semantic in
        addition to its forExit if semantic was previously unset.

        It also adds two validators to DFGValidate.cpp:
         - In both SSA and CPS form, a NodeOrigin semantic and forExit must be either both set or both unset
         - In CPS form, all nodes must have a set NodeOrigin forExit (this is
           the CPS counterpart to the SSA validator that checks that all nodes
           must have a set NodeOrigin except possibly for a continuous chunk of
           nodes at the top of a block)

        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::attemptHoist):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validate):
        (JSC::DFG::Validate::validateCPS):

2015-05-15  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, remove an unused declaration.

        * dfg/DFGSpeculativeJIT.h:

2015-05-14  Filip Pizlo  <fpizlo@apple.com>

        Remove unused constant-base and constant-value store barrier code in the DFG
        https://bugs.webkit.org/show_bug.cgi?id=145039

        Reviewed by Andreas Kling.
        
        Just killing dead code.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): Deleted.
        (JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::writeBarrier):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::writeBarrier):

2015-05-15  Alexandr Skachkov  <gskachkov@gmail.com>

        Fix typo in function name parseFunctionParamters -> parseFunctionParameters
        https://bugs.webkit.org/show_bug.cgi?id=145040

        Reviewed by Mark Lam.

        * parser/Parser.h:
        * parser/Parser.cpp:

2015-05-14  Filip Pizlo  <fpizlo@apple.com>

        Remove StoreBarrierWithNullCheck, nobody ever generates this.
        
        Rubber stamped by Benjamin Poulain and Michael Saboff.

        If we did bring something like this back in the future, we would just use UntypedUse instead
        of CellUse to indicate that this is what we want.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::isStoreBarrier):
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileStoreBarrierWithNullCheck): Deleted.

2015-05-14  Filip Pizlo  <fpizlo@apple.com>

        PutGlobalVar should reference the global object it's storing into
        https://bugs.webkit.org/show_bug.cgi?id=145036

        Reviewed by Michael Saboff.
        
        This makes it easier to reason about store barrier insertion and elimination. This changes
        the format of PutGlobalVar so that child1 is the global object and child2 is the value.
        Previously it just had child1, and that was the value.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compilePutGlobalVar):

2015-05-14  Michael Catanzaro  <mcatanzaro@igalia.com>

        [CMake] Error out when ruby is too old
        https://bugs.webkit.org/show_bug.cgi?id=145014

        Reviewed by Martin Robinson.

        Don't enforce the check for the Ruby executable here; it's now enforced in the top-level
        CMakeLists.txt instead.

        * CMakeLists.txt:

2015-05-12  Basile Clement  <basile_clement@apple.com>

        Enforce options coherency
        https://bugs.webkit.org/show_bug.cgi?id=144921

        Reviewed by Mark Lam.

        JavaScriptCore should be failing early when the options are set in such
        a way that we don't have a meaningful way to execute JavaScript, rather
        than failing for obscure reasons at some point during execution.

        This patch adds a new function that checks whether the options are set
        in a coherent way, and makes JSC::Options::initialize() crash when the
        environment enforces incoherent options.
        Client applications able to add or change additional options are
        responsible to check for coherency again before starting to actually
        execute JavaScript, if any additional options have been set. This is
        implemented for the jsc executable in this patch.

        * jsc.cpp:
        (CommandLine::parseArguments):
        * runtime/Options.cpp:
        (JSC::Options::initialize):
        (JSC::Options::ensureOptionsAreCoherent): Added.
        * runtime/Options.h:
        (JSC::Options::ensureOptionsAreCoherent): Added.

2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION (r184337): [EFL] unresolved reference errors in ARM builds
        https://bugs.webkit.org/show_bug.cgi?id=145019

        Reviewed by Ryosuke Niwa.

        Attempt to fix compile errors in EFL ARM buildbots.
        By executing `nm`, found JSTemplateRegistryKey.cpp.o and TemplateRegistry.cpp.o have
        unresolved reference to Structure::get. That is inlined function in StructureInlines.h.

        * runtime/JSTemplateRegistryKey.cpp:
        * runtime/TemplateRegistry.cpp:

2015-05-14  Alexandr Skachkov  <gskachkov@gmail.com>

        Small refactoring before implementation of the ES6 arrow function.
        https://bugs.webkit.org/show_bug.cgi?id=144954

        Reviewed by Ryosuke Niwa.

        * parser/Parser.h:
        * parser/Parser.cpp:

2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION (r184337): ASSERT failed in debug builds for tagged templates
        https://bugs.webkit.org/show_bug.cgi?id=145013

        Reviewed by Filip Pizlo.

        Fix the regression introduced by r184337.

        1. JSTemporaryRegistryKey::s_info should inherit the Base::s_info,
           JSDestructibleObject::s_info.

        2. The first register argument of BytecodeGenerator::emitNode
           should be a referenced register if it is a temporary register.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::TaggedTemplateNode::emitBytecode):
        * runtime/JSTemplateRegistryKey.cpp:

2015-05-14  Andreas Kling  <akling@apple.com>

        String.prototype.split() should create efficient substrings.
        <https://webkit.org/b/144985>
        <rdar://problem/20949344>

        Reviewed by Geoffrey Garen.

        Teach split() how to make substring JSStrings instead of relying on StringImpl's
        substring sharing mechanism. The optimization works by deferring the construction
        of a StringImpl until the substring's value is actually needed.

        This knocks ~2MB off of theverge.com by avoiding the extra StringImpl allocations.
        Out of ~70000 substrings created by split(), only ~2000 of them get reified.

        * runtime/StringPrototype.cpp:
        (JSC::jsSubstring):
        (JSC::splitStringByOneCharacterImpl):
        (JSC::stringProtoFuncSplit):

2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>

        Change the status of ES6 tagged templates to Done in features.json
        https://bugs.webkit.org/show_bug.cgi?id=145003

        Reviewed by Benjamin Poulain.

        Now it's implemented in r184337.

        * features.json:

2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>

        Introduce SymbolType into SpeculativeTypes
        https://bugs.webkit.org/show_bug.cgi?id=142651

        Reviewed by Filip Pizlo.

        Introduce SpecSymbol type into speculative types.
        Previously symbol type is categorized into SpecCellOther.
        But SpecCellOther is not intended to be used for such cells.

        This patch just introduces SpecSymbol.
        It represents the type of target value is definitely the symbol type.
        It is the part of SpecCell.

        In this patch, we do not introduce SymbolUse tracking.
        It will be added in the separate patch.

        * bytecode/SpeculatedType.cpp:
        (JSC::dumpSpeculation):
        (JSC::speculationFromStructure):
        * bytecode/SpeculatedType.h:
        (JSC::isSymbolSpeculation):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::setType):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * tests/stress/typeof-symbol.js: Added.

2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement tagged templates
        https://bugs.webkit.org/show_bug.cgi?id=143183

        Reviewed by Oliver Hunt.

        This patch implements ES6 tagged templates.
        In tagged templates, the function takes the template object.

        The template object contains the raw and cooked template strings,
        so when parsing the tagged templates, we need to tokenize the raw and cooked strings.
        While tagged templates require the both strings, the template literal only requires
        the cooked strings. So when tokenizing under the template literal context,
        we only builds the cooked strings.

        As per ES6 spec, the template objects for the same raw strings are shared in the same realm.
        The template objects is cached. And every time we evaluate the same tagged templates,
        the same (cached) template objects are used.
        Since the spec freezes this template objects completely,
        we cannot attach some properties to it.
        So we can say that it behaves as if the template objects are the primitive values (like JSString).
        Since we cannot attach properties, the only way to test the identity of the template object is comparing. (===)
        As the result, when there is no reference to the template object, we can garbage collect it
        because the user has no way to test that the newly created template object does not equal
        to the already collected template object.

        So, to implement tagged templates, we implement the following components.

        1. JSTemplateRegistryKey
        It holds the template registry key and it does not exposed to users.
        TemplateRegistryKey holds the vector of raw and cooked strings with the pre-computed hash value.
        When obtaining the template object for the (statically, a.k.a. at the parsing time) given raw string vectors,
        we use this JSTemplateRegistryKey as a key to the map and look up the template object from
        TemplateRegistry.
        JSTemplateRegistryKey is created at the bytecode compiling time and
        stored in the CodeBlock as like as JSString content values.

        2. TemplateRegistry
        This manages the cached template objects.
        It holds the weak map (JSTemplateRegistryKey -> the template object).
        The template object is weakly referenced.
        So if there is no reference to the template object,
        the template object is automatically GC-ed.
        When looking up the template object, it searches the cached template object.
        If it is found, it is returned to the users.
        If there is no cached template objects, it creates the new template object and
        stores it with the given template registry key.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addTemplateRegistryKeyConstant):
        (JSC::BytecodeGenerator::emitGetTemplateObject):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::TaggedTemplateNode::emitBytecode):
        (JSC::TemplateLiteralNode::emitBytecode): Deleted.
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createTaggedTemplate):
        (JSC::ASTBuilder::createTemplateLiteral): Deleted.
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::setCode):
        (JSC::Lexer<T>::parseTemplateLiteral):
        (JSC::Lexer<T>::lex):
        (JSC::Lexer<T>::scanTrailingTemplateString):
        (JSC::Lexer<T>::clear):
        * parser/Lexer.h:
        (JSC::Lexer<T>::makeEmptyIdentifier):
        * parser/NodeConstructors.h:
        (JSC::TaggedTemplateNode::TaggedTemplateNode):
        (JSC::TemplateLiteralNode::TemplateLiteralNode): Deleted.
        * parser/Nodes.h:
        (JSC::TemplateLiteralNode::templateStrings):
        (JSC::TemplateLiteralNode::templateExpressions):
        (JSC::TaggedTemplateNode::templateLiteral):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseTemplateString):
        (JSC::Parser<LexerType>::parseTemplateLiteral):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/Parser.h:
        * parser/ParserArena.h:
        (JSC::IdentifierArena::makeEmptyIdentifier):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createTaggedTemplate):
        (JSC::SyntaxChecker::createTemplateLiteral): Deleted.
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::getTemplateObject):
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::templateRegistry):
        * runtime/JSTemplateRegistryKey.cpp: Added.
        (JSC::JSTemplateRegistryKey::JSTemplateRegistryKey):
        (JSC::JSTemplateRegistryKey::create):
        (JSC::JSTemplateRegistryKey::destroy):
        * runtime/JSTemplateRegistryKey.h: Added.
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorFreeze):
        * runtime/ObjectConstructor.h:
        * runtime/TemplateRegistry.cpp: Added.
        (JSC::TemplateRegistry::TemplateRegistry):
        (JSC::TemplateRegistry::getTemplateObject):
        * runtime/TemplateRegistry.h: Added.
        * runtime/TemplateRegistryKey.h: Added.
        (JSC::TemplateRegistryKey::isDeletedValue):
        (JSC::TemplateRegistryKey::isEmptyValue):
        (JSC::TemplateRegistryKey::hash):
        (JSC::TemplateRegistryKey::rawStrings):
        (JSC::TemplateRegistryKey::cookedStrings):
        (JSC::TemplateRegistryKey::operator==):
        (JSC::TemplateRegistryKey::operator!=):
        (JSC::TemplateRegistryKey::Hasher::hash):
        (JSC::TemplateRegistryKey::Hasher::equal):
        (JSC::TemplateRegistryKey::TemplateRegistryKey):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * tests/stress/tagged-templates-identity.js: Added.
        (shouldBe):
        * tests/stress/tagged-templates-raw-strings.js: Added.
        (shouldBe):
        (tag):
        (testEval):
        * tests/stress/tagged-templates-syntax.js: Added.
        (tag):
        (testSyntax):
        (testSyntaxError):
        * tests/stress/tagged-templates-template-object.js: Added.
        (shouldBe):
        (tag):
        * tests/stress/tagged-templates-this.js: Added.
        (shouldBe):
        (tag):
        * tests/stress/tagged-templates.js: Added.
        (shouldBe):
        (raw):
        (cooked):
        (Counter):

2015-05-13  Ryosuke Niwa  <rniwa@webkit.org>

        REGRESSION(r180595): same-callee profiling no longer works
        https://bugs.webkit.org/show_bug.cgi?id=144787

        Reviewed by Filip Pizlo.

        This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
        always the same JSFunction. This condition doesn't hold when the byte code creates multiple
        JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();

        To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
        added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
        our speculation that the callee is the same. To avoid recompiling the same code for different callee
        objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
        LLint and baseline JIT when multiple callees are observed.

        Tests: stress/create-this-with-callee-variants.js

        * bytecode/BytecodeList.json: Increased the number of operands to 5.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
        (JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
        we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
        operand.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
        match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
        as seenMultipleCalleeObjects() to indicate the polymorphic behavior and/or we've OSR exited here.
        (JSC::JIT::emitSlow_op_create_this):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_create_this): Ditto.
        (JSC::JIT::emitSlow_op_create_this):
        * llint/LowLevelInterpreter32_64.asm:
        (_llint_op_create_this): Ditto.
        * llint/LowLevelInterpreter64.asm:
        (_llint_op_create_this): Ditto.
        * runtime/CommonSlowPaths.cpp:
        (slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
        been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
        * runtime/JSCell.h:
        (JSC::JSCell::seenMultipleCalleeObjects): Added.
        * runtime/WriteBarrier.h:
        (JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
        * tests/stress/create-this-with-callee-variants.js: Added.

2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>

        Clean up some possible RefPtr to PassRefPtr churn
        https://bugs.webkit.org/show_bug.cgi?id=144779

        Reviewed by Darin Adler.

        * runtime/GenericTypedArrayViewInlines.h:
        (JSC::GenericTypedArrayView<Adaptor>::create):
        (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::constructArrayBuffer):
        * runtime/Structure.cpp:
        (JSC::Structure::toStructureShape):
        * runtime/TypedArrayBase.h:
        (JSC::TypedArrayBase::create):
        (JSC::TypedArrayBase::createUninitialized):
        * tools/FunctionOverrides.cpp:
        (JSC::initializeOverrideInfo):
        Release the last use of a RefPtr as it is passed on.

2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>

        ES6: Allow duplicate property names
        https://bugs.webkit.org/show_bug.cgi?id=142895

        Reviewed by Geoffrey Garen.

        Introduce new `op_put_getter_by_id` and `op_put_setter_by_id` opcodes
        that will define a single getter or setter property on an object.

        The existing `op_put_getter_setter` opcode is still preferred for
        putting both a getter and setter at the same time but cannot be used
        for putting an individual getter or setter which is needed in
        some cases.

        Add a new slow path when generating bytecodes for a property list
        with computed properties, as computed properties are the only time
        the list of properties cannot be determined statically.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode):
        - fast path for all constant properties
        - slow but paired getter/setter path if there are no computed properties
        - slow path, individual put operation for every property, if there are computed properties

        * parser/Nodes.h:
        Distinguish a Computed property from a Constant property.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        Distingish Computed and Constant properties.

        (JSC::Parser<LexerType>::parseObjectLiteral):
        When we drop into strict mode it is because we saw a getter
        or setter, so be more explicit.

        (JSC::Parser<LexerType>::parseStrictObjectLiteral):
        Eliminate duplicate property syntax error exception.

        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::getName):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::getName): Deleted.
        No longer used.

        * runtime/JSObject.h:
        (JSC::JSObject::putDirectInternal):
        When updating a property. If the Accessor attribute changed
        update the Structure.

        * runtime/JSObject.cpp:
        (JSC::JSObject::putGetter):
        (JSC::JSObject::putSetter):
        Called by the opcodes, just perform the same operation that
        __defineGetter__ or __defineSetter__ would do.

        (JSC::JSObject::putDirectNonIndexAccessor):
        This transition is now handled in putDirectInternal.

        * runtime/Structure.h:
        Add needed export.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitPutGetterById):
        (JSC::BytecodeGenerator::emitPutSetterById):
        * bytecompiler/BytecodeGenerator.h:
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_put_getter_by_id):
        (JSC::JIT::emit_op_put_setter_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_getter_by_id):
        (JSC::JIT::emit_op_put_setter_by_id):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        New bytecodes. Modelled after existing op_put_getter_setter.

2015-05-13  Filip Pizlo  <fpizlo@apple.com>

        Creating a new blank document in icloud pages causes an AI error: Abstract value (CellBytecodedoubleBoolOther, TOP, TOP) for double node has type outside SpecFullDouble.
        https://bugs.webkit.org/show_bug.cgi?id=144856

        Reviewed by Benjamin Poulain.
        
        First I made fixTypeForRepresentation() print out better diagnostics when it dies.
        
        Then I fixed the bug: Node::convertToIdentityOn(Node*) needs to make sure that when it
        converts to a representation-changing node, it needs to use one of the UseKinds that such
        a node expects. For example, DoubleRep(UntypedUse:) doesn't make sense; it needs to be
        something like DoubleRep(NumberUse:) since it will speculate that the input is a number.

        * dfg/DFGAbstractInterpreter.h:
        (JSC::DFG::AbstractInterpreter::setBuiltInConstant):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::fixTypeForRepresentation):
        * dfg/DFGAbstractValue.h:
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::convertToIdentityOn):
        * tests/stress/cloned-arguments-get-by-val-double-array.js: Added.
        (foo):

2015-05-13  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r184313.
        https://bugs.webkit.org/show_bug.cgi?id=144974

        Introduced an assertion failure in class-syntax-
        declaration.js, class-syntax-expression.js, and object-
        literal-syntax.js (Requested by rniwa on #webkit).

        Reverted changeset:

        "Small refactoring before ES6 Arrow function implementation."
        https://bugs.webkit.org/show_bug.cgi?id=144954
        http://trac.webkit.org/changeset/184313

2015-05-13  Oliver Hunt  <oliver@apple.com>
        Ensure that all the smart pointer types in WTF clear their pointer before deref
        https://bugs.webkit.org/show_bug.cgi?id=143789

        Reviewed by Ryosuke Niwa.

        One of the simpler cases of this in JavaScriptCore. There
        are other cases where we need to guard the derefs but they
        are more complex cases.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::releaseImpl):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::releaseImpl):

2015-05-13  Alexandr Skachkov  <gskachkov@gmail.com>

        Small refactoring before ES6 Arrow function implementation.
        https://bugs.webkit.org/show_bug.cgi?id=144954

        Reviewed by Filip Pizlo.

        * parser/Parser.h:
        * parser/Parser.cpp:

2015-05-13  Filip Pizlo  <fpizlo@apple.com>

        The liveness pruning done by ObjectAllocationSinkingPhase ignores the possibility of an object's bytecode liveness being longer than its DFG liveness
        https://bugs.webkit.org/show_bug.cgi?id=144945

        Reviewed by Michael Saboff.
        
        We were making the mistake of using DFG liveness for object allocation sinking decisions.
        This is wrong. In fact we almost never want to use DFG liveness directly. The only place
        where that makes sense is pruning in DFG AI.
        
        So, I created a CombinedLiveness class that combines the DFG liveness with bytecode
        liveness.
        
        In the process of doing this, I realized that the DFGForAllKills definition of combined
        liveness at block tail was not strictly right; it was using the bytecode liveness at the
        block terminal instead of the union of the bytecode live-at-heads of successor blocks. So,
        I changed DFGForAllKills to work in terms of CombinedLiveness.
        
        This allows me to unskip the test I added in r184260. I also added a new test that tries to
        trigger this bug more directly.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGCombinedLiveness.cpp: Added.
        (JSC::DFG::liveNodesAtHead):
        (JSC::DFG::CombinedLiveness::CombinedLiveness):
        * dfg/DFGCombinedLiveness.h: Added.
        (JSC::DFG::CombinedLiveness::CombinedLiveness):
        * dfg/DFGForAllKills.h:
        (JSC::DFG::forAllKillsInBlock):
        (JSC::DFG::forAllLiveNodesAtTail): Deleted.
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::performSinking):
        (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
        (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
        (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
        * tests/stress/escape-object-in-diamond-then-exit.js: Added.
        * tests/stress/sink-object-past-invalid-check-sneaky.js:

2015-05-13  Ryosuke Niwa  <rniwa@webkit.org>

        I skipped a wrong test in r184270. Fix that.
        The failure is tracked by webkit.org/b/144947.

        * tests/stress/arith-modulo-node-behaviors.js:
        * tests/stress/arith-mul-with-constants.js:

2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>

        Avoid always running some debug code in type profiling
        https://bugs.webkit.org/show_bug.cgi?id=144775

        Reviewed by Daniel Bates.

        * runtime/TypeProfilerLog.cpp:
        (JSC::TypeProfilerLog::processLogEntries):

2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>

        Pass String as reference in more places
        https://bugs.webkit.org/show_bug.cgi?id=144769

        Reviewed by Daniel Bates.

        * debugger/Breakpoint.h:
        (JSC::Breakpoint::Breakpoint):
        * parser/Parser.h:
        (JSC::Parser::setErrorMessage):
        (JSC::Parser::updateErrorWithNameAndMessage):
        * parser/ParserError.h:
        (JSC::ParserError::ParserError):
        * runtime/RegExp.cpp:
        (JSC::RegExpFunctionalTestCollector::outputOneTest):
        * runtime/RegExpObject.cpp:
        (JSC::regExpObjectSourceInternal):
        * runtime/TypeProfiler.cpp:
        (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
        * runtime/TypeProfilerLog.cpp:
        (JSC::TypeProfilerLog::processLogEntries):
        * runtime/TypeProfilerLog.h:
        * tools/FunctionOverrides.cpp:
        (JSC::initializeOverrideInfo):
        * inspector/scripts/codegen/generate_objc_conversion_helpers.py:
        (ObjCConversionHelpersGenerator._generate_enum_from_protocol_string):

        * inspector/scripts/codegen/objc_generator_templates.py:
        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/expected/enum-values.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
        Rebaseline tests after updating the generator.

2015-05-13  Michael Saboff  <msaboff@apple.com>

        com.apple.WebKit.WebContent crashed at JavaScriptCore: JSC::CodeBlock::finalizeUnconditionally
        https://bugs.webkit.org/show_bug.cgi?id=144933

        Changed the RELEASE_ASSERT_NOT_REACHED into an ASSERT.  Added some diagnostic messages to
        help determine the cause for any crash.

        Reviewed by Geoffrey Garen.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finalizeUnconditionally):

2015-05-13  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(r184260): arguments elimination has stopped working because of Check(UntypedUse:) from SSAConversionPhase
        https://bugs.webkit.org/show_bug.cgi?id=144951

        Reviewed by Michael Saboff.
        
        There were two issues here:
        
        - In r184260 we expected a small number of possible use kinds in Check nodes, and
          UntypedUse was not one of them. That seemed like a sensible assumption because we don't
          create Check nodes unless it's to have a check. But, SSAConversionPhase was creating a
          Check that could have UntypedUse. I fixed this. It's cleaner for SSAConversionPhase to
          follow the same idiom as everyone else and not create tautological checks.
        
        - It's clearly not very robust to assume that Checks will not be used tautologically. So,
          this changes how we validate Checks in the escape analyses. We now use willHaveCheck,
          which catches cases that AI would have already marked as unnecessary. It then also uses
          a new helper called alreadyChecked(), which allows us to just ask if the check is
          unnecessary for objects. That's a good fall-back in case AI hadn't run yet.

        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGMayExit.cpp:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * dfg/DFGUseKind.h:
        (JSC::DFG::alreadyChecked):
        * dfg/DFGVarargsForwardingPhase.cpp:

k
2015-05-13  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement String.raw
        https://bugs.webkit.org/show_bug.cgi?id=144330

        Reviewed by Filip Pizlo.

        Implement String.raw. It is intended to be used with tagged-templates syntax.
        To implement ToString abstract operation efficiently,
        we introduce @toString bytecode intrinsic. It emits op_to_string directly.

        * CMakeLists.txt:
        * builtins/StringConstructor.js: Added.
        (raw):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_toString):
        * runtime/CommonIdentifiers.h:
        * runtime/StringConstructor.cpp:
        * tests/stress/string-raw.js: Added.
        (shouldBe):
        (.get shouldBe):
        (Counter):

2015-05-12  Ryosuke Niwa  <rniwa@webkit.org>

        Temporarily disable the test on Windows. The failure is tracked in webkit.org/b/144897.

        * tests/stress/arith-mul-with-constants.js:

2015-05-12  Filip Pizlo  <fpizlo@apple.com>

        js/dom/stack-trace.html fails with eager compilation
        https://bugs.webkit.org/show_bug.cgi?id=144853

        Reviewed by Benjamin Poulain.
        
        All of our escape analyses were mishandling Check(). They were assuming that this is a
        non-escaping operation. But, if we do for example a Check(Int32:@x) and @x is an escape
        candidate, then we need to do something: if we eliminate or sink @x, then the check no
        longer makes any sense since a phantom allocation has no type. This will make us forget
        that this operation would have exited. This was causing us to not call a valueOf method in
        js/dom/stack-trace.html with eager compilation enabled, because it was doing something like
        +o where o had a valueOf method, and o was otherwise sinkable.
        
        This changes our escape analyses to basically pretend that any Check() that isn't obviously
        unnecessary is an escape. We don't have to be super careful here. Most checks will be
        completely eliminated by constant-folding. If that doesn't run in time, then the most
        common check we will see is CellUse. So, we just recognize some very obvious check kinds
        that we know would have passed, and for all of the rest we just assume that it's an escape.
        
        This was super tricky to test. The obvious way to test it is to use +o like
        stack-trace.html, except that doing so relies on the fact that we still haven't implemented
        the optimal behavior for op_to_number. So, I take four approaches in testing this patch:
        
        1) Use +o. These will test what we want it to test for now, but at some point in the future
           these tests will just be a good sanity-check that our op_to_number implementation is
           right.
        
        2) Do fancy control flow tricks to fool the profiling into thinking that some arithmetic
           operation always sees integers even though we eventually feed it an object and that
           object is a sink candidate.
        
        3) Introduce a new jsc.cpp intrinsic called isInt32() which returns true if the incoming
           value is an int32. This intrinsic is required to be implemented by DFG by
           unconditionally speculating that the input is int32. This allows us to write much more
           targetted tests of the underlying issue.
        
        4) I made a version of stack-trace.html that runs in run-jsc-stress-tests, so that we can
           get regression test coverage of this test in eager mode.

        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        * dfg/DFGVarargsForwardingPhase.cpp:
        * ftl/FTLExitValue.cpp:
        (JSC::FTL::ExitValue::dumpInContext):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileFTLOSRExit):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionIsInt32):
        * runtime/Intrinsic.h:
        * tests/stress/sink-arguments-past-invalid-check-dfg.js: Added.
        * tests/stress/sink-arguments-past-invalid-check-int32-dfg.js: Added.
        * tests/stress/sink-arguments-past-invalid-check-int32.js: Added.
        * tests/stress/sink-arguments-past-invalid-check-sneakier.js: Added.
        * tests/stress/sink-arguments-past-invalid-check.js: Added.
        * tests/stress/sink-function-past-invalid-check-sneakier.js: Added.
        * tests/stress/sink-function-past-invalid-check-sneaky.js: Added.
        * tests/stress/sink-object-past-invalid-check-int32.js: Added.
        * tests/stress/sink-object-past-invalid-check-sneakier.js: Added.
        * tests/stress/sink-object-past-invalid-check-sneaky.js: Added.
        * tests/stress/sink-object-past-invalid-check.js: Added.

2015-05-12  Benjamin Poulain  <benjamin@webkit.org>

        Fix the iteration count of arith-modulo-node-behaviors.js

        * tests/stress/arith-modulo-node-behaviors.js:
        No need for big numbers for the real testing.

2015-05-12  Mark Lam  <mark.lam@apple.com>

        Windows: Cannot use HANDLE from GetCurrentThread() to get the CONTEXT of another thread.
        https://bugs.webkit.org/show_bug.cgi?id=144924

        Reviewed by Alex Christensen.

        The present stack scanning code in the Windows port is expecting that the
        GetCurrentThread() API will provide a unique HANDLE for each thread.  The code
        then saves and later uses that HANDLE with GetThreadContext() to get the
        runtime state of the target thread from the GC thread.  According to
        https://msdn.microsoft.com/en-us/library/windows/desktop/ms683182(v=vs.85).aspx,
        GetCurrentThread() does not provide this unique HANDLE that we expect:

            "The function cannot be used by one thread to create a handle that can
            be used by other threads to refer to the first thread. The handle is
            always interpreted as referring to the thread that is using it. A
            thread can create a "real" handle to itself that can be used by other
            threads, or inherited by other processes, by specifying the pseudo
            handle as the source handle in a call to the DuplicateHandle function."

        As a result of this, GetCurrentThread() always returns the same HANDLE value, and
        we end up never scanning the stacks of other threads because we wrongly think that
        they are all equal (in identity) to the scanning thread.  This, in turn, results
        in crashes due to objects that are incorrectly collected.

        The fix is to call DuplicateHandle() to create a HANDLE that we can use.  The
        MachineThreads::Thread class already accurately tracks the period of time when
        we need that HANDLE for the VM.  Hence, the life-cycle of the HANDLE can be tied
        to the life-cycle of the MachineThreads::Thread object for the corresponding thread.

        * heap/MachineStackMarker.cpp:
        (JSC::getCurrentPlatformThread):
        (JSC::MachineThreads::Thread::Thread):
        (JSC::MachineThreads::Thread::~Thread):
        (JSC::MachineThreads::Thread::suspend):
        (JSC::MachineThreads::Thread::resume):
        (JSC::MachineThreads::Thread::getRegisters):

2015-05-12  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Make the NegZero backward propagated flags of ArithMod stricter
        https://bugs.webkit.org/show_bug.cgi?id=144897

        Reviewed by Geoffrey Garen.

        The NegZero flags of ArithMod were the same as ArithDiv: both children were
        marked as needing to handle NegativeZero.

        Lucky for us, ArithMod is quite a bit different than ArithDiv.

        First, the sign of the result is completely independent from
        the sign of the divisor. A zero on the divisor always produces a NaN.
        That's great, we can remove the NodeBytecodeNeedsNegZero
        from the flags propagated to child2.

        Second, the sign of the result is always the same as the sign of
        the dividend. A dividend of zero produces a zero of same sign
        unless the divisor is zero (in which case the result is NaN).
        This is great too: we can just pass the flags we got into
        ArithMod.

        With those two out of the way, we can make a faster version of ArithRound
        for Kraken's oscillator. Since we no longer care about negative zero,
        rounding becomes cast<int32>(value + 0.5). This gives ~3% faster runtime
        on the benchmark.

        Unfortunatelly, most of the time is spent in FTL and the same optimization
        does not apply well just yet: rdar://problem/20904149.

        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        Never add NodeBytecodeNeedsNegZero unless needed by the users of this node.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithRound):
        Faster Math.round() when negative zero is not important.

        * tests/stress/arith-modulo-node-behaviors.js: Added.
        (moduloWithNegativeZeroDividend):
        (moduloWithUnusedNegativeZeroDividend):
        (moduloWithNegativeZeroDivisor):

2015-05-12  Mark Lam  <mark.lam@apple.com>

        Refactor MachineStackMarker.cpp so that it's easier to reason about MachineThreads::Thread.
        https://bugs.webkit.org/show_bug.cgi?id=144925

        Reviewed by Michael Saboff.

        Currently, the code in MachineStackMarker.cpp is written as a bunch of functions that
        operate on the platformThread value in the MachineThreads::Thread struct.  Instead, we
        can apply better OO encapsulation and convert all these functions into methods of the
        MachineThreads::Thread struct.

        This will also make it easier to reason about the fix for
        https://bugs.webkit.org/show_bug.cgi?id=144924 later.

        * heap/MachineStackMarker.cpp:
        (JSC::getCurrentPlatformThread):
        (JSC::MachineThreads::Thread::createForCurrentThread):
        (JSC::MachineThreads::Thread::operator!=):
        (JSC::MachineThreads::Thread::operator==):
        (JSC::MachineThreads::addCurrentThread):
        (JSC::MachineThreads::removeThreadIfFound):
        (JSC::MachineThreads::Thread::suspend):
        (JSC::MachineThreads::Thread::resume):
        (JSC::MachineThreads::Thread::getRegisters):
        (JSC::MachineThreads::Thread::Registers::stackPointer):
        (JSC::MachineThreads::Thread::freeRegisters):
        (JSC::MachineThreads::Thread::captureStack):
        (JSC::MachineThreads::tryCopyOtherThreadStack):
        (JSC::MachineThreads::tryCopyOtherThreadStacks):
        (JSC::equalThread): Deleted.
        (JSC::suspendThread): Deleted.
        (JSC::resumeThread): Deleted.
        (JSC::getPlatformThreadRegisters): Deleted.
        (JSC::otherThreadStackPointer): Deleted.
        (JSC::freePlatformThreadRegisters): Deleted.
        (JSC::otherThreadStack): Deleted.

2015-05-12  Ryosuke Niwa  <rniwa@webkit.org>

        Array.slice should have a fast path like Array.splice
        https://bugs.webkit.org/show_bug.cgi?id=144901

        Reviewed by Geoffrey Garen.

        Add a fast memcpy path to Array.prototype.slice as done for Array.prototype.splice.
        In Kraken, this appears to be 30% win on stanford-crypto-ccm and 10% win on stanford-crypto-pbkdf2.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSlice):
        * runtime/JSArray.cpp:
        (JSC::JSArray::fastSlice): Added.
        * runtime/JSArray.h:

2015-05-11  Filip Pizlo  <fpizlo@apple.com>

        OSR availability analysis would be more scalable (and correct) if it did more liveness pruning
        https://bugs.webkit.org/show_bug.cgi?id=143078

        Reviewed by Andreas Kling.
        
        In https://bugs.webkit.org/show_bug.cgi?id=144883, we found an example of where liveness
        pruning is actually necessary. Well, not quite: we just need to prune out keys from the
        heap availability map where the base node doesn't dominate the point where we are asking
        for availability. If we don't do this, then eventually the IR gets corrupt because we'll
        insert PutHints that reference the base node in places where the base node doesn't
        dominate. But if we're going to do any pruning, then it makes sense to prune by bytecode
        liveness. This is the strongest possible pruning we can do, and it should be sound. We
        shouldn't have a node available for a virtual register if that register is live and the
        node doesn't dominate.
        
        Making this work meant reusing the prune-to-liveness algorithm from the FTL backend. So, I
        abstracted this a bit better. You can now availabilityMap.pruneByLiveness(graph, origin).

        * dfg/DFGAvailabilityMap.cpp:
        (JSC::DFG::AvailabilityMap::pruneHeap):
        (JSC::DFG::AvailabilityMap::pruneByLiveness):
        (JSC::DFG::AvailabilityMap::prune): Deleted.
        * dfg/DFGAvailabilityMap.h:
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
        * tests/stress/liveness-pruning-needed-for-osr-availability.js: Added. This is a proper regression test.
        * tests/stress/liveness-pruning-needed-for-osr-availability-eager.js: Added. This is the original reduced test case, requires eager-no-cjit to fail prior to this changeset.

2015-05-12  Gabor Loki  <loki@webkit.org>

        Workaround for Cortex-A53 erratum 843419
        https://bugs.webkit.org/show_bug.cgi?id=144680

        Reviewed by Michael Saboff.

        This patch is about to give simple workaround for Cortex-A53 erratum 843419.
        It inserts nops after ADRP instruction to avoid wrong address accesses.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::adrp):
        (JSC::ARM64Assembler::nopCortexA53Fix843419):

2015-05-11  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r184009.
        https://bugs.webkit.org/show_bug.cgi?id=144900

        Caused crashes on inspector tests (Requested by ap on
        #webkit).

        Reverted changeset:

        "MapDataImpl::add() shouldn't do the same hash lookup twice."
        https://bugs.webkit.org/show_bug.cgi?id=144759
        http://trac.webkit.org/changeset/184009

2015-05-11  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r184123.
        https://bugs.webkit.org/show_bug.cgi?id=144899

        Seems to have introduced flaky crashes in many JS tests
        (Requested by rniwa on #webkit).

        Reverted changeset:

        "REGRESSION(r180595): same-callee profiling no longer works"
        https://bugs.webkit.org/show_bug.cgi?id=144787
        http://trac.webkit.org/changeset/184123

2015-05-11  Brent Fulgham  <bfulgham@apple.com>

        [Win] Move Windows build target to Windows 7 (or newer)
        https://bugs.webkit.org/show_bug.cgi?id=144890
        <rdar://problem/20707307>

        Reviewed by Anders Carlsson.

        Update linked SDK and minimal Windows level to be compatible with
        Windows 7 or newer.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj:
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
        * JavaScriptCore.vcxproj/jsc/jsc.vcxproj:
        * JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj:
        * JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.vcxproj:
        * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncher.vcxproj:
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
        * JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj:
        * config.h:

2015-05-08  Filip Pizlo  <fpizlo@apple.com>

        CPS rethreading phase's flush detector flushes way too many SetLocals
        https://bugs.webkit.org/show_bug.cgi?id=144819

        Reviewed by Geoffrey Garen.
        
        After probably unrelated changes, this eventually caused some arguments elimination to stop
        working because it would cause more SetLocals to turn into PutStacks. But it was a bug for
        a long time. Basically, we don't want the children of a SetLocal to be flushed. Flushing is
        meant to only affect the SetLocal itself.
        
        This is a speed-up on Octane/earley.

        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):

2015-05-11  Filip Pizlo  <fpizlo@apple.com>

        gmail and google maps fail to load with eager compilation: Failed to insert inline cache for varargs call (specifically, CallForwardVarargs) because we thought the size would be 250 but it ended up being 262 prior to compaction.
        https://bugs.webkit.org/show_bug.cgi?id=144854

        Reviewed by Oliver Hunt.
        
        This is easy: just lift the threshold. Also remove the need for some duplicate thresholds.
        It used to be that Construct required less code, but that's not the case for now.

        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfCallForwardVarargs):
        (JSC::FTL::sizeOfConstructVarargs):
        (JSC::FTL::sizeOfConstructForwardVarargs):

2015-05-11  Ryosuke Niwa  <rniwa@webkit.org>

        REGRESSION(r180595): same-callee profiling no longer works
        https://bugs.webkit.org/show_bug.cgi?id=144787

        Reviewed by Michael Saboff.

        This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
        always the same JSFunction. This condition doesn't hold when the byte code creates multiple
        JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();

        To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
        added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
        our speculation that the callee is the same. To avoid recompiling the same code for different callee
        objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
        LLint and baseline JIT when multiple callees are observed.

        Tests: stress/create-this-with-callee-variants.js

        * bytecode/BytecodeList.json: Increased the number of operands to 5.
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset): op_create_this uses 2nd (constructor) and 4th (callee cache)
        operands.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
        (JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
        we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
        operand.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
        match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
        as seenMultipleCalleeObjects() to indicate the polymorphic behavior.
        (JSC::JIT::emitSlow_op_create_this):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_create_this): Ditto.
        (JSC::JIT::emitSlow_op_create_this):
        * llint/LowLevelInterpreter32_64.asm:
        (_llint_op_create_this): Ditto.
        * llint/LowLevelInterpreter64.asm:
        (_llint_op_create_this): Ditto.
        * runtime/CommonSlowPaths.cpp:
        (slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
        been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
        * runtime/JSCell.h:
        (JSC::JSCell::seenMultipleCalleeObjects): Added.
        * runtime/WriteBarrier.h:
        (JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
        * tests/stress/create-this-with-callee-variants.js: Added.

2015-05-11  Andreas Kling  <akling@apple.com>

        PropertyNameArray should use a Vector when there are few entries.
        <https://webkit.org/b/144874>

        Reviewed by Geoffrey Garen.

        Bring back an optimization that was lost in the for-in refactoring.
        PropertyNameArray now holds a Vector<AtomicStringImpl*> until there are
        enough (20) entries to justify converting to a HashSet for contains().

        Also inlined the code while we're here, since it has so few clients and
        the call overhead adds up.

        ~5% progression on Kraken/json-stringify-tinderbox.

        * runtime/PropertyNameArray.cpp: Removed.
        * runtime/PropertyNameArray.h:
        (JSC::PropertyNameArray::canAddKnownUniqueForStructure):
        (JSC::PropertyNameArray::add):
        (JSC::PropertyNameArray::addKnownUnique):

2015-05-11  Matt Baker  <mattbaker@apple.com>

        Web Inspector: REGRESSION (r175203): No profile information is shown in Inspector
        https://bugs.webkit.org/show_bug.cgi?id=144808

        Reviewed by Darin Adler.

        Since a profile can be started after a timeline recording has already begun, we can't assume a zero start time.
        The start time for the root node's call entry should be based on the stopwatch used by the ProfileGenerator.

        * profiler/Profile.cpp:
        (JSC::Profile::create):
        (JSC::Profile::Profile):
        * profiler/Profile.h:
        * profiler/ProfileGenerator.cpp:
        (JSC::ProfileGenerator::ProfileGenerator):
        (JSC::AddParentForConsoleStartFunctor::operator()):

2015-05-11  Basile Clement  <basile_clement@apple.com>

        Unreviewed, remove unintended change.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2015-05-11  Filip Pizlo  <fpizlo@apple.com>

        Make it easy to enable eager/non-concurrent JIT compilation
        https://bugs.webkit.org/show_bug.cgi?id=144877

        Reviewed by Michael Saboff.

        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:

2015-05-10  Filip Pizlo  <fpizlo@apple.com>

        We shouldn't promote LoadVarargs to a sequence of GetStacks and PutStacks if doing so would exceed the LoadVarargs' limit
        https://bugs.webkit.org/show_bug.cgi?id=144851

        Reviewed by Michael Saboff.
        
        LoadVarargs loads arguments from some object and puts them on the stack. The region of
        stack is controlled by a bunch of meta-data, including InlineCallFrame. InlineCallFrame
        shouldn't really be edited after ByteCodeParser, so we cannot convert LoadVarargs to
        something that uses more stack than the LoadVarargs wanted to.
        
        This check was missing in the ArgumentsEliminationPhase's LoadVarargs->GetStack+PutStack
        promoter. This is an important promotion rule for performance, and in cases where we are
        compiling truly hot code, the LoadVarargs limit will be at least as big as the length of
        the phantom arguments array that this phase sees. The LoadVarargs limit is based on
        profiling and the phantom arguments array is a proof; in most cases the profiling is more
        conservative.
        
        But, you could write some crazy code where the statically obvious arguments array value is
        bigger than what the profiling would have told you. When this happens, this promotion
        effectively removes a bounds check. This either results in us clobbering a bunch of stack,
        or it means that we never initialize a region of the stack that a later operation will read
        (the uninitialization happens because PutStackSinkingPhase removes PutStacks that appear
        unnecessary, and a GetMyArgumentByVal will claim not to use the region of the stack outside
        the original LoadVarargs limit).
        
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * tests/stress/load-varargs-elimination-bounds-check-barely.js: Added.
        (foo):
        (bar):
        (baz):
        * tests/stress/load-varargs-elimination-bounds-check.js: Added.
        (foo):
        (bar):
        (baz):

2015-05-11  Andreas Kling  <akling@apple.com>

        JSON.stringify shouldn't use generic get() to access Array.length
        <https://webkit.org/b/144847>

        Reviewed by Geoffrey Garen.

        If the value being serialized is a JSArray object, we can downcast and call its
        length() directly instead of doing a generic property lookup.

        0.5% progression on Kraken/json-stringify-tinderbox.

        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Holder::appendNextProperty):

2015-05-10  Andreas Kling  <akling@apple.com>

        Remove unnecessary AtomicStringImpl* hash specification in PropertyNameArray.

        Follow up to r184050 suggested by Darin.

        * runtime/PropertyNameArray.h:

2015-05-10  Andreas Kling  <akling@apple.com>

        Remove unused things from PropertyNameArray.
        <https://webkit.org/b/144834>

        Reviewed by Filip Pizlo.

        PropertyNameArray had a bunch of bells and whistles added to it when for-in iteration
        was refactored and optimized last year. Then more refactoring happened and this class
        doesn't need to ring and toot anymore.

        The RefCountedIdentifierSet class disappears since the JSPropertyNameEnumerator wasn't
        actually using it for anything and we were just wasting time creating these.

        Also made the member functions take AtomicStringImpl* instead of plain StringImpl*.

        * runtime/JSObject.cpp:
        (JSC::JSObject::getPropertyNames):
        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::create):
        (JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator):
        * runtime/JSPropertyNameEnumerator.h:
        * runtime/PropertyNameArray.cpp:
        (JSC::PropertyNameArray::add):
        (JSC::PropertyNameArray::setPreviouslyEnumeratedProperties): Deleted.
        * runtime/PropertyNameArray.h:
        (JSC::PropertyNameArray::PropertyNameArray):
        (JSC::PropertyNameArray::add):
        (JSC::PropertyNameArray::addKnownUnique):
        (JSC::PropertyNameArray::canAddKnownUniqueForStructure):
        (JSC::RefCountedIdentifierSet::contains): Deleted.
        (JSC::RefCountedIdentifierSet::size): Deleted.
        (JSC::RefCountedIdentifierSet::add): Deleted.
        (JSC::PropertyNameArray::identifierSet): Deleted.
        (JSC::PropertyNameArray::numCacheableSlots): Deleted.
        (JSC::PropertyNameArray::setNumCacheableSlotsForObject): Deleted.
        (JSC::PropertyNameArray::setBaseObject): Deleted.
        (JSC::PropertyNameArray::setPreviouslyEnumeratedLength): Deleted.

2015-05-09  Yoav Weiss  <yoav@yoav.ws>

        Remove the PICTURE_SIZES build flag
        https://bugs.webkit.org/show_bug.cgi?id=144679

        Reviewed by Benjamin Poulain.

        Removed the PICTURE_SIZES build time flag.

        * Configurations/FeatureDefines.xcconfig:

2015-05-08  Filip Pizlo  <fpizlo@apple.com>

        Extend the SaneChain optimization to Contiguous arrays
        https://bugs.webkit.org/show_bug.cgi?id=144664

        Reviewed by Mark Lam.
        
        Previously if you loaded from a hole, you'd either have to take slow path for the array
        load (which means C++ calls and prototype chain walks) or you'd exit (if you hadn't
        gathered the necessary profiling yet). But that's unnecessary if we know that the
        prototype chain is sane - i.e. has no indexed properties. Then we can just return
        Undefined for the hole.
        
        Making this change requires setting more watchpoints on the array prototype chain. But
        that hit a horrible bug: ArrayPrototype still uses the static lookup tables and builds
        itself up lazily. This means that this increased the number of recompilations we'd get
        due to the array prototype chain being built up.
        
        So, this change also removes the laziness and static tables from ArrayPrototype.
        
        But to make that change, I also had to add a helper for eagerly building up a prototype
        that has builtin functions.

        * CMakeLists.txt:
        * DerivedSources.make:
        * dfg/DFGArrayMode.h:
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::ArrayPrototype::getOwnPropertySlot): Deleted.
        * runtime/ArrayPrototype.h:
        * runtime/JSObject.h:

2015-05-08  Michael Saboff  <msaboff@apple.com>

        Creating a large MarkedBlock sometimes results in more than one cell in the block
        https://bugs.webkit.org/show_bug.cgi?id=144815

        Reviewed by Mark Lam.

        Large MarkedBlocks should have one and only one cell.  Changed the calculation of
        m_endAtom for large blocks to use the location of the first cell + 1.  This
        assures that large blocks only have one cell.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::MarkedBlock):

2015-05-08  Oliver Hunt  <oliver@apple.com>

        MapDataImpl::add() shouldn't do the same hash lookup twice.
        https://bugs.webkit.org/show_bug.cgi?id=144759

        Reviewed by Gavin Barraclough.

        We don't actually need to do a double lookup here, all we need to
        do is update the index to point to the correct m_size.

        * runtime/MapDataInlines.h:
        (JSC::JSIterator>::add):

2015-05-08  Andreas Kling  <akling@apple.com>

        Micro-optimize JSON serialization of string primitives.
        <https://webkit.org/b/144800>

        Reviewed by Sam Weinig.

        Don't use the out-of-line JSValue::getString() to grab at string primitives
        in serialization. Just check if it's a JSString and then downcast to grab at
        the WTF::String inside.

        2% progression on Kraken/json-stringify-tinderbox.

        * runtime/JSONObject.cpp:
        (JSC::Stringifier::appendStringifiedValue):

2015-05-08  Andreas Kling  <akling@apple.com>

        Optimize serialization of quoted JSON strings.
        <https://webkit.org/b/144754>

        Reviewed by Darin Adler.

        Optimized the serialization of quoted strings into JSON by moving the logic into
        StringBuilder so it can make smarter decisions about buffering.

        12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ObjectPatternNode::toString): Use the new StringBuilder API.

        * runtime/JSONObject.h:
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Holder::appendNextProperty):
        (JSC::appendStringToStringBuilder): Deleted.
        (JSC::appendQuotedJSONStringToBuilder): Deleted.
        (JSC::Stringifier::appendQuotedString): Deleted.
        (JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
        to StringBuilder and call that from here.

2015-05-07  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r183961.
        https://bugs.webkit.org/show_bug.cgi?id=144784

        Broke js/dom/JSON-stringify.html (Requested by kling on
        #webkit).

        Reverted changeset:

        "Optimize serialization of quoted JSON strings."
        https://bugs.webkit.org/show_bug.cgi?id=144754
        http://trac.webkit.org/changeset/183961

2015-05-07  Filip Pizlo  <fpizlo@apple.com>

        GC has trouble with pathologically large array allocations
        https://bugs.webkit.org/show_bug.cgi?id=144609

        Reviewed by Geoffrey Garen.

        The bug was that SlotVisitor::copyLater() would return early for oversize blocks (right
        after pinning them), and would skip the accounting. The GC calculates the size of the heap
        in tandem with the scan to save time, and that accounting was part of how the GC would
        know how big the heap was. The GC would then think that oversize copied blocks use no
        memory, and would then mess up its scheduling of the next GC.
        
        Fixing this bug is harder than it seems. When running an eden GC, we figure out the heap
        size by summing the size from the last collection and the size by walking the eden heap.
        But this breaks when we eagerly delete objects that the last collection touched. We can do
        that in one corner case: copied block reallocation. The old block will be deleted from old
        space during the realloc and a new block will be allocated in new space. In order for the
        GC to know that the size of old space actually shrank, we need a field to tell us how much
        such shrinkage could occur. Since this is a very dirty corner case and it only works for
        very particular reasons arising from the special properties of copied space (single owner,
        and the realloc is used in places where the compiler already knows that it cannot register
        allocate a pointer to the old block), I opted for an equally dirty shrinkage counter
        devoted just to this case. It's called bytesRemovedFromOldSpaceDueToReallocation.
        
        To test this, I needed to add an Option to force a particular RAM size in the GC. This
        allows us to write tests that assert that the GC heap size is some value X, without
        worrying about machine-to-machine variations due to GC heuristics changing based on RAM
        size.

        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::CopiedSpace): Initialize the dirty shrinkage counter.
        (JSC::CopiedSpace::tryReallocateOversize): Bump the dirty shrinkage counter.
        * heap/CopiedSpace.h:
        (JSC::CopiedSpace::takeBytesRemovedFromOldSpaceDueToReallocation): Swap out the counter. Used by the GC when it does its accounting.
        * heap/Heap.cpp:
        (JSC::Heap::Heap): Allow the user to force the RAM size.
        (JSC::Heap::updateObjectCounts): Use the dirty shrinkage counter to good effect. Also, make this code less confusing.
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::copyLater): The early return for isOversize() was the bug. We still need to report these bytes as live. Otherwise the GC doesn't know that it owns this memory.
        * jsc.cpp: Add size measuring hooks to write the largeish test.
        (GlobalObject::finishCreation):
        (functionGCAndSweep):
        (functionFullGC):
        (functionEdenGC):
        (functionHeapSize):
        * runtime/Options.h:
        * tests/stress/new-array-storage-array-with-size.js: Fix this so that it actually allocates ArrayStorage arrays and tests the thing it was supposed to test.
        * tests/stress/new-largeish-contiguous-array-with-size.js: Added. This tests what the other test accidentally started testing, but does so without running your system out of memory.
        (foo):
        (test):

2015-05-07  Saam Barati  <saambarati1@gmail.com>

        Global functions should be initialized as JSFunctions in byte code
        https://bugs.webkit.org/show_bug.cgi?id=144178

        Reviewed by Geoffrey Garen.

        This patch makes the initialization of global functions more explicit by
        moving initialization into bytecode. It also prepares JSC for having ES6
        style lexical scoping because initializing global functions in bytecode
        easily allows global functions to be initialized with the proper scope that
        will have access to global lexical variables. Global lexical variables
        should be visible to global functions but don't live on the global object.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedProgramCodeBlock::visitChildren):
        * bytecode/UnlinkedCodeBlock.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * bytecompiler/BytecodeGenerator.h:
        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::addGlobalVar):
        (JSC::JSGlobalObject::addFunction):
        * runtime/JSGlobalObject.h:

2015-05-07  Benjamin Poulain  <bpoulain@apple.com>

        Fix the x86 32bits build

        * assembler/X86Assembler.h:

2015-05-07  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add basic DFG/FTL support for Math.round
        https://bugs.webkit.org/show_bug.cgi?id=144725

        Reviewed by Filip Pizlo.

        This patch adds two optimizations targeting Math.round():
        -Add a DFGNode ArithRound corresponding to the intrinsic RoundIntrinsic.
        -Change the MacroAssembler to be stricter on how we fail to convert a double
         to ingeter. Previously, any number valued zero would fail, now we only
         fail for -0.

        Since ArithRound speculate it produces int32, the MacroAssembler assembler
        part became necessary because zero is a pretty common output of Math.round()
        and we would OSR exit a lot (and eventually recompile for doubles).

        The implementation itself of the inline Math.round() is exactly the same
        as the C function that exists for Math.round(). We can very likely do better
        but it is a good start known to be valid and inlining alone alread provides
        significant speedups.

        * assembler/X86Assembler.h:
        (JSC::X86Assembler::movmskpd_rr):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
        When we have a zero, get the sign bit out of the double and check if is one.

        I'll look into doing the same improvement for ARM.

        * bytecode/SpeculatedType.cpp:
        (JSC::typeOfDoubleRounding):
        (JSC::typeOfDoubleFRound): Deleted.
        * bytecode/SpeculatedType.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::roundShouldSpeculateInt32):
        (JSC::DFG::Graph::negateShouldSpeculateMachineInt): Deleted.
        * dfg/DFGNode.h:
        (JSC::DFG::Node::arithNodeFlags):
        (JSC::DFG::Node::hasHeapPrediction):
        (JSC::DFG::Node::hasArithMode):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithRound):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::convertDoubleToInt32):
        (JSC::FTL::LowerDFGToLLVM::compileDoubleAsInt32):
        (JSC::FTL::LowerDFGToLLVM::compileArithRound):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::ceil64):
        * jit/ThunkGenerators.cpp:
        * runtime/MathCommon.cpp:
        * runtime/MathCommon.h:
        * runtime/MathObject.cpp:
        (JSC::mathProtoFuncRound):
        * tests/stress/math-round-basics.js: Added.
        (mathRoundOnIntegers):
        (mathRoundOnDoubles):
        (mathRoundOnBooleans):
        (uselessMathRound):
        (mathRoundWithOverflow):
        (mathRoundConsumedAsDouble):
        (mathRoundDoesNotCareAboutMinusZero):
        (mathRoundNoArguments):
        (mathRoundTooManyArguments):
        (testMathRoundOnConstants):
        (mathRoundStructTransition):
        (Math.round):

2015-05-07  Saam Barati  <saambarati1@gmail.com>

        exceptionFuzz tests should explicitly initialize the exceptionFuzz boolean in JavaScript code through a function in jsc.cpp
        https://bugs.webkit.org/show_bug.cgi?id=144753

        Reviewed by Mark Lam.

        This allows the BytecodeGenerator to freely emit startup code that "may"
        throw exceptions without worrying that this startup code will trigger
        the exceptionFuzz exception. The exceptionFuzz counter will only begin
        ticking when the 'enableExceptionFuzz' function is explicitly called in 
        the exceptionFuzz tests.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionEnableExceptionFuzz):
        * tests/exceptionFuzz/3d-cube.js:
        * tests/exceptionFuzz/date-format-xparb.js:
        * tests/exceptionFuzz/earley-boyer.js:

2015-05-07  Andreas Kling  <akling@apple.com>

        Optimize serialization of quoted JSON strings.
        <https://webkit.org/b/144754>

        Reviewed by Darin Adler.

        Optimized the serialization of quoted strings into JSON by moving the logic into
        StringBuilder so it can make smarter decisions about buffering.

        12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ObjectPatternNode::toString): Use the new StringBuilder API.

        * runtime/JSONObject.h:
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Holder::appendNextProperty):
        (JSC::appendStringToStringBuilder): Deleted.
        (JSC::appendQuotedJSONStringToBuilder): Deleted.
        (JSC::Stringifier::appendQuotedString): Deleted.
        (JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
        to StringBuilder and call that from here.

2015-05-07  Yusuke Suzuki  <utatane.tea@gmail.com>

        FunctionCallBracketNode should store the base value to the temporary when subscript has assignment
        https://bugs.webkit.org/show_bug.cgi?id=144678

        Reviewed by Geoffrey Garen.

        Currently, FunctionCallBracketNode directly use the RegisterID returned by emitNode.
        But if the base part is the local register and the subscript part has assignment to it, the base result is accidentally rewritten.

        function t() { var ok = {null: function () { } }; ok[ok = null](); }
        t();  // Should not throw error.

        This patch takes care about `subscriptHasAssignment`.
        By using `emitNodeForLeftHandSide`, when there's assignment to local variables in RHS,
        it correctly moves the LHS value to a temporary register.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionCallBracketNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::makeFunctionCallNode):
        * parser/NodeConstructors.h:
        (JSC::FunctionCallBracketNode::FunctionCallBracketNode):
        * parser/Nodes.h:
        * tests/stress/assignment-in-function-call-bracket-node.js: Added.
        (shouldBe):
        (shouldBe.):

2015-05-07  Basile Clement  <basile_clement@apple.com>

        Unreviewed, add missing braces on a single-line if that got expanded in r183939

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::buildExitArguments):

2015-05-05  Myles C. Maxfield  <mmaxfield@apple.com>

        Revert "Introducing the Platform Abstraction Layer (PAL)"
        https://bugs.webkit.org/show_bug.cgi?id=144751

        Unreviewed.

        PAL should be a new target inside WebCore, rather than a top-level folder.

        * Configurations/FeatureDefines.xcconfig: Updated

2015-05-07  Basile Clement  <basile_clement@apple.com>

        Dumping OSR ExitValue should expand materializations only once
        https://bugs.webkit.org/show_bug.cgi?id=144694

        Reviewed by Filip Pizlo.

        Currently, dumping OSR exit values will print the full materialization
        information each time it is encountered. We change it to print only a
        brief description (only the materialization's address), and print the
        whole set of materializations later on.

        This makes the dump less confusing (less likely to think that two
        instances of the same materialization are different), and will be a
        necessary change if/when we support materialization cycles.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLExitValue.cpp:
        (JSC::FTL::ExitValue::dumpInContext):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::buildExitArguments):

2015-05-07  Andreas Kling  <akling@apple.com>

        Worker threads leak WeakBlocks (as seen on leaks bot)
        <https://webkit.org/b/144721>
        <rdar://problem/20848288>

        Reviewed by Darin Adler.

        Nuke any remaining empty WeakBlocks when the Heap is being torn down.
        Trying to peek into these blocks after the VM is dead would be a bug anyway.

        This fixes a ~750 KB leak seen on the leaks bot.

        * heap/Heap.cpp:
        (JSC::Heap::~Heap):

2015-05-05  Geoffrey Garen  <ggaren@apple.com>

        Don't branch when accessing the callee
        https://bugs.webkit.org/show_bug.cgi?id=144645

        Reviewed by Michael Saboff.

        The branch was added in <http://trac.webkit.org/changeset/81040> without
        explanation.

        kling found it to be a performance problem. See <https://webkit.org/b/144586>.

        Our theory of access to Registers is that it's up to the client to access
        them in the right way. So, let's do that.

        * interpreter/CallFrame.h:
        (JSC::ExecState::callee):
        (JSC::ExecState::setCallee): Call the field object instead of function
        because nothing guarantees that it's a function.
        * interpreter/ProtoCallFrame.h:
        (JSC::ProtoCallFrame::callee):
        (JSC::ProtoCallFrame::setCallee):
        * interpreter/Register.h:
        * runtime/JSObject.h:
        (JSC::Register::object): Just do a cast like our other accessors do.
        (JSC::Register::operator=):
        (JSC::Register::function): Deleted.
        (JSC::Register::withCallee): Deleted.

2015-05-07  Dan Bernstein  <mitz@apple.com>

        <rdar://problem/19317140> [Xcode] Remove usage of AspenFamily.xcconfig in Source/
        https://bugs.webkit.org/show_bug.cgi?id=144727

        Reviewed by Darin Adler.

        * Configurations/Base.xcconfig: Don’t include AspenFamily.xcconfig, and define
        INSTALL_PATH_PREFIX and LD_DYLIB_INSTALL_NAME for the iOS 8.x Simulator.

2015-05-07  Andreas Kling  <akling@apple.com>

        Special-case Int32 values in JSON.stringify().
        <https://webkit.org/b/144731>

        Reviewed by Michael Saboff.

        Add a fast path for serializing Int32 values to JSON. This is far faster than dragging
        simple integers through the full-blown dtoa() machinery.

        ~50% speedup on Kraken/json-stringify-tinderbox.

        * runtime/JSONObject.cpp:
        (JSC::Stringifier::appendStringifiedValue):

2015-05-06  Ryosuke Niwa  <rniwa@webkit.org>

        ToT WebKit crashes while loading ES6 compatibility table
        https://bugs.webkit.org/show_bug.cgi?id=144726

        Reviewed by Filip Pizlo.

        The bug was caused by parseClass superfluously avoiding to build up the string after seeing {.

        Always build the identifier here as it could be a method name.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):

2015-05-05  Filip Pizlo  <fpizlo@apple.com>

        Sane chain and string watchpoints should be set in FixupPhase or the backend rather than WatchpointCollectionPhase
        https://bugs.webkit.org/show_bug.cgi?id=144665

        Reviewed by Michael Saboff.
        
        This is a step towards getting rid of WatchpointCollectionPhase. It's also a step towards
        extending SaneChain to all indexing shapes.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
        (JSC::DFG::FixupPhase::checkArray): Clarify the need for checking the structure. We often forget why we do this instead of always using CheckArray.
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
        * dfg/DFGWatchpointCollectionPhase.cpp:
        (JSC::DFG::WatchpointCollectionPhase::handle): Remove some code.
        (JSC::DFG::WatchpointCollectionPhase::handleStringGetByVal): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileStringCharAt): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.

2015-04-02  Myles C. Maxfield  <mmaxfield@apple.com>

        Introducing the Platform Abstraction Layer (PAL)
        https://bugs.webkit.org/show_bug.cgi?id=143358

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig: Updated

2015-05-06  Andreas Kling  <akling@apple.com>

        Don't allocate a StringImpl for every Number JSValue in JSON.stringify().
        <https://webkit.org/b/144676>

        Reviewed by Darin Adler.

        We were creating a new String for every number JSValue passing through the JSON stringifier.
        These StringImpl allocations were dominating one of the Kraken JSON benchmarks.
        Optimize this by using StringBuilder::appendECMAScriptNumber() which uses a stack buffer
        for the conversion instead.

        13% progression on Kraken/json-stringify-tinderbox.

        * runtime/JSONObject.cpp:
        (JSC::Stringifier::appendStringifiedValue):

2015-05-06  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r183847.
        https://bugs.webkit.org/show_bug.cgi?id=144691

        Caused many assertion failures (Requested by ap on #webkit).

        Reverted changeset:

        "GC has trouble with pathologically large array allocations"
        https://bugs.webkit.org/show_bug.cgi?id=144609
        http://trac.webkit.org/changeset/183847

2015-05-05  Filip Pizlo  <fpizlo@apple.com>

        PutGlobalVar shouldn't have an unconditional store barrier
        https://bugs.webkit.org/show_bug.cgi?id=133104

        Reviewed by Benjamin Poulain.
        
        We don't need a store barrier on PutGlobalVar if the value being stored can be
        speculated to not be a cell.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

2015-05-05  Filip Pizlo  <fpizlo@apple.com>

        CopiedBlock::reportLiveBytes() should be totally cool with oversize blocks
        https://bugs.webkit.org/show_bug.cgi?id=144667

        Reviewed by Andreas Kling.
        
        We are now calling this method for oversize blocks. It had an assertion that indirectly
        implied that the block is not oversize, because it was claiming that the number of live
        bytes should be smaller than the non-oversize-block size.

        * heap/CopiedBlockInlines.h:
        (JSC::CopiedBlock::reportLiveBytes):

2015-05-05  Filip Pizlo  <fpizlo@apple.com>

        GC has trouble with pathologically large array allocations
        https://bugs.webkit.org/show_bug.cgi?id=144609

        Reviewed by Mark Lam.

        * heap/Heap.cpp:
        (JSC::Heap::updateObjectCounts): Make this code less confusing.
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::copyLater): The early return for isOversize() was the bug. We still need to report these bytes as live. Otherwise the GC doesn't know that it owns this memory.
        * jsc.cpp: Add size measuring hooks to write the largeish test.
        (GlobalObject::finishCreation):
        (functionGCAndSweep):
        (functionFullGC):
        (functionEdenGC):
        (functionHeapSize):
        * tests/stress/new-array-storage-array-with-size.js: Fix this so that it actually allocates ArrayStorage arrays and tests the thing it was supposed to test.
        * tests/stress/new-largeish-contiguous-array-with-size.js: Added. This tests what the other test accidentally started testing, but does so without running your system out of memory.
        (foo):
        (test):

2015-05-05  Filip Pizlo  <fpizlo@apple.com>

        FTL SwitchString slow case creates duplicate switch cases
        https://bugs.webkit.org/show_bug.cgi?id=144634

        Reviewed by Geoffrey Garen.
        
        The problem of duplicate switches is sufficiently annoying that I fixed the issue and also
        added mostly-debug-only asserts to catch such issues earlier.

        * bytecode/CallVariant.cpp:
        (JSC::variantListWithVariant): Assertion to prevent similar bugs.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::switchStringRecurse): Assertion to prevent similar bugs.
        (JSC::FTL::LowerDFGToLLVM::switchStringSlow): This is the bug.
        * jit/BinarySwitch.cpp:
        (JSC::BinarySwitch::BinarySwitch): Assertion to prevent similar bugs.
        * jit/Repatch.cpp:
        (JSC::linkPolymorphicCall): Assertion to prevent similar bugs.
        * tests/stress/ftl-switch-string-slow-duplicate-cases.js: Added. This tests the FTL SwitchString bug. It was previously crashing every time.
        (foo):
        (cat):

2015-05-05  Basile Clement  <basile_clement@apple.com>

        Fix debug builds after r183812
        https://bugs.webkit.org/show_bug.cgi?id=144300

        Rubber stamped by Andreas Kling and Filip Pizlo.

        hasObjectMaterializationData() didn't treat MaterializeCreateActivation
        as having materialization data, which was causing an assertion failure when
        sinking CreateActivations on debug builds.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasObjectMaterializationData):

2015-05-04  Basile Clement  <basile_clement@apple.com>

        Allow CreateActivation sinking
        https://bugs.webkit.org/show_bug.cgi?id=144300

        Reviewed by Filip Pizlo.

        This pursues the work started in
        https://bugs.webkit.org/show_bug.cgi?id=144016 to expand the set of
        allocations we are able to sink by allowing sinking of CreateActivation
        node.

        This is achieved by following closely the way NewObject is currently
        sunk: we add a new PhantomCreateActivation node to record the initial
        position of the CreateActivation node, new ClosureVarPLoc promoted heap
        locations to keep track of the variables put in the activation, and a
        new MaterializeCreateActivation node to allocate and populate the sunk
        activation.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::convertToPutClosureVarHint):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToPhantomCreateActivation):
        (JSC::DFG::Node::isActivationAllocation):
        (JSC::DFG::Node::isPhantomActivationAllocation):
        (JSC::DFG::Node::isPhantomAllocation):
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
        (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGPromotedHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGPromotedHeapLocation.h:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validateCPS):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * tests/stress/activation-sink-osrexit.js: Added.
        (bar):
        (foo.set result):
        * tests/stress/activation-sink.js: Added.
        (bar):

2015-05-04  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix stale comment.

        * tests/mozilla/js1_5/Array/regress-101964.js:

2015-05-04  Filip Pizlo  <fpizlo@apple.com>

        Large array shouldn't be slow
        https://bugs.webkit.org/show_bug.cgi?id=144617

        Rubber stamped by Mark Lam.

        * tests/mozilla/js1_5/Array/regress-101964.js: 500ms isn't enough in debug mode. We don't care how long this takes so long as we run it to completion. I've raised the limit much higher.

2015-05-04  Filip Pizlo  <fpizlo@apple.com>

        Large array shouldn't be slow
        https://bugs.webkit.org/show_bug.cgi?id=144617

        Rubber stamped by Mark Lam.

        * tests/mozilla/js1_5/Array/regress-101964.js: Mozilla may have cared about this being fast a decade ago (or more), but we don't care. We've consistently found that an array implementation that punishes this case to get speed on common-case array accesses is better. This should fix some test failures on the bots.

2015-05-04  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r183789.
        https://bugs.webkit.org/show_bug.cgi?id=144620

        Causing flakiness on exceptionFuzz tests locally on 32-bit
        build (Requested by saamyjoon on #webkit).

        Reverted changeset:

        "Global functions should be initialized as JSFunctions in byte
        code"
        https://bugs.webkit.org/show_bug.cgi?id=144178
        http://trac.webkit.org/changeset/183789

2015-05-04  Saam Barati  <saambarati1@gmail.com>

        Global functions should be initialized as JSFunctions in byte code
        https://bugs.webkit.org/show_bug.cgi?id=144178

        Reviewed by Geoffrey Garen.

        This patch makes the initialization of global functions more explicit by
        moving initialization into bytecode. It also prepares JSC for having ES6
        style lexical scoping because initializing global functions in bytecode
        easily allows global functions to be initialized with the proper scope that
        will have access to global lexical variables. Global lexical variables
        should be visible to global functions but don't live on the global object.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedProgramCodeBlock::visitChildren):
        * bytecode/UnlinkedCodeBlock.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * bytecompiler/BytecodeGenerator.h:
        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::addGlobalVar):
        (JSC::JSGlobalObject::addFunction):
        * runtime/JSGlobalObject.h:

2015-05-04  Filip Pizlo  <fpizlo@apple.com>

        Large array shouldn't be slow
        https://bugs.webkit.org/show_bug.cgi?id=144617

        Reviewed by Geoffrey Garen.
        
        Decouple MIN_SPARSE_ARRAY_INDEX, which is the threshold for storing to the sparse map when
        you're already using ArrayStorage mode, from the minimul array length required to use
        ArrayStorage in a new Array(length) allocation.
        
        Lift the array allocation length threshold to something very high. If this works, we'll
        probably remove that threshold entirely.
        
        This is a 27% speed-up on JetStream/hash-map. Because run-jsc-benchmarks still can't run
        JetStream as a discrete suite, this adds hash-map to LongSpider so that we run it somewhere
        for now.

        * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNewArrayWithSize):
        * runtime/ArrayConventions.h:
        * runtime/JSArray.h:
        (JSC::JSArray::create):
        * runtime/JSGlobalObject.h:
        (JSC::constructEmptyArray):
        * tests/stress/new-array-storage-array-with-size.js: Skip this test until we fix https://bugs.webkit.org/show_bug.cgi?id=144609.

2015-05-03  Yusuke Suzuki  <utatane.tea@gmail.com>

        Add backed intrinsics to private functions exposed with private symbols in global object
        https://bugs.webkit.org/show_bug.cgi?id=144545

        Reviewed by Darin Adler.

        Math.abs and Math.floor have ASM intrinsics And it is further accelerated in DFG/FTL layers.
        This patch adds intrinsic to private functions exposed with private symbols in global object,
        @floor and @abs.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalPrivateFuncAbs): Deleted.
        (JSC::globalPrivateFuncFloor): Deleted.
        * runtime/MathObject.cpp:
        * runtime/MathObject.h:
        * tests/stress/array-from-abs-and-floor.js: Added.
        (target1):
        (target2):
        (target3):

2015-05-04  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] ARM related build system cleanup
        https://bugs.webkit.org/show_bug.cgi?id=144566

        Reviewed by Darin Adler.

        * CMakeLists.txt:

2015-05-04  Andreas Kling  <akling@apple.com>

        Optimize WeakBlock's "reap" and "visit" operations.
        <https://webkit.org/b/144585>

        Reviewed by Geoffrey Garen.

        WeakBlock was using Heap::isLive(void*) to determine the liveness of weak pointees.
        That function was really written with conservative roots marking in mind, and will do a bunch
        of sanity and bounds checks.

        For weaks, we know that the pointer will have been a valid cell pointer into a block
        of appropriate cell size, so we can skip a lot of the checks.

        We now keep a pointer to the MarkedBlock in each WeakBlock. That way we no longer have to do
        MarkedBlock::blockFor() for every single cell when iterating.

        Note that a WeakBlock's MarkedBlock pointer becomes null when we detach a logically empty
        WeakBlock from its WeakSet and transfer ownership to Heap. At that point, the block will never
        be pointing to any live cells, and the only operation that will run on the block is sweep().

        Finally, MarkedBlock allows liveness queries in three states: Marked, Retired, and Allocated.
        In Allocated state, all cells are reported as live. This state will reset to Marked on next GC.
        This patch uses that knowledge to avoid branching on the MarkedBlock's state for every cell.

        This is a ~3x speedup of visit() and a ~2x speedup of reap() on Dromaeo/dom-modify, netting
        what looks like a 1% speedup locally.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::MarkedBlock): Pass *this to the WeakSet's ctor.

        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::isMarkedOrNewlyAllocated): Added, stripped-down version of isLive() when the
        block's state is known to be either Marked or Retired.

        (JSC::MarkedBlock::isAllocated): Added, tells WeakBlock it's okay to skip reap/visit since isLive()
        would report that all cells are live anyway.

        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::create):
        (JSC::WeakBlock::WeakBlock): Stash a MarkedBlock* on each WeakBlock.

        (JSC::WeakBlock::visit):
        (JSC::WeakBlock::reap): Optimized these two to avoid a bunch of pointer arithmetic and branches.

        * heap/WeakBlock.h:
        (JSC::WeakBlock::disconnectMarkedBlock): Added.
        * heap/WeakSet.cpp:
        (JSC::WeakSet::sweep): Call the above when removing a WeakBlock from WeakSet and transferring
        ownership to Heap until it can die peacefully.

        (JSC::WeakSet::addAllocator):
        * heap/WeakSet.h:
        (JSC::WeakSet::WeakSet): Give WeakSet a MarkedBlock& for passing on to WeakBlocks.

2015-05-04  Basile Clement  <basile_clement@apple.com>

        Allocation sinking is prohibiting the creation of phis between a Phantom object and its materialization
        https://bugs.webkit.org/show_bug.cgi?id=144587

        Rubber stamped by Filip Pizlo.

        When sinking object allocations, we ensure in
        determineMaterializationPoints that whenever an allocation is
        materialized on a path to a block, it is materialized in all such
        paths. Thus when running the SSA calculator to place Phis in
        placeMaterializationPoints, we can't encounter a situation where some
        Upsilons are referring to a materialization while others are referring
        to the phantom object.

        This replaces the code that was adding a materialization late in
        placeMaterializationPoints to handle that case by an assertion that it
        does not happen, which will make
        https://bugs.webkit.org/show_bug.cgi?id=143073 easier to implement.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):

2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>

        Extending undefined in class syntax should throw a TypeError
        https://bugs.webkit.org/show_bug.cgi?id=144284

        Reviewed by Darin Adler.

        The bug was caused by op_eq_null evaluating to true when compared to undefined.
        Explicitly check op_eq_undefined first to detect the case where we're extending undefined.

        We also had bogus test cases checked in class-syntax-extends.html. This patch also fixes them.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ClassExprNode::emitBytecode):

2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>

        new super should be a syntax error
        https://bugs.webkit.org/show_bug.cgi?id=144282

        Reviewed by Joseph Pecoraro.

        Disallow "new super" as ES6 spec doesn't allow this.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseMemberExpression):

2015-05-04  Saam Barati  <saambarati1@gmail.com>

        JSCallbackObject does not maintain symmetry between accesses for getOwnPropertySlot and put
        https://bugs.webkit.org/show_bug.cgi?id=144265

        Reviewed by Geoffrey Garen.

        JSCallbackObject will defer to a parent's implementation of getOwnPropertySlot
        for a static function if the parent has that property slot. JSCallbackObject::put 
        did not maintain this symmetry of also calling ::put on the parent if the parent 
        has the property. We should ensure that this symmetry exists.

        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::put):
        * API/tests/testapi.c:
        * API/tests/testapi.js:
        (globalStaticFunction2):
        (this.globalStaticFunction2):
        (iAmNotAStaticFunction):
        (this.iAmNotAStaticFunction):

2015-05-04  Andreas Kling  <akling@apple.com>

        Make ExecState::vm() branchless in release builds.
        <https://webkit.org/b/144586>

        Reviewed by Geoffrey Garen.

        Avoid null checking the ExecState's callee() before getting the
        VM from it. The code was already dereferencing it anyway, since we
        know it's not gonna be null.

        * runtime/JSCellInlines.h:
        (JSC::ExecState::vm):

2015-05-04  Basile Clement  <basile_clement@apple.com>

        Object allocation not sinking properly through CheckStructure
        https://bugs.webkit.org/show_bug.cgi?id=144465

        Reviewed by Filip Pizlo.

        Currently, sinking an allocation through a CheckStructure will
        completely ignore all structure checking, which is obviously wrong.

        A CheckStructureImmediate node type was present for that purpose, but
        the CheckStructures were not properly replaced.  This ensures that
        CheckStructure nodes are replaced by CheckStructureImmediate nodes when
        sunk through, and that structure checking happens correctly.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToCheckStructureImmediate): Added.
        (JSC::DFG::Node::hasStructureSet):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
        (JSC::FTL::LowerDFGToLLVM::compileCheckStructureImmediate):
        (JSC::FTL::LowerDFGToLLVM::checkStructure):
        * tests/stress/sink_checkstructure.js: Added.
        (foo):

2015-05-01  Geoffrey Garen  <ggaren@apple.com>

        REGRESSION(r183570): jslib-traverse-jquery is 22% slower
        https://bugs.webkit.org/show_bug.cgi?id=144476

        Reviewed by Sam Weinig.

        jslib-traverse-jquery is now 31% faster than its unregressed baseline.

        The jQuery algorithm for sorting DOM nodes is so pathologically slow that,
        to my knowledge, the topic of how to optimize it is not covered in any
        literature about sorting.

        On the slowest jQuery sorting test -- prevAll -- our new
        Array.prototype.sort, compared to its predecessor, performed 12% fewer
        comparisons and requireed 10X less overhead per comparison. Yet, it was
        slower.

        It was slower because it inadvertantly increased the average cost of the
        comparison function by 2X. jQuery uses compareDocumentPosition to compare
        DOM nodes, and compareDocumentPosition(a, b) is O(N) in the distance
        required to traverse backwards from b to a. In prevAll, we encounter the
        worst case for merge sort of compareDocumentPosition: A long list of DOM
        nodes in mostly reverse order. In this case, merge sort will sequentially
        compareDocumentPosition(a, b), where a is not reachable backwards from
        b, and therefore compareDocumentPosition will traverse the whole sibling
        list.

        The solution is simple enough: Call compareDocumentPosition(b, a) instead.

        This is a pretty silly thing to do, but it is harmless, and jQuery is
        popular, so let's do it.

        We do not risk suffering the same problem in reverse when sorting a long
        list of DOM nodes in forward order. (We still have a 37% speedup on the
        nextAll benchmark.) The reason is that merge sort performs 2X fewer
        comparisons when the list is already sorted, so we can worry less about
        the cost of each comparison.

        A fully principled soultion to this problem would probably do something
        like Python's timsort, which special-cases ordered ranges to perform
        only O(n) comparisons. But that would contradict our original
        goal of just having something simple that works.

        Another option is for elements to keep a compareDocumentPosition cache,
        like a node list cache, which allows you to determine the absolute
        position of a node using a hash lookup. I will leave this as an exercise
        for kling.

        * builtins/Array.prototype.js:
        (sort.merge): Compare in an order that is favorable to a comparator
        that calls compareDocumentPosition.

2015-05-04  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] Fix generate-js-builtins related incremental build issue
        https://bugs.webkit.org/show_bug.cgi?id=144094

        Reviewed by Michael Saboff.

        * CMakeLists.txt: Generated JSCBuiltins.<cpp|h> should depend on Source/JavaScriptCore/builtins directory.
        Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
        * DerivedSources.make:
        Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
        * generate-js-builtins: Accept input files and input directory too.

2015-05-03  Simon Fraser  <simon.fraser@apple.com>

        Make some static data const
        https://bugs.webkit.org/show_bug.cgi?id=144552

        Reviewed by Andreas Kling.
        
        Turn characterSetInfo into const data.

        * yarr/YarrCanonicalizeUCS2.cpp:
        * yarr/YarrCanonicalizeUCS2.h:

2015-05-01  Filip Pizlo  <fpizlo@apple.com>

        TypeOf should be fast
        https://bugs.webkit.org/show_bug.cgi?id=144396

        Reviewed by Geoffrey Garen.
        
        Adds comprehensive support for fast typeof to the optimizing JITs. Calls into the runtime
        are only used for very exotic objects - they must have either the MasqueradesAsUndefined or
        TypeOfShouldCallGetCallData type flags set. All other cases are handled inline.
        
        This means optimizing IsObjectOrNull, IsFunction, and TypeOf - all node types that used to
        rely heavily on C++ calls to fulfill their function.
        
        Because TypeOf is now so fast, we no longer need to do any speculations on this node.
        
        In the FTL, we take this further by querying AI for each branch in the TypeOf decision tree.
        This means that if the TypeOf is dominated by any type checks, we will automatically prune
        out cases that are redundant.
        
        This patch anticipates the addition of SwitchTypeOf or something like that. So, the TypeOf
        code generation is designed to be reusable.
        
        This is a speed-up on most typeof benchmarks. But, it is a slow-down on benchmarks that take
        the exotic call trap hook. That hook is now in a deeper slow path than before.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize): TypeOf was pure all along, but we failed to realize this.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileIsObjectOrNull):
        (JSC::DFG::SpeculativeJIT::compileIsFunction):
        (JSC::DFG::SpeculativeJIT::compileTypeOf):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::blessedBooleanResult):
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
        (JSC::FTL::LowerDFGToLLVM::compileIsFunction):
        (JSC::FTL::LowerDFGToLLVM::compileTypeOf):
        (JSC::FTL::LowerDFGToLLVM::buildTypeOf): Reusable TypeOf building for the FTL.
        (JSC::FTL::LowerDFGToLLVM::isExoticForTypeof):
        * ftl/FTLSwitchCase.h:
        (JSC::FTL::SwitchCase::SwitchCase):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfNotEqual):
        (JSC::AssemblyHelpers::branchIfEqual):
        (JSC::AssemblyHelpers::branchIfNumber):
        (JSC::AssemblyHelpers::branchIfNotNumber):
        (JSC::AssemblyHelpers::branchIfBoolean):
        (JSC::AssemblyHelpers::branchIfNotBoolean):
        (JSC::AssemblyHelpers::boxBooleanPayload):
        (JSC::AssemblyHelpers::boxBoolean):
        (JSC::AssemblyHelpers::emitTypeOf): Reusable TypeOf building for assembly JITs.
        * jit/JITOperations.h:
        * runtime/SmallStrings.h:
        (JSC::SmallStrings::typeString):
        * runtime/TypeofType.cpp: Added.
        (WTF::printInternal):
        * runtime/TypeofType.h: Added.
        * tests/stress/type-of-functions-and-objects.js: Modified this test to give more comprehensive feedback.

2015-05-02  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=144527.

        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::attemptHoist):

2015-05-02  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, add FIXMEs referencing https://bugs.webkit.org/show_bug.cgi?id=144524 and
        https://bugs.webkit.org/show_bug.cgi?id=144525.

        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::attemptHoist):
        * dfg/DFGPhantomInsertionPhase.cpp:

2015-05-02  Yusuke Suzuki  <utatane.tea@gmail.com>

        Static property hashtable should only lookup with non-symbol key
        https://bugs.webkit.org/show_bug.cgi?id=144438

        Reviewed by Darin Adler.

        Static property hashtable compares the Identifier's uid
        with the normal C string without interning it.
        So this comparison is performed in their contents.
        As the result, in this comparison, symbol-ness is not considered.

        So if accidentally the hash collision occur with the symbol and the string
        and they have the same contents, the hash table entry is looked up incorrectly.

        * runtime/Lookup.h:
        (JSC::HashTable::entry):

2015-05-01  Ryosuke Niwa  <rniwa@webkit.org>

        Class syntax should allow string and numeric identifiers for method names
        https://bugs.webkit.org/show_bug.cgi?id=144254

        Reviewed by Darin Adler.

        Added the support for string and numeric identifiers in class syntax.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo): Instead of using ConstructorKind to indicate whether we're
        inside a class or not, use the newly added SuperBinding argument instead. ConstructorKind is now None
        outside a class constructor as it should be.
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass): No longer expects an identifier at the beginning of every class
        element to allow numeric and string method names. For both of those method names, parse it here instead
        of parseFunctionInfo since it doesn't support either type. Also pass in SuperBinding::Needed.
        (JSC::Parser<LexerType>::parsePropertyMethod): Call parseFunctionInfo with SuperBinding::NotNeeded since
        this function is never used to parse a class method.
        (JSC::Parser<LexerType>::parseGetterSetter): Pass in superBinding argument to parseFunctionInfo.
        (JSC::Parser<LexerType>::parsePrimaryExpression): Call parseFunctionInfo with SuperBinding::NotNeeded.
        * parser/Parser.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createProperty):

2015-05-01  Filip Pizlo  <fpizlo@apple.com>

        FTL should use AI more
        https://bugs.webkit.org/show_bug.cgi?id=144500

        Reviewed by Oliver Hunt.
        
        This makes our type check folding even more comprehensive by ensuring that even if the FTL
        decides to emit some checks, it will still do another query to the abstract interpreter to
        see if the check is necessary. This helps with cases where we decided early on to speculate
        one way, but later proved a more specific type of the value in question, and the constant
        folder didn't catch it.
        
        This also makes it more natural to query the abstract interpreter. For example, if you just
        want the proven type, you can now say provenType(node) or provenType(edge).

        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::alreadyChecked):
        * dfg/DFGArrayMode.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
        (JSC::FTL::LowerDFGToLLVM::compileToThis):
        (JSC::FTL::LowerDFGToLLVM::compileValueAdd):
        (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
        (JSC::FTL::LowerDFGToLLVM::compileArithPow):
        (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
        (JSC::FTL::LowerDFGToLLVM::compileGetById):
        (JSC::FTL::LowerDFGToLLVM::compileCheckArray):
        (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
        (JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
        (JSC::FTL::LowerDFGToLLVM::compileToPrimitive):
        (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
        (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
        (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
        (JSC::FTL::LowerDFGToLLVM::compileSwitch):
        (JSC::FTL::LowerDFGToLLVM::compileIsBoolean):
        (JSC::FTL::LowerDFGToLLVM::compileIsNumber):
        (JSC::FTL::LowerDFGToLLVM::compileIsString):
        (JSC::FTL::LowerDFGToLLVM::compileIsObject):
        (JSC::FTL::LowerDFGToLLVM::compileInstanceOf):
        (JSC::FTL::LowerDFGToLLVM::numberOrNotCellToInt32):
        (JSC::FTL::LowerDFGToLLVM::baseIndex):
        (JSC::FTL::LowerDFGToLLVM::compareEqObjectOrOtherToObject):
        (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
        (JSC::FTL::LowerDFGToLLVM::boolify):
        (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
        (JSC::FTL::LowerDFGToLLVM::lowInt32):
        (JSC::FTL::LowerDFGToLLVM::lowInt52):
        (JSC::FTL::LowerDFGToLLVM::lowCell):
        (JSC::FTL::LowerDFGToLLVM::lowBoolean):
        (JSC::FTL::LowerDFGToLLVM::lowDouble):
        (JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
        (JSC::FTL::LowerDFGToLLVM::isNotCellOrMisc):
        (JSC::FTL::LowerDFGToLLVM::isNumber):
        (JSC::FTL::LowerDFGToLLVM::isNotNumber):
        (JSC::FTL::LowerDFGToLLVM::isNotCell):
        (JSC::FTL::LowerDFGToLLVM::isCell):
        (JSC::FTL::LowerDFGToLLVM::isNotMisc):
        (JSC::FTL::LowerDFGToLLVM::isMisc):
        (JSC::FTL::LowerDFGToLLVM::isNotBoolean):
        (JSC::FTL::LowerDFGToLLVM::isBoolean):
        (JSC::FTL::LowerDFGToLLVM::isNotOther):
        (JSC::FTL::LowerDFGToLLVM::isOther):
        (JSC::FTL::LowerDFGToLLVM::isProvenValue):
        (JSC::FTL::LowerDFGToLLVM::isObject):
        (JSC::FTL::LowerDFGToLLVM::isNotObject):
        (JSC::FTL::LowerDFGToLLVM::isNotString):
        (JSC::FTL::LowerDFGToLLVM::isString):
        (JSC::FTL::LowerDFGToLLVM::isFunction):
        (JSC::FTL::LowerDFGToLLVM::isNotFunction):
        (JSC::FTL::LowerDFGToLLVM::speculateObjectOrOther):
        (JSC::FTL::LowerDFGToLLVM::speculateStringObjectForStructureID):
        (JSC::FTL::LowerDFGToLLVM::speculateNotStringVar):
        (JSC::FTL::LowerDFGToLLVM::abstractValue):
        (JSC::FTL::LowerDFGToLLVM::provenType):
        (JSC::FTL::LowerDFGToLLVM::provenValue):
        (JSC::FTL::LowerDFGToLLVM::abstractStructure):

2015-05-01  Martin Robinson  <mrobinson@igalia.com>

        USE(...) macro should expect unprefixed variables
        https://bugs.webkit.org/show_bug.cgi?id=144454

        Reviewed by Daniel Bates.

        * CMakeLists.txt: Replace all occurrences WTF_USE with USE.

2015-05-01  Jordan Harband  <ljharb@gmail.com>

        String#startsWith/endsWith/includes don't handle Infinity position/endPosition args correctly
        https://bugs.webkit.org/show_bug.cgi?id=144314

        Reviewed by Darin Adler.

        Fixing handling of Infinity position args, per
        https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
        https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
        https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith

        * runtime/StringPrototype.cpp:
        (JSC::clampInt32):
        (JSC::stringProtoFuncStartsWith):
        (JSC::stringProtoFuncEndsWith):
        (JSC::stringProtoFuncIncludes):

2015-05-01  Basile Clement  <basile_clement@apple.com>

        Math.abs() returns negative
        https://bugs.webkit.org/show_bug.cgi?id=137827

        Reviewed by Michael Saboff.

        Math.abs() on doubles was mistakenly assumed by the DFG AI to be the
        identity function.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * tests/stress/math-abs-positive.js: Added, was previously failing.
        (foo):

2015-05-01  Basile Clement  <basile_clement@apple.com>

        Function allocation sinking shouldn't be performed on singleton functions
        https://bugs.webkit.org/show_bug.cgi?id=144166

        Reviewed by Geoffrey Garen.

        Function allocations usually are free of any other side effects, but
        this is not the case for allocations performed while the underlying
        FunctionExecutable is still a singleton (as this allogation will fire
        watchpoints invalidating code that depends on it being a singleton).
        As the object allocation sinking phase assumes object allocation is
        free of side-effects, sinking these allocations is not correct.

        This also means that when materializing a function allocation on OSR
        exit, that function's executable will never be a singleton, and we don't have
        to worry about its watchpoint, allowing us to use
        JSFunction::createWithInvalidatedRellocationWatchpoint instead of
        JSFunction::create.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):

2015-04-30  Jon Davis  <jond@apple.com>

        Web Inspector: console should show an icon for console.info() messages
        https://bugs.webkit.org/show_bug.cgi?id=18530

        Reviewed by Timothy Hatcher.

        * inspector/ConsoleMessage.cpp:
        (Inspector::messageLevelValue):
        * inspector/protocol/Console.json:
        * runtime/ConsoleClient.cpp:
        (JSC::appendMessagePrefix):
        * runtime/ConsolePrototype.cpp:
        (JSC::ConsolePrototype::finishCreation):
        (JSC::consoleProtoFuncInfo):
        * runtime/ConsoleTypes.h:

2015-04-30  Filip Pizlo  <fpizlo@apple.com>

        Move all of the branchIs<type> helpers from SpeculativeJIT into AssemblyHelpers
        https://bugs.webkit.org/show_bug.cgi?id=144462

        Reviewed by Geoffrey Garen and Mark Lam.
        
        At some point we started adding representation-agnostic helpers for doing common type tests.
        We added some in SpeculativeJIT, and then some in AssemblyHelpers. Prior to this change,
        they had overlapping powers, though SpeculativeJIT was a bit better.
        
        This removes SpeculativeJIT's helpers and strengthens AssemblyHelpers' helpers. This is
        better because now all of these helpers can be used in all of the assembly-based JITs, not
        just the DFG. It also settles on what I find to be a slightly better naming convention.
        For example where we previously would have said branchIsString, now we say
        branchIfString. Similarly, branchNotString becomes branchIfNotString.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
        (JSC::DFG::SpeculativeJIT::compileInstanceOf):
        (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
        (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
        (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
        (JSC::DFG::SpeculativeJIT::speculateObject):
        (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
        (JSC::DFG::SpeculativeJIT::speculateString):
        (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
        (JSC::DFG::SpeculativeJIT::speculateNotCell):
        (JSC::DFG::SpeculativeJIT::speculateOther):
        (JSC::DFG::SpeculativeJIT::emitSwitchChar):
        (JSC::DFG::SpeculativeJIT::emitSwitchString):
        (JSC::DFG::SpeculativeJIT::branchIsObject): Deleted.
        (JSC::DFG::SpeculativeJIT::branchNotObject): Deleted.
        (JSC::DFG::SpeculativeJIT::branchIsString): Deleted.
        (JSC::DFG::SpeculativeJIT::branchNotString): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
        (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
        (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
        (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::writeBarrier):
        (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
        (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
        (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
        (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfCell):
        (JSC::AssemblyHelpers::branchIfOther):
        (JSC::AssemblyHelpers::branchIfNotOther):
        (JSC::AssemblyHelpers::branchIfObject):
        (JSC::AssemblyHelpers::branchIfNotObject):
        (JSC::AssemblyHelpers::branchIfType):
        (JSC::AssemblyHelpers::branchIfNotType):
        (JSC::AssemblyHelpers::branchIfString):
        (JSC::AssemblyHelpers::branchIfNotString):
        (JSC::AssemblyHelpers::branchIfSymbol):
        (JSC::AssemblyHelpers::branchIfNotSymbol):
        (JSC::AssemblyHelpers::branchIfFunction):
        (JSC::AssemblyHelpers::branchIfNotFunction):
        (JSC::AssemblyHelpers::branchIfEmpty):
        (JSC::AssemblyHelpers::branchIsEmpty): Deleted.
        (JSC::AssemblyHelpers::branchIfCellNotObject): Deleted.
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitScopedArgumentsGetByVal):

2015-04-30  Filip Pizlo  <fpizlo@apple.com>

        js/regress/is-string-fold-tricky.html and js/regress/is-string-fold.html are crashing
        https://bugs.webkit.org/show_bug.cgi?id=144463

        Reviewed by Benjamin Poulain.
        
        Fixup phase was super cleverly folding an IsString(@x) when @x is predicted SpecString
        into a Check(String:@x) followed by JSConstant(true). Then in these tests the
        ValueAdd(IsString(@x), @stuff) would try to turn this into an integer add by cleverly
        converting the boolean into an integer. But as part of doing that, it would try to
        short-circuit any profiling by leveraging the fact that the IsString is now a constant,
        and it would try to figure out if the addition might overflow. Part of that logic
        involved checking if the immediate is either a boolean or a sufficiently small integer.
        But: it would check if it's a sufficiently small integer before checking if it was a
        boolean, so it would try to call asNumber() on the boolean.
        
        All of this cleverness was very deliberate, but apparently the @stuff + booleanConstant
        case was previously never hit until I wrote these tests, and so we never knew that
        calling asNumber() on a boolean was wrong.
        
        The fix is super simple: the expression should just check for boolean first.
        
        This bug was benign in release builds. JSValue::asNumber() on a boolean would return
        garbage, and that's OK, since we'd take the boolean case anyway.

        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):

2015-04-30  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, add a FIXME comment referencing https://bugs.webkit.org/show_bug.cgi?id=144458.

        * jit/JITOperations.cpp:

2015-04-30  Filip Pizlo  <fpizlo@apple.com>

        Add a comment clarifying the behavior and semantics of getCallData/getConstructData, in
        particular that they cannot change their minds and may be called from compiler threads.

        Rubber stamped by Geoffrey Garen.

        * runtime/JSCell.h:

2015-04-29  Filip Pizlo  <fpizlo@apple.com>

        DFG Is<Blah> versions of TypeOf should fold based on proven input type
        https://bugs.webkit.org/show_bug.cgi?id=144409

        Reviewed by Geoffrey Garen.
        
        We were missing some obvious folding opportunities here. I don't know how this affects real
        code, but in general, we like to ensure that our constant folding is comprehensive. So this
        is more about placating my static analysis OCD than anything else.
        
        I added a bunch of speed/correctness tests for this in LayoutTests/js/regress.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2015-04-30  Yusuke Suzuki  <utatane.tea@gmail.com>

        Use the default hash value for Symbolized StringImpl
        https://bugs.webkit.org/show_bug.cgi?id=144347

        Reviewed by Darin Adler.

        Before this patch, symbolized StringImpl* has a special hash value
        to avoid the hash collision with the other normal StringImpl*.
        I guess that it is introduced when private symbols are introduced.
        However, it prevents using symbolized StringImpl* in the other place
        For example, using it as WTFString cause a problem because of its special hash value.

        When only using private symbols, they are not exposed to the outside of JSC,
        so we can handle it carefully. But now, it's extended to symbols.
        So I think storing a special hash value in StringImpl* causes an error.

        To avoid this, I propose using the usual hash value in symbolized StringImpl*.
        And to provide significantly different hash value when using it as symbol,
        store the additional hash value in symbolized StringImpl*. It is used when
        the hash value is required by IdentifierRepHash.

        * runtime/Identifier.h:
        (JSC::IdentifierRepHash::hash):
        * runtime/Lookup.h:
        (JSC::HashTable::entry):
        * runtime/PropertyMapHashTable.h:
        (JSC::PropertyTable::find):
        (JSC::PropertyTable::get):
        * runtime/Structure.cpp:
        (JSC::PropertyTable::checkConsistency):

2015-04-29  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove RageConvert array conversion
        https://bugs.webkit.org/show_bug.cgi?id=144433

        Reviewed by Filip Pizlo.

        RageConvert was causing a subtle bug that was hitting the Kraken crypto tests
        pretty hard:
        -The indexing types shows that the array access varies between Int32 and DoubleArray.
        -ArrayMode::fromObserved() decided to use the most generic type: DoubleArray.
         An Arrayify node would convert the Int32 to that type.
        -Somewhere, a GetByVal or PutByVal would have the flag NodeBytecodeUsesAsInt. That
         node would use RageConvert instead of Convert.
        -The Arrayify for that GetByVal with RageConvert would not convert the array to
         Contiguous.
        -All the following array access that do not have the flag NodeBytecodeUsesAsInt would
         now expect a DoubleArray and always get a Contiguous Array. The CheckStructure
         fail systematically and we never get to run the later code.

        Getting rid of RageConvert fixes the problem and does not seems to have any
        negative side effect on other benchmarks.

        The improvments on Kraken are:
            -stanford-crypto-aes: definitely 1.0915x faster.
            -stanford-crypto-pbkdf2: definitely 1.2446x faster.
            -stanford-crypto-sha256-iterative: definitely 1.0544x faster.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::refine):
        (JSC::DFG::arrayConversionToString):
        * dfg/DFGArrayMode.h:
        * dfg/DFGArrayifySlowPathGenerator.h:
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
        * runtime/JSObject.cpp:
        (JSC::JSObject::convertDoubleToContiguous):
        (JSC::JSObject::ensureContiguousSlow):
        (JSC::JSObject::genericConvertDoubleToContiguous): Deleted.
        (JSC::JSObject::rageConvertDoubleToContiguous): Deleted.
        (JSC::JSObject::rageEnsureContiguousSlow): Deleted.
        * runtime/JSObject.h:
        (JSC::JSObject::rageEnsureContiguous): Deleted.

2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>

        Gracefully handle missing auto pause key on remote inspector setup
        https://bugs.webkit.org/show_bug.cgi?id=144411

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::receivedSetupMessage):

2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>

        NodeList has issues with Symbol and empty string
        https://bugs.webkit.org/show_bug.cgi?id=144310

        Reviewed by Darin Adler.

        * runtime/PropertyName.h:
        (JSC::PropertyName::isSymbol):
        Helper to check if the PropertyName is a string or symbol property.

2015-04-29  Alex Christensen  <achristensen@webkit.org>

        Fix non-cygwin incremental builds on Windows.
        https://bugs.webkit.org/show_bug.cgi?id=143264

        Reviewed by Brent Fulgham.

        * generate-js-builtins:
        Remove stale headers before calling os.rename to replace them.

2015-04-29  Filip Pizlo  <fpizlo@apple.com>

        JSTypeInfo should have an inline type flag to indicate of getCallData() has been overridden
        https://bugs.webkit.org/show_bug.cgi?id=144397

        Reviewed by Andreas Kling.
        
        Add the flag to JSTypeInfo. It's an inline flag so that it's fast to query. Slap the flag on
        callback objects and internal functions. Modify the TypeOf operation to use this flag to avoid
        making a getCallData() call if it isn't necessary.

        * API/JSCallbackObject.h:
        * runtime/InternalFunction.h:
        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::typeOfShouldCallGetCallData):
        * runtime/Operations.cpp:
        (JSC::jsTypeStringForValue):
        * tests/stress/type-of-functions-and-objects.js: Added.
        (foo):
        (bar):
        (baz):
        (fuzz):
        (expect):
        (test):

2015-04-28  Geoffrey Garen  <ggaren@apple.com>

        It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
        https://bugs.webkit.org/show_bug.cgi?id=144013

        Reviewed by Mark Lam.

        This patch implements Array.prototype.sort in JavaScript, removing the
        C++ implementations. It is simpler and less error-prone to express our
        operations in JavaScript, which provides memory safety, exception safety,
        and recursion safety.

        The performance result is mixed, but net positive in my opinion. It's
        difficult to enumerate all the results, since we used to have so many
        different sorting modes, and there are lots of different data patterns
        across which you might want to measure sorting. Suffice it to say:

            (*) The benchmarks we track are faster or unchanged.

            (*) Sorting random input using a comparator -- which we think is
            common -- is 3X faster.

            (*) Sorting random input in a non-array object -- which jQuery does
            -- is 4X faster.

            (*) Sorting random input in a compact array of integers using a
            trivial pattern-matchable comparator is 2X *slower*.

        * builtins/Array.prototype.js:
        (sort.min):
        (sort.stringComparator):
        (sort.compactSparse): Special case compaction for sparse arrays because
        we don't want to hang when sorting new Array(BIG).

        (sort.compact):
        (sort.merge):
        (sort.mergeSort): Use merge sort because it's a reasonably efficient
        stable sort. We have evidence that some sites depend on stable sort,
        even though the ES6 spec does not mandate it. (See
        <http://trac.webkit.org/changeset/33967>.)

        This is a textbook implementation of merge sort with three optimizations:

            (1) Use iteration instead of recursion;

            (2) Use array subscripting instead of array copying in order to
            create logical sub-lists without creating physical sub-lists;

            (3) Swap src and dst at each iteration instead of copying src into
            dst, and only copy src into the subject array at the end if src is
            not the subject array.

        (sort.inflate):
        (sort.comparatorSort):
        (sort): Sort in JavaScript for the win.

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
        names so we can use helper functions.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::isNumericCompareFunction): Deleted.
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
        (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionNode::emitBytecode): We don't do this special casing based
        on pattern matching anymore. This was mainly an optimization to avoid 
        the overhead of calling from C++ to JS, which we now avoid by
        sorting in JS.

        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::pushTempSortVector): Deleted.
        (JSC::Heap::popTempSortVector): Deleted.
        (JSC::Heap::visitTempSortVectors): Deleted.
        * heap/Heap.h: We don't have temp sort vectors anymore because we sort
        in JavaScript using a normal JavaScript array for our temporary storage.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
        helper functions.

        * runtime/ArrayPrototype.cpp:
        (JSC::isNumericCompareFunction): Deleted.
        (JSC::attemptFastSort): Deleted.
        (JSC::performSlowSort): Deleted.
        (JSC::arrayProtoFuncSort): Deleted.

        * runtime/CommonIdentifiers.h: New strings used by sort.

        * runtime/JSArray.cpp:
        (JSC::compareNumbersForQSortWithInt32): Deleted.
        (JSC::compareNumbersForQSortWithDouble): Deleted.
        (JSC::compareNumbersForQSort): Deleted.
        (JSC::compareByStringPairForQSort): Deleted.
        (JSC::JSArray::sortNumericVector): Deleted.
        (JSC::JSArray::sortNumeric): Deleted.
        (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
        (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
        (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
        (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
        (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
        (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
        (JSC::JSArray::sortCompactedVector): Deleted.
        (JSC::JSArray::sort): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
        (JSC::JSArray::sortVector): Deleted.
        (JSC::JSArray::compactForSorting): Deleted.
        * runtime/JSArray.h:

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation): Provide some builtins used
        by sort.

2015-04-29  Mark Lam  <mark.lam@apple.com>

        Safari WebKit crash when loading Google Spreadsheet.
        https://bugs.webkit.org/show_bug.cgi?id=144020

        Reviewed by Filip Pizlo.

        The bug is that the object allocation sinking phase did not account for a case
        where a property of a sunken object is only initialized on one path and not
        another.  As a result, on the path where the property is not initialized, we'll
        encounter an Upsilon with a BottomValue (which is not allowed by definition).

        The fix is to use a JSConstant(undefined) as the bottom value instead (of
        BottomValue).  If the property is uninitialized, it should still be accessible
        and have the value undefined.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
        * tests/stress/object-allocation-sinking-with-uninitialized-property-on-one-path.js: Added.
        (foo):
        (foo2):

2015-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
        https://bugs.webkit.org/show_bug.cgi?id=144257

        Reviewed by Darin Adler.

        SHA1 is used to calculate CodeBlockHash.
        To calculate hash value, we pass the source code UTF-8 CString to SHA1::addBytes.
        However, the source code can contain null character.
        So when performing `strlen` on the source code's CString, it returns the incorrect length.
        In SHA1::addBytes, there's assertion `input.length() == strlen(string)` and it fails.

        In the template-literal-syntax.js, we perform `eval` with the script contains "\0".
        As the result, `strlen(string)` accidentally shortened by the contained "\0", and assertion fails.

        CString will be changed not to contain a null-character[1]. However, inserting the assertion here
        is not correct. Because

        1. If CString should not contain a null character, this should be asserted in CString side instead of SHA1::addBytes.
        2. If CString can contain a null character, this assertion becomes incorrect.

        So this patch just drops the assertion.

        In the current implementation, we once convert the entire source code to the newly allocated
        UTF-8 string and pass it to the SHA1 processing. However, this is memory consuming.
        Ideally, we should stream the decoded bytes into the SHA1 processing iteratively.
        We'll implement it in the separate patch[2].

        [1]: https://bugs.webkit.org/show_bug.cgi?id=144339
        [2]: https://bugs.webkit.org/show_bug.cgi?id=144263

        * tests/stress/eval-script-contains-null-character.js: Added.
        (shouldBe):
        (test):
        * tests/stress/template-literal-line-terminators.js:
        * tests/stress/template-literal-syntax.js:
        * tests/stress/template-literal.js:

2015-04-29  Filip Pizlo  <fpizlo@apple.com>

        Evict IsEnvironmentRecord from inline type flags
        https://bugs.webkit.org/show_bug.cgi?id=144398

        Reviewed by Mark Lam and Michael Saboff.
        
        In https://bugs.webkit.org/show_bug.cgi?id=144397, we'll need an extra bit in the inline
        type flags. This change picks the least important inline type flag - IsEnvironmentRecord -
        and evicts it into the out-of-line type flags. This change has no performance implications
        because we never even accessed IsEnvironmentRecord via the StructureIDBlob. The only place
        where we access it at all is in String.prototype.repeat, and there we already load the
        structure anyway.

        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::implementsHasInstance):
        (JSC::TypeInfo::structureIsImmortal):
        (JSC::TypeInfo::isEnvironmentRecord):

2015-04-29  Darin Adler  <darin@apple.com>

        [ES6] Implement Unicode code point escapes
        https://bugs.webkit.org/show_bug.cgi?id=144377

        Reviewed by Antti Koivisto.

        * parser/Lexer.cpp: Moved the UnicodeHexValue class in here from
        the header. Made it a non-member class so it doesn't need to be part
        of a template. Made it use UChar32 instead of int for the value to
        make it clearer what goes into this class.
        (JSC::ParsedUnicodeEscapeValue::isIncomplete): Added. Replaces the
        old type() function.
        (JSC::Lexer<CharacterType>::parseUnicodeEscape): Renamed from
        parseFourDigitUnicodeHex and added support for code point escapes.
        (JSC::isLatin1): Added an overload for UChar32.
        (JSC::isIdentStart): Changed this to take UChar32; no caller tries
        to call it with a UChar, so no need to overload for that type for now.
        (JSC::isNonLatin1IdentPart): Changed argument type to UChar32 for clarity.
        Also added FIXME about a subtle ES6 change that we might want to make later.
        (JSC::isIdentPart): Changed this to take UChar32; no caller tries
        to call it with a UChar, so no need to overload for that type for now.
        (JSC::isIdentPartIncludingEscapeTemplate): Made this a template so that we
        don't need to repeat the code twice. Added code to handle code point escapes.
        (JSC::isIdentPartIncludingEscape): Call the template instead of having the
        code in line.
        (JSC::Lexer<CharacterType>::recordUnicodeCodePoint): Added.
        (JSC::Lexer<CharacterType>::parseIdentifierSlowCase): Made small tweaks and
        updated to call parseUnicodeEscape instead of parseFourDigitUnicodeHex.
        (JSC::Lexer<CharacterType>::parseComplexEscape): Call parseUnicodeEscape
        instead of parseFourDigitUnicodeHex. Move the code to handle "\u" before
        the code that handles the escapes, since the code point escape code now
        consumes characters while parsing rather than peeking ahead. Test case
        covers this: Symptom would be that "\u{" would evaluate to "u" instead of
        giving a syntax error.

        * parser/Lexer.h: Updated for above changes.

        * runtime/StringConstructor.cpp:
        (JSC::stringFromCodePoint): Use ICU's UCHAR_MAX_VALUE instead of writing
        out 0x10FFFF; clearer this way.

2015-04-29  Martin Robinson  <mrobinson@igalia.com>

        [CMake] [GTK] Organize and clean up unused CMake variables
        https://bugs.webkit.org/show_bug.cgi?id=144364

        Reviewed by Gyuyoung Kim.

        * PlatformGTK.cmake: Add variables specific to this project.

2015-04-28  Filip Pizlo  <fpizlo@apple.com>

        TypeOf should return SpecStringIdent and the DFG should know this
        https://bugs.webkit.org/show_bug.cgi?id=144376

        Reviewed by Andreas Kling.
        
        Make TypeOf return atomic strings. That's a simple change in SmallStrings.
        
        Make the DFG know this and use it for optimization. This makes Switch(TypeOf) a bit less
        bad.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::setType):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::setType):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * runtime/SmallStrings.cpp:
        (JSC::SmallStrings::initialize):
        * tests/stress/switch-typeof-indirect.js: Added.
        (bar):
        (foo):
        (test):
        * tests/stress/switch-typeof-slightly-indirect.js: Added.
        (foo):
        (test):
        * tests/stress/switch-typeof.js: Added.
        (foo):
        (test):

2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION(181868): Windows Live SkyDrive cannot open an excel file
        https://bugs.webkit.org/show_bug.cgi?id=144373

        Reviewed by Darin Adler.

        Revert r181868 as it caused a failure on live.com. We can try
        re-enabling this exception after we make idl attributes configurable,
        which may have prevented this particular failure.

        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncDefineGetter):
        (JSC::objectProtoFuncDefineSetter):

2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>

        Deadlock on applications using JSContext on non-main thread
        https://bugs.webkit.org/show_bug.cgi?id=144370

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::singleton):
        Prevent a possible deadlock by assuming we can synchronously
        run something on the main queue at this time.

2015-04-28  Filip Pizlo  <fpizlo@apple.com>

        FTL should fully support Switch (it currently lacks the SwitchString variant)
        https://bugs.webkit.org/show_bug.cgi?id=144348

        Reviewed by Benjamin Poulain.
        
        This adds SwitchString support to the FTL. This is already tested by switch microbenchmarks
        in LayoutTests/js/regress.

        * dfg/DFGCommon.cpp:
        (JSC::DFG::stringLessThan):
        * dfg/DFGCommon.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileSwitch):
        (JSC::FTL::LowerDFGToLLVM::switchString):
        (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::StringSwitchCase):
        (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::operator<):
        (JSC::FTL::LowerDFGToLLVM::CharacterCase::CharacterCase):
        (JSC::FTL::LowerDFGToLLVM::CharacterCase::operator<):
        (JSC::FTL::LowerDFGToLLVM::switchStringRecurse):
        (JSC::FTL::LowerDFGToLLVM::switchStringSlow):
        (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::check):
        * ftl/FTLOutput.h:
        * ftl/FTLWeight.h:
        (JSC::FTL::Weight::inverse):
        * jit/JITOperations.h:

2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>

        Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
        https://bugs.webkit.org/show_bug.cgi?id=144304

        Reviewed by Geoffrey Garen.

        * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
        ENABLE_LLINT_C_LOOP, disabled by default.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.

2015-04-28  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r183514.
        https://bugs.webkit.org/show_bug.cgi?id=144359

        It broke cloop test bots (Requested by mcatanzaro on #webkit).

        Reverted changeset:

        "Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT"
        https://bugs.webkit.org/show_bug.cgi?id=144304
        http://trac.webkit.org/changeset/183514

2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>

        Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
        https://bugs.webkit.org/show_bug.cgi?id=144304

        Reviewed by Geoffrey Garen.

        * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
        ENABLE_LLINT_C_LOOP, disabled by default.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.

2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>

        Fix common typo "targetting" => "targeting"
        https://bugs.webkit.org/show_bug.cgi?id=144349

        Reviewed by Daniel Bates.

        * bytecode/ExecutionCounter.h:

2015-04-28  Yusuke Suzuki  <utatane.tea@gmail.com>

        Update the features.json for WeakSet, WeakMap, Template literals, Tagged templates
        https://bugs.webkit.org/show_bug.cgi?id=144328

        Reviewed by Andreas Kling.

        Update the status of ES6 features.

        * features.json:

2015-04-28  Filip Pizlo  <fpizlo@apple.com>

        DFG should not use or preserve Phantoms during transformations
        https://bugs.webkit.org/show_bug.cgi?id=143736

        Reviewed by Geoffrey Garen.
        
        Since http://trac.webkit.org/changeset/183207 and http://trac.webkit.org/changeset/183406, it is
        no longer necessary to preserve Phantoms during transformations. They are still useful just
        before FixupPhase to support backwards propagation analyses. They are still inserted late in the
        game in the DFG backend. But transformations don't need to worry about them. Inside a basic
        block, we can be sure that so long as the IR pinpoints the place where the value becomes
        available in a bytecode register (using MovHint) and so long as there is a SetLocal anytime some
        other block would need the value (either for OSR or for DFG execution), then we don't need any
        liveness markers.
        
        So, this removes any places where we inserted Phantoms just for liveness during transformation
        and it replaces convertToPhantom() with remove(), which just converts the node to a Check. A
        Check node only keeps its children so long as those children have checks.
        
        The fact that we no longer convertToPhantom() means that we have to be more careful when
        constant-folding GetLocal. Previously we would convertToPhantom() and use the fact that
        Phantom(Phi) was a valid construct. It's not valid anymore. So, when constant folding encounters
        a GetLocal it needs to insert a PhantomLocal directly. This allows us to simplify
        Graph::convertToConstant() a bit. Luckily, none of the other users of this method would see
        GetLocals.
        
        The only Phantom-like cruft left over after this patch is:
        
        - Phantoms before FixupPhase. I kind of like these. It means that before FixupPhase, we can do
          backwards analyses and rely on the fact that the users of a node in DFG IR are a superset of
          the users of the original local's live range in bytecode. This is essential for supporting our
          BackwardsPropagationPhase, which is an important optimization for things like asm.js.
        
        - PhantomLocals and GetLocals being NodeMustGenerate. See discussion in
          https://bugs.webkit.org/show_bug.cgi?id=144086. It appears that this is not as evil as the
          alternatives. The best long-term plan is to simply ditch the ThreadedCPS IR entirely and have
          the DFG use SSA. For now, so long as any new DFG optimizations we add are block-local and
          treat GetLocal/SetLocal conservatively, this should all be sound.
        
        This change should be perf-neutral although it does reduce the total work that the compiler
        does.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAdjacencyList.h:
        (JSC::DFG::AdjacencyList::justChecks):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGBasicBlock.cpp:
        (JSC::DFG::BasicBlock::replaceTerminal):
        * dfg/DFGBasicBlock.h:
        (JSC::DFG::BasicBlock::findTerminal):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
        (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::CPSRethreadingPhase):
        (JSC::DFG::CPSRethreadingPhase::clearVariables):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
        * dfg/DFGCSEPhase.cpp:
        * dfg/DFGCleanUpPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.cpp.
        (JSC::DFG::CleanUpPhase::CleanUpPhase):
        (JSC::DFG::CleanUpPhase::run):
        (JSC::DFG::performCleanUp):
        (JSC::DFG::PhantomRemovalPhase::PhantomRemovalPhase): Deleted.
        (JSC::DFG::PhantomRemovalPhase::run): Deleted.
        (JSC::DFG::performPhantomRemoval): Deleted.
        * dfg/DFGCleanUpPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.h.
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
        (JSC::DFG::ConstantFoldingPhase::fixUpsilons):
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::run):
        (JSC::DFG::DCEPhase::fixupBlock):
        (JSC::DFG::DCEPhase::cleanVariables):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupBlock):
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::convertStringAddUse):
        (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
        (JSC::DFG::FixupPhase::checkArray):
        (JSC::DFG::FixupPhase::fixIntConvertingEdge):
        (JSC::DFG::FixupPhase::fixIntOrBooleanEdge):
        (JSC::DFG::FixupPhase::fixDoubleOrBooleanEdge):
        (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
        (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
        (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
        (JSC::DFG::FixupPhase::addRequiredPhantom): Deleted.
        (JSC::DFG::FixupPhase::addPhantomsIfNecessary): Deleted.
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::convertToConstant):
        (JSC::DFG::Graph::mergeRelevantToOSR): Deleted.
        * dfg/DFGGraph.h:
        * dfg/DFGInsertionSet.h:
        (JSC::DFG::InsertionSet::insertCheck):
        * dfg/DFGIntegerCheckCombiningPhase.cpp:
        (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::attemptHoist):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::remove):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::replaceWith):
        (JSC::DFG::Node::convertToPhantom): Deleted.
        (JSC::DFG::Node::convertToCheck): Deleted.
        (JSC::DFG::Node::willHaveCodeGenOrOSR): Deleted.
        * dfg/DFGNodeFlags.h:
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        * dfg/DFGPhantomCanonicalizationPhase.cpp: Removed.
        * dfg/DFGPhantomCanonicalizationPhase.h: Removed.
        * dfg/DFGPhantomRemovalPhase.cpp: Removed.
        * dfg/DFGPhantomRemovalPhase.h: Removed.
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPutStackSinkingPhase.cpp:
        * dfg/DFGResurrectionForValidationPhase.cpp: Removed.
        * dfg/DFGResurrectionForValidationPhase.h: Removed.
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
        * dfg/DFGStoreBarrierElisionPhase.cpp:
        (JSC::DFG::StoreBarrierElisionPhase::elideBarrier):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validate):
        (JSC::DFG::Validate::validateCPS):
        (JSC::DFG::Validate::validateSSA):
        * dfg/DFGVarargsForwardingPhase.cpp:
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileNoOp):
        (JSC::FTL::LowerDFGToLLVM::compilePhantom): Deleted.

2015-04-28  Andreas Kling  <akling@apple.com>

        DFG+FTL should generate efficient code for branching on a string's boolean value.
        <https://webkit.org/b/144317>

        Reviewed by Geoff Garen & Filip Pizlo

        Teach Branch nodes about StringUse and have them generate an efficient zero-length string check
        instead of dropping out to C++ whenever we branch on a string.

        The FTL JIT already handled Branch nodes with StringUse through its use of boolify(), so only
        the DFG JIT gets some new codegen logic in this patch.

        Test: js/regress/branch-on-string-as-boolean.js (~4.5x speedup)

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitStringBranch):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitBranch):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitBranch):

2015-04-28  Filip Pizlo  <fpizlo@apple.com>

        VarargsForwardingPhase should only consider MovHints that have the candidate as a child
        https://bugs.webkit.org/show_bug.cgi?id=144340

        Reviewed by Michael Saboff and Mark Lam.
        
        Since we were considering all MovHints, we'd assume that the CreateDirectArguments or
        CreateClosedArguments node was live so long as any MovHinted bytecode variable was alive.
        Basically, we'd keep it alive until the end of the block. This maximized the chances of
        there being an interfering operation, which would prevent elimination.
        
        The fix is to only consider MovHints that have the arguments candidate as a child. We only
        care to track the liveness of those bytecode locals that would need an arguments object
        recovery on OSR exit.
        
        This is a speed-up on V8Spider/raytrace and Octane/raytrace because it undoes the regression
        introduced in http://trac.webkit.org/changeset/183406.

        * dfg/DFGVarargsForwardingPhase.cpp:

2015-04-28  Csaba Osztrogonác  <ossy@webkit.org>

        Remove WinCE cruft from cmake build system
        https://bugs.webkit.org/show_bug.cgi?id=144325

        Reviewed by Gyuyoung Kim.

        * CMakeLists.txt:
        * create_jit_stubs: Removed.

2015-04-27  Andreas Kling  <akling@apple.com>

        RegExp matches arrays should use contiguous indexing.
        <https://webkit.org/b/144286>

        Reviewed by Geoffrey Garen.

        We had a custom Structure being used for RegExp matches arrays that would
        put the arrays into SlowPutArrayStorageShape mode. This was just left
        from when matches arrays were custom, lazily initialized objects.

        This change removes that Structure and switches the matches arrays to
        using the default ContiguousShape Structure. This allows the FTL JIT
        to compile the inner loop of the Octane/regexp benchmark.

        Also made a version of initializeIndex() [inline] that takes the indexing
        type in an argument, allowing createRegExpMatchesArray() to initialize
        the entire array without branching on the indexing type for each entry.

        ~3% progression on Octane/regexp.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::mapStructure):
        (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
        * runtime/JSObject.h:
        (JSC::JSObject::initializeIndex):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::createRegExpMatchesArray):

2015-04-27  Filip Pizlo  <fpizlo@apple.com>

        FTL failed to initialize arguments.callee on the slow path as well as the fast path
        https://bugs.webkit.org/show_bug.cgi?id=144293

        Reviewed by Mark Lam.
        
        The slow path doesn't fully initialize DirectArguments - it leaves callee blank. So, we need
        to initialize the callee on the common path after the fast and slow path.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileCreateDirectArguments):
        * tests/stress/arguments-callee-uninitialized.js: Added.
        (foo):

2015-04-27  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add support for typed arrays to the Array profiling
        https://bugs.webkit.org/show_bug.cgi?id=143913

        Reviewed by Filip Pizlo.

        This patch adds ArrayModes for every typed arrays. Having that information
        let us generate better GetByVal and PutByVal when the type speculation
        are not good enough.

        A typical case where this is useful is any basic block for which the type
        of the object is always more restrictive than the speculation (for example, 
        a basic block gated by a branch only taken for on type).

        * bytecode/ArrayProfile.cpp:
        (JSC::dumpArrayModes):
        * bytecode/ArrayProfile.h:
        (JSC::arrayModeFromStructure):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::fromObserved):
        (JSC::DFG::ArrayMode::refine):
        Maintain the refine() semantic. We do not support OutOfBounds access
        for GetByVal on typed array.

        * runtime/IndexingType.h:
        * tests/stress/typed-array-get-by-val-profiling.js: Added.
        (testArray.testCode):
        (testArray):
        * tests/stress/typed-array-put-by-val-profiling.js: Added.
        (testArray.testCode):
        (testArray):

2015-04-27  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, roll out r183438 "RegExp matches arrays should use contiguous indexing". It
        causes many debug test failures.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::regExpMatchesArrayStructure):
        * runtime/JSObject.h:
        (JSC::JSObject::initializeIndex):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::createRegExpMatchesArray):

2015-04-27  Andreas Kling  <akling@apple.com>

        RegExp matches arrays should use contiguous indexing.
        <https://webkit.org/b/144286>

        Reviewed by Geoffrey Garen.

        We had a custom Structure being used for RegExp matches arrays that would
        put the arrays into SlowPutArrayStorageShape mode. This was just left
        from when matches arrays were custom, lazily initialized objects.

        This change removes that Structure and switches the matches arrays to
        using the default ContiguousShape Structure. This allows the FTL JIT
        to compile the inner loop of the Octane/regexp benchmark.

        Also made a version of initializeIndex() [inline] that takes the indexing
        type in an argument, allowing createRegExpMatchesArray() to initialize
        the entire array without branching on the indexing type for each entry.

        ~3% progression on Octane/regexp.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::mapStructure):
        (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
        * runtime/JSObject.h:
        (JSC::JSObject::initializeIndex):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::createRegExpMatchesArray):

2015-04-27  Ryosuke Niwa  <rniwa@webkit.org>

        REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
        https://bugs.webkit.org/show_bug.cgi?id=144257

        Temporarily disable skip these tests.

        * tests/stress/template-literal-line-terminators.js:
        * tests/stress/template-literal-syntax.js:
        * tests/stress/template-literal.js:

2015-04-27  Basile Clement  <basile_clement@apple.com>

        Function allocations shouldn't sink through Put operations
        https://bugs.webkit.org/show_bug.cgi?id=144176

        Reviewed by Filip Pizlo.

        By design, we don't support function allocation sinking through any
        related operation ; however object allocation can sink through PutByOffset et
        al.

        Currently, the checks to prevent function allocation to sink through
        these are misguided and do not prevent anything ; function allocation sinking
        through these operations is prevented as a side effect of requiring an
        AllocatePropertyStorage through which the function allocation is seen as
        escaping.

        This changes it so that ObjectAllocationSinkingPhase::handleNode()
        checks properly that only object allocations sink through related write
        operations.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):

2015-04-25  Filip Pizlo  <fpizlo@apple.com>

        VarargsForwardingPhase should use bytecode liveness in addition to other uses to determine the last point that a candidate is used
        https://bugs.webkit.org/show_bug.cgi?id=143843

        Reviewed by Geoffrey Garen.
        
        It will soon come to pass that Phantom isn't available at the time that
        VarargsForwardingPhase runs. So, it needs to use some other mechanism for discovering when
        a value dies for OSR.
        
        This is simplified by two things:
        
        1) The bytecode kill analysis is now reusable. This patch makes it even more reusable than
           before by polishing the API.
        
        2) This phase already operates on one node at a time and allows itself to do a full search
           of the enclosing basic block for that node. This is fine because CreateDirectArguments
           and friends is a rarely occurring node. The fact that it operates on one node at a time
           makes it even easier to reason about OSR liveness - we just track the list of locals in
           which it is live.
        
        This change has no effect right now but it is a necessary prerequisite to implementing
        https://bugs.webkit.org/show_bug.cgi?id=143736.

        * dfg/DFGBasicBlock.h:
        (JSC::DFG::BasicBlock::tryAt):
        * dfg/DFGForAllKills.h:
        (JSC::DFG::forAllKilledOperands):
        * dfg/DFGPhantomInsertionPhase.cpp:
        * dfg/DFGVarargsForwardingPhase.cpp:

2015-04-27  Jordan Harband  <ljharb@gmail.com>

        Map#entries and Map#keys error for non-Maps is swapped
        https://bugs.webkit.org/show_bug.cgi?id=144253

        Reviewed by Simon Fraser.

        Correcting error messages on Set/Map methods when called on
        incompatible objects.

        * runtime/MapPrototype.cpp:
        (JSC::mapProtoFuncEntries):
        (JSC::mapProtoFuncKeys):
        * runtime/SetPrototype.cpp:
        (JSC::setProtoFuncEntries):

2015-04-24  Filip Pizlo  <fpizlo@apple.com>

        Rationalize DFG DCE handling of nodes that perform checks that propagate through AI
        https://bugs.webkit.org/show_bug.cgi?id=144186

        Reviewed by Geoffrey Garen.
        
        If I do ArithAdd(Int32Use, Int32Use, CheckOverflow) then AI will prove that this returns
        Int32. We may later perform code simplifications based on the proof that this is Int32, and
        we may kill all DFG users of this ArithAdd. Then we may prove that there is no exit site at
        which the ArithAdd is live. This seems like it is sufficient to then kill the ArithAdd,
        except that we still need the overflow check!

        Previously we mishandled this:

        - In places where we want the overflow check we need to use MustGenerate(@ArithAdd) as a hack
          to keep it alive. That's dirty and it's just indicative of a deeper issue.

        - Our MovHint removal doesn't do Phantom canonicalization which essentially makes it
          powerless. This was sort of hiding the bug.

        - Nodes that have checks that AI leverages should always be NodeMustGenerate. You can't kill
          something that you are relying on for subsequent simplifications.
        
        This fixes MovHint removal to also canonicalize Phantoms. This also adds ModeMustGenerate to
        nodes that may perform checks that are used by AI to guarantee the result type. As a result,
        we no longer need the weird MustGenerate node.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::run):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
        * dfg/DFGIntegerCheckCombiningPhase.cpp:
        (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
        (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd): Deleted.
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::willHaveCodeGenOrOSR):
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        * dfg/DFGPhantomCanonicalizationPhase.cpp:
        (JSC::DFG::PhantomCanonicalizationPhase::run):
        * dfg/DFGPhantomRemovalPhase.cpp:
        (JSC::DFG::PhantomRemovalPhase::run):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
        * dfg/DFGVarargsForwardingPhase.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        * tests/stress/fold-based-on-int32-proof-mul-branch.js: Added.
        (foo):
        * tests/stress/fold-based-on-int32-proof-mul.js: Added.
        (foo):
        * tests/stress/fold-based-on-int32-proof-or-zero.js: Added.
        (foo):
        * tests/stress/fold-based-on-int32-proof.js: Added.
        (foo):

2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>

        Class body ending with a semicolon throws a SyntaxError
        https://bugs.webkit.org/show_bug.cgi?id=144244

        Reviewed by Darin Adler.

        The bug was caused by parseClass's inner loop for method definitions not moving onto the next iteration
        it encounters a semicolon. As a result, we always expected a method to appear after a semicolon. Fixed
        it by continue'ing when it encounters a semicolon.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):

2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>

        Getter or setter method named "prototype" or "constrcutor" should throw SyntaxError
        https://bugs.webkit.org/show_bug.cgi?id=144243

        Reviewed by Darin Adler.

        Fixed the bug by adding explicit checks in parseGetterSetter when we're parsing class methods.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseGetterSetter):

2015-04-26  Jordan Harband  <ljharb@gmail.com>

        Map#forEach does not pass "map" argument to callback.
        https://bugs.webkit.org/show_bug.cgi?id=144187

        Reviewed by Darin Adler.

        Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-map.prototype.foreach
        step 7.a.i., the callback should be called with three arguments.

        * runtime/MapPrototype.cpp:
        (JSC::mapProtoFuncForEach):

2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement ES6 template literals
        https://bugs.webkit.org/show_bug.cgi?id=142691

        Reviewed by Darin Adler.

        This patch implements TemplateLiteral.
        Since TaggedTemplate requires some global states and
        primitive operations like GetTemplateObject,
        we separate the patch. It will be implemented in a subsequent patch.

        Template Literal Syntax is guarded by ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX compile time flag.
        By disabling it, we can disable Template Literal support.

        To implement template literals, in this patch,
        we newly introduces bytecode op_to_string.
        In template literals, we alternately evaluate the expression and
        perform ToString onto the result of evaluation.
        For example,

        `${f1()} ${f2()}`

        In this template literal, execution order is the following,
        1. calling f1()
        2. ToString(the result of f1())
        3. calling f2()
        4. ToString(the result of f2())

        op_strcat also performs ToString. However, performing ToString
        onto expressions are batched in op_strcat, it's not the same to the
        template literal spec. In the above example,
        ToString(f1()) should be called before calling f2().

        * Configurations/FeatureDefines.xcconfig:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitToString):
        (JSC::BytecodeGenerator::emitToNumber): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::TemplateStringNode::emitBytecode):
        (JSC::TemplateLiteralNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_to_string):
        (JSC::JIT::emitSlow_op_to_string):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_to_string):
        (JSC::JIT::emitSlow_op_to_string):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createTemplateString):
        (JSC::ASTBuilder::createTemplateStringList):
        (JSC::ASTBuilder::createTemplateExpressionList):
        (JSC::ASTBuilder::createTemplateLiteral):
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::Lexer):
        (JSC::Lexer<T>::parseIdentifierSlowCase):
        (JSC::Lexer<T>::parseString):
        (JSC::LineNumberAdder::LineNumberAdder):
        (JSC::LineNumberAdder::clear):
        (JSC::LineNumberAdder::add):
        (JSC::Lexer<T>::parseTemplateLiteral):
        (JSC::Lexer<T>::lex):
        (JSC::Lexer<T>::scanRegExp):
        (JSC::Lexer<T>::scanTrailingTemplateString):
        (JSC::Lexer<T>::parseStringSlowCase): Deleted.
        * parser/Lexer.h:
        * parser/NodeConstructors.h:
        (JSC::TemplateExpressionListNode::TemplateExpressionListNode):
        (JSC::TemplateStringNode::TemplateStringNode):
        (JSC::TemplateStringListNode::TemplateStringListNode):
        (JSC::TemplateLiteralNode::TemplateLiteralNode):
        * parser/Nodes.h:
        (JSC::TemplateExpressionListNode::value):
        (JSC::TemplateExpressionListNode::next):
        (JSC::TemplateStringNode::cooked):
        (JSC::TemplateStringNode::raw):
        (JSC::TemplateStringListNode::value):
        (JSC::TemplateStringListNode::next):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseTemplateString):
        (JSC::Parser<LexerType>::parseTemplateLiteral):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        * parser/Parser.h:
        * parser/ParserTokens.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createTemplateString):
        (JSC::SyntaxChecker::createTemplateStringList):
        (JSC::SyntaxChecker::createTemplateExpressionList):
        (JSC::SyntaxChecker::createTemplateLiteral):
        (JSC::SyntaxChecker::createSpreadExpression): Deleted.
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * tests/stress/template-literal-line-terminators.js: Added.
        (test):
        (testEval):
        (testEvalLineNumber):
        * tests/stress/template-literal-syntax.js: Added.
        (testSyntax):
        (testSyntaxError):
        * tests/stress/template-literal.js: Added.
        (test):
        (testEval):
        (testEmbedded):

2015-04-26  Jordan Harband  <ljharb@gmail.com>

        Set#forEach does not pass "key" or "set" arguments to callback.
        https://bugs.webkit.org/show_bug.cgi?id=144188

        Reviewed by Darin Adler.

        Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.foreach
        Set#forEach should pass 3 arguments to the callback.

        * runtime/SetPrototype.cpp:
        (JSC::setProtoFuncForEach):

2015-04-26  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Implement Math.clz32(), remove Number.clz()
        https://bugs.webkit.org/show_bug.cgi?id=144205

        Reviewed by Michael Saboff.

        This patch adds the ES6 function Math.clz32(), and remove the non-standard
        Number.clz(). Number.clz() probably came from an older draft.

        The new function has a corresponding instrinsic: Clz32Intrinsic,
        and a corresponding DFG node: ArithClz32, optimized all the way to LLVM.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::countLeadingZeros32):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::bsr_rr):
        The x86 assembler did not have countLeadingZeros32() because there is
        no native CLZ instruction on that architecture.

        I have added the version with bsr + branches for the case of zero.
        An other popular version uses cmov to handle the case of zero. I kept
        it simple since the Assembler has no support for cmov.

        It is unlikely to matter much. If the code is hot enough, LLVM picks
        something good based on the surrounding code.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        Constant handling + effect propagation. The node only produces integer (between 0 and 32).

        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        Thanks to the definition of toUint32(), we can ignore plenty of details
        from doubles.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithClz32):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileArithClz32):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::ctlz32):
        * jit/ThunkGenerators.cpp:
        (JSC::clz32ThunkGenerator):
        * jit/ThunkGenerators.h:
        * runtime/Intrinsic.h:
        * runtime/MathCommon.h:
        (JSC::clz32):
        Fun fact: InstCombine does not recognize this pattern to eliminate
        the branch which makes our FTL version better than the C version.

        * runtime/MathObject.cpp:
        (JSC::MathObject::finishCreation):
        (JSC::mathProtoFuncClz32):
        * runtime/NumberPrototype.cpp:
        (JSC::clz): Deleted.
        (JSC::numberProtoFuncClz): Deleted.
        * runtime/VM.cpp:
        (JSC::thunkGeneratorForIntrinsic):
        * tests/stress/math-clz32-basics.js: Added.
        (mathClz32OnInteger):
        (testMathClz32OnIntegers):
        (verifyMathClz32OnIntegerWithOtherTypes):
        (mathClz32OnDouble):
        (testMathClz32OnDoubles):
        (verifyMathClz32OnDoublesWithOtherTypes):
        (mathClz32NoArguments):
        (mathClz32TooManyArguments):
        (testMathClz32OnConstants):
        (mathClz32StructTransition):
        (Math.clz32):

2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Array.from need to accept iterables
        https://bugs.webkit.org/show_bug.cgi?id=141055

        Reviewed by Darin Adler.

        ES6 spec requires that Array.from accepts iterable objects.
        This patch introduces this functionality, Array.from accepting iterable objects.

        Currently, `isConstructor` is not used. Instead of it, `typeof thiObj === "function"` is used.
        However, it doesn't conform to the spec. While `isConstructor` queries the given object has `[[Construct]]`,
        `typeof thisObj === "function"` queries the given object has `[[Call]]`.
        This will be fixed in the subsequent patch[1].

        [1]: https://bugs.webkit.org/show_bug.cgi?id=144093

        * builtins/ArrayConstructor.js:
        (from):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * tests/stress/array-from-with-iterable.js: Added.
        (shouldBe):
        (.set for):
        (.set var):
        (.get var):
        (argumentsGenerators):
        (.set shouldBe):
        (.set new):
        * tests/stress/array-from-with-iterator.js: Added.
        (shouldBe):
        (shouldThrow):
        (createIterator.iterator.return):
        (createIterator):
        (.):

2015-04-25  Jordan Harband  <ljharb@gmail.com>

        Set#keys !== Set#values
        https://bugs.webkit.org/show_bug.cgi?id=144190

        Reviewed by Darin Adler.

        per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.keys
        Set#keys should === Set#values

        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        (JSC::setProtoFuncValues):
        (JSC::setProtoFuncEntries):
        (JSC::setProtoFuncKeys): Deleted.

2015-04-25  Joseph Pecoraro  <pecoraro@apple.com>

        Allow for pausing a JSContext when opening a Web Inspector
        <rdar://problem/20564788>

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::receivedSetupMessage):
        * inspector/remote/RemoteInspectorConstants.h:
        * inspector/remote/RemoteInspectorDebuggable.h:
        * inspector/remote/RemoteInspectorDebuggableConnection.h:
        * inspector/remote/RemoteInspectorDebuggableConnection.mm:
        (Inspector::RemoteInspectorDebuggableConnection::setup):
        On any incoming setup message, we may want to automatically
        pause the debuggable. If requested, pause the debuggable
        after we have setup the frontend connection.

        * runtime/JSGlobalObjectDebuggable.h:
        * runtime/JSGlobalObjectDebuggable.cpp:
        (JSC::JSGlobalObjectDebuggable::pause):
        Pass through to the inspector controller.

        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::pause):
        Enable pause on next statement.

2015-04-23  Ryosuke Niwa  <rniwa@webkit.org>

        class methods should be non-enumerable
        https://bugs.webkit.org/show_bug.cgi?id=143181

        Reviewed by Darin Adler.

        Fixed the bug by using Object.defineProperty to define methods.

        This patch adds the concept of link time constants and uses it to resolve Object.defineProperty
        inside CodeBlock's constructor since bytecode can be linked against multiple global objects.

        * bytecode/CodeBlock.cpp: 
        (JSC::CodeBlock::CodeBlock): Resolve link time constants that are used. Ignore ones with register
        index of zero.
        * bytecode/SpecialPointer.h: Added a new enum for link time constants. It currently contains
        exactly one entry for Object.defineProperty.
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::addConstant): Added. Like addConstant that takes JSValue, allocate a new
        constant register for the link time constant we're adding.
        (JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Added.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitMoveLinkTimeConstant): Added. Like addConstantValue, allocate a new
        register for the specified link time constant and notify UnlinkedCodeBlock about it.
        (JSC::BytecodeGenerator::emitCallDefineProperty): Added. Create a new property descriptor and call
        Object.defineProperty with it.
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode): Make static and non-static getters and setters for classes
        non-enumerable by using emitCallDefineProperty to define them.
        (JSC::PropertyListNode::emitPutConstantProperty): Ditto for a non-accessor properties.
        (JSC::ClassExprNode::emitBytecode): Make prototype.constructor non-enumerable and make prototype
        property on the class non-writable, non-configurable, and non-enumerable by using defineProperty.
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Set m_definePropertyFunction.
        (JSC::JSGlobalObject::visitChildren): Visit m_definePropertyFunction.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::definePropertyFunction): Added.
        (JSC::JSGlobalObject::actualPointerFor): Added a variant that takes LinkTimeConstant.
        (JSC::JSGlobalObject::jsCellForLinkTimeConstant): Like actualPointerFor, takes LinkTimeConstant and
        returns a JSCell; e.g. Object.defineProperty.
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::addDefineProperty): Added. Returns Object.defineProperty.
        * runtime/ObjectConstructor.h:

2015-04-25  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement String.fromCodePoint
        https://bugs.webkit.org/show_bug.cgi?id=144160

        Reviewed by Darin Adler.

        This patch implements String.fromCodePoint.
        It accepts multiple code points and generates a string that consists of given code points.
        The range [0x0000 - 0x10FFFF] is valid for code points.
        If the given value is out of range, throw a range error.

        When a 0xFFFF <= valid code point is given,
        String.fromCodePoint generates a string that contains surrogate pairs.

        * runtime/StringConstructor.cpp:
        (JSC::stringFromCodePoint):
        (JSC::constructWithStringConstructor):
        * tests/stress/string-from-code-point.js: Added.
        (shouldBe):
        (shouldThrow):
        (toCodePoints):
        (passThrough):

2015-04-25  Martin Robinson  <mrobinson@igalia.com>

        Rename ENABLE_3D_RENDERING to ENABLE_3D_TRANSFORMS
        https://bugs.webkit.org/show_bug.cgi?id=144182

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig: Replace all instances of 3D_RENDERING with 3D_TRANSFORMS.

2015-04-25  Mark Lam  <mark.lam@apple.com>

        mayExit() is wrong about Branch nodes with ObjectOrOtherUse: they can exit.
        https://bugs.webkit.org/show_bug.cgi?id=144152

        Reviewed by Filip Pizlo.

        Changed the EdgeMayExit functor to recognize ObjectUse, ObjectOrOtherUse,
        StringObjectUse, and StringOrStringObjectUse kinds as potentially triggering
        OSR exits.  This was overlooked in the original code.

        While only the ObjectOrOtherUse kind is relevant for manifesting this bug with
        the Branch node, the other 3 may also trigger the same bug for other nodes.
        To prevent this bug from manifesting with other nodes (and future ones that
        are yet to be added to mayExits()'s "potential won't exit" set), we fix the
        EdgeMayExit functor to handle all 4 use kinds (instead of just ObjectOrOtherUse).

        Also added a test to exercise a code path that will trigger this bug with
        the Branch node before the fix is applied.

        * dfg/DFGMayExit.cpp:
        * tests/stress/branch-may-exit-due-to-object-or-other-use-kind.js: Added.
        (inlinedFunction):
        (foo):

2015-04-24  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r183288.
        https://bugs.webkit.org/show_bug.cgi?id=144189

        Made js/sort-with-side-effecting-comparisons.html time out in
        debug builds (Requested by ap on #webkit).

        Reverted changeset:

        "It shouldn't take 1846 lines of code and 5 FIXMEs to sort an
        array."
        https://bugs.webkit.org/show_bug.cgi?id=144013
        http://trac.webkit.org/changeset/183288

2015-04-24  Filip Pizlo  <fpizlo@apple.com>

        CRASH in operationCreateDirectArgumentsDuringExit()
        https://bugs.webkit.org/show_bug.cgi?id=143962

        Reviewed by Geoffrey Garen.
        
        We shouldn't assume that constant-like OSR exit values are always recoverable. They are only
        recoverable so long as they are live. Therefore, OSR exit should track liveness of
        constants instead of assuming that they are always live.

        * dfg/DFGGenerationInfo.h:
        (JSC::DFG::GenerationInfo::noticeOSRBirth):
        (JSC::DFG::GenerationInfo::appendBirth):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        * dfg/DFGVariableEvent.cpp:
        (JSC::DFG::VariableEvent::dump):
        * dfg/DFGVariableEvent.h:
        (JSC::DFG::VariableEvent::birth):
        (JSC::DFG::VariableEvent::id):
        (JSC::DFG::VariableEvent::dataFormat):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::reconstruct):
        * tests/stress/phantom-direct-arguments-clobber-argument-count.js: Added.
        (foo):
        (bar):
        * tests/stress/phantom-direct-arguments-clobber-callee.js: Added.
        (foo):
        (bar):

2015-04-24  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] When inserting a NaN into a Int32 array, we convert it to DoubleArray then to ContiguousArray
        https://bugs.webkit.org/show_bug.cgi?id=144169

        Reviewed by Geoffrey Garen.

        * runtime/JSObject.cpp:
        (JSC::JSObject::convertInt32ForValue):
        DoubleArray do not store NaN, they are used for holes.
        What happened was:
        1) We fail to insert the NaN in the Int32 array because it is a double.
        2) We were converting the array to DoubleArray.
        3) We were trying to insert the value again. We would fail again because
           DoubleArray does not store NaN.
        4) We would convert the DoubleArrayt to Contiguous Array, converting the values
           to boxed values.

        * tests/stress/int32array-transition-on-nan.js: Added.
        The behavior is not really observable. This only test nothing crashes in those
        cases.

        (insertNaNWhileFilling):
        (testInsertNaNWhileFilling):
        (insertNaNAfterFilling):
        (testInsertNaNAfterFilling):
        (pushNaNWhileFilling):
        (testPushNaNWhileFilling):

2015-04-21  Geoffrey Garen  <ggaren@apple.com>

        It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
        https://bugs.webkit.org/show_bug.cgi?id=144013

        Reviewed by Mark Lam.

        This patch implements Array.prototype.sort in JavaScript, removing the
        C++ implementations. It is simpler and less error-prone to express our
        operations in JavaScript, which provides memory safety, exception safety,
        and recursion safety.

        The performance result is mixed, but net positive in my opinion. It's
        difficult to enumerate all the results, since we used to have so many
        different sorting modes, and there are lots of different data patterns
        across which you might want to measure sorting. Suffice it to say:

            (*) The benchmarks we track are faster or unchanged.

            (*) Sorting random input using a comparator -- which we think is
            common -- is 3X faster.

            (*) Sorting random input in a non-array object -- which jQuery does
            -- is 4X faster.

            (*) Sorting random input in a compact array of integers using a
            trivial pattern-matchable comparator is 2X *slower*.

        * builtins/Array.prototype.js:
        (sort.min):
        (sort.stringComparator):
        (sort.compactSparse): Special case compaction for sparse arrays because
        we don't want to hang when sorting new Array(BIG).

        (sort.compact):
        (sort.merge):
        (sort.mergeSort): Use merge sort because it's a reasonably efficient
        stable sort. We have evidence that some sites depend on stable sort,
        even though the ES6 spec does not mandate it. (See
        <http://trac.webkit.org/changeset/33967>.)

        This is a textbook implementation of merge sort with three optimizations:

            (1) Use iteration instead of recursion;

            (2) Use array subscripting instead of array copying in order to
            create logical sub-lists without creating physical sub-lists;

            (3) Swap src and dst at each iteration instead of copying src into
            dst, and only copy src into the subject array at the end if src is
            not the subject array.

        (sort.inflate):
        (sort.comparatorSort):
        (sort): Sort in JavaScript for the win.

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
        names so we can use helper functions.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::isNumericCompareFunction): Deleted.
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
        (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionNode::emitBytecode): We don't do this special casing based
        on pattern matching anymore. This was mainly an optimization to avoid 
        the overhead of calling from C++ to JS, which we now avoid by
        sorting in JS.

        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::pushTempSortVector): Deleted.
        (JSC::Heap::popTempSortVector): Deleted.
        (JSC::Heap::visitTempSortVectors): Deleted.
        * heap/Heap.h: We don't have temp sort vectors anymore because we sort
        in JavaScript using a normal JavaScript array for our temporary storage.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
        helper functions.

        * runtime/ArrayPrototype.cpp:
        (JSC::isNumericCompareFunction): Deleted.
        (JSC::attemptFastSort): Deleted.
        (JSC::performSlowSort): Deleted.
        (JSC::arrayProtoFuncSort): Deleted.

        * runtime/CommonIdentifiers.h: New strings used by sort.

        * runtime/JSArray.cpp:
        (JSC::compareNumbersForQSortWithInt32): Deleted.
        (JSC::compareNumbersForQSortWithDouble): Deleted.
        (JSC::compareNumbersForQSort): Deleted.
        (JSC::compareByStringPairForQSort): Deleted.
        (JSC::JSArray::sortNumericVector): Deleted.
        (JSC::JSArray::sortNumeric): Deleted.
        (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
        (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
        (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
        (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
        (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
        (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
        (JSC::JSArray::sortCompactedVector): Deleted.
        (JSC::JSArray::sort): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
        (JSC::JSArray::sortVector): Deleted.
        (JSC::JSArray::compactForSorting): Deleted.
        * runtime/JSArray.h:

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation): Provide some builtins used
        by sort.

2015-04-24  Matthew Mirman  <mmirman@apple.com>

        Made Object.prototype.__proto__ native getter and setter check that this object not null or undefined
        https://bugs.webkit.org/show_bug.cgi?id=141865
        rdar://problem/19927273

        Reviewed by Filip Pizlo.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoGetter):
        (JSC::globalFuncProtoSetter):

2015-04-23  Benjamin Poulain  <bpoulain@apple.com>

        Remove a useless branch on DFGGraph::addShouldSpeculateMachineInt()
        https://bugs.webkit.org/show_bug.cgi?id=144118

        Reviewed by Geoffrey Garen.

        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addShouldSpeculateMachineInt):
        Both block do the same thing.

2015-04-23  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Speculative fix for non-main thread auto-attach failures
        https://bugs.webkit.org/show_bug.cgi?id=144134

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::singleton):

2015-04-23  Basile Clement  <basile_clement@apple.com>

        Allow function allocation sinking
        https://bugs.webkit.org/show_bug.cgi?id=144016

        Reviewed by Filip Pizlo.

        This adds the ability to sink function allocations in the
        DFGObjectAllocationSinkingPhase.

        In order to enable this, we add a new PhantomNewFunction node that is
        used similarily to the PhantomNewObject node, i.e. as a placeholder to replace
        a sunk NewFunction and keep track of the allocations that have to be performed
        in case of OSR exit after the sunk allocation but before the real one.
        The FunctionExecutable and JSLexicalEnvironment (activation) of the function
        are stored onto the PhantomNewFunction through PutHints in order for them
        to be recovered on OSR exit.

        Contrary to sunk object allocations, sunk function allocations do not
        support any kind of operations (e.g. storing into a field) ; any such operation
        will mark the function allocation as escaping and trigger materialization. As
        such, function allocations can only be sunk to places where it would have been
        correct to syntactically move them, and we don't need a special
        MaterializeNewFunction node to recover possible operations on the function. A
        sunk NewFunction node will simply create new NewFunction nodes, then replace
        itself with a PhantomNewFunction node.

        In itself, this change is not expected to have a significant impact on
        performances other than in degenerate cases (see e.g.
        JSRegress/sink-function), but it is a step towards being able to sink recursive
        closures onces we support CreateActivation sinking as well as allocation cycles
        sinking.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToPhantomNewFunction):
        (JSC::DFG::Node::isPhantomAllocation):
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
        (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGPromotedHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGPromotedHeapLocation.h:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validateCPS):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * tests/stress/function-sinking-no-double-allocate.js: Added.
        (call):
        (.f):
        (sink):
        * tests/stress/function-sinking-osrexit.js: Added.
        (.g):
        (sink):
        * tests/stress/function-sinking-put.js: Added.
        (.g):
        (sink):

2015-04-23  Basile Clement  <basile_clement@apple.com>

        Make FunctionRareData allocation thread-safe
        https://bugs.webkit.org/show_bug.cgi?id=144001

        Reviewed by Mark Lam.

        The two things we want to prevent are:

         1. A thread seeing a pointer to a not-yet-fully-created rare data from
            a JSFunction
         2. A thread seeing a pointer to a not-yet-fully-created Structure from
            an ObjectAllocationProfile

        For 1., only the JS thread can be creating the rare data (in
        runtime/CommonSlowPaths.cpp or in dfg/DFGOperations.cpp), so we don't need to
        worry about concurrent writes, and we don't need any fences when *reading* the
        rare data from the JS thread. Thus we only need a storeStoreFence between the
        rare data creation and assignment to m_rareData in
        JSFunction::createAndInitializeRareData() to ensure that when the store to
        m_rareData is issued, the rare data has been properly created.

        For the DFG compilation threads, the only place they can access the
        rare data is through JSFunction::rareData(), and so we only need a
        loadLoadFence there to ensure that when we see a non-null pointer in
        m_rareData, the pointed object will be seen as a fully created
        FunctionRareData.


        For 2., the structure is created in
        ObjectAllocationProfile::initialize() (which appears to be called only by the
        JS thread as well, in bytecode/CodeBlock.cpp and on rare data initialization,
        which always happen in the JS thread), and read through
        ObjectAllocationProfile::structure() and
        ObjectAllocationProfile::inlineCapacity(), so following the same reasoning we
        put a storeStoreFence in ObjectAllocationProfile::initialize() and a
        loadLoadFence in ObjectAllocationProfile::structure() (and change
        ObjectAllocationProfile::inlineCapacity() to go through
        ObjectAllocationProfile::structure()).

        We don't need a fence in ObjectAllocationProfile::clear() because
        clearing the structure is already as atomic as it gets.

        Finally, notice that we don't care about the ObjectAllocationProfile's
        m_allocator as that is only used by ObjectAllocationProfile::initialize() and
        ObjectAllocationProfile::clear() that are always run in the JS thread.
        ObjectAllocationProfile::isNull() could cause some trouble, but it is
        currently only used in the ObjectAllocationProfile::clear()'s ASSERT in the JS
        thread.  Doing isNull()-style pre-checks would be wrong in any other concurrent
        thread anyway.

        * bytecode/ObjectAllocationProfile.h:
        (JSC::ObjectAllocationProfile::initialize):
        (JSC::ObjectAllocationProfile::structure):
        (JSC::ObjectAllocationProfile::inlineCapacity):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::allocateAndInitializeRareData):
        * runtime/JSFunction.h:
        (JSC::JSFunction::rareData):
        (JSC::JSFunction::allocationStructure): Deleted.
        This is no longer used, as all the accesses to the ObjectAllocationProfile go through the rare data.

2015-04-22  Filip Pizlo  <fpizlo@apple.com>

        DFG should insert Phantoms late using BytecodeKills and block-local OSR availability
        https://bugs.webkit.org/show_bug.cgi?id=143735

        Reviewed by Geoffrey Garen.
        
        We've always had bugs arising from the fact that we would MovHint something into a local,
        and then fail to keep it alive. We would then try to keep things alive by putting Phantoms
        on those Nodes that were MovHinted. But this became increasingly tricky. Given the
        sophistication of the transformations we are doing today, this approach is just not sound
        anymore.
        
        This comprehensively fixes these bugs by having the DFG backend automatically insert
        Phantoms just before codegen based on bytecode liveness. To make this practical, this also
        makes it much faster to query bytecode liveness.
        
        It's about as perf-neutral as it gets for a change that increases compiler work without
        actually optimizing anything. Later changes will remove the old Phantom-preserving logic,
        which should then speed us up. I can't really report concrete slow-down numbers because
        they are low enough to basically be in the noise. For example, a 20-iteration run of
        SunSpider yields "maybe 0.8% slower", whatever that means.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
        * bytecode/FullBytecodeLiveness.h:
        (JSC::FullBytecodeLiveness::getLiveness):
        * bytecode/VirtualRegister.h:
        (JSC::VirtualRegister::operator+):
        (JSC::VirtualRegister::operator-):
        * dfg/DFGForAllKills.h:
        (JSC::DFG::forAllLiveNodesAtTail):
        (JSC::DFG::forAllKilledOperands):
        (JSC::DFG::forAllKilledNodesAtNodeIndex):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::isLiveInBytecode):
        (JSC::DFG::Graph::localsLiveInBytecode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
        (JSC::DFG::Graph::forAllLiveInBytecode):
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGMovHintRemovalPhase.cpp:
        * dfg/DFGNodeType.h:
        * dfg/DFGPhantomInsertionPhase.cpp: Added.
        (JSC::DFG::performPhantomInsertion):
        * dfg/DFGPhantomInsertionPhase.h: Added.
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGScoreBoard.h:
        (JSC::DFG::ScoreBoard::sortFree):
        (JSC::DFG::ScoreBoard::assertClear):
        * dfg/DFGVirtualRegisterAllocationPhase.cpp:
        (JSC::DFG::VirtualRegisterAllocationPhase::run):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
        * tests/stress/phantom-inadequacy.js: Added.
        (bar):
        (baz):
        (foo):

2015-04-23  Filip Pizlo  <fpizlo@apple.com>

        Rename HardPhantom to MustGenerate.

        Rubber stamped by Geoffrey Garen.
        
        We are steadily moving towards Phantom just being a backend hack in the DFG. HardPhantom
        is more than that; it's a utility for forcing the execution of otherwise killable nodes.
        NodeMustGenerate is the flag we use to indicate that something isn't killable. So this
        node should just be called MustGenerate.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::run):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
        * dfg/DFGIntegerCheckCombiningPhase.cpp:
        (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd):
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::willHaveCodeGenOrOSR):
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        * dfg/DFGPhantomCanonicalizationPhase.cpp:
        (JSC::DFG::PhantomCanonicalizationPhase::run):
        * dfg/DFGPhantomRemovalPhase.cpp:
        (JSC::DFG::PhantomRemovalPhase::run):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
        * dfg/DFGVarargsForwardingPhase.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):

2015-04-23  Jordan Harband  <ljharb@gmail.com>

        Implement `Object.assign`
        https://bugs.webkit.org/show_bug.cgi?id=143980

        Reviewed by Filip Pizlo.

        per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.assign

        * builtins/ObjectConstructor.js: Added.
        (assign):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/ObjectConstructor.cpp:
        * runtime/ObjectConstructor.h:

2015-04-22  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix debug build.

        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::performSubstitutionForEdge):

2015-04-22  Filip Pizlo  <fpizlo@apple.com>

        Nodes should have an optional epoch field
        https://bugs.webkit.org/show_bug.cgi?id=144084

        Reviewed by Ryosuke Niwa and Mark Lam.
        
        This makes it easier to do epoch-based analyses on nodes. I plan to do just that in
        https://bugs.webkit.org/show_bug.cgi?id=143735. Currently the epoch field is not yet
        used.

        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
        * dfg/DFGCSEPhase.cpp:
        * dfg/DFGEpoch.h:
        (JSC::DFG::Epoch::fromUnsigned):
        (JSC::DFG::Epoch::toUnsigned):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::clearReplacements):
        (JSC::DFG::Graph::clearEpochs):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::performSubstitutionForEdge):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::Node):
        (JSC::DFG::Node::replaceWith):
        (JSC::DFG::Node::replacement):
        (JSC::DFG::Node::setReplacement):
        (JSC::DFG::Node::epoch):
        (JSC::DFG::Node::setEpoch):
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):

2015-04-22  Mark Lam  <mark.lam@apple.com>

        Fix assertion failure and race condition in Options::dumpSourceAtDFGTime().
        https://bugs.webkit.org/show_bug.cgi?id=143898

        Reviewed by Filip Pizlo.

        CodeBlock::dumpSource() will access SourceCode strings in a way that requires
        ref'ing of the underlying StringImpls. This is unsafe to do from arbitrary
        compilation threads because StringImpls are not thread safe. As a result, we get
        an assertion failure when we run with JSC_dumpSourceAtDFGTime=true on a debug
        build.

        This patch fixes the issue by only collecting the CodeBlock (and associated info)
        into a DeferredSourceDump record while compiling, and stashing it away in a
        deferredSourceDump list in the DeferredCompilationCallback object to be dumped
        later.

        When compilation is done, the callback object will be notified that
        compilationDidComplete().  We will dump the SourceCode strings from there. 
        Since compilationDidComplete() is guaranteed to only be called on the thread
        doing JS execution, it is safe to access the SourceCode strings there and ref
        their underlying StringImpls as needed.        

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/DeferredCompilationCallback.cpp:
        (JSC::DeferredCompilationCallback::compilationDidComplete):
        (JSC::DeferredCompilationCallback::sourceDumpInfo):
        (JSC::DeferredCompilationCallback::dumpCompiledSources):
        * bytecode/DeferredCompilationCallback.h:
        * bytecode/DeferredSourceDump.cpp: Added.
        (JSC::DeferredSourceDump::DeferredSourceDump):
        (JSC::DeferredSourceDump::dump):
        * bytecode/DeferredSourceDump.h: Added.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):

2015-04-22  Benjamin Poulain  <benjamin@webkit.org>

        Implement String.codePointAt()
        https://bugs.webkit.org/show_bug.cgi?id=143934

        Reviewed by Darin Adler.

        This patch adds String.codePointAt() as defined by ES6.
        I opted for a C++ implementation for now.

        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::codePointAt):
        (JSC::stringProtoFuncCodePointAt):

2015-04-22  Mark Lam  <mark.lam@apple.com>

        SparseArrayEntry's write barrier owner should be the SparseArrayValueMap.
        https://bugs.webkit.org/show_bug.cgi?id=144067

        Reviewed by Michael Saboff.

        Currently, there are a few places where the JSObject that owns the
        SparseArrayValueMap is designated as the owner of the SparseArrayEntry
        write barrier.  This is a bug and can result in the GC collecting the
        SparseArrayEntry even though it is being referenced by the
        SparseArrayValueMap.  This patch fixes the bug.

        * runtime/JSObject.cpp:
        (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
        (JSC::JSObject::putIndexedDescriptor):
        * tests/stress/sparse-array-entry-update-144067.js: Added.
        (useMemoryToTriggerGCs):
        (foo):

2015-04-22  Mark Lam  <mark.lam@apple.com>

        Give the heap object iterators the ability to return early.
        https://bugs.webkit.org/show_bug.cgi?id=144011

        Reviewed by Michael Saboff.

        JSDollarVMPrototype::isValidCell() uses a heap object iterator to validate
        candidate cell pointers, and, when in use, is called a lot more often than
        the normal way those iterators are used.  As a result, I see my instrumented
        VM killed with a SIGXCPU (CPU time limit exceeded).  This patch gives the
        callback functor the ability to tell the iterators to return early when the
        functor no longer needs to continue iterating.  With this, my instrumented
        VM is useful again for debugging.

        Since heap iteration is not something that we do in a typical fast path,
        I don't expect this to have any noticeable impact on performance.

        I also renamed ObjectAddressCheckFunctor to CellAddressCheckFunctor since
        it checks JSCell addresses, not just JSObjects.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * debugger/Debugger.cpp:
        * heap/GCLogging.cpp:
        (JSC::LoggingFunctor::operator()):
        * heap/Heap.cpp:
        (JSC::Zombify::visit):
        (JSC::Zombify::operator()):
        * heap/HeapStatistics.cpp:
        (JSC::StorageStatistics::visit):
        (JSC::StorageStatistics::operator()):
        * heap/HeapVerifier.cpp:
        (JSC::GatherLiveObjFunctor::visit):
        (JSC::GatherLiveObjFunctor::operator()):
        * heap/MarkedBlock.cpp:
        (JSC::SetNewlyAllocatedFunctor::operator()):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::forEachCell):
        (JSC::MarkedBlock::forEachLiveCell):
        (JSC::MarkedBlock::forEachDeadCell):
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::forEachLiveCell):
        (JSC::MarkedSpace::forEachDeadCell):
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::TypeRecompiler::visit):
        (Inspector::TypeRecompiler::operator()):
        * runtime/IterationStatus.h: Added.
        * runtime/JSGlobalObject.cpp:
        * runtime/VM.cpp:
        (JSC::StackPreservingRecompiler::visit):
        (JSC::StackPreservingRecompiler::operator()):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
        (JSC::CellAddressCheckFunctor::operator()):
        (JSC::JSDollarVMPrototype::isValidCell):
        (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor): Deleted.
        (JSC::ObjectAddressCheckFunctor::operator()): Deleted.

2015-04-22  Yusuke Suzuki  <utatane.tea@gmail.com>

        [[Set]] should be properly executed in JS builtins
        https://bugs.webkit.org/show_bug.cgi?id=143996

        Reviewed by Geoffrey Garen.

        Currently, all assignments in builtins JS code is compiled into put_by_val_direct.
        However,

        1. Some functions (like Array.from) needs [[Set]]. (but it is now compiled into put_by_val_direct, [[DefineOwnProperty]]).
        2. It's different from the default JS behavior.

        In this patch, we implement the bytecode intrinsic emitting put_by_val_direct and use it explicitly.
        And dropping the current hack for builtins.

        * builtins/Array.prototype.js:
        (filter):
        (map):
        (find):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitPutByVal):
        * tests/stress/array-fill-put-by-val.js: Added.
        (shouldThrow):
        (.set get array):
        * tests/stress/array-filter-put-by-val-direct.js: Added.
        (shouldBe):
        (.set get var):
        * tests/stress/array-find-does-not-lookup-twice.js: Added.
        (shouldBe):
        (shouldThrow):
        (.get shouldBe):
        * tests/stress/array-from-put-by-val-direct.js: Added.
        (shouldBe):
        (.set get var):
        * tests/stress/array-from-set-length.js: Added.
        (shouldBe):
        (ArrayLike):
        (ArrayLike.prototype.set length):
        (ArrayLike.prototype.get length):
        * tests/stress/array-map-put-by-val-direct.js: Added.
        (shouldBe):
        (.set get var):

2015-04-22  Basile Clement  <basile_clement@apple.com>
 
        Don't de-allocate FunctionRareData
        https://bugs.webkit.org/show_bug.cgi?id=144000

        Reviewed by Michael Saboff.

        A function rare data (containing most notably its allocation profile) is currently
        freed and re-allocated each time the function's prototype is cleared.
        This is not optimal as it means we are invalidating the watchpoint and recompiling the
        scope each time the prototype is cleared.

        This makes it so that a single rare data is reused, clearing the underlying
        ObjectAllocationProfile instead of throwing away the whole rare data on
        .prototype updates.

        * runtime/FunctionRareData.cpp:
        (JSC::FunctionRareData::create):
        (JSC::FunctionRareData::finishCreation):
        * runtime/FunctionRareData.h:
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::allocateAndInitializeRareData):
        (JSC::JSFunction::initializeRareData):

2015-04-21  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix 32-bit. Forgot to make this simple change to 32_64 as well.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2015-04-21  Filip Pizlo  <fpizlo@apple.com>

        DFG should allow Phantoms after terminals
        https://bugs.webkit.org/show_bug.cgi?id=126778

        Reviewed by Mark Lam.
        
        It's important for us to be able to place liveness-marking nodes after nodes that do
        things. These liveness-marking nodes are nops. Previously, we disallowed such nodes after
        terminals. That made things awkward, especially for Switch and Branch, which may do
        things that necessitate liveness markers (for example they might want to use a converted
        version of a value rather than the value that was MovHinted). We previously made this
        work by disallowing certain optimizations on Switch and Branch, which was probably a bad
        thing.
        
        This changes our IR to allow for the terminal to not be the last node in a block. Asking
        for the terminal involves a search. DFG::validate() checks that the nodes after the
        terminal are liveness markers that have no effects or checks.
        
        This is perf-neutral but will allow more optimizations in the future. It will also make
        it cleaner to fix https://bugs.webkit.org/show_bug.cgi?id=143735.

        * dfg/DFGBasicBlock.cpp:
        (JSC::DFG::BasicBlock::replaceTerminal):
        * dfg/DFGBasicBlock.h:
        (JSC::DFG::BasicBlock::findTerminal):
        (JSC::DFG::BasicBlock::terminal):
        (JSC::DFG::BasicBlock::insertBeforeTerminal):
        (JSC::DFG::BasicBlock::numSuccessors):
        (JSC::DFG::BasicBlock::successor):
        (JSC::DFG::BasicBlock::successorForCondition):
        (JSC::DFG::BasicBlock::successors):
        (JSC::DFG::BasicBlock::last): Deleted.
        (JSC::DFG::BasicBlock::takeLast): Deleted.
        (JSC::DFG::BasicBlock::insertBeforeLast): Deleted.
        (JSC::DFG::BasicBlock::SuccessorsIterable::SuccessorsIterable): Deleted.
        (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::iterator): Deleted.
        (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator*): Deleted.
        (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator++): Deleted.
        (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator==): Deleted.
        (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator!=): Deleted.
        (JSC::DFG::BasicBlock::SuccessorsIterable::begin): Deleted.
        (JSC::DFG::BasicBlock::SuccessorsIterable::end): Deleted.
        * dfg/DFGBasicBlockInlines.h:
        (JSC::DFG::BasicBlock::appendNonTerminal):
        (JSC::DFG::BasicBlock::replaceTerminal):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addToGraph):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::linkBlock):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::run):
        (JSC::DFG::CFGSimplificationPhase::convertToJump):
        (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
        * dfg/DFGCommon.h:
        (JSC::DFG::NodeAndIndex::NodeAndIndex):
        (JSC::DFG::NodeAndIndex::operator!):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupBlock):
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
        (JSC::DFG::FixupPhase::clearPhantomsAtEnd): Deleted.
        * dfg/DFGForAllKills.h:
        (JSC::DFG::forAllLiveNodesAtTail):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::terminalsAreValid):
        (JSC::DFG::Graph::dumpBlockHeader):
        * dfg/DFGGraph.h:
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::run):
        (JSC::DFG::LICMPhase::attemptHoist):
        * dfg/DFGMovHintRemovalPhase.cpp:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::SuccessorsIterable::SuccessorsIterable):
        (JSC::DFG::Node::SuccessorsIterable::iterator::iterator):
        (JSC::DFG::Node::SuccessorsIterable::iterator::operator*):
        (JSC::DFG::Node::SuccessorsIterable::iterator::operator++):
        (JSC::DFG::Node::SuccessorsIterable::iterator::operator==):
        (JSC::DFG::Node::SuccessorsIterable::iterator::operator!=):
        (JSC::DFG::Node::SuccessorsIterable::begin):
        (JSC::DFG::Node::SuccessorsIterable::end):
        (JSC::DFG::Node::successors):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
        (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
        (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
        * dfg/DFGPhantomRemovalPhase.cpp:
        (JSC::DFG::PhantomRemovalPhase::run):
        * dfg/DFGPutStackSinkingPhase.cpp:
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStaticExecutionCountEstimationPhase.cpp:
        (JSC::DFG::StaticExecutionCountEstimationPhase::run):
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validate):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        * tests/stress/closure-call-exit.js: Added.
        (foo):

2015-04-21  Basile Clement  <basile_clement@apple.com>

        PhantomNewObject should be marked NodeMustGenerate
        https://bugs.webkit.org/show_bug.cgi?id=143974

        Reviewed by Filip Pizlo.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToPhantomNewObject):
        Was not properly marking NodeMustGenerate when converting.

2015-04-21  Filip Pizlo  <fpizlo@apple.com>

        DFG Call/ConstructForwardVarargs fails to restore the stack pointer
        https://bugs.webkit.org/show_bug.cgi?id=144007

        Reviewed by Mark Lam.
        
        We were conditioning the stack pointer restoration on isVarargs, but we also need to do it
        if isForwardVarargs.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * tests/stress/varargs-then-slow-call.js: Added.
        (foo):
        (bar):
        (fuzz):
        (baz):

2015-04-21  Basile Clement  <basile_clement@apple.com>

        Remove AllocationProfileWatchpoint node
        https://bugs.webkit.org/show_bug.cgi?id=143999

        Reviewed by Filip Pizlo.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasCellOperand):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGWatchpointCollectionPhase.cpp:
        (JSC::DFG::WatchpointCollectionPhase::handle):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        * runtime/JSFunction.h:
        (JSC::JSFunction::rareData):
        (JSC::JSFunction::allocationProfileWatchpointSet): Deleted.

2015-04-19  Filip Pizlo  <fpizlo@apple.com>

        MovHint should be a strong use
        https://bugs.webkit.org/show_bug.cgi?id=143734

        Reviewed by Geoffrey Garen.
        
        This disables any DCE that assumes equivalence between DFG IR uses and bytecode uses. Doing
        so is a major step towards allowing more fancy DFG transformations and also probably fixing
        some bugs.
        
        Just making MovHint a strong use would also completely disable DCE. So we mitigate this by
        introducing a MovHint removal phase that runs in FTL.
        
        This is a slight slowdown on Octane/gbemu, but it's basically neutral on suite averages.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeOrigin.cpp:
        (JSC::InlineCallFrame::dumpInContext):
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::fixupBlock):
        * dfg/DFGDisassembler.cpp:
        (JSC::DFG::Disassembler::createDumpList):
        * dfg/DFGEpoch.cpp: Added.
        (JSC::DFG::Epoch::dump):
        * dfg/DFGEpoch.h: Added.
        (JSC::DFG::Epoch::Epoch):
        (JSC::DFG::Epoch::first):
        (JSC::DFG::Epoch::operator!):
        (JSC::DFG::Epoch::next):
        (JSC::DFG::Epoch::bump):
        (JSC::DFG::Epoch::operator==):
        (JSC::DFG::Epoch::operator!=):
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGMovHintRemovalPhase.cpp: Added.
        (JSC::DFG::performMovHintRemoval):
        * dfg/DFGMovHintRemovalPhase.h: Added.
        * dfg/DFGNodeType.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * runtime/Options.h:

2015-04-21  Basile Clement  <basile_clement@apple.com>

        REGRESSION (r182899): icloud.com crashes
        https://bugs.webkit.org/show_bug.cgi?id=143960

        Reviewed by Filip Pizlo.

        * runtime/JSFunction.h:
        (JSC::JSFunction::allocationStructure):
        * tests/stress/dfg-rare-data.js: Added.
        (F): Regression test

2015-04-21  Michael Saboff  <msaboff@apple.com>

        Crash in JSC::Interpreter::execute
        https://bugs.webkit.org/show_bug.cgi?id=142625

        Reviewed by Filip Pizlo.

        We need to keep the FunctionExecutables in the code block for the eval flavor of 
        Interpreter::execute() in order to create the scope used to eval.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::jettisonFunctionDeclsAndExprs): Deleted.
        * bytecode/CodeBlock.h:
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::registerFrozenValues):

2015-04-21  Chris Dumez  <cdumez@apple.com>

        Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&) constructor explicit
        https://bugs.webkit.org/show_bug.cgi?id=143970

        Reviewed by Darin Adler.

        Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&)
        constructor explicit as it copies the vector and it is easy to call it
        by mistake.

        * bytecode/UnlinkedInstructionStream.cpp:
        (JSC::UnlinkedInstructionStream::UnlinkedInstructionStream):
        * bytecode/UnlinkedInstructionStream.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::lower):

2015-04-20  Basile Clement  <basile_clement@apple.com>

        PhantomNewObject should be marked NodeMustGenerate
        https://bugs.webkit.org/show_bug.cgi?id=143974

        Reviewed by Filip Pizlo.

        * dfg/DFGNodeType.h: Mark PhantomNewObject as NodeMustGenerate

2015-04-20  Joseph Pecoraro  <pecoraro@apple.com>

        Cleanup some StringBuilder use
        https://bugs.webkit.org/show_bug.cgi?id=143550

        Reviewed by Darin Adler.

        * runtime/Symbol.cpp:
        (JSC::Symbol::descriptiveString):
        * runtime/TypeProfiler.cpp:
        (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::toJSONString):
        (JSC::StructureShape::propertyHash):
        (JSC::StructureShape::stringRepresentation):
        (JSC::StructureShape::toJSONString):

2015-04-20  Mark Lam  <mark.lam@apple.com>

        Add debugging tools to test if a given pointer is a valid object and in the heap.
        https://bugs.webkit.org/show_bug.cgi?id=143910

        Reviewed by Geoffrey Garen.

        When doing debugging from lldb, sometimes, it is useful to be able to tell if a
        purported JSObject is really a valid object in the heap or not.  We can add the
        following utility functions to help:
            isValidCell(heap, candidate) - returns true if the candidate is a "live" cell in the heap.
            isInHeap(heap, candidate) - returns true if the candidate is the heap's Object space or Storage space.
            isInObjectSpace(heap, candidate) - returns true if the candidate is the heap's Object space.
            isInStorageSpace(heap, candidate) - returns true if the candidate is the heap's Storage space.

        Also moved lldb callable debug utility function prototypes from
        JSDollarVMPrototype.cpp to JSDollarVMPrototype.h as static members of the
        JSDollarVMPrototype class.  This is so that we can conveniently #include that
        file to get the prototypes when we need to call them programmatically from
        instrumentation that we add while debugging an issue.

        * heap/Heap.h:
        (JSC::Heap::storageSpace):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::JSDollarVMPrototype::currentThreadOwnsJSLock):
        (JSC::ensureCurrentThreadOwnsJSLock):
        (JSC::JSDollarVMPrototype::gc):
        (JSC::functionGC):
        (JSC::JSDollarVMPrototype::edenGC):
        (JSC::functionEdenGC):
        (JSC::JSDollarVMPrototype::isInHeap):
        (JSC::JSDollarVMPrototype::isInObjectSpace):
        (JSC::JSDollarVMPrototype::isInStorageSpace):
        (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor):
        (JSC::ObjectAddressCheckFunctor::operator()):
        (JSC::JSDollarVMPrototype::isValidCell):
        (JSC::JSDollarVMPrototype::isValidCodeBlock):
        (JSC::JSDollarVMPrototype::codeBlockForFrame):
        (JSC::functionCodeBlockForFrame):
        (JSC::codeBlockFromArg):
        (JSC::JSDollarVMPrototype::printCallFrame):
        (JSC::JSDollarVMPrototype::printStack):
        (JSC::JSDollarVMPrototype::printValue):
        (JSC::currentThreadOwnsJSLock): Deleted.
        (JSC::gc): Deleted.
        (JSC::edenGC): Deleted.
        (JSC::isValidCodeBlock): Deleted.
        (JSC::codeBlockForFrame): Deleted.
        (JSC::printCallFrame): Deleted.
        (JSC::printStack): Deleted.
        (JSC::printValue): Deleted.
        * tools/JSDollarVMPrototype.h:

2015-04-20  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Improve Support for WeakSet in Console
        https://bugs.webkit.org/show_bug.cgi?id=143951

        Reviewed by Darin Adler.

        * inspector/InjectedScriptSource.js:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        (Inspector::JSInjectedScriptHost::weakSetSize):
        (Inspector::JSInjectedScriptHost::weakSetEntries):
        * inspector/JSInjectedScriptHost.h:
        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetSize):
        (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetEntries):
        Treat WeakSets like special sets.

        * inspector/protocol/Runtime.json:
        Add a new object subtype, "weakset".

2015-04-20  Yusuke Suzuki  <utatane.tea@gmail.com>

        HashMap storing PropertyKey StringImpl* need to use IdentifierRepHash to handle Symbols
        https://bugs.webkit.org/show_bug.cgi?id=143947

        Reviewed by Darin Adler.

        Type profiler has map between PropertyKey (StringImpl*) and offset.
        StringImpl* is also used for Symbol PropertyKey.
        So equality of hash tables is considered by interned StringImpl*'s pointer value.
        To do so, use IdentifierRepHash instead of StringHash.

        * runtime/SymbolTable.h:

2015-04-20  Jordan Harband  <ljharb@gmail.com>

        Implement `Object.is`
        https://bugs.webkit.org/show_bug.cgi?id=143865

        Reviewed by Darin Adler.

        Expose sameValue to JS, via Object.is
        https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.is

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorIs):
        * runtime/PropertyDescriptor.cpp:
        (JSC::sameValue):

2015-04-19  Darin Adler  <darin@apple.com>

        Remove all the remaining uses of OwnPtr and PassOwnPtr in JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=143941

        Reviewed by Gyuyoung Kim.

        * API/JSCallbackObject.h: Use unique_ptr for m_callbackObjectData.
        * API/JSCallbackObjectFunctions.h: Ditto.

        * API/ObjCCallbackFunction.h: Use unique_ptr for the arguments to the
        create function and the constructor and for m_impl.
        * API/ObjCCallbackFunction.mm:
        (CallbackArgumentOfClass::CallbackArgumentOfClass): Streamline this
        class by using RetainPtr<Class>.
        (ArgumentTypeDelegate::typeInteger): Use make_unique.
        (ArgumentTypeDelegate::typeDouble): Ditto.
        (ArgumentTypeDelegate::typeBool): Ditto.
        (ArgumentTypeDelegate::typeVoid): Ditto.
        (ArgumentTypeDelegate::typeId): Ditto.
        (ArgumentTypeDelegate::typeOfClass): Ditto.
        (ArgumentTypeDelegate::typeBlock): Ditto.
        (ArgumentTypeDelegate::typeStruct): Ditto.
        (ResultTypeDelegate::typeInteger): Ditto.
        (ResultTypeDelegate::typeDouble): Ditto.
        (ResultTypeDelegate::typeBool): Ditto.
        (ResultTypeDelegate::typeVoid): Ditto.
        (ResultTypeDelegate::typeId): Ditto.
        (ResultTypeDelegate::typeOfClass): Ditto.
        (ResultTypeDelegate::typeBlock): Ditto.
        (ResultTypeDelegate::typeStruct): Ditto.
        (JSC::ObjCCallbackFunctionImpl::ObjCCallbackFunctionImpl): Use
        unique_ptr for the arguments to the constructor, m_arguments, and m_result.
        Use RetainPtr<Class> for m_instanceClass.
        (JSC::objCCallbackFunctionCallAsConstructor): Use nullptr instead of nil or 0
        for non-Objective-C object pointer null.
        (JSC::ObjCCallbackFunction::ObjCCallbackFunction): Use unique_ptr for
        the arguments to the constructor and for m_impl.
        (JSC::ObjCCallbackFunction::create): Use unique_ptr for arguments.
        (skipNumber): Mark this static since it's local to this source file.
        (objCCallbackFunctionForInvocation): Call parseObjCType without doing any
        explicit adoptPtr since the types in the traits are now unique_ptr. Also use
        nullptr instead of nil for JSObjectRef values.
        (objCCallbackFunctionForMethod): Tweaked comment.
        (objCCallbackFunctionForBlock): Use nullptr instead of 0 for JSObjectRef.

        * bytecode/CallLinkInfo.h: Removed unneeded include of OwnPtr.h.

        * heap/GCThread.cpp:
        (JSC::GCThread::GCThread): Use unique_ptr.
        * heap/GCThread.h: Use unique_ptr for arguments to the constructor and for
        m_slotVisitor and m_copyVisitor.
        * heap/GCThreadSharedData.cpp:
        (JSC::GCThreadSharedData::GCThreadSharedData): Ditto.

        * parser/SourceProvider.h: Removed unneeded include of PassOwnPtr.h.

2015-04-19  Benjamin Poulain  <benjamin@webkit.org>

        Improve the feature.json files

        * features.json:

2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>

        Introduce bytecode intrinsics
        https://bugs.webkit.org/show_bug.cgi?id=143926

        Reviewed by Filip Pizlo.

        This patch introduces bytecode level intrinsics into builtins/*.js JS code.
        When implementing functions in builtins/*.js,
        sometimes we require lower level functionality.

        For example, in the current Array.from, we use `result[k] = value`.
        The spec requires `[[DefineOwnProperty]]` operation here.
        However, usual `result[k] = value` is evaluated as `[[Set]]`. (`PutValue` => `[[Set]]`)
        So if we implement `Array.prototype[k]` getter/setter, the difference is observable.

        Ideally, reaching here, we would like to use put_by_val_direct bytecode.
        However, there's no syntax to generate it directly.

        This patch introduces bytecode level intrinsics into JSC BytecodeCompiler.
        Like @call, @apply, we introduce a new node, Intrinsic.
        These are generated when calling appropriate private symbols in privileged code.
        AST parser detects them and generates Intrinsic nodes and
        BytecodeCompiler detects them and generate required bytecodes.

        Currently, Array.from implementation works fine without this patch.
        This is because when the target code is builtin JS,
        BytecodeGenerator emits put_by_val_direct instead of put_by_val.
        This solves the above issue. However, instead of solving this issue,
        it raises another issue; There's no way to emit `[[Set]]` operation.
        `[[Set]]` operation is actually used in the spec (Array.from's "length" is set by `[[Set]]`).
        So to implement it precisely, introducing bytecode level intrinsics is necessary.

        In the subsequent fixes, we'll remove that special path emitting put_by_val_direct
        for `result[k] = value` under builtin JS environment. Instead of that special handling,
        use bytecode intrinsics instead. It solves problems and it is more intuitive
        because written JS code in builtin works as the same to the usual JS code.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ArrayConstructor.js:
        (from):
        * bytecode/BytecodeIntrinsicRegistry.cpp: Added.
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        (JSC::BytecodeIntrinsicRegistry::lookup):
        * bytecode/BytecodeIntrinsicRegistry.h: Added.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emitBytecode):
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByValDirect):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::makeFunctionCallNode):
        * parser/NodeConstructors.h:
        (JSC::BytecodeIntrinsicNode::BytecodeIntrinsicNode):
        * parser/Nodes.h:
        (JSC::BytecodeIntrinsicNode::identifier):
        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::CommonIdentifiers):
        * runtime/CommonIdentifiers.h:
        (JSC::CommonIdentifiers::bytecodeIntrinsicRegistry):
        * tests/stress/array-from-with-accessors.js: Added.
        (shouldBe):

2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>

        Make Builtin functions non constructible
        https://bugs.webkit.org/show_bug.cgi?id=143923

        Reviewed by Darin Adler.

        Builtin functions defined by builtins/*.js accidentally have [[Construct]].
        According to the spec, these functions except for explicitly defined as a constructor do not have [[Construct]].
        This patch fixes it. When the JS function used for a construction is builtin function, throw not a constructor error.

        Ideally, returning ConstructTypeNone in JSFunction::getConstructData is enough.
        However, to avoid calling getConstructData (it involves indirect call of function pointer of getConstructData), some places do not check ConstructType.
        In these places, they only check the target function is JSFunction because previously JSFunction always has [[Construct]].
        So in this patch, we check `isBuiltinFunction()` in those places.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::inliningCost):
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setUpCall):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getConstructData):
        * tests/stress/builtin-function-is-construct-type-none.js: Added.
        (shouldThrow):

2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement WeakSet
        https://bugs.webkit.org/show_bug.cgi?id=142408

        Reviewed by Darin Adler.

        This patch implements ES6 WeakSet.
        Current implementation simply leverages WeakMapData with undefined value.
        This WeakMapData should be optimized in the same manner as MapData/SetData in the subsequent patch[1].

        And in this patch, we also fix WeakMap/WeakSet behavior to conform the ES6 spec.
        Except for adders (WeakMap.prototype.set/WeakSet.prototype.add),
        methods return false (or undefined for WeakMap.prototype.get)
        when a key is not Object instead of throwing a type error.

        [1]: https://bugs.webkit.org/show_bug.cgi?id=143919

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
        * runtime/JSWeakSet.cpp: Added.
        (JSC::JSWeakSet::finishCreation):
        (JSC::JSWeakSet::visitChildren):
        * runtime/JSWeakSet.h: Added.
        (JSC::JSWeakSet::createStructure):
        (JSC::JSWeakSet::create):
        (JSC::JSWeakSet::weakMapData):
        (JSC::JSWeakSet::JSWeakSet):
        * runtime/WeakMapPrototype.cpp:
        (JSC::getWeakMapData):
        (JSC::protoFuncWeakMapDelete):
        (JSC::protoFuncWeakMapGet):
        (JSC::protoFuncWeakMapHas):
        * runtime/WeakSetConstructor.cpp: Added.
        (JSC::WeakSetConstructor::finishCreation):
        (JSC::callWeakSet):
        (JSC::constructWeakSet):
        (JSC::WeakSetConstructor::getConstructData):
        (JSC::WeakSetConstructor::getCallData):
        * runtime/WeakSetConstructor.h: Added.
        (JSC::WeakSetConstructor::create):
        (JSC::WeakSetConstructor::createStructure):
        (JSC::WeakSetConstructor::WeakSetConstructor):
        * runtime/WeakSetPrototype.cpp: Added.
        (JSC::WeakSetPrototype::finishCreation):
        (JSC::getWeakMapData):
        (JSC::protoFuncWeakSetDelete):
        (JSC::protoFuncWeakSetHas):
        (JSC::protoFuncWeakSetAdd):
        * runtime/WeakSetPrototype.h: Added.
        (JSC::WeakSetPrototype::create):
        (JSC::WeakSetPrototype::createStructure):
        (JSC::WeakSetPrototype::WeakSetPrototype):
        * tests/stress/weak-set-constructor-adder.js: Added.
        (WeakSet.prototype.add):
        * tests/stress/weak-set-constructor.js: Added.

2015-04-17  Alexey Proskuryakov  <ap@apple.com>

        Remove unused BoundsCheckedPointer
        https://bugs.webkit.org/show_bug.cgi?id=143896

        Reviewed by Geoffrey Garen.

        * bytecode/SpeculatedType.cpp: The header was included here.

2015-04-17  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Fix name enumeration of static functions for Symbol constructor
        https://bugs.webkit.org/show_bug.cgi?id=143891

        Reviewed by Geoffrey Garen.

        Fix missing symbolPrototypeTable registration to the js class object.
        This patch fixes name enumeration of static functions (Symbol.key, Symbol.keyFor) for Symbol constructor.

        * runtime/SymbolConstructor.cpp:

2015-04-17  Basile Clement  <basile_clement@apple.com>

        Inline JSFunction allocation in DFG
        https://bugs.webkit.org/show_bug.cgi?id=143858

        Reviewed by Filip Pizlo.

        Followup to my previous patch which inlines JSFunction allocation when
        using FTL, now also enabled in DFG.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunction):

2015-04-16  Jordan Harband  <ljharb@gmail.com>

        Number.parseInt is not === global parseInt in nightly r182673
        https://bugs.webkit.org/show_bug.cgi?id=143799

        Reviewed by Darin Adler.

        Ensuring parseInt === Number.parseInt, per spec
        https://people.mozilla.org/~jorendorff/es6-draft.html#sec-number.parseint

        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::parseIntFunction):
        * runtime/NumberConstructor.cpp:
        (JSC::NumberConstructor::finishCreation):

2015-04-16  Mark Lam  <mark.lam@apple.com>

        Gardening: fix CLOOP build after r182927.

        Not reviewed.

        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::print):

2015-04-16  Basile Clement  <basile_clement@apple.com>

        Inline JSFunction allocation in FTL
        https://bugs.webkit.org/show_bug.cgi?id=143851

        Reviewed by Filip Pizlo.

        JSFunction allocation is a simple operation that should be inlined when possible.

        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNewFunction):
        * runtime/JSFunction.h:
        (JSC::JSFunction::allocationSize):

2015-04-16  Mark Lam  <mark.lam@apple.com>

        Add $vm debugging tool.
        https://bugs.webkit.org/show_bug.cgi?id=143809

        Reviewed by Geoffrey Garen.

        For debugging VM bugs, it would be useful to be able to dump VM data structures
        from JS code that we instrument.  To this end, let's introduce a
        JS_enableDollarVM option that, if true, installs an $vm property into each JS
        global object at creation time.  The $vm property refers to an object that
        provides a collection of useful utility functions.  For this initial
        implementation, $vm will have the following:

            crash() - trigger an intentional crash.

            dfgTrue() - returns true if the current function is DFG compiled, else returns false.
            jitTrue() - returns true if the current function is compiled by the baseline JIT, else returns false.
            llintTrue() - returns true if the current function is interpreted by the LLINT, else returns false.

            gc() - runs a full GC.
            edenGC() - runs an eden GC.

            codeBlockForFrame(frameNumber) - gets the codeBlock at the specified frame (0 = current, 1 = caller, etc).
            printSourceFor(codeBlock) - prints the source code for the codeBlock.
            printByteCodeFor(codeBlock) - prints the bytecode for the codeBlock.

            print(str) - prints a string to dataLog output.
            printCallFrame() - prints the current CallFrame.
            printStack() - prints the JS stack.
            printInternal(value) - prints the JSC internal info for the specified value.

        With JS_enableDollarVM=true, JS code can use the above functions like so:

            $vm.print("Using $vm features\n");

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printCallOp):
        - FTL compiled functions don't like it when we try to compute the CallLinkStatus.
          Hence, we skip this step if we're dumping an FTL codeBlock.

        * heap/Heap.cpp:
        (JSC::Heap::collectAndSweep):
        (JSC::Heap::collectAllGarbage): Deleted.
        * heap/Heap.h:
        (JSC::Heap::collectAllGarbage):
        - Add ability to do an Eden collection and sweep.

        * interpreter/StackVisitor.cpp:
        (JSC::printIndents):
        (JSC::log):
        (JSC::logF):
        (JSC::StackVisitor::Frame::print):
        (JSC::jitTypeName): Deleted.
        (JSC::printif): Deleted.
        - Modernize the implementation of StackVisitor::Frame::print(), and remove some
          now redundant code.
        - Also fix it so that it downgrades gracefully when encountering inlined DFG
          and compiled FTL functions.

        (DebugPrintFrameFunctor::DebugPrintFrameFunctor): Deleted.
        (DebugPrintFrameFunctor::operator()): Deleted.
        (debugPrintCallFrame): Deleted.
        (debugPrintStack): Deleted.
        - these have been moved into JSDollarVMPrototype.cpp. 

        * interpreter/StackVisitor.h:
        - StackVisitor::Frame::print() is now enabled for release builds as well so that
          we can call it from $vm.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        - Added the $vm instance to global objects conditional on the JSC_enableDollarVM
          option.

        * runtime/Options.h:
        - Added the JSC_enableDollarVM option.

        * tools/JSDollarVM.cpp: Added.
        * tools/JSDollarVM.h: Added.
        (JSC::JSDollarVM::createStructure):
        (JSC::JSDollarVM::create):
        (JSC::JSDollarVM::JSDollarVM):

        * tools/JSDollarVMPrototype.cpp: Added.
        - This file contains 2 sets of functions:

          a. a C++ implementation of debugging utility functions that are callable when
             doing debugging from lldb.  To the extent possible, these functions try to
             be cautious and not cause unintended crashes should the user call them with
             the wrong info.  Hence, they are designed to be robust rather than speedy.

          b. the native implementations of JS functions in the $vm object.  Where there
             is overlapping functionality, these are built on top of the C++ functions
             above to do the work.

          Note: it does not make sense for all of the $vm functions to have a C++
          counterpart for lldb debugging.  For example, the $vm.dfgTrue() function is
          only useful for JS code, and works via the DFG intrinsics mechanism.
          When doing debugging via lldb, the optimization level of the currently
          executing JS function can be gotten by dumping the current CallFrame instead.

        (JSC::currentThreadOwnsJSLock):
        (JSC::ensureCurrentThreadOwnsJSLock):
        (JSC::JSDollarVMPrototype::addFunction):
        (JSC::functionCrash): - $vm.crash()
        (JSC::functionDFGTrue): - $vm.dfgTrue()
        (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
        (JSC::CallerFrameJITTypeFunctor::operator()):
        (JSC::CallerFrameJITTypeFunctor::jitType):
        (JSC::functionLLintTrue): - $vm.llintTrue()
        (JSC::functionJITTrue): - $vm.jitTrue()
        (JSC::gc):
        (JSC::functionGC): - $vm.gc()
        (JSC::edenGC):
        (JSC::functionEdenGC): - $vm.edenGC()
        (JSC::isValidCodeBlock):
        (JSC::codeBlockForFrame):
        (JSC::functionCodeBlockForFrame): - $vm.codeBlockForFrame(frameNumber)
        (JSC::codeBlockFromArg):
        (JSC::functionPrintSourceFor): - $vm.printSourceFor(codeBlock)
        (JSC::functionPrintByteCodeFor): - $vm.printBytecodeFor(codeBlock)
        (JSC::functionPrint): - $vm.print(str)
        (JSC::PrintFrameFunctor::PrintFrameFunctor):
        (JSC::PrintFrameFunctor::operator()):
        (JSC::printCallFrame):
        (JSC::printStack):
        (JSC::functionPrintCallFrame): - $vm.printCallFrame()
        (JSC::functionPrintStack): - $vm.printStack()
        (JSC::printValue):
        (JSC::functionPrintValue): - $vm.printValue()
        (JSC::JSDollarVMPrototype::finishCreation):
        * tools/JSDollarVMPrototype.h: Added.
        (JSC::JSDollarVMPrototype::create):
        (JSC::JSDollarVMPrototype::createStructure):
        (JSC::JSDollarVMPrototype::JSDollarVMPrototype):

2015-04-16  Geoffrey Garen  <ggaren@apple.com>

        Speculative fix after r182915
        https://bugs.webkit.org/show_bug.cgi?id=143404

        Reviewed by Alexey Proskuryakov.

        * runtime/SymbolConstructor.h:

2015-04-16  Mark Lam  <mark.lam@apple.com>

        Fixed some typos in a comment.

        Not reviewed.

        * dfg/DFGGenerationInfo.h:

2015-04-16  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement Symbol.for and Symbol.keyFor
        https://bugs.webkit.org/show_bug.cgi?id=143404

        Reviewed by Geoffrey Garen.

        This patch implements Symbol.for and Symbol.keyFor.
        SymbolRegistry maintains registered StringImpl* symbols.
        And to make this mapping enabled over realms,
        VM owns this mapping (not JSGlobalObject).

        While there's Default AtomicStringTable per thread,
        SymbolRegistry should not exist over VMs.
        So everytime VM is created, SymbolRegistry is also created.

        In SymbolRegistry implementation, we don't leverage WeakGCMap (or weak reference design).
        Theres are several reasons.
        1. StringImpl* which represents identity of Symbols is not GC-managed object.
           So we cannot use WeakGCMap directly.
           While Symbol* is GC-managed object, holding weak reference to Symbol* doesn't maintain JS symbols (exposed primitive values to users) liveness,
           because distinct Symbol* can exist.
           Distinct Symbol* means the Symbol* object that pointer value (Symbol*) is different from weakly referenced Symbol* but held StringImpl* is the same.

        2. We don't use WTF::WeakPtr. If we add WeakPtrFactory into StringImpl's member, we can track StringImpl*'s liveness by WeakPtr.
           However there's problem about when we prune staled entries in SymbolRegistry.
           Since the memory allocated for the Symbol is typically occupied by allocated symbolized StringImpl*'s content,
           and it is not in GC-heap.
           While heavily registering Symbols and storing StringImpl* into SymbolRegistry, Heap's EdenSpace is not so occupied.
           So GC typically attempt to perform EdenCollection, and it doesn't call WeakGCMap's pruleStaleEntries callback.
           As a result, before pruning staled entries in SymbolRegistry, fast malloc-ed memory fills up the system memory.

        So instead of using Weak reference, we take relatively easy design.
        When we register symbolized StringImpl* into SymbolRegistry, symbolized StringImpl* is aware of that.
        And when destructing it, it removes its reference from SymbolRegistry as if atomic StringImpl do so with AtomicStringTable.

        * CMakeLists.txt:
        * DerivedSources.make:
        * runtime/SymbolConstructor.cpp:
        (JSC::SymbolConstructor::getOwnPropertySlot):
        (JSC::symbolConstructorFor):
        (JSC::symbolConstructorKeyFor):
        * runtime/SymbolConstructor.h:
        * runtime/VM.cpp:
        * runtime/VM.h:
        (JSC::VM::symbolRegistry):
        * tests/stress/symbol-registry.js: Added.
        (test):

2015-04-16  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Use specific functions for @@iterator functions
        https://bugs.webkit.org/show_bug.cgi?id=143838

        Reviewed by Geoffrey Garen.

        In ES6, some methods are defined with the different names.

        For example,

        Map.prototype[Symbol.iterator] === Map.prototype.entries
        Set.prototype[Symbol.iterator] === Set.prototype.values
        Array.prototype[Symbol.iterator] === Array.prototype.values
        %Arguments%[Symbol.iterator] === Array.prototype.values

        However, current implementation creates different function objects per name.
        This patch fixes it by setting the object that is used for the other method to @@iterator.
        e.g. Setting Array.prototype.values function object to Array.prototype[Symbol.iterator].

        And we drop Arguments' iterator implementation and replace Argument[@@iterator] implementation
        with Array.prototype.values to conform to the spec.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        (Inspector::JSInjectedScriptHost::iteratorEntries):
        * runtime/ArgumentsIteratorConstructor.cpp: Removed.
        * runtime/ArgumentsIteratorConstructor.h: Removed.
        * runtime/ArgumentsIteratorPrototype.cpp: Removed.
        * runtime/ArgumentsIteratorPrototype.h: Removed.
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        * runtime/ArrayPrototype.h:
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::getOwnPropertySlot):
        (JSC::ClonedArguments::put):
        (JSC::ClonedArguments::deleteProperty):
        (JSC::ClonedArguments::defineOwnProperty):
        (JSC::ClonedArguments::materializeSpecials):
        * runtime/ClonedArguments.h:
        * runtime/CommonIdentifiers.h:
        * runtime/DirectArguments.cpp:
        (JSC::DirectArguments::overrideThings):
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::getOwnPropertySlot):
        (JSC::GenericArguments<Type>::getOwnPropertyNames):
        (JSC::GenericArguments<Type>::put):
        (JSC::GenericArguments<Type>::deleteProperty):
        (JSC::GenericArguments<Type>::defineOwnProperty):
        * runtime/JSArgumentsIterator.cpp: Removed.
        * runtime/JSArgumentsIterator.h: Removed.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::arrayProtoValuesFunction):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/ScopedArguments.cpp:
        (JSC::ScopedArguments::overrideThings):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        * tests/stress/arguments-iterator.js: Added.
        (test):
        (testArguments):
        * tests/stress/iterator-functions.js: Added.
        (test):
        (argumentsTests):

2015-04-14  Mark Lam  <mark.lam@apple.com>

        Add JSC_functionOverrides=<overrides file> debugging tool.
        https://bugs.webkit.org/show_bug.cgi?id=143717

        Reviewed by Geoffrey Garen.

        This tool allows us to do runtime replacement of function bodies with alternatives
        for debugging purposes.  For example, this is useful when we need to debug VM bugs
        which manifest in scripts executing in webpages downloaded from remote servers
        that we don't control.  The tool allows us to augment those scripts with logging
        or test code to help isolate the bugs.

        This tool works by substituting the SourceCode at FunctionExecutable creation
        time.  It identifies which SourceCode to substitute by comparing the source
        string against keys in a set of key value pairs.

        The keys are function body strings defined by 'override' clauses in the overrides
        file specified by in the JSC_functionOverrides option.  The values are function
        body strings defines by 'with' clauses in the overrides file.
        See comment blob at top of FunctionOverrides.cpp on the formatting
        of the overrides file.

        At FunctionExecutable creation time, if the SourceCode string matches one of the
        'override' keys from the overrides file, the tool will replace the SourceCode with
        a new one based on the corresponding 'with' value string.  The FunctionExecutable
        will then be created with the new SourceCode instead.

        Some design decisions:
        1. We opted to require that the 'with' clause appear on a separate line than the
           'override' clause because this makes it easier to read and write when the
           'override' clause's function body is single lined and long.

        2. The user can use any sequence of characters for the delimiter (except for '{',
           '}' and white space characters) because this ensures that there can always be
           some delimiter pattern that does not appear in the function body in the clause
           e.g. in the body of strings in the JS code.

           '{' and '}' are disallowed because they are used to mark the boundaries of the
           function body string.  White space characters are disallowed because they can
           be error prone (the user may not be able to tell between spaces and tabs).

        3. The start and end delimiter must be an identical sequence of characters.

           I had considered allowing the use of complementary characters like <>, [], and
           () for making delimiter pairs like:
               [[[[ ... ]]]]
               <[([( ... )])]>

           But in the end, decided against it because:
           a. These sequences of complementary characters can exists in JS code.
              In contrast, a repeating delimiter like %%%% is unlikely to appear in JS
              code.
           b. It can be error prone for the user to have to type the exact complement
              character for the end delimiter in reverse order.
              In contrast, a repeating delimiter like %%%% is much easier to type and
              less error prone.  Even a sequence like @#$%^ is less error prone than
              a complementary sequence because it can be copy-pasted, and need not be
              typed in reverse order.
           c. It is easier to parse for the same delimiter string for both start and end.

        4. The tool does a lot of checks for syntax errors in the overrides file because
           we don't want any overrides to fail silently.  If a syntax error is detected,
           the tool will print an error message and call exit().  This avoids the user
           wasting time doing debugging only to be surprised later that their specified
           overrides did not take effect because of some unnoticed typo.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::link):
        * runtime/Executable.h:
        * runtime/Options.h:
        * tools/FunctionOverrides.cpp: Added.
        (JSC::FunctionOverrides::overrides):
        (JSC::FunctionOverrides::FunctionOverrides):
        (JSC::initializeOverrideInfo):
        (JSC::FunctionOverrides::initializeOverrideFor):
        (JSC::hasDisallowedCharacters):
        (JSC::parseClause):
        (JSC::FunctionOverrides::parseOverridesInFile):
        * tools/FunctionOverrides.h: Added.

2015-04-16  Basile Clement  <basile_clement@apple.com>
 
        Extract the allocation profile from JSFunction into a rare object
        https://bugs.webkit.org/show_bug.cgi?id=143807
 
        Reviewed by Filip Pizlo.
 
        The allocation profile is only needed for those functions that are used
        to create objects with [new].
        Extracting it into its own JSCell removes the need for JSFunction and
        JSCallee to be JSDestructibleObjects, which should improve performances in most
        cases at the cost of an extra pointer dereference when the allocation profile
        is actually needed.
 
        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_create_this):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_create_this):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/FunctionRareData.cpp: Added.
        (JSC::FunctionRareData::create):
        (JSC::FunctionRareData::destroy):
        (JSC::FunctionRareData::createStructure):
        (JSC::FunctionRareData::visitChildren):
        (JSC::FunctionRareData::FunctionRareData):
        (JSC::FunctionRareData::~FunctionRareData):
        (JSC::FunctionRareData::finishCreation):
        * runtime/FunctionRareData.h: Added.
        (JSC::FunctionRareData::offsetOfAllocationProfile):
        (JSC::FunctionRareData::allocationProfile):
        (JSC::FunctionRareData::allocationStructure):
        (JSC::FunctionRareData::allocationProfileWatchpointSet):
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::destroy): Deleted.
        * runtime/JSBoundFunction.h:
        * runtime/JSCallee.cpp:
        (JSC::JSCallee::destroy): Deleted.
        * runtime/JSCallee.h:
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::JSFunction):
        (JSC::JSFunction::createRareData):
        (JSC::JSFunction::visitChildren):
        (JSC::JSFunction::put):
        (JSC::JSFunction::defineOwnProperty):
        (JSC::JSFunction::destroy): Deleted.
        (JSC::JSFunction::createAllocationProfile): Deleted.
        * runtime/JSFunction.h:
        (JSC::JSFunction::offsetOfRareData):
        (JSC::JSFunction::rareData):
        (JSC::JSFunction::allocationStructure):
        (JSC::JSFunction::allocationProfileWatchpointSet):
        (JSC::JSFunction::offsetOfAllocationProfile): Deleted.
        (JSC::JSFunction::allocationProfile): Deleted.
        * runtime/JSFunctionInlines.h:
        (JSC::JSFunction::JSFunction):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
 
2015-04-16  Csaba Osztrogonác  <ossy@webkit.org>

        Remove the unnecessary WTF_CHANGES define
        https://bugs.webkit.org/show_bug.cgi?id=143825

        Reviewed by Andreas Kling.

        * config.h:

2015-04-15  Andreas Kling  <akling@apple.com>

        Make MarkedBlock and WeakBlock 4x smaller.
        <https://webkit.org/b/143802>

        Reviewed by Mark Hahnenberg.

        To reduce GC heap fragmentation and generally use less memory, reduce the size of MarkedBlock
        and its buddy WeakBlock by 4x, bringing them from 64kB+4kB to 16kB+1kB.

        In a sampling of cool web sites, I'm seeing ~8% average reduction in overall GC heap size.
        Some examples:

                   apple.com:  6.3MB ->  5.5MB (14.5% smaller)
                  reddit.com:  4.5MB ->  4.1MB ( 9.7% smaller)
                 twitter.com: 23.2MB -> 21.4MB ( 8.4% smaller)
            cuteoverload.com: 24.5MB -> 23.6MB ( 3.8% smaller)

        Benchmarks look mostly neutral.
        Some small slowdowns on Octane, some slightly bigger speedups on Kraken and SunSpider.

        * heap/MarkedBlock.h:
        * heap/WeakBlock.h:
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:

2015-04-15  Jordan Harband  <ljharb@gmail.com>

        String.prototype.startsWith/endsWith/includes have wrong length in r182673
        https://bugs.webkit.org/show_bug.cgi?id=143659

        Reviewed by Benjamin Poulain.

        Fix lengths of String.prototype.{includes,startsWith,endsWith} per spec
        https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
        https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
        https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith

        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):

2015-04-15  Mark Lam  <mark.lam@apple.com>

        Remove obsolete VMInspector debugging tool.
        https://bugs.webkit.org/show_bug.cgi?id=143798

        Reviewed by Michael Saboff.

        I added the VMInspector tool 3 years ago to aid in VM hacking work.  Some of it
        has bit rotted, and now the VM also has better ways to achieve its functionality.
        Hence this code is now obsolete and should be removed.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * interpreter/CallFrame.h:
        * interpreter/VMInspector.cpp: Removed.
        * interpreter/VMInspector.h: Removed.
        * llint/LowLevelInterpreter.cpp:

2015-04-15  Jordan Harband  <ljharb@gmail.com>

        Math.imul has wrong length in Safari 8.0.4
        https://bugs.webkit.org/show_bug.cgi?id=143658

        Reviewed by Benjamin Poulain.

        Correcting function length from 1, to 2, to match spec
        https://people.mozilla.org/~jorendorff/es6-draft.html#sec-math.imul

        * runtime/MathObject.cpp:
        (JSC::MathObject::finishCreation):

2015-04-15  Jordan Harband  <ljharb@gmail.com>

        Number.parseInt in nightly r182673 has wrong length
        https://bugs.webkit.org/show_bug.cgi?id=143657

        Reviewed by Benjamin Poulain.

        Correcting function length from 1, to 2, to match spec
        https://people.mozilla.org/~jorendorff/es6-draft.html#sec-number.parseint

        * runtime/NumberConstructor.cpp:
        (JSC::NumberConstructor::finishCreation):

2015-04-15  Filip Pizlo  <fpizlo@apple.com>

        Harden DFGForAllKills
        https://bugs.webkit.org/show_bug.cgi?id=143792

        Reviewed by Geoffrey Garen.
        
        Unfortunately, we don't have a good way to test this yet - but it will be needed to prevent
        bugs in https://bugs.webkit.org/show_bug.cgi?id=143734.
        
        Previously ForAllKills used the bytecode kill analysis. That seemed like a good idea because
        that analysis is cheaper than the full liveness analysis. Unfortunately, it's probably wrong:
        
        - It looks for kill sites at forExit origin boundaries. But, something might have been killed
          by an operation that was logically in between the forExit origins at the boundary, but was
          removed from the DFG for whatever reason. The DFG is allowed to have bytecode instruction
          gaps.
        
        - It overlooked the fact that a MovHint that addresses a local that is always live kills that
          local. For example, storing to an argument means that the prior value of the argument is
          killed.
        
        This fixes the analysis by making it handle MovHints directly, and making it define kills in
        the most conservative way possible: it asks if you were live before but dead after. If we
        have the compile time budget to afford this more direct approach, then it's definitel a good
        idea since it's so fool-proof.

        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGForAllKills.h:
        (JSC::DFG::forAllKilledOperands):
        (JSC::DFG::forAllKilledNodesAtNodeIndex):
        (JSC::DFG::forAllDirectlyKilledOperands): Deleted.

2015-04-15  Joseph Pecoraro  <pecoraro@apple.com>

        Provide SPI to allow changing whether JSContexts are remote debuggable by default
        https://bugs.webkit.org/show_bug.cgi?id=143681

        Reviewed by Darin Adler.

        * API/JSRemoteInspector.h:
        * API/JSRemoteInspector.cpp:
        (JSRemoteInspectorGetInspectionEnabledByDefault):
        (JSRemoteInspectorSetInspectionEnabledByDefault):
        Provide SPI to toggle the default enabled inspection state of debuggables.

        * API/JSContextRef.cpp:
        (JSGlobalContextCreateInGroup):
        Respect the default setting.

2015-04-15  Joseph Pecoraro  <pecoraro@apple.com>

        JavaScriptCore: Use kCFAllocatorDefault where possible
        https://bugs.webkit.org/show_bug.cgi?id=143747

        Reviewed by Darin Adler.

        * heap/HeapTimer.cpp:
        (JSC::HeapTimer::HeapTimer):
        * inspector/remote/RemoteInspectorDebuggableConnection.mm:
        (Inspector::RemoteInspectorInitializeGlobalQueue):
        (Inspector::RemoteInspectorDebuggableConnection::setupRunLoop):
        For consistency and readability use the constant instead of
        different representations of null.

2015-04-14  Michael Saboff  <msaboff@apple.com>

        Remove JavaScriptCoreUseJIT default from JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=143746

        Reviewed by Mark Lam.

        * runtime/VM.cpp:
        (JSC::enableAssembler):

2015-04-14  Chris Dumez  <cdumez@apple.com>

        Regression(r180020): Web Inspector crashes on pages that have a stylesheet with an invalid MIME type
        https://bugs.webkit.org/show_bug.cgi?id=143745
        <rdar://problem/20243916>

        Reviewed by Joseph Pecoraro.

        Add assertion in ContentSearchUtilities::findMagicComment() to make
        sure the content String is not null or we would crash in
        JSC::Yarr::interpret() later.

        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::findMagicComment):

2015-04-14  Michael Saboff  <msaboff@apple.com>

        DFG register fillSpeculate*() functions should validate incoming spill format is compatible with requested fill format
        https://bugs.webkit.org/show_bug.cgi?id=143727

        Reviewed by Geoffrey Garen.

        Used the result of AbstractInterpreter<>::filter() to check that the current spill format is compatible
        with the requested fill format.  If filter() reports a contradiction, then we force an OSR exit.
        Removed individual checks made redundant by the new check.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):

2015-04-14  Joseph Pecoraro  <pecoraro@apple.com>

        Replace JavaScriptCoreOutputConsoleMessagesToSystemConsole default with an SPI
        https://bugs.webkit.org/show_bug.cgi?id=143691

        Reviewed by Geoffrey Garen.

        * API/JSRemoteInspector.h:
        * API/JSRemoteInspector.cpp:
        (JSRemoteInspectorSetLogToSystemConsole):
        Add SPI to enable/disable logging to the system console.
        This only affects JSContext `console` logs and warnings.

        * inspector/JSGlobalObjectConsoleClient.h:
        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::logToSystemConsole):
        (Inspector::JSGlobalObjectConsoleClient::setLogToSystemConsole):
        (Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
        (Inspector::JSGlobalObjectConsoleClient::initializeLogToSystemConsole): Deleted.
        Simplify access to the setting now that it doesn't need to
        initialize its value from preferences.

2015-04-14  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Auto-attach fails after r179562, initialization too late after dispatch
        https://bugs.webkit.org/show_bug.cgi?id=143682

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::singleton):
        If we are on the main thread, run the initialization immediately.
        Otherwise dispatch to the main thread. This way if the first JSContext
        was created on the main thread it can get auto-attached if applicable.

2015-04-14  Joseph Pecoraro  <pecoraro@apple.com>

        Unreviewed build fix for Mavericks.

        Mavericks includes this file but does not enable ENABLE_REMOTE_INSPECTOR
        so the Inspector namespace is not available when compiling this file.

        * API/JSRemoteInspector.cpp:

2015-04-14  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Expose private APIs to interact with RemoteInspector instead of going through WebKit
        https://bugs.webkit.org/show_bug.cgi?id=143729

        Reviewed by Timothy Hatcher.

        * API/JSRemoteInspector.h: Added.
        * API/JSRemoteInspector.cpp: Added.
        (JSRemoteInspectorDisableAutoStart):
        (JSRemoteInspectorStart):
        (JSRemoteInspectorSetParentProcessInformation):
        Add the new SPIs for basic remote inspection behavior.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        Add the new files to Mac only, since remote inspection is only
        enabled there anyways.

2015-04-14  Mark Lam  <mark.lam@apple.com>

        Rename JSC_dfgFunctionWhitelistFile to JSC_dfgWhitelist.
        https://bugs.webkit.org/show_bug.cgi?id=143722

        Reviewed by Michael Saboff.

        Renaming JSC_dfgFunctionWhitelistFile to JSC_dfgWhitelist so that it is
        shorter, and easier to remember (without having to look it up) and to
        type.  JSC options now support descriptions, and one can always look up
        the description if the option's purpose is not already obvious.

        * dfg/DFGFunctionWhitelist.cpp:
        (JSC::DFG::FunctionWhitelist::ensureGlobalWhitelist):
        (JSC::DFG::FunctionWhitelist::contains):
        * runtime/Options.h:

2015-04-13  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix Windows build. Windows doesn't take kindly to private classes that use FAST_ALLOCATED.

        * runtime/InferredValue.h:

2015-04-13  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix build. I introduced a new cell type at the same time as kling changed how new cell types are written.

        * runtime/InferredValue.h:

2015-04-08  Filip Pizlo  <fpizlo@apple.com>

        JSC should detect singleton functions
        https://bugs.webkit.org/show_bug.cgi?id=143232

        Reviewed by Geoffrey Garen.
        
        This started out as an attempt to make constructors faster by detecting when a constructor is a
        singleton. The idea is that each FunctionExecutable has a VariableWatchpointSet - a watchpoint
        along with an inferred value - that detects if only one JSFunction has been allocated for that
        executable, and if so, what that JSFunction is. Then, inside the code for the FunctionExecutable,
        if the watchpoint set has an inferred value (i.e. it's been initialized and it is still valid),
        we can constant-fold GetCallee.
        
        Unfortunately, constructors don't use GetCallee anymore, so that didn't pan out. But in the
        process I realized a bunch of things:
        
        - This allows us to completely eliminate the GetCallee/GetScope sequence that we still sometimes
          had even in code where our singleton-closure detection worked. That's because singleton-closure
          inference worked at the op_resolve_scope, and that op_resolve_scope still needed to keep alive
          the incoming scope in case we OSR exit. But by constant-folding GetCallee, that sequence
          disappears. OSR exit can rematerialize the callee or the scope by just knowing their constant
          values.
          
        - Singleton detection should be a reusable thing. So, I got rid of VariableWatchpointSet and
          created InferredValue. InferredValue is a cell, so it can handle its own GC magic.
          FunctionExecutable uses an InferredValue to tell you about singleton JSFunctions.
        
        - The old singleton-scope detection in op_resolve_scope is better abstracted as a SymbolTable
          detecting a singleton JSSymbolTableObject. So, SymbolTable uses an InferredValue to tell you
          about singleton JSSymbolTableObjects. It's curious that we want to have singleton detection in
          SymbolTable if we already have it in FunctionExecutable. This comes into play in two ways.
          First, it means that the DFG can realize sooner that a resolve_scope resolves to a constant
          scope. Ths saves compile times and it allows prediction propagation to benefit from the
          constant folding. Second, it means that we will detect a singleton scope even if it is
          referenced from a non-singleton scope that is nearer to us in the scope chain. This refactoring
          allows us to eliminate the function reentry watchpoint.
        
        - This allows us to use a normal WatchpointSet, instead of a VariableWatchpointSet, for inferring
          constant values in scopes. Previously when the DFG inferred that a closure variable was
          constant, it wouldn't know which closure that variable was in and so it couldn't just load that
          value. But now we are first inferring that the function is a singleton, which means that we
          know exactly what scope it points to, and we can load the value from the scope. Using a
          WatchpointSet instead of a VariableWatchpointSet saves some memory and simplifies a bunch of
          code. This also means that now, the only user of VariableWatchpointSet is FunctionExecutable.
          I've tweaked the code of VariableWatchpointSet to reduce its power to just be what
          FunctionExecutable wants.
        
        This also has the effect of simplifying the implementation of block scoping. Prior to this
        change, block scoping would have needed to have some story for the function reentry watchpoint on
        any nested symbol table. That's totally weird to think about; it's not really a function reentry
        but a scope reentry. Now we don't have to think about this. Constant inference on nested scopes
        will "just work": if we prove that we know the constant value of the scope then the machinery
        kicks in, otherwise it doesn't.
        
        This is a small Octane and AsmBench speed-up. AsmBench sees 1% while Octane sees sub-1%.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::valueProfileForBytecodeOffset):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::valueProfileForBytecodeOffset): Deleted.
        * bytecode/CodeOrigin.cpp:
        (JSC::InlineCallFrame::calleeConstant):
        (JSC::InlineCallFrame::visitAggregate):
        * bytecode/CodeOrigin.h:
        (JSC::InlineCallFrame::calleeConstant): Deleted.
        (JSC::InlineCallFrame::visitAggregate): Deleted.
        * bytecode/Instruction.h:
        * bytecode/VariableWatchpointSet.cpp: Removed.
        * bytecode/VariableWatchpointSet.h: Removed.
        * bytecode/VariableWatchpointSetInlines.h: Removed.
        * bytecode/VariableWriteFireDetail.cpp: Added.
        (JSC::VariableWriteFireDetail::dump):
        (JSC::VariableWriteFireDetail::touch):
        * bytecode/VariableWriteFireDetail.h: Added.
        (JSC::VariableWriteFireDetail::VariableWriteFireDetail):
        * bytecode/Watchpoint.h:
        (JSC::WatchpointSet::stateOnJSThread):
        (JSC::WatchpointSet::startWatching):
        (JSC::WatchpointSet::fireAll):
        (JSC::WatchpointSet::touch):
        (JSC::WatchpointSet::invalidate):
        (JSC::InlineWatchpointSet::stateOnJSThread):
        (JSC::InlineWatchpointSet::state):
        (JSC::InlineWatchpointSet::hasBeenInvalidated):
        (JSC::InlineWatchpointSet::invalidate):
        (JSC::InlineWatchpointSet::touch):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::get):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::getScope): Deleted.
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDesiredWatchpoints.cpp:
        (JSC::DFG::InferredValueAdaptor::add):
        (JSC::DFG::DesiredWatchpoints::addLazily):
        (JSC::DFG::DesiredWatchpoints::reallyAdd):
        (JSC::DFG::DesiredWatchpoints::areStillValid):
        * dfg/DFGDesiredWatchpoints.h:
        (JSC::DFG::InferredValueAdaptor::hasBeenInvalidated):
        (JSC::DFG::DesiredWatchpoints::isWatched):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::tryGetConstantClosureVar):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasWatchpointSet):
        (JSC::DFG::Node::watchpointSet):
        (JSC::DFG::Node::hasVariableWatchpointSet): Deleted.
        (JSC::DFG::Node::variableWatchpointSet): Deleted.
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunction):
        (JSC::DFG::SpeculativeJIT::compileCreateActivation):
        (JSC::DFG::SpeculativeJIT::compileNotifyWrite):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGVarargsForwardingPhase.cpp:
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileCreateActivation):
        (JSC::FTL::LowerDFGToLLVM::compileNewFunction):
        (JSC::FTL::LowerDFGToLLVM::compileNotifyWrite):
        * interpreter/Interpreter.cpp:
        (JSC::StackFrame::friendlySourceURL):
        (JSC::StackFrame::friendlyFunctionName):
        * interpreter/Interpreter.h:
        (JSC::StackFrame::friendlySourceURL): Deleted.
        (JSC::StackFrame::friendlyFunctionName): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::emitNotifyWrite):
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_touch_entry): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitPutGlobalVar):
        (JSC::JIT::emitPutClosureVar):
        (JSC::JIT::emitNotifyWrite): Deleted.
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitPutGlobalVar):
        (JSC::JIT::emitPutClosureVar):
        (JSC::JIT::emitNotifyWrite): Deleted.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL): Deleted.
        * runtime/CommonSlowPaths.h:
        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::finishCreation):
        (JSC::FunctionExecutable::visitChildren):
        * runtime/Executable.h:
        (JSC::FunctionExecutable::singletonFunction):
        * runtime/InferredValue.cpp: Added.
        (JSC::InferredValue::create):
        (JSC::InferredValue::destroy):
        (JSC::InferredValue::createStructure):
        (JSC::InferredValue::visitChildren):
        (JSC::InferredValue::InferredValue):
        (JSC::InferredValue::~InferredValue):
        (JSC::InferredValue::notifyWriteSlow):
        (JSC::InferredValue::ValueCleanup::ValueCleanup):
        (JSC::InferredValue::ValueCleanup::~ValueCleanup):
        (JSC::InferredValue::ValueCleanup::finalizeUnconditionally):
        * runtime/InferredValue.h: Added.
        (JSC::InferredValue::inferredValue):
        (JSC::InferredValue::state):
        (JSC::InferredValue::isStillValid):
        (JSC::InferredValue::hasBeenInvalidated):
        (JSC::InferredValue::add):
        (JSC::InferredValue::notifyWrite):
        (JSC::InferredValue::invalidate):
        * runtime/JSEnvironmentRecord.cpp:
        (JSC::JSEnvironmentRecord::visitChildren):
        * runtime/JSEnvironmentRecord.h:
        (JSC::JSEnvironmentRecord::isValid):
        (JSC::JSEnvironmentRecord::finishCreation):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::create):
        * runtime/JSFunction.h:
        (JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
        (JSC::JSFunction::createImpl):
        (JSC::JSFunction::create): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::addGlobalVar):
        (JSC::JSGlobalObject::addFunction):
        * runtime/JSGlobalObject.h:
        * runtime/JSLexicalEnvironment.cpp:
        (JSC::JSLexicalEnvironment::symbolTablePut):
        * runtime/JSScope.h:
        (JSC::ResolveOp::ResolveOp):
        * runtime/JSSegmentedVariableObject.h:
        (JSC::JSSegmentedVariableObject::finishCreation):
        * runtime/JSSymbolTableObject.h:
        (JSC::JSSymbolTableObject::JSSymbolTableObject):
        (JSC::JSSymbolTableObject::setSymbolTable):
        (JSC::symbolTablePut):
        (JSC::symbolTablePutWithAttributes):
        * runtime/PutPropertySlot.h:
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTableEntry::prepareToWatch):
        (JSC::SymbolTable::SymbolTable):
        (JSC::SymbolTable::finishCreation):
        (JSC::SymbolTable::visitChildren):
        (JSC::SymbolTableEntry::inferredValue): Deleted.
        (JSC::SymbolTableEntry::notifyWriteSlow): Deleted.
        (JSC::SymbolTable::WatchpointCleanup::WatchpointCleanup): Deleted.
        (JSC::SymbolTable::WatchpointCleanup::~WatchpointCleanup): Deleted.
        (JSC::SymbolTable::WatchpointCleanup::finalizeUnconditionally): Deleted.
        * runtime/SymbolTable.h:
        (JSC::SymbolTableEntry::disableWatching):
        (JSC::SymbolTableEntry::watchpointSet):
        (JSC::SymbolTable::singletonScope):
        (JSC::SymbolTableEntry::notifyWrite): Deleted.
        * runtime/TypeProfiler.cpp:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * tests/stress/infer-uninitialized-closure-var.js: Added.
        (foo.f):
        (foo):
        * tests/stress/singleton-scope-then-overwrite.js: Added.
        (foo.f):
        (foo):
        * tests/stress/singleton-scope-then-realloc-and-overwrite.js: Added.
        (foo):
        * tests/stress/singleton-scope-then-realloc.js: Added.
        (foo):

2015-04-13  Andreas Kling  <akling@apple.com>

        Don't segregate heap objects based on Structure immortality.
        <https://webkit.org/b/143638>

        Reviewed by Darin Adler.

        Put all objects that need a destructor call into the same MarkedBlock.
        This reduces memory consumption in many situations, while improving locality,
        since much more of the MarkedBlock space can be shared.

        Instead of branching on the MarkedBlock type, we now check a bit in the
        JSCell's inline type flags (StructureIsImmortal) to see whether it's safe
        to access the cell's Structure during destruction or not.

        Performance benchmarks look mostly neutral. Maybe a small regression on
        SunSpider's date objects.

        On the amazon.com landing page, this saves us 50 MarkedBlocks (3200kB) along
        with a bunch of WeakBlocks that were hanging off of them. That's on the higher
        end of savings we can get from this, but still a very real improvement.

        Most of this patch is removing the "hasImmortalStructure" constant from JSCell
        derived classes and passing that responsibility to the StructureIsImmortal flag.
        StructureFlags is made public so that it's accessible from non-member functions.
        I made sure to declare it everywhere and make classes final to try to make it
        explicit what each class is doing to its inherited flags.

        * API/JSCallbackConstructor.h:
        * API/JSCallbackObject.h:
        * bytecode/UnlinkedCodeBlock.h:
        * debugger/DebuggerScope.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileMakeRope):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileMakeRope):
        * heap/Heap.h:
        (JSC::Heap::subspaceForObjectDestructor):
        (JSC::Heap::allocatorForObjectWithDestructor):
        (JSC::Heap::subspaceForObjectNormalDestructor): Deleted.
        (JSC::Heap::subspaceForObjectsWithImmortalStructure): Deleted.
        (JSC::Heap::allocatorForObjectWithNormalDestructor): Deleted.
        (JSC::Heap::allocatorForObjectWithImmortalStructureDestructor): Deleted.
        * heap/HeapInlines.h:
        (JSC::Heap::allocateWithDestructor):
        (JSC::Heap::allocateObjectOfType):
        (JSC::Heap::subspaceForObjectOfType):
        (JSC::Heap::allocatorForObjectOfType):
        (JSC::Heap::allocateWithNormalDestructor): Deleted.
        (JSC::Heap::allocateWithImmortalStructureDestructor): Deleted.
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateBlock):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::needsDestruction):
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::init):
        (JSC::MarkedAllocator::destructorType): Deleted.
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC::MarkedBlock::callDestructor):
        (JSC::MarkedBlock::specializedSweep):
        (JSC::MarkedBlock::sweep):
        (JSC::MarkedBlock::sweepHelper):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::needsDestruction):
        (JSC::MarkedBlock::destructorType): Deleted.
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::forEachAllocator):
        (JSC::MarkedSpace::isPagedOut):
        (JSC::MarkedSpace::clearNewlyAllocated):
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::subspaceForObjectsWithDestructor):
        (JSC::MarkedSpace::destructorAllocatorFor):
        (JSC::MarkedSpace::allocateWithDestructor):
        (JSC::MarkedSpace::forEachBlock):
        (JSC::MarkedSpace::subspaceForObjectsWithNormalDestructor): Deleted.
        (JSC::MarkedSpace::subspaceForObjectsWithImmortalStructure): Deleted.
        (JSC::MarkedSpace::immortalStructureDestructorAllocatorFor): Deleted.
        (JSC::MarkedSpace::normalDestructorAllocatorFor): Deleted.
        (JSC::MarkedSpace::allocateWithImmortalStructureDestructor): Deleted.
        (JSC::MarkedSpace::allocateWithNormalDestructor): Deleted.
        * inspector/JSInjectedScriptHost.h:
        * inspector/JSInjectedScriptHostPrototype.h:
        * inspector/JSJavaScriptCallFrame.h:
        * inspector/JSJavaScriptCallFramePrototype.h:
        * jsc.cpp:
        * runtime/ArrayBufferNeuteringWatchpoint.h:
        * runtime/ArrayConstructor.h:
        * runtime/ArrayIteratorPrototype.h:
        * runtime/BooleanPrototype.h:
        * runtime/ClonedArguments.h:
        * runtime/CustomGetterSetter.h:
        * runtime/DateConstructor.h:
        * runtime/DatePrototype.h:
        * runtime/ErrorPrototype.h:
        * runtime/ExceptionHelpers.h:
        * runtime/Executable.h:
        * runtime/GenericArguments.h:
        * runtime/GetterSetter.h:
        * runtime/InternalFunction.h:
        * runtime/JSAPIValueWrapper.h:
        * runtime/JSArgumentsIterator.h:
        * runtime/JSArray.h:
        * runtime/JSArrayBuffer.h:
        * runtime/JSArrayBufferView.h:
        * runtime/JSBoundFunction.h:
        * runtime/JSCallee.h:
        * runtime/JSCell.h:
        * runtime/JSCellInlines.h:
        (JSC::JSCell::classInfo):
        * runtime/JSDataViewPrototype.h:
        * runtime/JSEnvironmentRecord.h:
        * runtime/JSFunction.h:
        * runtime/JSGenericTypedArrayView.h:
        * runtime/JSGlobalObject.h:
        * runtime/JSLexicalEnvironment.h:
        * runtime/JSNameScope.h:
        * runtime/JSNotAnObject.h:
        * runtime/JSONObject.h:
        * runtime/JSObject.h:
        (JSC::JSFinalObject::JSFinalObject):
        * runtime/JSPromiseConstructor.h:
        * runtime/JSPromiseDeferred.h:
        * runtime/JSPromisePrototype.h:
        * runtime/JSPromiseReaction.h:
        * runtime/JSPropertyNameEnumerator.h:
        * runtime/JSProxy.h:
        * runtime/JSScope.h:
        * runtime/JSString.h:
        * runtime/JSSymbolTableObject.h:
        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::structureIsImmortal):
        * runtime/MathObject.h:
        * runtime/NumberConstructor.h:
        * runtime/NumberPrototype.h:
        * runtime/ObjectConstructor.h:
        * runtime/PropertyMapHashTable.h:
        * runtime/RegExp.h:
        * runtime/RegExpConstructor.h:
        * runtime/RegExpObject.h:
        * runtime/RegExpPrototype.h:
        * runtime/ScopedArgumentsTable.h:
        * runtime/SparseArrayValueMap.h:
        * runtime/StrictEvalActivation.h:
        * runtime/StringConstructor.h:
        * runtime/StringIteratorPrototype.h:
        * runtime/StringObject.h:
        * runtime/StringPrototype.h:
        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        * runtime/Structure.h:
        * runtime/StructureChain.h:
        * runtime/StructureRareData.h:
        * runtime/Symbol.h:
        * runtime/SymbolPrototype.h:
        * runtime/SymbolTable.h:
        * runtime/WeakMapData.h:

2015-04-13  Mark Lam  <mark.lam@apple.com>

        DFG inlining of op_call_varargs should keep the callee alive in case of OSR exit.
        https://bugs.webkit.org/show_bug.cgi?id=143407

        Reviewed by Filip Pizlo.

        DFG inlining of a varargs call / construct needs to keep the local
        containing the callee alive with a Phantom node because the LoadVarargs
        node may OSR exit.  After the OSR exit, the baseline JIT executes the
        op_call_varargs with that callee in the local.

        Previously, because that callee local was not explicitly kept alive,
        the op_call_varargs case can OSR exit a DFG function and leave an
        undefined value in that local.  As a result, the baseline observes the
        side effect of an op_call_varargs on an undefined value instead of the
        function it expected.

        Note: this issue does not manifest with op_construct_varargs because
        the inlined constructor will have an op_create_this which operates on
        the incoming callee value, thereby keeping it alive.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleInlining):
        * tests/stress/call-varargs-with-different-arguments-length-after-warmup.js: Added.
        (foo):
        (Foo):
        (doTest):

2015-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement Array.prototype.values
        https://bugs.webkit.org/show_bug.cgi?id=143633

        Reviewed by Darin Adler.

        Symbol.unscopables is implemented, so we can implement Array.prototype.values
        without largely breaking the web. The following script passes.

        var array = [];
        var values = 42;
        with (array) {
            assert(values, 42);
        }

        * runtime/ArrayPrototype.cpp:
        * tests/stress/array-iterators-next.js:
        * tests/stress/map-iterators-next.js:
        * tests/stress/set-iterators-next.js:
        * tests/stress/values-unscopables.js: Added.
        (test):

2015-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>

        Run flaky conservative GC related test first before polluting stack and registers
        https://bugs.webkit.org/show_bug.cgi?id=143634

        Reviewed by Ryosuke Niwa.

        After r182653, JSC API tests fail. However, it's not related to the change.
        After investigating the cause of this failure, I've found that the failed test is flaky
        because JSC's GC is conservative. If previously allocated JSGlobalObject is accidentally alive
        due to conservative roots in C stack and registers, this test fails.

        Since GC marks C stack and registers as roots conservatively,
        objects not referenced logically can be accidentally marked and alive.
        To avoid this situation as possible as we can,
        1. run this test first before stack is polluted,
        2. extract this test as a function to suppress stack height.

        * API/tests/testapi.mm:
        (testWeakValue):
        (testObjectiveCAPIMain):
        (testObjectiveCAPI):

2015-04-11  Matt Baker  <mattbaker@apple.com>

        Web Inspector: create content view and details sidebar for Frames timeline
        https://bugs.webkit.org/show_bug.cgi?id=143533

        Reviewed by Timothy Hatcher.

        Refactoring: RunLoop prefix changed to RenderingFrame.

        * inspector/protocol/Timeline.json:

2015-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Enable Symbol in web pages
        https://bugs.webkit.org/show_bug.cgi?id=143375

        Reviewed by Ryosuke Niwa.

        Expose Symbol to web pages.
        Symbol was exposed, but it was hidden since it breaks Facebook comments.
        This is because at that time Symbol is implemented,
        but methods for Symbol.iterator and Object.getOwnPropertySymbols are not implemented yet
        and it breaks React.js and immutable.js.

        Now methods for Symbol.iterator and Object.getOwnPropertySymbols are implemented
        and make sure that Facebook comment input functionality is not broken with exposed Symbol.

        So this patch replaces runtime flags SymbolEnabled to SymbolDisabled
        and makes enabling symbols by default.

        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        * runtime/RuntimeFlags.h:

2015-04-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        ES6: Iterator toString names should be consistent
        https://bugs.webkit.org/show_bug.cgi?id=142424

        Reviewed by Geoffrey Garen.

        Iterator Object Names in the spec right now have spaces.
        In our implementation some do and some don't.
        This patch aligns JSC to the spec.

        * runtime/JSArrayIterator.cpp:
        * runtime/JSStringIterator.cpp:
        * tests/stress/iterator-names.js: Added.
        (test):
        (iter):
        (check):

2015-04-10  Michael Saboff  <msaboff@apple.com>

        REGRESSION (182567): regress/script-tests/sorting-benchmark.js fails on 32 bit dfg-eager tests
        https://bugs.webkit.org/show_bug.cgi?id=143582

        Reviewed by Mark Lam.

        For 32 bit builds, we favor spilling unboxed values.  The ASSERT at the root of this bug doesn't
        fire for 64 bit builds, because we spill an "Other" value as a full JS value (DataFormatJS).
        For 32 bit builds however, if we are able, we spill Other values as JSCell* (DataFormatCell).
        The fix is to add a check in fillSpeculateInt32Internal() before the ASSERT that always OSR exits
        if the spillFormat is DataFormatCell.  Had we spilled in DataFormatJS and the value was a JSCell*,
        we would still OSR exit after the speculation check.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): Fixed an error in a comment while debugging.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):

2015-04-10  Milan Crha  <mcrha@redhat.com>

        Disable Linux-specific code in a Windows build
        https://bugs.webkit.org/show_bug.cgi?id=137973

        Reviewed by Joseph Pecoraro.

        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):

2015-04-10  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Fix calleeSaveRegisters() on non iOS platforms after r180516
        https://bugs.webkit.org/show_bug.cgi?id=143368

        Reviewed by Michael Saboff.

        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::calleeSaveRegisters):

2015-04-08  Joseph Pecoraro  <pecoraro@apple.com>

        Use jsNontrivialString in more places if the string is guaranteed to be 2 or more characters
        https://bugs.webkit.org/show_bug.cgi?id=143430

        Reviewed by Darin Adler.

        * runtime/ExceptionHelpers.cpp:
        (JSC::errorDescriptionForValue):
        * runtime/NumberPrototype.cpp:
        (JSC::numberProtoFuncToExponential):
        (JSC::numberProtoFuncToPrecision):
        (JSC::numberProtoFuncToString):
        * runtime/SymbolPrototype.cpp:
        (JSC::symbolProtoFuncToString):

2015-04-08  Filip Pizlo  <fpizlo@apple.com>

        JSArray::sortNumeric should handle ArrayWithUndecided
        https://bugs.webkit.org/show_bug.cgi?id=143535

        Reviewed by Geoffrey Garen.
        
        ArrayWithUndecided is what you get if you haven't stored anything into the array yet. We need to handle it.

        * runtime/JSArray.cpp:
        (JSC::JSArray::sortNumeric):
        * tests/stress/sort-array-with-undecided.js: Added.

2015-04-08  Filip Pizlo  <fpizlo@apple.com>

        DFG::IntegerCheckCombiningPhase's wrap-around check shouldn't trigger C++ undef behavior on wrap-around
        https://bugs.webkit.org/show_bug.cgi?id=143532

        Reviewed by Gavin Barraclough.
        
        Oh the irony!  We were protecting an optimization that only worked if there was no wrap-around in JavaScript.
        But the C++ code had wrap-around, which is undef in C++.  So, if the compiler was smart enough, our compiler
        would think that there never was wrap-around.
        
        This fixes a failure in stress/tricky-array-boiunds-checks.js when JSC is compiled with bleeding-edge clang.

        * dfg/DFGIntegerCheckCombiningPhase.cpp:
        (JSC::DFG::IntegerCheckCombiningPhase::isValid):

2015-04-07  Michael Saboff  <msaboff@apple.com>

        Lazily initialize LogToSystemConsole flag to reduce memory usage
        https://bugs.webkit.org/show_bug.cgi?id=143506

        Reviewed by Mark Lam.

        Only call into CF preferences code when we need to in order to reduce memory usage.

        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::logToSystemConsole):
        (Inspector::JSGlobalObjectConsoleClient::setLogToSystemConsole):
        (Inspector::JSGlobalObjectConsoleClient::initializeLogToSystemConsole):
        (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):

2015-04-07  Benjamin Poulain  <benjamin@webkit.org>

        Get the features.json files ready for open contributions
        https://bugs.webkit.org/show_bug.cgi?id=143436

        Reviewed by Darin Adler.

        * features.json:

2015-04-07  Filip Pizlo  <fpizlo@apple.com>

        Constant folding of typed array properties should be handled by AI rather than strength reduction
        https://bugs.webkit.org/show_bug.cgi?id=143496

        Reviewed by Geoffrey Garen.
        
        Handling constant folding in AI is better because it precludes us from having to fixpoint the CFA
        phase and whatever other phase did the folding in order to find all constants.
        
        This also removes the TypedArrayWatchpoint node type because we can just set the watchpoint
        directly.
        
        This also fixes a bug in FTL lowering of GetTypedArrayByteOffset. The bug was previously not
        found because all of the tests for it involved the property getting constant folded. I found that
        the codegen was bad because an earlier version of the patch broke that constant folding. This
        adds a new test for that node type, which makes constant folding impossible by allocating a new
        typed array every type. The lesson here is: if you write a test for something, run the test with
        full IR dumps to make sure it's actually testing the thing you want it to test.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::tryGetFoldableView):
        (JSC::DFG::Graph::tryGetFoldableViewForChild1): Deleted.
        * dfg/DFGGraph.h:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasTypedArray): Deleted.
        (JSC::DFG::Node::typedArray): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::jumpForTypedArrayOutOfBounds):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        (JSC::DFG::StrengthReductionPhase::foldTypedArrayPropertyToConstant): Deleted.
        (JSC::DFG::StrengthReductionPhase::prepareToFoldTypedArray): Deleted.
        * dfg/DFGWatchpointCollectionPhase.cpp:
        (JSC::DFG::WatchpointCollectionPhase::handle):
        (JSC::DFG::WatchpointCollectionPhase::addLazily):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileGetTypedArrayByteOffset):
        (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
        * tests/stress/fold-typed-array-properties.js:
        (foo):
        * tests/stress/typed-array-byte-offset.js: Added.
        (foo):

2015-04-07  Matthew Mirman  <mmirman@apple.com>

        Source and stack information should get appended only to native errors
        and should be added directly after construction rather than when thrown. 
        This fixes frozen objects being unfrozen when thrown while conforming to 
        ecma script standard and other browser behavior.
        rdar://problem/19927293
        https://bugs.webkit.org/show_bug.cgi?id=141871
        
        Reviewed by Geoffrey Garen.

        Appending stack, source, line, and column information to an object whenever that object is thrown 
        is incorrect because it violates the ecma script standard for the behavior of throw.  Suppose for example
        that the object being thrown already has one of these properties or is frozen.  Adding the properties 
        would then violate the frozen contract or overwrite those properties.  Other browsers do not do this,
        and doing this causes unnecessary performance hits in code with heavy use of the throw construct as
        a control flow construct rather than just an error reporting mechanism.  
        
        Because WebCore adds "native" errors which do not inherit from any JSC native error, 
        appending the error properties as a seperate call after construction of the error is required 
        to avoid having to manually truncate the stack and gather local source information due to 
        the stack being extended by a nested call to construct one of the native jsc error.
        
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * interpreter/Interpreter.h:
        * parser/ParserError.h:
        (JSC::ParserError::toErrorObject):
        * runtime/CommonIdentifiers.h:
        * runtime/Error.cpp:
        (JSC::createError):
        (JSC::createEvalError):
        (JSC::createRangeError):
        (JSC::createReferenceError):
        (JSC::createSyntaxError):
        (JSC::createTypeError):
        (JSC::createNotEnoughArgumentsError):
        (JSC::createURIError):
        (JSC::createOutOfMemoryError):
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor):
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()):
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::foundCallFrame):
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::index):
        (JSC::addErrorInfoAndGetBytecodeOffset):  Added.
        (JSC::addErrorInfo): Added special case for appending complete error info 
        to a newly constructed error object.
        * runtime/Error.h:
        * runtime/ErrorConstructor.cpp:
        (JSC::Interpreter::constructWithErrorConstructor):
        (JSC::Interpreter::callErrorConstructor):
        * runtime/ErrorInstance.cpp:
        (JSC::appendSourceToError): Moved from VM.cpp
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor):
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()):
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::foundCallFrame):
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::index):
        (JSC::addErrorInfoAndGetBytecodeOffset):
        (JSC::ErrorInstance::finishCreation):
        * runtime/ErrorInstance.h:
        (JSC::ErrorInstance::create):
        * runtime/ErrorPrototype.cpp:
        (JSC::ErrorPrototype::finishCreation):
        * runtime/ExceptionFuzz.cpp:
        (JSC::doExceptionFuzzing):
        * runtime/ExceptionHelpers.cpp:
        (JSC::createError):
        (JSC::createInvalidFunctionApplyParameterError):
        (JSC::createInvalidInParameterError):
        (JSC::createInvalidInstanceofParameterError):
        (JSC::createNotAConstructorError):
        (JSC::createNotAFunctionError):
        (JSC::createNotAnObjectError):
        (JSC::throwOutOfMemoryError):
        (JSC::createStackOverflowError): Deleted.
        (JSC::createOutOfMemoryError): Deleted.
        * runtime/ExceptionHelpers.h:
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::constructArrayBuffer):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::arrayBufferProtoFuncSlice):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::create):
        (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):
        * runtime/NativeErrorConstructor.cpp:
        (JSC::Interpreter::constructWithNativeErrorConstructor):
        (JSC::Interpreter::callNativeErrorConstructor):
        * runtime/VM.cpp:
        (JSC::VM::throwException):
        (JSC::appendSourceToError): Moved to Error.cpp
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor): Deleted.
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()): Deleted.
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::foundCallFrame): Deleted.
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::index): Deleted.
        * tests/stress/freeze_leek.js: Added.

2015-04-07  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: ES6: Show Symbol properties on Objects
        https://bugs.webkit.org/show_bug.cgi?id=141279

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Runtime.json:
        Give PropertyDescriptor a reference to the Symbol RemoteObject
        if the property is a symbol property.

        * inspector/InjectedScriptSource.js:
        Enumerate symbol properties on objects.

2015-04-07  Filip Pizlo  <fpizlo@apple.com>

        Make it possible to enable LLVM FastISel
        https://bugs.webkit.org/show_bug.cgi?id=143489

        Reviewed by Michael Saboff.

        The decision to enable FastISel is made by Options.h|cpp, but the LLVM library can disable it if it finds that it is built
        against a version of LLVM that doesn't support it. Thereafter, JSC::enableLLVMFastISel is the flag that tells the system
        if we should enable it.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * llvm/InitializeLLVM.cpp:
        (JSC::initializeLLVMImpl):
        * llvm/InitializeLLVM.h:
        * llvm/InitializeLLVMLinux.cpp:
        (JSC::getLLVMInitializerFunction):
        (JSC::initializeLLVMImpl): Deleted.
        * llvm/InitializeLLVMMac.cpp:
        (JSC::getLLVMInitializerFunction):
        (JSC::initializeLLVMImpl): Deleted.
        * llvm/InitializeLLVMPOSIX.cpp:
        (JSC::getLLVMInitializerFunctionPOSIX):
        (JSC::initializeLLVMPOSIX): Deleted.
        * llvm/InitializeLLVMPOSIX.h:
        * llvm/InitializeLLVMWin.cpp:
        (JSC::getLLVMInitializerFunction):
        (JSC::initializeLLVMImpl): Deleted.
        * llvm/LLVMAPI.cpp:
        * llvm/LLVMAPI.h:
        * llvm/library/LLVMExports.cpp:
        (initCommandLine):
        (initializeAndGetJSCLLVMAPI):
        * runtime/Options.cpp:
        (JSC::Options::initialize):

2015-04-06  Yusuke Suzuki  <utatane.tea@gmail.com>

        put_by_val_direct need to check the property is index or not for using putDirect / putDirectIndex
        https://bugs.webkit.org/show_bug.cgi?id=140426

        Reviewed by Darin Adler.

        In the put_by_val_direct operation, we use JSObject::putDirect.
        However, it only accepts non-index property. For index property, we need to use JSObject::putDirectIndex.
        This patch checks toString-ed Identifier is index or not to choose putDirect / putDirectIndex.

        * dfg/DFGOperations.cpp:
        (JSC::DFG::putByVal):
        (JSC::DFG::operationPutByValInternal):
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/Identifier.h:
        (JSC::isIndex):
        (JSC::parseIndex):
        * tests/stress/dfg-put-by-val-direct-with-edge-numbers.js: Added.
        (lookupWithKey):
        (toStringThrowsError.toString):

2015-04-06  Alberto Garcia  <berto@igalia.com>

        [GTK] Fix HPPA build
        https://bugs.webkit.org/show_bug.cgi?id=143453

        Reviewed by Darin Adler.

        Add HPPA to the list of supported CPUs.

        * CMakeLists.txt:

2015-04-06  Mark Lam  <mark.lam@apple.com>

        In the 64-bit DFG and FTL, Array::Double case for HasIndexedProperty should set its result to true when all is well.
        <https://webkit.org/b/143396>

        Reviewed by Filip Pizlo.

        The DFG was neglecting to set the result boolean.  The FTL was setting it with
        an inverted value.  Both of these are now resolved.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileHasIndexedProperty):
        * tests/stress/for-in-array-mode.js: Added.
        (.):
        (test):

2015-04-06  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] DFG and FTL should be aware of that StringConstructor behavior for symbols becomes different from ToString
        https://bugs.webkit.org/show_bug.cgi?id=143424

        Reviewed by Geoffrey Garen.

        In ES6, StringConstructor behavior becomes different from ToString abstract operations in the spec. (and JSValue::toString).

        ToString(symbol) throws a type error.
        However, String(symbol) produces SymbolDescriptiveString(symbol).

        So, in DFG and FTL phase, they should not inline StringConstructor to ToString.

        Now, in the template literals patch, ToString DFG operation is planned to be used.
        And current ToString behavior is aligned to the spec (and JSValue::toString) and it's better.
        So intead of changing ToString behavior, this patch adds CallStringConstructor operation into DFG and FTL.
        In CallStringConstructor, all behavior in DFG analysis is the same.
        Only the difference from ToString is, when calling DFG operation functions, it calls
        operationCallStringConstructorOnCell and operationCallStringConstructor instead of
        operationToStringOnCell and operationToString.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
        (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
        (JSC::DFG::FixupPhase::fixupToString): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
        (JSC::DFG::SpeculativeJIT::compileToStringOnCell): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
        (JSC::FTL::LowerDFGToLLVM::compileToString): Deleted.
        * runtime/StringConstructor.cpp:
        (JSC::stringConstructor):
        (JSC::callStringConstructor):
        * runtime/StringConstructor.h:
        * tests/stress/symbol-and-string-constructor.js: Added.
        (performString):

2015-04-06  Yusuke Suzuki  <utatane.tea@gmail.com>

        Return Optional<uint32_t> from PropertyName::asIndex
        https://bugs.webkit.org/show_bug.cgi?id=143422

        Reviewed by Darin Adler.

        PropertyName::asIndex returns uint32_t and use UINT_MAX as NotAnIndex.
        But it's not obvious to callers.

        This patch changes
        1. PropertyName::asIndex() to return Optional<uint32_t> and
        2. function name `asIndex()` to `parseIndex()`.
        It forces callers to check the value is index or not explicitly.

        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFor):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitDirectPutById):
        * jit/Repatch.cpp:
        (JSC::emitPutTransitionStubAndGetOldStructure):
        * jsc.cpp:
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSort):
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::getOwnPropertySlot):
        (JSC::GenericArguments<Type>::put):
        (JSC::GenericArguments<Type>::deleteProperty):
        (JSC::GenericArguments<Type>::defineOwnProperty):
        * runtime/Identifier.h:
        (JSC::parseIndex):
        (JSC::Identifier::isSymbol):
        * runtime/JSArray.cpp:
        (JSC::JSArray::defineOwnProperty):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
        (JSC::JSGenericTypedArrayView<Adaptor>::put):
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
        (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
        * runtime/JSObject.cpp:
        (JSC::JSObject::put):
        (JSC::JSObject::putDirectAccessor):
        (JSC::JSObject::putDirectCustomAccessor):
        (JSC::JSObject::deleteProperty):
        (JSC::JSObject::putDirectMayBeIndex):
        (JSC::JSObject::defineOwnProperty):
        * runtime/JSObject.h:
        (JSC::JSObject::getOwnPropertySlot):
        (JSC::JSObject::getPropertySlot):
        (JSC::JSObject::putDirectInternal):
        * runtime/JSString.cpp:
        (JSC::JSString::getStringPropertyDescriptor):
        * runtime/JSString.h:
        (JSC::JSString::getStringPropertySlot):
        * runtime/LiteralParser.cpp:
        (JSC::LiteralParser<CharType>::parse):
        * runtime/PropertyName.h:
        (JSC::parseIndex):
        (JSC::toUInt32FromCharacters): Deleted.
        (JSC::toUInt32FromStringImpl): Deleted.
        (JSC::PropertyName::asIndex): Deleted.
        * runtime/PropertyNameArray.cpp:
        (JSC::PropertyNameArray::add):
        * runtime/StringObject.cpp:
        (JSC::StringObject::deleteProperty):
        * runtime/Structure.cpp:
        (JSC::Structure::prototypeChainMayInterceptStoreTo):

2015-04-05  Andreas Kling  <akling@apple.com>

        URI encoding/escaping should use efficient string building instead of calling snprintf().
        <https://webkit.org/b/143426>

        Reviewed by Gavin Barraclough.

        I saw 0.5% of main thread time in snprintf() on <http://polymerlabs.github.io/benchmarks/>
        which seemed pretty silly. This change gets that down to nothing in favor of using our
        existing JSStringBuilder and HexNumber.h facilities.

        These APIs are well-exercised by our existing test suite.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::encode):
        (JSC::globalFuncEscape):

2015-04-05  Masataka Yakura  <masataka.yakura@gmail.com>

        documentation for ES Promises points to the wrong one
        https://bugs.webkit.org/show_bug.cgi?id=143263

        Reviewed by Darin Adler.

        * features.json:

2015-04-05  Simon Fraser  <simon.fraser@apple.com>

        Remove "go ahead and" from comments
        https://bugs.webkit.org/show_bug.cgi?id=143421

        Reviewed by Darin Adler, Benjamin Poulain.

        Remove the phrase "go ahead and" from comments where it doesn't add
        anything (which is almost all of them).

        * interpreter/JSStack.cpp:
        (JSC::JSStack::growSlowCase):

2015-04-04  Andreas Kling  <akling@apple.com>

        Logically empty WeakBlocks should not pin down their MarkedBlocks indefinitely.
        <https://webkit.org/b/143210>

        Reviewed by Geoffrey Garen.

        Since a MarkedBlock cannot be destroyed until all the WeakBlocks pointing into it are gone,
        we had a little problem where WeakBlocks with only null pointers would still keep their
        MarkedBlock alive.

        This patch fixes that by detaching WeakBlocks from their MarkedBlock once a sweep discovers
        that the WeakBlock contains no pointers to live objects. Ownership of the WeakBlock is passed
        to the Heap, which will sweep the list of these detached WeakBlocks as part of a full GC,
        destroying them once they're fully dead.

        This allows the garbage collector to reclaim the 64kB MarkedBlocks much sooner, and resolves
        a mysterious issue where doing two full garbage collections back-to-back would free additional
        memory in the second collection.

        Management of detached WeakBlocks is implemented as a Vector<WeakBlock*> in Heap, along with
        an index of the next block in that vector that needs to be swept. The IncrementalSweeper then
        calls into Heap::sweepNextLogicallyEmptyWeakBlock() to sweep one block at a time.

        * heap/Heap.h:
        * heap/Heap.cpp:
        (JSC::Heap::collectAllGarbage): Add a final pass where we sweep the logically empty WeakBlocks
        owned by Heap, after everything else has been swept.

        (JSC::Heap::notifyIncrementalSweeper): Set up an incremental sweep of logically empty WeakBlocks
        after a full garbage collection ends. Note that we don't do this after Eden collections, since
        they are unlikely to cause entire WeakBlocks to go empty.

        (JSC::Heap::addLogicallyEmptyWeakBlock): Added. Interface for passing ownership of a WeakBlock
        to the Heap when it's detached from a WeakSet.

        (JSC::Heap::sweepAllLogicallyEmptyWeakBlocks): Helper for collectAllGarbage() that sweeps all
        of the logically empty WeakBlocks owned by Heap.

        (JSC::Heap::sweepNextLogicallyEmptyWeakBlock): Sweeps one logically empty WeakBlock if needed
        and updates the next-logically-empty-weak-block-to-sweep index.

        (JSC::Heap::lastChanceToFinalize): call sweepAllLogicallyEmptyWeakBlocks() here, since there
        won't be another chance after this.

        * heap/IncrementalSweeper.h:
        (JSC::IncrementalSweeper::hasWork): Deleted.

        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::fullSweep):
        (JSC::IncrementalSweeper::doSweep):
        (JSC::IncrementalSweeper::sweepNextBlock): Restructured IncrementalSweeper a bit to simplify
        adding a new sweeping stage for the Heap's logically empty WeakBlocks. sweepNextBlock() is
        changed to return a bool (true if there's more work to be done.)

        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::sweep): This now figures out if the WeakBlock is logically empty, i.e doesn't
        contain any pointers to live objects. The answer is stored in a new SweepResult member.

        * heap/WeakBlock.h:
        (JSC::WeakBlock::isLogicallyEmptyButNotFree): Added. Can be queried after a sweep to determine
        if the WeakBlock could be detached from the MarkedBlock.

        (JSC::WeakBlock::SweepResult::SweepResult): Deleted in favor of initializing member variables
        when declaring them.

2015-04-04  Yusuke Suzuki  <utatane.tea@gmail.com>

        Implement ES6 Object.getOwnPropertySymbols
        https://bugs.webkit.org/show_bug.cgi?id=141106

        Reviewed by Geoffrey Garen.

        This patch implements `Object.getOwnPropertySymbols`.
        One technical issue is that, since we use private symbols (such as `@Object`) in the
        privileged JS code in `builtins/`, they should not be exposed.
        To distinguish them from the usual symbols, check the target `StringImpl*` is a not private name
        before adding it into PropertyNameArray.

        To check the target `StringImpl*` is a private name, we leverage privateToPublic map in `BuiltinNames`
        since all private symbols are held in this map.

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutableInternal):
        * builtins/BuiltinNames.h:
        (JSC::BuiltinNames::isPrivateName):
        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::isPrivateName):
        * runtime/CommonIdentifiers.h:
        * runtime/EnumerationMode.h:
        (JSC::EnumerationMode::EnumerationMode):
        (JSC::EnumerationMode::includeSymbolProperties):
        * runtime/ExceptionHelpers.cpp:
        (JSC::createUndefinedVariableError):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSLexicalEnvironment.cpp:
        (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        (JSC::objectConstructorGetOwnPropertySymbols):
        (JSC::defineProperties):
        (JSC::objectConstructorSeal):
        (JSC::objectConstructorFreeze):
        (JSC::objectConstructorIsSealed):
        (JSC::objectConstructorIsFrozen):
        * runtime/ObjectConstructor.h:
        (JSC::ObjectConstructor::create):
        * runtime/Structure.cpp:
        (JSC::Structure::getPropertyNamesFromStructure):
        * tests/stress/object-get-own-property-symbols-perform-to-object.js: Added.
        (compare):
        * tests/stress/object-get-own-property-symbols.js: Added.
        (forIn):
        * tests/stress/symbol-define-property.js: Added.
        (testSymbol):
        * tests/stress/symbol-seal-and-freeze.js: Added.
        * tests/stress/symbol-with-json.js: Added.

2015-04-03  Mark Lam  <mark.lam@apple.com>

        Add Options::jitPolicyScale() as a single knob to make all compilations happen sooner.
        <https://webkit.org/b/143385>

        Reviewed by Geoffrey Garen.

        For debugging purposes, sometimes, we want to be able to make compilation happen
        sooner to see if we can accelerate the manifestation of certain events / bugs.
        Currently, in order to achieve this, we'll have to tweak multiple JIT thresholds
        which make up the compilation policy.  Let's add a single knob that can tune all
        the thresholds up / down in one go proportionately so that we can easily tweak
        how soon compilation occurs.

        * runtime/Options.cpp:
        (JSC::scaleJITPolicy):
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:

2015-04-03  Geoffrey Garen  <ggaren@apple.com>

        is* API methods should be @properties
        https://bugs.webkit.org/show_bug.cgi?id=143388

        Reviewed by Mark Lam.

        This appears to be the preferred idiom in WebKit, CA, AppKit, and
        Foundation.

        * API/JSValue.h: Be @properties.

        * API/tests/testapi.mm:
        (testObjectiveCAPI): Use the @properties.

2015-04-03  Mark Lam  <mark.lam@apple.com>

        Some JSC Options refactoring and enhancements.
        <https://webkit.org/b/143384>

        Rubber stamped by Benjamin Poulain.

        Create a better encapsulated Option class to make working with options easier.  This
        is a building block towards a JIT policy scaling debugging option I will introduce later.

        This work entails:
        1. Convert Options::Option into a public class Option (who works closely with Options).
        2. Convert Options::EntryType into an enum class Options::Type and make it public.
        3. Renamed Options::OPT_<option name> to Options::<option name>ID because it reads better.
        4. Add misc methods to class Option to make it more useable.

        * runtime/Options.cpp:
        (JSC::Options::dumpOption):
        (JSC::Option::dump):
        (JSC::Option::operator==):
        (JSC::Options::Option::dump): Deleted.
        (JSC::Options::Option::operator==): Deleted.
        * runtime/Options.h:
        (JSC::Option::Option):
        (JSC::Option::operator!=):
        (JSC::Option::name):
        (JSC::Option::description):
        (JSC::Option::type):
        (JSC::Option::isOverridden):
        (JSC::Option::defaultOption):
        (JSC::Option::boolVal):
        (JSC::Option::unsignedVal):
        (JSC::Option::doubleVal):
        (JSC::Option::int32Val):
        (JSC::Option::optionRangeVal):
        (JSC::Option::optionStringVal):
        (JSC::Option::gcLogLevelVal):
        (JSC::Options::Option::Option): Deleted.
        (JSC::Options::Option::operator!=): Deleted.

2015-04-03  Geoffrey Garen  <ggaren@apple.com>

        JavaScriptCore API should support type checking for Array and Date
        https://bugs.webkit.org/show_bug.cgi?id=143324

        Follow-up to address a comment by Dan.

        * API/WebKitAvailability.h: __MAC_OS_X_VERSION_MIN_REQUIRED <= 101100
        is wrong, since this API is available when __MAC_OS_X_VERSION_MIN_REQUIRED
        is equal to 101100.

2015-04-03  Geoffrey Garen  <ggaren@apple.com>

        JavaScriptCore API should support type checking for Array and Date
        https://bugs.webkit.org/show_bug.cgi?id=143324

        Follow-up to address a comment by Dan.

        * API/WebKitAvailability.h: Do use 10.0 because it was right all along.
        Added a comment explaining why.

2015-04-03  Csaba Osztrogonác  <ossy@webkit.org>

        FTL JIT tests should fail if LLVM library isn't available
        https://bugs.webkit.org/show_bug.cgi?id=143374

        Reviewed by Mark Lam.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * runtime/Options.h:

2015-04-03  Zan Dobersek  <zdobersek@igalia.com>

        Fix the EFL and GTK build after r182243
        https://bugs.webkit.org/show_bug.cgi?id=143361

        Reviewed by Csaba Osztrogonác.

        * CMakeLists.txt: InspectorBackendCommands.js is generated in the
        DerivedSources/JavaScriptCore/inspector/ directory.

2015-04-03  Zan Dobersek  <zdobersek@igalia.com>

        Unreviewed, fixing Clang builds of the GTK port on Linux.

        * runtime/Options.cpp:
        Include the <math.h> header for isnan().

2015-04-02  Mark Lam  <mark.lam@apple.com>

        Enhance ability to dump JSC Options.
        <https://webkit.org/b/143357>

        Reviewed by Benjamin Poulain.

        Some enhancements to how the JSC options work:

        1. Add a JSC_showOptions option which take values: 0 = None, 1 = Overridden only,
           2 = All, 3 = Verbose.

           The default is 0 (None).  This dumps nothing.
           With the Overridden setting, at VM initialization time, we will dump all
           option values that have been changed from their default.
           With the All setting, at VM initialization time, we will dump all option values.
           With the Verbose setting, at VM initialization time, we will dump all option
           values along with their descriptions (if available).

        2. We now store a copy of the default option values.

           We later use this for comparison to tell if an option has been overridden, and
           print the default value for reference.  As a result, we no longer need the
           didOverride flag since we can compute whether the option is overridden at any time.

        3. Added description strings to some options to be printed when JSC_showOptions=3 (Verbose).

           This will come in handy later when we want to rename some of the options to more sane
           names that are easier to remember.  For example, we can change
           Options::dfgFunctionWhitelistFile() to Options::dfgWhiteList(), and
           Options::slowPathAllocsBetweenGCs() to Options::forcedGcRate().  With the availability
           of the description, we can afford to use shorter and less descriptive option names,
           but they will be easier to remember and use for day to day debugging work.

           In this patch, I did not change the names of any of the options yet.  I only added
           description strings for options that I know about, and where I think the option name
           isn't already descriptive enough.

        4. Also deleted some unused code.

        * jsc.cpp:
        (CommandLine::parseArguments):
        * runtime/Options.cpp:
        (JSC::Options::initialize):
        (JSC::Options::setOption):
        (JSC::Options::dumpAllOptions):
        (JSC::Options::dumpOption):
        (JSC::Options::Option::dump):
        (JSC::Options::Option::operator==):
        * runtime/Options.h:
        (JSC::OptionRange::rangeString):
        (JSC::Options::Option::Option):
        (JSC::Options::Option::operator!=):

2015-04-02  Geoffrey Garen  <ggaren@apple.com>

        JavaScriptCore API should support type checking for Array and Date
        https://bugs.webkit.org/show_bug.cgi?id=143324

        Reviewed by Darin Adler, Sam Weinig, Dan Bernstein.

        * API/JSValue.h:
        * API/JSValue.mm:
        (-[JSValue isArray]):
        (-[JSValue isDate]): Added an ObjC API.

        * API/JSValueRef.cpp:
        (JSValueIsArray):
        (JSValueIsDate):
        * API/JSValueRef.h: Added a C API.

        * API/WebKitAvailability.h: Brought our availability macros up to date
        and fixed a harmless bug where "10_10" translated to "10.0".

        * API/tests/testapi.c:
        (main): Added a test and corrected a pre-existing leak.

        * API/tests/testapi.mm:
        (testObjectiveCAPI): Added a test.

2015-04-02  Mark Lam  <mark.lam@apple.com>

        Add Options::dumpSourceAtDFGTime().
        <https://webkit.org/b/143349>

        Reviewed by Oliver Hunt, and Michael Saboff.

        Sometimes, we will want to see the JS source code that we're compiling, and it
        would be nice to be able to do this without having to jump thru a lot of hoops.
        So, let's add a Options::dumpSourceAtDFGTime() option just like we have a
        Options::dumpBytecodeAtDFGTime() option.

        Also added versions of CodeBlock::dumpSource() and CodeBlock::dumpBytecode()
        that explicitly take no arguments (instead of relying on the version that takes
        the default argument).  These versions are friendlier to use when we want to call
        them from an interactive debugging session.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpSource):
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/CodeBlock.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * runtime/Options.h:

2015-04-02  Yusuke Suzuki  <utatane.tea@gmail.com>

        Clean up EnumerationMode to easily extend
        https://bugs.webkit.org/show_bug.cgi?id=143276

        Reviewed by Geoffrey Garen.

        To make the followings easily,
        1. Adding new flag Include/ExcludeSymbols in the Object.getOwnPropertySymbols patch
        2. Make ExcludeSymbols implicitly default for the existing flags
        we encapsulate EnumerationMode flags into EnumerationMode class.

        And this class manages 2 flags. Later it will be extended to 3.
        1. DontEnumPropertiesMode (default is Exclude)
        2. JSObjectPropertiesMode (default is Include)
        3. SymbolPropertiesMode (default is Exclude)
            SymbolPropertiesMode will be added in Object.getOwnPropertySymbols patch.

        This patch replaces places using ExcludeDontEnumProperties
        to EnumerationMode() value which represents default mode.

        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::getOwnNonIndexPropertyNames):
        * API/JSObjectRef.cpp:
        (JSObjectCopyPropertyNames):
        * bindings/ScriptValue.cpp:
        (Deprecated::jsToInspectorValue):
        * bytecode/ObjectAllocationProfile.h:
        (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSort):
        * runtime/EnumerationMode.h:
        (JSC::EnumerationMode::EnumerationMode):
        (JSC::EnumerationMode::includeDontEnumProperties):
        (JSC::EnumerationMode::includeJSObjectProperties):
        (JSC::shouldIncludeDontEnumProperties): Deleted.
        (JSC::shouldExcludeDontEnumProperties): Deleted.
        (JSC::shouldIncludeJSObjectPropertyNames): Deleted.
        (JSC::modeThatSkipsJSObject): Deleted.
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::getOwnPropertyNames):
        * runtime/JSArray.cpp:
        (JSC::JSArray::getOwnNonIndexPropertyNames):
        * runtime/JSArrayBuffer.cpp:
        (JSC::JSArrayBuffer::getOwnNonIndexPropertyNames):
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::getOwnNonIndexPropertyNames):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnNonIndexPropertyNames):
        * runtime/JSFunction.h:
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnNonIndexPropertyNames):
        * runtime/JSLexicalEnvironment.cpp:
        (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Holder::appendNextProperty):
        (JSC::Walker::walk):
        * runtime/JSObject.cpp:
        (JSC::getClassPropertyNames):
        (JSC::JSObject::getOwnPropertyNames):
        (JSC::JSObject::getOwnNonIndexPropertyNames):
        (JSC::JSObject::getGenericPropertyNames):
        * runtime/JSPropertyNameEnumerator.h:
        (JSC::propertyNameEnumerator):
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetOwnPropertyNames):
        (JSC::objectConstructorKeys):
        (JSC::defineProperties):
        (JSC::objectConstructorSeal):
        (JSC::objectConstructorFreeze):
        (JSC::objectConstructorIsSealed):
        (JSC::objectConstructorIsFrozen):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::getOwnNonIndexPropertyNames):
        (JSC::RegExpObject::getPropertyNames):
        (JSC::RegExpObject::getGenericPropertyNames):
        * runtime/StringObject.cpp:
        (JSC::StringObject::getOwnPropertyNames):
        * runtime/Structure.cpp:
        (JSC::Structure::getPropertyNamesFromStructure):

2015-04-01  Alex Christensen  <achristensen@webkit.org>

        Progress towards CMake on Windows and Mac.
        https://bugs.webkit.org/show_bug.cgi?id=143293

        Reviewed by Filip Pizlo.

        * CMakeLists.txt:
        Enabled using assembly on Windows.
        Replaced unix commands with CMake commands.
        * PlatformMac.cmake:
        Tell open source builders where to find unicode headers.

2015-04-01  Yusuke Suzuki  <utatane.tea@gmail.com>

        IteratorClose should be called when jumping over the target for-of loop
        https://bugs.webkit.org/show_bug.cgi?id=143140

        Reviewed by Geoffrey Garen.

        This patch fixes labeled break/continue behaviors with for-of and iterators.

        1. Support IteratorClose beyond multiple loop contexts
        Previously, IteratorClose is only executed in for-of's breakTarget().
        However, this misses IteratorClose execution when statement roll-ups multiple control flow contexts.
        For example,
        outer: for (var e1 of outer) {
            inner: for (var e2 of inner) {
                break outer;
            }
        }
        In this case, return method of inner should be called.
        We leverage the existing system for `finally` to execute inner.return method correctly.
        Leveraging `finally` system fixes `break`, `continue` and `return` cases.
        `throw` case is already supported by emitting try-catch handlers in for-of.

        2. Incorrect LabelScope creation is done in ForOfNode
        ForOfNode creates duplicated LabelScope.
        It causes infinite loop when executing the following program that contains
        explicitly labeled for-of loop.
        For example,
        inner: for (var elm of array) {
            continue inner;
        }

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::pushFinallyContext):
        (JSC::BytecodeGenerator::pushIteratorCloseContext):
        (JSC::BytecodeGenerator::popFinallyContext):
        (JSC::BytecodeGenerator::popIteratorCloseContext):
        (JSC::BytecodeGenerator::emitComplexPopScopes):
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::emitIteratorClose):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForOfNode::emitBytecode):
        * tests/stress/iterator-return-beyond-multiple-iteration-scopes.js: Added.
        (createIterator.iterator.return):
        (createIterator):
        * tests/stress/raise-error-in-iterator-close.js: Added.
        (createIterator.iterator.return):
        (createIterator):

2015-04-01  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement Symbol.unscopables
        https://bugs.webkit.org/show_bug.cgi?id=142829

        Reviewed by Geoffrey Garen.

        This patch introduces Symbol.unscopables functionality.
        In ES6, some generic names (like keys, values) are introduced
        as Array's method name. And this breaks the web since some web sites
        use like the following code.

        var values = ...;
        with (array) {
            values;  // This values is trapped by array's method "values".
        }

        To fix this, Symbol.unscopables introduces blacklist
        for with scope's trapping. When resolving scope,
        if name is found in the target scope and the target scope is with scope,
        we check Symbol.unscopables object to filter generic names.

        This functionality is only active for with scopes.
        Global scope does not have unscopables functionality.

        And since
        1) op_resolve_scope for with scope always return Dynamic resolve type,
        2) in that case, JSScope::resolve is always used in JIT and LLInt,
        3) the code which contains op_resolve_scope that returns Dynamic cannot be compiled with DFG and FTL,
        to implement this functionality, we just change JSScope::resolve and no need to change JIT code.
        So performance regression is only visible in Dynamic resolving case, and it is already much slow.

        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::runtimeFlags):
        * runtime/JSScope.cpp:
        (JSC::isUnscopable):
        (JSC::JSScope::resolve):
        * runtime/JSScope.h:
        (JSC::ScopeChainIterator::scope):
        * tests/stress/global-environment-does-not-trap-unscopables.js: Added.
        (test):
        * tests/stress/unscopables.js: Added.
        (test):
        (.):

2015-03-31  Ryosuke Niwa  <rniwa@webkit.org>

        ES6 class syntax should allow static setters and getters
        https://bugs.webkit.org/show_bug.cgi?id=143180

        Reviewed by Filip Pizlo

        Apparently I misread the spec when I initially implemented parseClass.
        ES6 class syntax allows static getters and setters so just allow that.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):

2015-03-31  Filip Pizlo  <fpizlo@apple.com>

        PutClosureVar CSE def() rule has a wrong base
        https://bugs.webkit.org/show_bug.cgi?id=143280

        Reviewed by Michael Saboff.
        
        I think that this code was incorrect in a benign way, since the base of a
        PutClosureVar is not a JS-visible object. But it was preventing some optimizations.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):

2015-03-31  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r182200.
        https://bugs.webkit.org/show_bug.cgi?id=143279

        Probably causing assertion extravaganza on bots. (Requested by
        kling on #webkit).

        Reverted changeset:

        "Logically empty WeakBlocks should not pin down their
        MarkedBlocks indefinitely."
        https://bugs.webkit.org/show_bug.cgi?id=143210
        http://trac.webkit.org/changeset/182200

2015-03-31  Yusuke Suzuki  <utatane.tea@gmail.com>

        Clean up Identifier factories to clarify the meaning of StringImpl*
        https://bugs.webkit.org/show_bug.cgi?id=143146

        Reviewed by Filip Pizlo.

        In the a lot of places, `Identifier(VM*/ExecState*, StringImpl*)` constructor is used.
        However, it's ambiguous because `StringImpl*` has 2 different meanings.
        1) normal string, it is replacable with `WTFString` and
        2) `uid`, which holds `isSymbol` information to represent Symbols.
        So we dropped Identifier constructors for strings and instead, introduced 2 factory functions.
        + `Identifier::fromString(VM*/ExecState*, const String&)`.
        Just construct Identifier from strings. The symbol-ness of StringImpl* is not kept.
        + `Identifier::fromUid(VM*/ExecState*, StringImpl*)`.
        This function is used for 2) `uid`. So symbol-ness of `StringImpl*` is kept.

        And to clean up `StringImpl` which is used as uid,
        we introduce `StringKind` into `StringImpl`. There's 3 kinds
        1. StringNormal (non-atomic, non-symbol)
        2. StringAtomic (atomic, non-symbol)
        3. StringSymbol (non-atomic, symbol)
        They are mutually exclusive. And (atomic, symbol) case should not exist.

        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::getOwnNonIndexPropertyNames):
        * API/JSObjectRef.cpp:
        (JSObjectMakeFunction):
        * API/OpaqueJSString.cpp:
        (OpaqueJSString::identifier):
        * bindings/ScriptFunctionCall.cpp:
        (Deprecated::ScriptFunctionCall::call):
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutableInternal):
        * builtins/BuiltinNames.h:
        (JSC::BuiltinNames::BuiltinNames):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitThrowReferenceError):
        (JSC::BytecodeGenerator::emitThrowTypeError):
        (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
        (JSC::BytecodeGenerator::emitEnumeration):
        * dfg/DFGDesiredIdentifiers.cpp:
        (JSC::DFG::DesiredIdentifiers::reallyAdd):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::functionDetails):
        (Inspector::constructInternalProperty):
        (Inspector::JSInjectedScriptHost::weakMapEntries):
        (Inspector::JSInjectedScriptHost::iteratorEntries):
        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::extractSourceInformationFromException):
        * jit/JITOperations.cpp:
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (GlobalObject::addFunction):
        (GlobalObject::addConstructableFunction):
        (functionRun):
        (runWithScripts):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::addVar):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::createBindingPattern):
        * parser/ParserArena.h:
        (JSC::IdentifierArena::makeIdentifier):
        (JSC::IdentifierArena::makeIdentifierLCharFromUChar):
        (JSC::IdentifierArena::makeNumericIdentifier):
        * runtime/ArgumentsIteratorPrototype.cpp:
        (JSC::ArgumentsIteratorPrototype::finishCreation):
        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::arrayProtoFuncPush):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::getOwnPropertySlot):
        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::CommonIdentifiers):
        * runtime/CommonIdentifiers.h:
        * runtime/Error.cpp:
        (JSC::addErrorInfo):
        (JSC::hasErrorInfo):
        * runtime/ExceptionHelpers.cpp:
        (JSC::createUndefinedVariableError):
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::getOwnPropertySlot):
        * runtime/Identifier.h:
        (JSC::Identifier::isSymbol):
        (JSC::Identifier::Identifier):
        (JSC::Identifier::from): Deleted.
        * runtime/IdentifierInlines.h:
        (JSC::Identifier::Identifier):
        (JSC::Identifier::fromUid):
        (JSC::Identifier::fromString):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::dumpInContextAssumingStructure):
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::toPropertyKey):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSLexicalEnvironment.cpp:
        (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
        * runtime/JSObject.cpp:
        (JSC::getClassPropertyNames):
        (JSC::JSObject::reifyStaticFunctionsForDelete):
        * runtime/JSObject.h:
        (JSC::makeIdentifier):
        * runtime/JSPromiseConstructor.cpp:
        (JSC::JSPromiseConstructorFuncRace):
        (JSC::JSPromiseConstructorFuncAll):
        * runtime/JSString.h:
        (JSC::JSString::toIdentifier):
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
        * runtime/LiteralParser.cpp:
        (JSC::LiteralParser<CharType>::tryJSONPParse):
        (JSC::LiteralParser<CharType>::makeIdentifier):
        * runtime/Lookup.h:
        (JSC::reifyStaticProperties):
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototype::finishCreation):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/MathObject.cpp:
        (JSC::MathObject::finishCreation):
        * runtime/NumberConstructor.cpp:
        (JSC::NumberConstructor::finishCreation):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        * runtime/PrivateName.h:
        (JSC::PrivateName::PrivateName):
        * runtime/PropertyMapHashTable.h:
        (JSC::PropertyTable::find):
        (JSC::PropertyTable::get):
        * runtime/PropertyName.h:
        (JSC::PropertyName::PropertyName):
        (JSC::PropertyName::publicName):
        (JSC::PropertyName::asIndex):
        * runtime/PropertyNameArray.cpp:
        (JSC::PropertyNameArray::add):
        * runtime/PropertyNameArray.h:
        (JSC::PropertyNameArray::addKnownUnique):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::finishCreation):
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototype::finishCreation):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        * runtime/StringIteratorPrototype.cpp:
        (JSC::StringIteratorPrototype::finishCreation):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        * runtime/Structure.cpp:
        (JSC::Structure::getPropertyNamesFromStructure):
        * runtime/SymbolConstructor.cpp:
        * runtime/VM.cpp:
        (JSC::VM::throwException):
        * runtime/WeakMapConstructor.cpp:
        (JSC::constructWeakMap):

2015-03-31  Andreas Kling  <akling@apple.com>

        Logically empty WeakBlocks should not pin down their MarkedBlocks indefinitely.
        <https://webkit.org/b/143210>

        Reviewed by Geoffrey Garen.

        Since a MarkedBlock cannot be destroyed until all the WeakBlocks pointing into it are gone,
        we had a little problem where WeakBlocks with only null pointers would still keep their
        MarkedBlock alive.

        This patch fixes that by detaching WeakBlocks from their MarkedBlock once a sweep discovers
        that the WeakBlock contains no pointers to live objects. Ownership of the WeakBlock is passed
        to the Heap, which will sweep the list of these detached WeakBlocks as part of a full GC,
        destroying them once they're fully dead.

        This allows the garbage collector to reclaim the 64kB MarkedBlocks much sooner, and resolves
        a mysterious issue where doing two full garbage collections back-to-back would free additional
        memory in the second collection.

        Management of detached WeakBlocks is implemented as a Vector<WeakBlock*> in Heap, along with
        an index of the next block in that vector that needs to be swept. The IncrementalSweeper then
        calls into Heap::sweepNextLogicallyEmptyWeakBlock() to sweep one block at a time.

        * heap/Heap.h:
        * heap/Heap.cpp:
        (JSC::Heap::collectAllGarbage): Add a final pass where we sweep the logically empty WeakBlocks
        owned by Heap, after everything else has been swept.

        (JSC::Heap::notifyIncrementalSweeper): Set up an incremental sweep of logically empty WeakBlocks
        after a full garbage collection ends. Note that we don't do this after Eden collections, since
        they are unlikely to cause entire WeakBlocks to go empty.

        (JSC::Heap::addLogicallyEmptyWeakBlock): Added. Interface for passing ownership of a WeakBlock
        to the Heap when it's detached from a WeakSet.

        (JSC::Heap::sweepAllLogicallyEmptyWeakBlocks): Helper for collectAllGarbage() that sweeps all
        of the logically empty WeakBlocks owned by Heap.

        (JSC::Heap::sweepNextLogicallyEmptyWeakBlock): Sweeps one logically empty WeakBlock if needed
        and updates the next-logically-empty-weak-block-to-sweep index.

        (JSC::Heap::lastChanceToFinalize): call sweepAllLogicallyEmptyWeakBlocks() here, since there
        won't be another chance after this.

        * heap/IncrementalSweeper.h:
        (JSC::IncrementalSweeper::hasWork): Deleted.

        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::fullSweep):
        (JSC::IncrementalSweeper::doSweep):
        (JSC::IncrementalSweeper::sweepNextBlock): Restructured IncrementalSweeper a bit to simplify
        adding a new sweeping stage for the Heap's logically empty WeakBlocks. sweepNextBlock() is
        changed to return a bool (true if there's more work to be done.)

        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::sweep): This now figures out if the WeakBlock is logically empty, i.e doesn't
        contain any pointers to live objects. The answer is stored in a new SweepResult member.

        * heap/WeakBlock.h:
        (JSC::WeakBlock::isLogicallyEmptyButNotFree): Added. Can be queried after a sweep to determine
        if the WeakBlock could be detached from the MarkedBlock.

        (JSC::WeakBlock::SweepResult::SweepResult): Deleted in favor of initializing member variables
        when declaring them.

2015-03-31  Ryosuke Niwa  <rniwa@webkit.org>

        eval("this.foo") causes a crash if this had not been initialized in a derived class's constructor
        https://bugs.webkit.org/show_bug.cgi?id=142883

        Reviewed by Filip Pizlo.

        The crash was caused by eval inside the constructor of a derived class not checking TDZ.

        Fixed the bug by adding a parser flag that forces the TDZ check to be always emitted when accessing "this"
        in eval inside a derived class' constructor.

        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::getSlow):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluate):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::thisExpr):
        * parser/NodeConstructors.h:
        (JSC::ThisNode::ThisNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        * parser/Parser.h:
        (JSC::parse):
        * parser/ParserModes.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::thisExpr):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        * runtime/CodeCache.h:
        (JSC::SourceCodeKey::SourceCodeKey):
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::create):
        * runtime/Executable.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createEvalCodeBlock):
        * runtime/JSGlobalObject.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
        * tests/stress/class-syntax-no-tdz-in-eval.js: Added.
        * tests/stress/class-syntax-tdz-in-eval.js: Added.

2015-03-31  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r182186.
        https://bugs.webkit.org/show_bug.cgi?id=143270

        it crashes all the WebGL tests on the Debug bots (Requested by
        dino on #webkit).

        Reverted changeset:

        "Web Inspector: add 2D/WebGL canvas instrumentation
        infrastructure"
        https://bugs.webkit.org/show_bug.cgi?id=137278
        http://trac.webkit.org/changeset/182186

2015-03-31  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Object type restrictions on a first parameter of several Object.* functions are relaxed
        https://bugs.webkit.org/show_bug.cgi?id=142937

        Reviewed by Darin Adler.

        In ES6, Object type restrictions on a first parameter of several Object.* functions are relaxed.
        In ES5 or prior, when a first parameter is not object type, these functions raise TypeError.
        But now, several functions perform ToObject onto a non-object parameter.
        And others behaves as if a parameter is a non-extensible ordinary object with no own properties.
        It is described in ES6 Annex E.
        Functions different from ES5 are following.

        1. An attempt is make to coerce the argument using ToObject.
            Object.getOwnPropertyDescriptor
            Object.getOwnPropertyNames
            Object.getPrototypeOf
            Object.keys

        2. Treated as if it was a non-extensible ordinary object with no own properties.
            Object.freeze
            Object.isExtensible
            Object.isFrozen
            Object.isSealed
            Object.preventExtensions
            Object.seal

        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
        (JSC::objectConstructorGetPrototypeOf):
        (JSC::objectConstructorGetOwnPropertyDescriptor):
        (JSC::objectConstructorGetOwnPropertyNames):
        (JSC::objectConstructorKeys):
        (JSC::objectConstructorSeal):
        (JSC::objectConstructorFreeze):
        (JSC::objectConstructorPreventExtensions):
        (JSC::objectConstructorIsSealed):
        (JSC::objectConstructorIsFrozen):
        (JSC::objectConstructorIsExtensible):
        * tests/stress/object-freeze-accept-non-object.js: Added.
        * tests/stress/object-get-own-property-descriptor-perform-to-object.js: Added.
        (canary):
        * tests/stress/object-get-own-property-names-perform-to-object.js: Added.
        (compare):
        * tests/stress/object-get-prototype-of-perform-to-object.js: Added.
        * tests/stress/object-is-extensible-accept-non-object.js: Added.
        * tests/stress/object-is-frozen-accept-non-object.js: Added.
        * tests/stress/object-is-sealed-accept-non-object.js: Added.
        * tests/stress/object-keys-perform-to-object.js: Added.
        (compare):
        * tests/stress/object-prevent-extensions-accept-non-object.js: Added.
        * tests/stress/object-seal-accept-non-object.js: Added.

2015-03-31  Matt Baker  <mattbaker@apple.com>

        Web Inspector: add 2D/WebGL canvas instrumentation infrastructure
        https://bugs.webkit.org/show_bug.cgi?id=137278

        Reviewed by Timothy Hatcher.

        Added Canvas protocol which defines types used by InspectorCanvasAgent.

        * CMakeLists.txt:
        * DerivedSources.make:
        * inspector/protocol/Canvas.json: Added.

        * inspector/scripts/codegen/generator.py:
        (Generator.stylized_name_for_enum_value):
        Added special handling for 2D (always uppercase) and WebGL (rename mapping) enum strings.

2015-03-30  Ryosuke Niwa  <rniwa@webkit.org>

        Extending null should set __proto__ to null
        https://bugs.webkit.org/show_bug.cgi?id=142882

        Reviewed by Geoffrey Garen and Benjamin Poulain.

        Set Derived.prototype.__proto__ to null when extending null.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ClassExprNode::emitBytecode):

2015-03-30  Mark Lam  <mark.lam@apple.com>

        REGRESSION (r181993): inspector-protocol/debugger/setBreakpoint-dfg-and-modify-local.html crashes.
        <https://webkit.org/b/143105>

        Reviewed by Filip Pizlo.

        With r181993, the DFG and FTL may elide the storing of the scope register.  As a result,
        on OSR exits from DFG / FTL frames where this elision has take place, we may get baseline
        JIT frames that may have its scope register not set.  The Debugger's current implementation
        which relies on the scope register is not happy about this.  For example, this results in a
        crash in the layout test inspector-protocol/debugger/setBreakpoint-dfg-and-modify-local.html.

        The fix is to disable inlining when the debugger is in use.  Also, we add Flush nodes to
        ensure that the scope register value is flushed to the register in the stack frame.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::ByteCodeParser):
        (JSC::DFG::ByteCodeParser::setLocal):
        (JSC::DFG::ByteCodeParser::flush):
        - Add code to flush the scope register.
        (JSC::DFG::ByteCodeParser::inliningCost):
        - Pretend that all codeBlocks are too expensive to inline if the debugger is in use, thereby
          disabling inlining whenever the debugger is in use.
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::hasDebuggerEnabled):
        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):
        - Update the DFG codeBlock's scopeRegister since it can be moved during stack layout.
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        - Update the FTL codeBlock's scopeRegister since it can be moved during stack layout.

2015-03-30  Michael Saboff  <msaboff@apple.com>

        Fix flakey float32-repeat-out-of-bounds.js and int8-repeat-out-of-bounds.js tests for ARM64
        https://bugs.webkit.org/show_bug.cgi?id=138391

        Reviewed by Mark Lam.

        Re-enabling these tests as I can't get them to fail on local iOS test devices.
        There have been many changes since these tests were disabled.
        I'll watch automated test results for failures.  If there are failures running automated
        testing, it might be due to the device's relative CPU performance.
        
        * tests/stress/float32-repeat-out-of-bounds.js:
        * tests/stress/int8-repeat-out-of-bounds.js:

2015-03-30  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Regression: Preview for [[null]] shouldn't be []
        https://bugs.webkit.org/show_bug.cgi?id=143208

        Reviewed by Mark Lam.

        * inspector/InjectedScriptSource.js:
        Handle null when generating simple object previews.

2015-03-30  Per Arne Vollan  <peavo@outlook.com>

        Avoid using hardcoded values for JSValue::Int32Tag, if possible.
        https://bugs.webkit.org/show_bug.cgi?id=143134

        Reviewed by Geoffrey Garen.

        * jit/JSInterfaceJIT.h:
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):

2015-03-30  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION: js/regress/inline-arguments-local-escape.html is flaky
        https://bugs.webkit.org/show_bug.cgi?id=143104

        Reviewed by Geoffrey Garen.
        
        Created a test that is a 100% repro of the flaky failure. This test is called
        get-my-argument-by-val-for-inlined-escaped-arguments.js. It fails all of the time because it
        always causes the compiler to emit a GetMyArgumentByVal of the arguments object returned by
        the inlined function. Other than that, it's the same as inline-arguments-local-escape.
        
        Also created three more tests for three similar, but not identical, failures.
        
        Then fixed the bug: PreciseLocalClobberize was assuming that if we read(Stack) then we are
        only reading those parts of the stack that are relevant to the current semantic code origin.
        That's false after ArgumentsEliminationPhase - we might have operations on phantom arguments,
        like GetMyArgumentByVal, ForwardVarargs, CallForwardVarargs, and ConstructForwardVarargs, that
        read parts of the stack associated with the inline call frame for the phantom arguments. This
        may not be subsumed by the current semantic origin's stack area in cases that the arguments
        were allowed to "locally" escape.
        
        The higher-order lesson here is that in DFG SSA IR, the current semantic origin's stack area
        is not really a meaningful concept anymore. It is only meaningful for nodes that will read
        the stack due to function.arguments, but there are a bunch of other ways that we could also
        read the stack and those operations may read any stack slot. I believe that this change makes
        PreciseLocalClobberize right: it will refine a read(Stack) from Clobberize correctly by casing
        on node type. In future, if we add a read(Stack) to Clobberize, we'll have to make sure that
        readTop() in PreciseLocalClobberize does the right thing.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * dfg/DFGPutStackSinkingPhase.cpp:
        * tests/stress/call-forward-varargs-for-inlined-escaped-arguments.js: Added.
        * tests/stress/construct-forward-varargs-for-inlined-escaped-arguments.js: Added.
        * tests/stress/forward-varargs-for-inlined-escaped-arguments.js: Added.
        * tests/stress/get-my-argument-by-val-for-inlined-escaped-arguments.js: Added.
        * tests/stress/real-forward-varargs-for-inlined-escaped-arguments.js: Added.

2015-03-30  Benjamin Poulain  <benjamin@webkit.org>

        Start the features.json files
        https://bugs.webkit.org/show_bug.cgi?id=143207

        Reviewed by Darin Adler.

        Start the features.json files to have something to experiment
        with for the UI.

        * features.json: Added.

2015-03-29  Myles C. Maxfield  <mmaxfield@apple.com>

        [Win] Addresing post-review comment after r182122
        https://bugs.webkit.org/show_bug.cgi?id=143189

        Unreviewed.

2015-03-29  Myles C. Maxfield  <mmaxfield@apple.com>

        [Win] Allow building JavaScriptCore without Cygwin
        https://bugs.webkit.org/show_bug.cgi?id=143189

        Reviewed by Brent Fulgham.

        Paths like /usr/bin/ don't exist on Windows.
        Hashbangs don't work on Windows. Instead we must explicitly call the executable.
        Prefixing commands with environment variables doesn't work on Windows.
        Windows doesn't have 'cmp'
        Windows uses 'del' instead of 'rm'
        Windows uses 'type NUL' intead of 'touch'

        * DerivedSources.make:
        * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make:
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.pl:
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make:
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.pl:
        * JavaScriptCore.vcxproj/build-generated-files.pl:
        * UpdateContents.py: Copied from Source/JavaScriptCore/JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.pl.

2015-03-28  Joseph Pecoraro  <pecoraro@apple.com>

        Clean up JavaScriptCore/builtins
        https://bugs.webkit.org/show_bug.cgi?id=143177

        Reviewed by Ryosuke Niwa.

        * builtins/ArrayConstructor.js:
        (from):
        - We can compare to undefined instead of using a typeof undefined check.
        - Converge on double quoted strings everywhere.

        * builtins/ArrayIterator.prototype.js:
        (next):
        * builtins/StringIterator.prototype.js:
        (next):
        - Use shorthand object construction to avoid duplication.
        - Improve grammar in error messages.

        * tests/stress/array-iterators-next-with-call.js:
        * tests/stress/string-iterators.js:
        - Update for new error message strings.

2015-03-28  Saam Barati  <saambarati1@gmail.com>

        Web Inspector: ES6: Better support for Symbol types in Type Profiler
        https://bugs.webkit.org/show_bug.cgi?id=141257

        Reviewed by Joseph Pecoraro.

        ES6 introduces the new primitive type Symbol. This patch makes JSC's 
        type profiler support this new primitive type.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * inspector/protocol/Runtime.json:
        * runtime/RuntimeType.cpp:
        (JSC::runtimeTypeForValue):
        * runtime/RuntimeType.h:
        (JSC::runtimeTypeIsPrimitive):
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::addTypeInformation):
        (JSC::TypeSet::dumpTypes):
        (JSC::TypeSet::doesTypeConformTo):
        (JSC::TypeSet::displayName):
        (JSC::TypeSet::inspectorTypeSet):
        (JSC::TypeSet::toJSONString):
        * runtime/TypeSet.h:
        (JSC::TypeSet::seenTypes):
        * tests/typeProfiler/driver/driver.js:
        * tests/typeProfiler/symbol.js: Added.
        (wrapper.foo):
        (wrapper.bar):
        (wrapper.bar.bar.baz):
        (wrapper):

2015-03-27  Saam Barati  <saambarati1@gmail.com>

        Deconstruction parameters are bound too late
        https://bugs.webkit.org/show_bug.cgi?id=143148

        Reviewed by Filip Pizlo.

        Currently, a deconstruction pattern named with the same
        name as a function will shadow the function. This is
        wrong. It should be the other way around.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):

2015-03-27  Ryosuke Niwa  <rniwa@webkit.org>

        parse doesn't initialize the 16-bit version of the JSC parser with defaultConstructorKind
        https://bugs.webkit.org/show_bug.cgi?id=143170

        Reviewed by Benjamin Poulain.

        Assert that we never use 16-bit version of the parser to parse a default constructor
        since both base and derived default constructors should be using a 8-bit string.

        * parser/Parser.h:
        (JSC::parse):

2015-03-27  Ryosuke Niwa  <rniwa@webkit.org>

        ES6 Classes: Runtime error in JIT'd class calling super() with arguments and superclass has default constructor
        https://bugs.webkit.org/show_bug.cgi?id=142862

        Reviewed by Benjamin Poulain.

        Add a test that used to fail in DFG now that the bug has been fixed by r181993.

        * tests/stress/class-syntax-derived-default-constructor.js: Added.

2015-03-27  Michael Saboff  <msaboff@apple.com>

        load8Signed() and load16Signed() should be renamed to avoid confusion
        https://bugs.webkit.org/show_bug.cgi?id=143168

        Reviewed by Benjamin Poulain.

        Renamed load8Signed() to load8SignedExtendTo32() and load16Signed() to load16SignedExtendTo32().

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::load8SignedExtendTo32):
        (JSC::MacroAssemblerARM::load16SignedExtendTo32):
        (JSC::MacroAssemblerARM::load8Signed): Deleted.
        (JSC::MacroAssemblerARM::load16Signed): Deleted.
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::load16SignedExtendTo32):
        (JSC::MacroAssemblerARM64::load8SignedExtendTo32):
        (JSC::MacroAssemblerARM64::load16Signed): Deleted.
        (JSC::MacroAssemblerARM64::load8Signed): Deleted.
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::load16SignedExtendTo32):
        (JSC::MacroAssemblerARMv7::load8SignedExtendTo32):
        (JSC::MacroAssemblerARMv7::load16Signed): Deleted.
        (JSC::MacroAssemblerARMv7::load8Signed): Deleted.
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::load8SignedExtendTo32):
        (JSC::MacroAssemblerMIPS::load16SignedExtendTo32):
        (JSC::MacroAssemblerMIPS::load8Signed): Deleted.
        (JSC::MacroAssemblerMIPS::load16Signed): Deleted.
        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::load8SignedExtendTo32):
        (JSC::MacroAssemblerSH4::load8):
        (JSC::MacroAssemblerSH4::load16SignedExtendTo32):
        (JSC::MacroAssemblerSH4::load16):
        (JSC::MacroAssemblerSH4::load8Signed): Deleted.
        (JSC::MacroAssemblerSH4::load16Signed): Deleted.
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::load8SignedExtendTo32):
        (JSC::MacroAssemblerX86Common::load16SignedExtendTo32):
        (JSC::MacroAssemblerX86Common::load8Signed): Deleted.
        (JSC::MacroAssemblerX86Common::load16Signed): Deleted.
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitIntTypedArrayGetByVal):

2015-03-27  Michael Saboff  <msaboff@apple.com>

        Fix flakey dfg-int8array.js and dfg-int16array.js tests for ARM64
        https://bugs.webkit.org/show_bug.cgi?id=138390

        Reviewed by Mark Lam.

        Changed load8Signed() and load16Signed() to only sign extend the loaded value to 32 bits
        instead of 64 bits.  This is what X86-64 does.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::load16Signed):
        (JSC::MacroAssemblerARM64::load8Signed):

2015-03-27  Saam Barati  <saambarati1@gmail.com>

        Add back previously broken assert from bug 141869
        https://bugs.webkit.org/show_bug.cgi?id=143005

        Reviewed by Michael Saboff.

        * runtime/ExceptionHelpers.cpp:
        (JSC::invalidParameterInSourceAppender):

2015-03-26  Geoffrey Garen  <ggaren@apple.com>

        Make some more objects use FastMalloc
        https://bugs.webkit.org/show_bug.cgi?id=143122

        Reviewed by Csaba Osztrogonác.

        * API/JSCallbackObject.h:
        * heap/IncrementalSweeper.h:
        * jit/JITThunks.h:
        * runtime/JSGlobalObjectDebuggable.h:
        * runtime/RegExpCache.h:

2015-03-27  Michael Saboff  <msaboff@apple.com>

        Objects with numeric properties intermittently get a phantom 'length' property
        https://bugs.webkit.org/show_bug.cgi?id=142792

        Reviewed by Csaba Osztrogonác.

        Fixed a > (greater than) that should be a >> (right shift) in the code that disassembles
        test and branch instructions.  This function is used for linking tbz/tbnz branches between
        two seperately JIT'ed sections of code.  Sometime we'd create a bogus tbz instruction in
        the failure case checks in the GetById array length stub created for "obj.length" access.
        If the failure case code address was at a negative offset from the stub, we'd look for bit 1
        being set when we should have been looking for bit 0.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::disassembleTestAndBranchImmediate):

2015-03-27  Yusuke Suzuki  <utatane.tea@gmail.com>

        Insert exception check around toPropertyKey call
        https://bugs.webkit.org/show_bug.cgi?id=142922

        Reviewed by Geoffrey Garen.

        In some places, exception check is missing after/before toPropertyKey.
        However, since it calls toString, it's observable to users,

        Missing exception checks in Object.prototype methods can be
        observed since it would be overridden with toObject(null/undefined) errors.
        We inserted exception checks after toPropertyKey.

        Missing exception checks in GetById related code can be
        observed since it would be overridden with toObject(null/undefined) errors.
        In this case, we need to insert exception checks before/after toPropertyKey
        since RequireObjectCoercible followed by toPropertyKey can cause exceptions.

        JSValue::get checks null/undefined and raise an exception if |this| is null or undefined.
        However, we need to check whether the baseValue is object coercible before executing JSValue::toPropertyKey.
        According to the spec, we first perform RequireObjectCoercible and check the exception.
        And second, we perform ToPropertyKey and check the exception.
        Since JSValue::toPropertyKey can cause toString call, this is observable to users.
        For example, if the target is not object coercible,
        ToPropertyKey should not be executed, and toString should not be executed by ToPropertyKey.
        So the order of observable actions (RequireObjectCoercible and ToPropertyKey) should be correct to the spec.

        This patch introduces JSValue::requireObjectCoercible and use it because of the following 2 reasons.

        1. Using toObject instead of requireObjectCoercible produces unnecessary wrapper object.

        toObject converts primitive types into wrapper objects.
        But it is not efficient since wrapper objects are not necessary
        if we look up methods from primitive values's prototype. (using synthesizePrototype is better).

        2. Using the result of toObject is not correct to the spec.

        To align to the spec correctly, we cannot use JSObject::get
        by using the wrapper object produced by the toObject suggested in (1).
        If we use JSObject that is converted by toObject, getter will be called by using this JSObject as |this|.
        It is not correct since getter should be called with the original |this| value that may be primitive types.

        So in this patch, we use JSValue::requireObjectCoercible
        to check the target is object coercible and raise an error if it's not.

        * dfg/DFGOperations.cpp:
        * jit/JITOperations.cpp:
        (JSC::getByVal):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::getByVal):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::requireObjectCoercible):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncHasOwnProperty):
        (JSC::objectProtoFuncDefineGetter):
        (JSC::objectProtoFuncDefineSetter):
        (JSC::objectProtoFuncLookupGetter):
        (JSC::objectProtoFuncLookupSetter):
        (JSC::objectProtoFuncPropertyIsEnumerable):
        * tests/stress/exception-in-to-property-key-should-be-handled-early-in-object-methods.js: Added.
        (shouldThrow):
        (if):
        * tests/stress/exception-in-to-property-key-should-be-handled-early.js: Added.
        (shouldThrow):
        (.):

2015-03-26  Joseph Pecoraro  <pecoraro@apple.com>

        WebContent Crash when instantiating class with Type Profiling enabled
        https://bugs.webkit.org/show_bug.cgi?id=143037

        Reviewed by Ryosuke Niwa.

        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitMoveEmptyValue):
        We cannot profile the type of an uninitialized empty JSValue.
        Nor do we expect this to be necessary, since it is effectively
        an unseen undefined value. So add a way to put the empty value
        without profiling.

        (JSC::BytecodeGenerator::emitMove):
        Add an assert to try to catch this issue early on, and force
        callers to explicitly use emitMoveEmptyValue instead.

        * tests/typeProfiler/classes.js: Added.
        (wrapper.Base):
        (wrapper.Derived):
        (wrapper):
        Add test coverage both for this case and classes in general.

2015-03-26  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: ES6: Provide a better view for Classes in the console
        https://bugs.webkit.org/show_bug.cgi?id=142999

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Runtime.json:
        Provide a new `subtype` enum "class". This is a subtype of `type`
        "function", all other subtypes are subtypes of `object` types.
        For a class, the frontend will immediately want to get the prototype
        to enumerate its methods, so include the `classPrototype`.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        Denote class construction functions as "class" subtypes.

        * inspector/InjectedScriptSource.js:
        Handling for the new "class" type.

        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedFunctionExecutable::isClassConstructorFunction):
        * runtime/Executable.h:
        (JSC::FunctionExecutable::isClassConstructorFunction):
        * runtime/JSFunction.h:
        * runtime/JSFunctionInlines.h:
        (JSC::JSFunction::isClassConstructorFunction):
        Check if this function is a class constructor function. That information
        is on the UnlinkedFunctionExecutable, so plumb it through to JSFunction.

2015-03-26  Geoffrey Garen  <ggaren@apple.com>

        Function.prototype.toString should not decompile the AST
        https://bugs.webkit.org/show_bug.cgi?id=142853

        Reviewed by Darin Adler.

        Following up on Darin's review comments.

        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):

2015-03-26  Geoffrey Garen  <ggaren@apple.com>

        "lineNo" does not match WebKit coding style guidelines
        https://bugs.webkit.org/show_bug.cgi?id=143119

        Reviewed by Michael Saboff.

        We can afford to use whole words.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::lineNumberForBytecodeOffset):
        (JSC::CodeBlock::expressionRangeForBytecodeOffset):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::link):
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        * bytecode/UnlinkedCodeBlock.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::WhileNode::emitBytecode):
        * debugger/Debugger.cpp:
        (JSC::Debugger::toggleBreakpoint):
        * interpreter/Interpreter.cpp:
        (JSC::StackFrame::computeLineAndColumn):
        (JSC::GetStackTraceFunctor::operator()):
        (JSC::Interpreter::execute):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::computeLineAndColumn):
        * parser/Nodes.h:
        (JSC::Node::firstLine):
        (JSC::Node::lineNo): Deleted.
        (JSC::StatementNode::firstLine): Deleted.
        * parser/ParserError.h:
        (JSC::ParserError::toErrorObject):
        * profiler/LegacyProfiler.cpp:
        (JSC::createCallIdentifierFromFunctionImp):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::ScriptExecutable):
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::FunctionExecutable::fromGlobalCode):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::firstLine):
        (JSC::ScriptExecutable::setOverrideLineNumber):
        (JSC::ScriptExecutable::hasOverrideLineNumber):
        (JSC::ScriptExecutable::overrideLineNumber):
        (JSC::ScriptExecutable::lineNo): Deleted.
        (JSC::ScriptExecutable::setOverrideLineNo): Deleted.
        (JSC::ScriptExecutable::hasOverrideLineNo): Deleted.
        (JSC::ScriptExecutable::overrideLineNo): Deleted.
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionConstructor.h:
        * tools/CodeProfile.cpp:
        (JSC::CodeProfile::report):
        * tools/CodeProfile.h:
        (JSC::CodeProfile::CodeProfile):

2015-03-26  Geoffrey Garen  <ggaren@apple.com>

        Assertion firing in JavaScriptCore/parser/parser.h for statesman.com site
        https://bugs.webkit.org/show_bug.cgi?id=142974

        Reviewed by Joseph Pecoraro.

        This patch does two things:

        (1) Restore JavaScriptCore's sanitization of line and column numbers to
        one-based values.

        We need this because WebCore sometimes provides huge negative column
        numbers.

        (2) Solve the attribute event listener line numbering problem a different
        way: Rather than offseting all line numbers by -1 in an attribute event
        listener in order to arrange for a custom result, instead use an explicit
        feature for saying "all errors in this code should map to this line number".

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::link):
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        * bytecode/UnlinkedCodeBlock.h:
        * interpreter/Interpreter.cpp:
        (JSC::StackFrame::computeLineAndColumn):
        (JSC::GetStackTraceFunctor::operator()):
        * interpreter/Interpreter.h:
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::computeLineAndColumn):
        * parser/ParserError.h:
        (JSC::ParserError::toErrorObject): Plumb through an override line number.
        When a function has an override line number, all syntax and runtime
        errors in the function will map to it. This is useful for attribute event
        listeners.
 
        * parser/SourceCode.h:
        (JSC::SourceCode::SourceCode): Restore the old sanitization of line and
        column numbers to one-based integers. It was kind of a hack to remove this.

        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::ScriptExecutable):
        (JSC::FunctionExecutable::fromGlobalCode):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::setOverrideLineNo):
        (JSC::ScriptExecutable::hasOverrideLineNo):
        (JSC::ScriptExecutable::overrideLineNo):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionConstructor.h: Plumb through an override line number.

2015-03-26  Filip Pizlo  <fpizlo@apple.com>

        If we're in code for accessing scoped arguments, we should probably check if the object is a scoped arguments rather than checking if it's a direct arguments.

        Reviewed by Michael Saboff.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitScopedArgumentsGetByVal):
        * tests/stress/scoped-then-direct-arguments-get-by-val-in-baseline.js: Added.

2015-03-26  Filip Pizlo  <fpizlo@apple.com>

        FTL ScopedArguments GetArrayLength generates incorrect code and crashes in LLVM
        https://bugs.webkit.org/show_bug.cgi?id=143098

        Reviewed by Csaba Osztrogonác.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength): Fix a typo.
        * tests/stress/scoped-arguments-array-length.js: Added. This test previously always crashed in ftl-no-cjit mode.

2015-03-26  Csaba Osztrogonác  <ossy@webkit.org>

        Unreviewed gardening, skip failing tests on AArch64 Linux.

        * tests/mozilla/mozilla-tests.yaml:
        * tests/stress/cached-prototype-setter.js:

2015-03-26  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fixes to silly things. While landing fixes to r181993, I introduced crashes. This fixes them.

        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants): I landed a fix for a VS warning. It broke this. Now I'm fixing it.
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile): Make sure we pass the module when dumping. This makes FTL debugging possible again.
        * ftl/FTLState.cpp:
        (JSC::FTL::State::dumpState): New overload that takes a module, so that we can call this after FTL::compile() clears State's module.
        * ftl/FTLState.h:

2015-03-25  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix obvious goof that was causing 32-bit debug crashes. The 64-bit version did it
        right, so this just makes 32-bit do the same.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):

2015-03-25  Filip Pizlo  <fpizlo@apple.com>

        Fix a typo that ggaren found but that I didn't fix before.

        * runtime/DirectArgumentsOffset.h:

2015-03-25  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, VC found a bug. This fixes the bug.

        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):

2015-03-25  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, try to fix Windows build.

        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createWithInlineFrame):

2015-03-25  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix debug build.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ConstDeclNode::emitCodeSingle):

2015-03-25  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix CLOOP build.

        * dfg/DFGMinifiedID.h:

2015-03-25  Filip Pizlo  <fpizlo@apple.com>

        Heap variables shouldn't end up in the stack frame
        https://bugs.webkit.org/show_bug.cgi?id=141174

        Reviewed by Geoffrey Garen.
        
        This is a major change to how JavaScriptCore handles declared variables (i.e. "var"). It removes
        any ambiguity about whether a variable should be in the heap or on the stack. A variable will no
        longer move between heap and stack during its lifetime. This enables a bunch of optimizations and
        simplifications:
        
        - Accesses to variables no longer need checks or indirections to determine where the variable is
          at that moment in time. For example, loading a closure variable now takes just one load instead
          of two. Loading an argument by index now takes a bounds check and a load in the fastest case
          (when no arguments object allocation is required) while previously that same operation required
          a "did I allocate arguments yet" check, a bounds check, and then the load.
        
        - Reasoning about the allocation of an activation or arguments object now follows the same simple
          logic as the allocation of any other kind of object. Previously, those objects were lazily
          allocated - so an allocation instruction wasn't the actual allocation site, since it might not
          allocate anything at all. This made the implementation of traditional escape analyses really
          awkward, and ultimately it meant that we missed important cases. Now, we can reason about the
          arguments object using the usual SSA tricks which allows for more comprehensive removal.
        
        - The allocations of arguments objects, functions, and activations are now much faster. While
          this patch generally expands our ability to eliminate arguments object allocations, an earlier
          version of the patch - which lacked that functionality - was a progression on some arguments-
          and closure-happy benchmarks because although no allocations were eliminated, all allocations
          were faster.
        
        - There is no tear-off. The runtime no loner needs to know about where on the stack a frame keeps
          its arguments objects or activations. The runtime doesn't have to do things to the arguments
          objects and activations that a frame allocated, when the frame is unwound. We always had horrid
          bugs in that code, so it's good to see it go. This removes *a ton* of machinery from the DFG,
          FTL, CodeBlock, and other places. All of the things having to do with "captured variables" is
          now gone. This also enables implementing block-scoping. Without this change, block-scope
          support would require telling CodeBlock and all of the rest of the runtime about all of the
          variables that store currently-live scopes. That would have been so disastrously hard that it
          might as well be impossible. With this change, it's fair game for the bytecode generator to
          simply allocate whatever activations it wants, wherever it wants, and to keep them live for
          however long it wants. This all works, because after bytecode generation, an activation is just
          an object and variables that refer to it are just normal variables.
        
        - SymbolTable can now tell you explicitly where a variable lives. The answer is in the form of a
          VarOffset object, which has methods like isStack(), isScope(), etc. VirtualRegister is never
          used for offsets of non-stack variables anymore. We now have shiny new objects for other kinds
          of offsets - ScopeOffset for offsets into scopes, and DirectArgumentsOffset for offsets into
          an arguments object.
        
        - Functions that create activations can now tier-up into the FTL. Previously they couldn't. Also,
          using activations used to prevent inlining; now functions that use activations can be inlined
          just fine.
        
        This is a >1% speed-up on Octane. This is a >2% speed-up on CompressionBench. This is a tiny
        speed-up on AsmBench (~0.4% or something). This looks like it might be a speed-up on SunSpider.
        It's only a slow-down on very short-running microbenchmarks we had previously written for our old
        style of tear-off-based arguments optimization. Those benchmarks are not part of any major suite.
        
        The easiest way of understanding this change is to start by looking at the changes in runtime/,
        and then the changes in bytecompiler/, and then sort of work your way up the compiler tiers.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbortReason.h:
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::BaseIndex::withOffset):
        * bytecode/ByValInfo.h:
        (JSC::hasOptimizableIndexingForJSType):
        (JSC::hasOptimizableIndexing):
        (JSC::jitArrayModeForJSType):
        (JSC::jitArrayModePermitsPut):
        (JSC::jitArrayModeForStructure):
        * bytecode/BytecodeKills.h: Added.
        (JSC::BytecodeKills::BytecodeKills):
        (JSC::BytecodeKills::operandIsKilled):
        (JSC::BytecodeKills::forEachOperandKilledAt):
        (JSC::BytecodeKills::KillSet::KillSet):
        (JSC::BytecodeKills::KillSet::add):
        (JSC::BytecodeKills::KillSet::forEachLocal):
        (JSC::BytecodeKills::KillSet::contains):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::isValidRegisterForLiveness):
        (JSC::stepOverInstruction):
        (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
        (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset):
        (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset):
        (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
        (JSC::BytecodeLivenessAnalysis::computeKills):
        (JSC::indexForOperand): Deleted.
        (JSC::BytecodeLivenessAnalysis::getLivenessInfoForNonCapturedVarsAtBytecodeOffset): Deleted.
        (JSC::getLivenessInfo): Deleted.
        * bytecode/BytecodeLivenessAnalysis.h:
        * bytecode/BytecodeLivenessAnalysisInlines.h:
        (JSC::operandIsAlwaysLive):
        (JSC::operandThatIsNotAlwaysLiveIsLive):
        (JSC::operandIsLive):
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::nameForRegister):
        (JSC::CodeBlock::validate):
        (JSC::CodeBlock::isCaptured): Deleted.
        (JSC::CodeBlock::framePointerOffsetToGetActivationRegisters): Deleted.
        (JSC::CodeBlock::machineSlowArguments): Deleted.
        * bytecode/CodeBlock.h:
        (JSC::unmodifiedArgumentsRegister): Deleted.
        (JSC::CodeBlock::setArgumentsRegister): Deleted.
        (JSC::CodeBlock::argumentsRegister): Deleted.
        (JSC::CodeBlock::uncheckedArgumentsRegister): Deleted.
        (JSC::CodeBlock::usesArguments): Deleted.
        (JSC::CodeBlock::captureCount): Deleted.
        (JSC::CodeBlock::captureStart): Deleted.
        (JSC::CodeBlock::captureEnd): Deleted.
        (JSC::CodeBlock::argumentIndexAfterCapture): Deleted.
        (JSC::CodeBlock::hasSlowArguments): Deleted.
        (JSC::ExecState::argumentAfterCapture): Deleted.
        * bytecode/CodeOrigin.h:
        * bytecode/DataFormat.h:
        (JSC::dataFormatToString):
        * bytecode/FullBytecodeLiveness.h:
        (JSC::FullBytecodeLiveness::getLiveness):
        (JSC::FullBytecodeLiveness::operandIsLive):
        (JSC::FullBytecodeLiveness::FullBytecodeLiveness): Deleted.
        (JSC::FullBytecodeLiveness::getOut): Deleted.
        * bytecode/Instruction.h:
        (JSC::Instruction::Instruction):
        * bytecode/Operands.h:
        (JSC::Operands::virtualRegisterForIndex):
        * bytecode/SpeculatedType.cpp:
        (JSC::dumpSpeculation):
        (JSC::speculationToAbbreviatedString):
        (JSC::speculationFromClassInfo):
        * bytecode/SpeculatedType.h:
        (JSC::isDirectArgumentsSpeculation):
        (JSC::isScopedArgumentsSpeculation):
        (JSC::isActionableMutableArraySpeculation):
        (JSC::isActionableArraySpeculation):
        (JSC::isArgumentsSpeculation): Deleted.
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::setArgumentsRegister): Deleted.
        (JSC::UnlinkedCodeBlock::usesArguments): Deleted.
        (JSC::UnlinkedCodeBlock::argumentsRegister): Deleted.
        * bytecode/ValueRecovery.cpp:
        (JSC::ValueRecovery::dumpInContext):
        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::directArgumentsThatWereNotCreated):
        (JSC::ValueRecovery::outOfBandArgumentsThatWereNotCreated):
        (JSC::ValueRecovery::nodeID):
        (JSC::ValueRecovery::argumentsThatWereNotCreated): Deleted.
        * bytecode/VirtualRegister.h:
        (JSC::VirtualRegister::operator==):
        (JSC::VirtualRegister::operator!=):
        (JSC::VirtualRegister::operator<):
        (JSC::VirtualRegister::operator>):
        (JSC::VirtualRegister::operator<=):
        (JSC::VirtualRegister::operator>=):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeNextParameter):
        (JSC::BytecodeGenerator::visibleNameForParameter):
        (JSC::BytecodeGenerator::emitMove):
        (JSC::BytecodeGenerator::variable):
        (JSC::BytecodeGenerator::createVariable):
        (JSC::BytecodeGenerator::emitResolveScope):
        (JSC::BytecodeGenerator::emitGetFromScope):
        (JSC::BytecodeGenerator::emitPutToScope):
        (JSC::BytecodeGenerator::initializeVariable):
        (JSC::BytecodeGenerator::emitInstanceOf):
        (JSC::BytecodeGenerator::emitNewFunction):
        (JSC::BytecodeGenerator::emitNewFunctionInternal):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitReturn):
        (JSC::BytecodeGenerator::emitConstruct):
        (JSC::BytecodeGenerator::isArgumentNumber):
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::addVar): Deleted.
        (JSC::BytecodeGenerator::emitInitLazyRegister): Deleted.
        (JSC::BytecodeGenerator::initializeCapturedVariable): Deleted.
        (JSC::BytecodeGenerator::resolveCallee): Deleted.
        (JSC::BytecodeGenerator::addCallee): Deleted.
        (JSC::BytecodeGenerator::addParameter): Deleted.
        (JSC::BytecodeGenerator::willResolveToArgumentsRegister): Deleted.
        (JSC::BytecodeGenerator::uncheckedLocalArgumentsRegister): Deleted.
        (JSC::BytecodeGenerator::createLazyRegisterIfNecessary): Deleted.
        (JSC::BytecodeGenerator::isCaptured): Deleted.
        (JSC::BytecodeGenerator::local): Deleted.
        (JSC::BytecodeGenerator::constLocal): Deleted.
        (JSC::BytecodeGenerator::emitResolveConstantLocal): Deleted.
        (JSC::BytecodeGenerator::emitGetArgumentsLength): Deleted.
        (JSC::BytecodeGenerator::emitGetArgumentByVal): Deleted.
        (JSC::BytecodeGenerator::emitLazyNewFunction): Deleted.
        (JSC::BytecodeGenerator::createArgumentsIfNecessary): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::Variable::Variable):
        (JSC::Variable::isResolved):
        (JSC::Variable::ident):
        (JSC::Variable::offset):
        (JSC::Variable::isLocal):
        (JSC::Variable::local):
        (JSC::Variable::isSpecial):
        (JSC::BytecodeGenerator::argumentsRegister):
        (JSC::BytecodeGenerator::emitNode):
        (JSC::BytecodeGenerator::registerFor):
        (JSC::Local::Local): Deleted.
        (JSC::Local::operator bool): Deleted.
        (JSC::Local::get): Deleted.
        (JSC::Local::isSpecial): Deleted.
        (JSC::ResolveScopeInfo::ResolveScopeInfo): Deleted.
        (JSC::ResolveScopeInfo::isLocal): Deleted.
        (JSC::ResolveScopeInfo::localIndex): Deleted.
        (JSC::BytecodeGenerator::hasSafeLocalArgumentsRegister): Deleted.
        (JSC::BytecodeGenerator::captureMode): Deleted.
        (JSC::BytecodeGenerator::shouldTearOffArgumentsEagerly): Deleted.
        (JSC::BytecodeGenerator::shouldCreateArgumentsEagerly): Deleted.
        (JSC::BytecodeGenerator::hasWatchableVariable): Deleted.
        (JSC::BytecodeGenerator::watchableVariableIdentifier): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ResolveNode::isPure):
        (JSC::ResolveNode::emitBytecode):
        (JSC::BracketAccessorNode::emitBytecode):
        (JSC::DotAccessorNode::emitBytecode):
        (JSC::EvalFunctionCallNode::emitBytecode):
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::PostfixNode::emitResolve):
        (JSC::DeleteResolveNode::emitBytecode):
        (JSC::TypeOfResolveNode::emitBytecode):
        (JSC::PrefixNode::emitResolve):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::ConstDeclNode::emitCodeSingle):
        (JSC::EmptyVarExpression::emitBytecode):
        (JSC::ForInNode::tryGetBoundLocal):
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForOfNode::emitBytecode):
        (JSC::ArrayPatternNode::emitDirectBinding):
        (JSC::BindingNode::bindValue):
        (JSC::getArgumentByVal): Deleted.
        * dfg/DFGAbstractHeap.h:
        * dfg/DFGAbstractInterpreter.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::clobberWorld):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::clobberCapturedVars): Deleted.
        * dfg/DFGAbstractValue.h:
        * dfg/DFGArgumentPosition.h:
        (JSC::DFG::ArgumentPosition::addVariable):
        * dfg/DFGArgumentsEliminationPhase.cpp: Added.
        (JSC::DFG::performArgumentsElimination):
        * dfg/DFGArgumentsEliminationPhase.h: Added.
        * dfg/DFGArgumentsSimplificationPhase.cpp: Removed.
        * dfg/DFGArgumentsSimplificationPhase.h: Removed.
        * dfg/DFGArgumentsUtilities.cpp: Added.
        (JSC::DFG::argumentsInvolveStackSlot):
        (JSC::DFG::emitCodeToGetArgumentsArrayLength):
        * dfg/DFGArgumentsUtilities.h: Added.
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::refine):
        (JSC::DFG::ArrayMode::alreadyChecked):
        (JSC::DFG::arrayTypeToString):
        * dfg/DFGArrayMode.h:
        (JSC::DFG::ArrayMode::canCSEStorage):
        (JSC::DFG::ArrayMode::modeForPut):
        * dfg/DFGAvailabilityMap.cpp:
        (JSC::DFG::AvailabilityMap::prune):
        * dfg/DFGAvailabilityMap.h:
        (JSC::DFG::AvailabilityMap::closeOverNodes):
        (JSC::DFG::AvailabilityMap::closeStartingWithLocal):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::newVariableAccessData):
        (JSC::DFG::ByteCodeParser::getLocal):
        (JSC::DFG::ByteCodeParser::setLocal):
        (JSC::DFG::ByteCodeParser::getArgument):
        (JSC::DFG::ByteCodeParser::setArgument):
        (JSC::DFG::ByteCodeParser::flushDirect):
        (JSC::DFG::ByteCodeParser::flush):
        (JSC::DFG::ByteCodeParser::noticeArgumentsUse):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
        * dfg/DFGCSEPhase.cpp:
        * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h: Added.
        (JSC::DFG::CallCreateDirectArgumentsSlowPathGenerator::CallCreateDirectArgumentsSlowPathGenerator):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::isSupportedForInlining):
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGCommon.h:
        * dfg/DFGCommonData.h:
        (JSC::DFG::CommonData::CommonData):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::cleanVariables):
        * dfg/DFGDisassembler.h:
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGFlushFormat.cpp:
        (WTF::printInternal):
        * dfg/DFGFlushFormat.h:
        (JSC::DFG::resultFor):
        (JSC::DFG::useKindFor):
        (JSC::DFG::dataFormatFor):
        * dfg/DFGForAllKills.h: Added.
        (JSC::DFG::forAllLiveNodesAtTail):
        (JSC::DFG::forAllDirectlyKilledOperands):
        (JSC::DFG::forAllKilledOperands):
        (JSC::DFG::forAllKilledNodesAtNodeIndex):
        (JSC::DFG::forAllKillsInBlock):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::substituteGetLocal):
        (JSC::DFG::Graph::livenessFor):
        (JSC::DFG::Graph::killsFor):
        (JSC::DFG::Graph::tryGetConstantClosureVar):
        (JSC::DFG::Graph::tryGetRegisters): Deleted.
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::symbolTableFor):
        (JSC::DFG::Graph::uses):
        (JSC::DFG::Graph::bytecodeRegisterForArgument): Deleted.
        (JSC::DFG::Graph::capturedVarsFor): Deleted.
        (JSC::DFG::Graph::usesArguments): Deleted.
        (JSC::DFG::Graph::argumentsRegisterFor): Deleted.
        (JSC::DFG::Graph::machineArgumentsRegisterFor): Deleted.
        (JSC::DFG::Graph::uncheckedArgumentsRegisterFor): Deleted.
        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):
        (JSC::DFG::InPlaceAbstractState::mergeStateAtTail):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGMinifiedID.h:
        * dfg/DFGMinifiedNode.cpp:
        (JSC::DFG::MinifiedNode::fromNode):
        * dfg/DFGMinifiedNode.h:
        (JSC::DFG::belongsInMinifiedGraph):
        (JSC::DFG::MinifiedNode::hasInlineCallFrame):
        (JSC::DFG::MinifiedNode::inlineCallFrame):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::convertToIdentityOn):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasConstant):
        (JSC::DFG::Node::constant):
        (JSC::DFG::Node::hasScopeOffset):
        (JSC::DFG::Node::scopeOffset):
        (JSC::DFG::Node::hasDirectArgumentsOffset):
        (JSC::DFG::Node::capturedArgumentsOffset):
        (JSC::DFG::Node::variablePointer):
        (JSC::DFG::Node::hasCallVarargsData):
        (JSC::DFG::Node::hasLoadVarargsData):
        (JSC::DFG::Node::hasHeapPrediction):
        (JSC::DFG::Node::hasCellOperand):
        (JSC::DFG::Node::objectMaterializationData):
        (JSC::DFG::Node::isPhantomAllocation):
        (JSC::DFG::Node::willHaveCodeGenOrOSR):
        (JSC::DFG::Node::shouldSpeculateDirectArguments):
        (JSC::DFG::Node::shouldSpeculateScopedArguments):
        (JSC::DFG::Node::isPhantomArguments): Deleted.
        (JSC::DFG::Node::hasVarNumber): Deleted.
        (JSC::DFG::Node::varNumber): Deleted.
        (JSC::DFG::Node::registerPointer): Deleted.
        (JSC::DFG::Node::shouldSpeculateArguments): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
        * dfg/DFGOSRExitCompiler.cpp:
        (JSC::DFG::OSRExitCompiler::emitRestoreArguments):
        * dfg/DFGOSRExitCompiler.h:
        (JSC::DFG::OSRExitCompiler::badIndex): Deleted.
        (JSC::DFG::OSRExitCompiler::initializePoisoned): Deleted.
        (JSC::DFG::OSRExitCompiler::poisonIndex): Deleted.
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::ArgumentsRecoveryGenerator::ArgumentsRecoveryGenerator): Deleted.
        (JSC::DFG::ArgumentsRecoveryGenerator::~ArgumentsRecoveryGenerator): Deleted.
        (JSC::DFG::ArgumentsRecoveryGenerator::generateFor): Deleted.
        * dfg/DFGOSRExitCompilerCommon.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::read):
        (JSC::DFG::PreciseLocalClobberizeAdaptor::write):
        (JSC::DFG::PreciseLocalClobberizeAdaptor::def):
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        (JSC::DFG::preciseLocalClobberize):
        (JSC::DFG::PreciseLocalClobberizeAdaptor::writeTop): Deleted.
        (JSC::DFG::forEachLocalReadByUnwind): Deleted.
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::run):
        (JSC::DFG::PredictionPropagationPhase::propagate):
        (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting):
        (JSC::DFG::PredictionPropagationPhase::propagateThroughArgumentPositions):
        * dfg/DFGPromoteHeapAccess.h:
        (JSC::DFG::promoteHeapAccess):
        * dfg/DFGPromotedHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGPromotedHeapLocation.h:
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateJSArray):
        (JSC::DFG::SpeculativeJIT::emitGetLength):
        (JSC::DFG::SpeculativeJIT::emitGetCallee):
        (JSC::DFG::SpeculativeJIT::emitGetArgumentStart):
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        (JSC::DFG::SpeculativeJIT::compileNewFunction):
        (JSC::DFG::SpeculativeJIT::compileForwardVarargs):
        (JSC::DFG::SpeculativeJIT::compileCreateActivation):
        (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
        (JSC::DFG::SpeculativeJIT::compileGetFromArguments):
        (JSC::DFG::SpeculativeJIT::compilePutToArguments):
        (JSC::DFG::SpeculativeJIT::compileCreateScopedArguments):
        (JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
        (JSC::DFG::SpeculativeJIT::emitAllocateArguments): Deleted.
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): Deleted.
        (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength): Deleted.
        (JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck): Deleted.
        (JSC::DFG::SpeculativeJIT::compileNewFunctionExpression): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObjectWithKnownSize):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
        (JSC::DFG::SpeculativeJIT::framePointerOffsetToGetActivationRegisters): Deleted.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):
        * dfg/DFGUnificationPhase.cpp:
        (JSC::DFG::UnificationPhase::run):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validateCPS):
        * dfg/DFGValueSource.cpp:
        (JSC::DFG::ValueSource::dump):
        * dfg/DFGValueSource.h:
        (JSC::DFG::dataFormatToValueSourceKind):
        (JSC::DFG::valueSourceKindToDataFormat):
        (JSC::DFG::ValueSource::ValueSource):
        (JSC::DFG::ValueSource::forFlushFormat):
        (JSC::DFG::ValueSource::valueRecovery):
        * dfg/DFGVarargsForwardingPhase.cpp: Added.
        (JSC::DFG::performVarargsForwarding):
        * dfg/DFGVarargsForwardingPhase.h: Added.
        * dfg/DFGVariableAccessData.cpp:
        (JSC::DFG::VariableAccessData::VariableAccessData):
        (JSC::DFG::VariableAccessData::flushFormat):
        (JSC::DFG::VariableAccessData::mergeIsCaptured): Deleted.
        * dfg/DFGVariableAccessData.h:
        (JSC::DFG::VariableAccessData::shouldNeverUnbox):
        (JSC::DFG::VariableAccessData::shouldUseDoubleFormat):
        (JSC::DFG::VariableAccessData::isCaptured): Deleted.
        (JSC::DFG::VariableAccessData::mergeIsArgumentsAlias): Deleted.
        (JSC::DFG::VariableAccessData::isArgumentsAlias): Deleted.
        * dfg/DFGVariableAccessDataDump.cpp:
        (JSC::DFG::VariableAccessDataDump::dump):
        * dfg/DFGVariableAccessDataDump.h:
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::tryToSetConstantRecovery):
        * dfg/DFGVariableEventStream.h:
        * ftl/FTLAbstractHeap.cpp:
        (JSC::FTL::AbstractHeap::dump):
        (JSC::FTL::AbstractField::dump):
        (JSC::FTL::IndexedAbstractHeap::dump):
        (JSC::FTL::NumberedAbstractHeap::dump):
        (JSC::FTL::AbsoluteAbstractHeap::dump):
        * ftl/FTLAbstractHeap.h:
        * ftl/FTLAbstractHeapRepository.cpp:
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLExitArgument.cpp:
        (JSC::FTL::ExitArgument::dump):
        * ftl/FTLExitPropertyValue.cpp:
        (JSC::FTL::ExitPropertyValue::withLocalsOffset):
        * ftl/FTLExitPropertyValue.h:
        * ftl/FTLExitTimeObjectMaterialization.cpp:
        (JSC::FTL::ExitTimeObjectMaterialization::ExitTimeObjectMaterialization):
        (JSC::FTL::ExitTimeObjectMaterialization::accountForLocalsOffset):
        * ftl/FTLExitTimeObjectMaterialization.h:
        (JSC::FTL::ExitTimeObjectMaterialization::origin):
        * ftl/FTLExitValue.cpp:
        (JSC::FTL::ExitValue::withLocalsOffset):
        (JSC::FTL::ExitValue::valueFormat):
        (JSC::FTL::ExitValue::dumpInContext):
        * ftl/FTLExitValue.h:
        (JSC::FTL::ExitValue::isArgument):
        (JSC::FTL::ExitValue::argumentsObjectThatWasNotCreated): Deleted.
        (JSC::FTL::ExitValue::isArgumentsObjectThatWasNotCreated): Deleted.
        (JSC::FTL::ExitValue::valueFormat): Deleted.
        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfCallForwardVarargs):
        (JSC::FTL::sizeOfConstructForwardVarargs):
        (JSC::FTL::sizeOfICFor):
        * ftl/FTLInlineCacheSize.h:
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLJSCallVarargs.cpp:
        (JSC::FTL::JSCallVarargs::JSCallVarargs):
        (JSC::FTL::JSCallVarargs::emit):
        * ftl/FTLJSCallVarargs.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::lower):
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compilePutStack):
        (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
        (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
        (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
        (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
        (JSC::FTL::LowerDFGToLLVM::compileArrayPush):
        (JSC::FTL::LowerDFGToLLVM::compileArrayPop):
        (JSC::FTL::LowerDFGToLLVM::compileCreateActivation):
        (JSC::FTL::LowerDFGToLLVM::compileNewFunction):
        (JSC::FTL::LowerDFGToLLVM::compileCreateDirectArguments):
        (JSC::FTL::LowerDFGToLLVM::compileCreateScopedArguments):
        (JSC::FTL::LowerDFGToLLVM::compileCreateClonedArguments):
        (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
        (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
        (JSC::FTL::LowerDFGToLLVM::compileGetGlobalVar):
        (JSC::FTL::LowerDFGToLLVM::compilePutGlobalVar):
        (JSC::FTL::LowerDFGToLLVM::compileGetArgumentCount):
        (JSC::FTL::LowerDFGToLLVM::compileGetClosureVar):
        (JSC::FTL::LowerDFGToLLVM::compilePutClosureVar):
        (JSC::FTL::LowerDFGToLLVM::compileGetFromArguments):
        (JSC::FTL::LowerDFGToLLVM::compilePutToArguments):
        (JSC::FTL::LowerDFGToLLVM::compileCallOrConstructVarargs):
        (JSC::FTL::LowerDFGToLLVM::compileForwardVarargs):
        (JSC::FTL::LowerDFGToLLVM::compileGetEnumeratorPname):
        (JSC::FTL::LowerDFGToLLVM::ArgumentsLength::ArgumentsLength):
        (JSC::FTL::LowerDFGToLLVM::getArgumentsLength):
        (JSC::FTL::LowerDFGToLLVM::getCurrentCallee):
        (JSC::FTL::LowerDFGToLLVM::getArgumentsStart):
        (JSC::FTL::LowerDFGToLLVM::baseIndex):
        (JSC::FTL::LowerDFGToLLVM::allocateObject):
        (JSC::FTL::LowerDFGToLLVM::allocateVariableSizedObject):
        (JSC::FTL::LowerDFGToLLVM::isArrayType):
        (JSC::FTL::LowerDFGToLLVM::emitStoreBarrier):
        (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
        (JSC::FTL::LowerDFGToLLVM::exitValueForAvailability):
        (JSC::FTL::LowerDFGToLLVM::exitValueForNode):
        (JSC::FTL::LowerDFGToLLVM::loadStructure):
        (JSC::FTL::LowerDFGToLLVM::compilePhantomArguments): Deleted.
        (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentsLength): Deleted.
        (JSC::FTL::LowerDFGToLLVM::compileGetClosureRegisters): Deleted.
        (JSC::FTL::LowerDFGToLLVM::compileCheckArgumentsNotCreated): Deleted.
        (JSC::FTL::LowerDFGToLLVM::checkArgumentsNotCreated): Deleted.
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileRecovery):
        (JSC::FTL::compileStub):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::aShr):
        (JSC::FTL::Output::lShr):
        (JSC::FTL::Output::zeroExtPtr):
        * heap/CopyToken.h:
        * interpreter/CallFrame.h:
        (JSC::ExecState::getArgumentUnsafe):
        * interpreter/Interpreter.cpp:
        (JSC::sizeOfVarargs):
        (JSC::sizeFrameForVarargs):
        (JSC::loadVarargs):
        (JSC::unwindCallFrame):
        * interpreter/Interpreter.h:
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::createArguments):
        (JSC::StackVisitor::Frame::existingArguments): Deleted.
        * interpreter/StackVisitor.h:
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::storeValue):
        (JSC::AssemblyHelpers::loadValue):
        (JSC::AssemblyHelpers::storeTrustedValue):
        (JSC::AssemblyHelpers::branchIfNotCell):
        (JSC::AssemblyHelpers::branchIsEmpty):
        (JSC::AssemblyHelpers::argumentsStart):
        (JSC::AssemblyHelpers::baselineArgumentsRegisterFor): Deleted.
        (JSC::AssemblyHelpers::offsetOfLocals): Deleted.
        (JSC::AssemblyHelpers::offsetOfArguments): Deleted.
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgument):
        * jit/GPRInfo.h:
        (JSC::JSValueRegs::withTwoAvailableRegs):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_create_lexical_environment):
        (JSC::JIT::emit_op_new_func):
        (JSC::JIT::emit_op_create_direct_arguments):
        (JSC::JIT::emit_op_create_scoped_arguments):
        (JSC::JIT::emit_op_create_out_of_band_arguments):
        (JSC::JIT::emit_op_tear_off_arguments): Deleted.
        (JSC::JIT::emit_op_create_arguments): Deleted.
        (JSC::JIT::emit_op_init_lazy_reg): Deleted.
        (JSC::JIT::emit_op_get_arguments_length): Deleted.
        (JSC::JIT::emitSlow_op_get_arguments_length): Deleted.
        (JSC::JIT::emit_op_get_argument_by_val): Deleted.
        (JSC::JIT::emitSlow_op_get_argument_by_val): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_create_lexical_environment):
        (JSC::JIT::emit_op_tear_off_arguments): Deleted.
        (JSC::JIT::emit_op_create_arguments): Deleted.
        (JSC::JIT::emit_op_init_lazy_reg): Deleted.
        (JSC::JIT::emit_op_get_arguments_length): Deleted.
        (JSC::JIT::emitSlow_op_get_arguments_length): Deleted.
        (JSC::JIT::emit_op_get_argument_by_val): Deleted.
        (JSC::JIT::emitSlow_op_get_argument_by_val): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitGetClosureVar):
        (JSC::JIT::emitPutClosureVar):
        (JSC::JIT::emit_op_get_from_arguments):
        (JSC::JIT::emit_op_put_to_arguments):
        (JSC::JIT::emit_op_init_global_const):
        (JSC::JIT::privateCompileGetByVal):
        (JSC::JIT::emitDirectArgumentsGetByVal):
        (JSC::JIT::emitScopedArgumentsGetByVal):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitGetClosureVar):
        (JSC::JIT::emitPutClosureVar):
        (JSC::JIT::emit_op_get_from_arguments):
        (JSC::JIT::emit_op_put_to_arguments):
        (JSC::JIT::emit_op_init_global_const):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/Nodes.h:
        (JSC::ScopeNode::captures):
        * runtime/Arguments.cpp: Removed.
        * runtime/Arguments.h: Removed.
        * runtime/ArgumentsMode.h: Added.
        * runtime/DirectArgumentsOffset.cpp: Added.
        (JSC::DirectArgumentsOffset::dump):
        * runtime/DirectArgumentsOffset.h: Added.
        (JSC::DirectArgumentsOffset::DirectArgumentsOffset):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * runtime/ConstantMode.cpp: Added.
        (WTF::printInternal):
        * runtime/ConstantMode.h:
        (JSC::modeForIsConstant):
        * runtime/DirectArguments.cpp: Added.
        (JSC::DirectArguments::DirectArguments):
        (JSC::DirectArguments::createUninitialized):
        (JSC::DirectArguments::create):
        (JSC::DirectArguments::createByCopying):
        (JSC::DirectArguments::visitChildren):
        (JSC::DirectArguments::copyBackingStore):
        (JSC::DirectArguments::createStructure):
        (JSC::DirectArguments::overrideThings):
        (JSC::DirectArguments::overrideThingsIfNecessary):
        (JSC::DirectArguments::overrideArgument):
        (JSC::DirectArguments::copyToArguments):
        (JSC::DirectArguments::overridesSize):
        * runtime/DirectArguments.h: Added.
        (JSC::DirectArguments::internalLength):
        (JSC::DirectArguments::length):
        (JSC::DirectArguments::canAccessIndexQuickly):
        (JSC::DirectArguments::getIndexQuickly):
        (JSC::DirectArguments::setIndexQuickly):
        (JSC::DirectArguments::callee):
        (JSC::DirectArguments::argument):
        (JSC::DirectArguments::overrodeThings):
        (JSC::DirectArguments::offsetOfCallee):
        (JSC::DirectArguments::offsetOfLength):
        (JSC::DirectArguments::offsetOfMinCapacity):
        (JSC::DirectArguments::offsetOfOverrides):
        (JSC::DirectArguments::storageOffset):
        (JSC::DirectArguments::offsetOfSlot):
        (JSC::DirectArguments::allocationSize):
        (JSC::DirectArguments::storage):
        * runtime/FunctionPrototype.cpp:
        * runtime/GenericArguments.h: Added.
        (JSC::GenericArguments::GenericArguments):
        * runtime/GenericArgumentsInlines.h: Added.
        (JSC::GenericArguments<Type>::getOwnPropertySlot):
        (JSC::GenericArguments<Type>::getOwnPropertySlotByIndex):
        (JSC::GenericArguments<Type>::getOwnPropertyNames):
        (JSC::GenericArguments<Type>::put):
        (JSC::GenericArguments<Type>::putByIndex):
        (JSC::GenericArguments<Type>::deleteProperty):
        (JSC::GenericArguments<Type>::deletePropertyByIndex):
        (JSC::GenericArguments<Type>::defineOwnProperty):
        (JSC::GenericArguments<Type>::copyToArguments):
        * runtime/GenericOffset.h: Added.
        (JSC::GenericOffset::GenericOffset):
        (JSC::GenericOffset::operator!):
        (JSC::GenericOffset::offsetUnchecked):
        (JSC::GenericOffset::offset):
        (JSC::GenericOffset::operator==):
        (JSC::GenericOffset::operator!=):
        (JSC::GenericOffset::operator<):
        (JSC::GenericOffset::operator>):
        (JSC::GenericOffset::operator<=):
        (JSC::GenericOffset::operator>=):
        (JSC::GenericOffset::operator+):
        (JSC::GenericOffset::operator-):
        (JSC::GenericOffset::operator+=):
        (JSC::GenericOffset::operator-=):
        * runtime/JSArgumentsIterator.cpp:
        (JSC::JSArgumentsIterator::finishCreation):
        (JSC::argumentsFuncIterator):
        * runtime/JSArgumentsIterator.h:
        (JSC::JSArgumentsIterator::create):
        (JSC::JSArgumentsIterator::next):
        * runtime/JSEnvironmentRecord.cpp:
        (JSC::JSEnvironmentRecord::visitChildren):
        * runtime/JSEnvironmentRecord.h:
        (JSC::JSEnvironmentRecord::variables):
        (JSC::JSEnvironmentRecord::isValid):
        (JSC::JSEnvironmentRecord::variableAt):
        (JSC::JSEnvironmentRecord::offsetOfVariables):
        (JSC::JSEnvironmentRecord::offsetOfVariable):
        (JSC::JSEnvironmentRecord::allocationSizeForScopeSize):
        (JSC::JSEnvironmentRecord::allocationSize):
        (JSC::JSEnvironmentRecord::JSEnvironmentRecord):
        (JSC::JSEnvironmentRecord::finishCreationUninitialized):
        (JSC::JSEnvironmentRecord::finishCreation):
        (JSC::JSEnvironmentRecord::registers): Deleted.
        (JSC::JSEnvironmentRecord::registerAt): Deleted.
        (JSC::JSEnvironmentRecord::addressOfRegisters): Deleted.
        (JSC::JSEnvironmentRecord::offsetOfRegisters): Deleted.
        * runtime/JSFunction.cpp:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::addGlobalVar):
        (JSC::JSGlobalObject::addFunction):
        (JSC::JSGlobalObject::visitChildren):
        (JSC::JSGlobalObject::addStaticGlobals):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::directArgumentsStructure):
        (JSC::JSGlobalObject::scopedArgumentsStructure):
        (JSC::JSGlobalObject::outOfBandArgumentsStructure):
        (JSC::JSGlobalObject::argumentsStructure): Deleted.
        * runtime/JSLexicalEnvironment.cpp:
        (JSC::JSLexicalEnvironment::symbolTableGet):
        (JSC::JSLexicalEnvironment::symbolTablePut):
        (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
        (JSC::JSLexicalEnvironment::symbolTablePutWithAttributes):
        (JSC::JSLexicalEnvironment::visitChildren): Deleted.
        * runtime/JSLexicalEnvironment.h:
        (JSC::JSLexicalEnvironment::create):
        (JSC::JSLexicalEnvironment::JSLexicalEnvironment):
        (JSC::JSLexicalEnvironment::registersOffset): Deleted.
        (JSC::JSLexicalEnvironment::storageOffset): Deleted.
        (JSC::JSLexicalEnvironment::storage): Deleted.
        (JSC::JSLexicalEnvironment::allocationSize): Deleted.
        (JSC::JSLexicalEnvironment::isValidIndex): Deleted.
        (JSC::JSLexicalEnvironment::isValid): Deleted.
        (JSC::JSLexicalEnvironment::registerAt): Deleted.
        * runtime/JSNameScope.cpp:
        (JSC::JSNameScope::visitChildren): Deleted.
        * runtime/JSNameScope.h:
        (JSC::JSNameScope::create):
        (JSC::JSNameScope::value):
        (JSC::JSNameScope::finishCreation):
        (JSC::JSNameScope::JSNameScope):
        * runtime/JSScope.cpp:
        (JSC::abstractAccess):
        * runtime/JSSegmentedVariableObject.cpp:
        (JSC::JSSegmentedVariableObject::findVariableIndex):
        (JSC::JSSegmentedVariableObject::addVariables):
        (JSC::JSSegmentedVariableObject::visitChildren):
        (JSC::JSSegmentedVariableObject::findRegisterIndex): Deleted.
        (JSC::JSSegmentedVariableObject::addRegisters): Deleted.
        * runtime/JSSegmentedVariableObject.h:
        (JSC::JSSegmentedVariableObject::variableAt):
        (JSC::JSSegmentedVariableObject::assertVariableIsInThisObject):
        (JSC::JSSegmentedVariableObject::registerAt): Deleted.
        (JSC::JSSegmentedVariableObject::assertRegisterIsInThisObject): Deleted.
        * runtime/JSSymbolTableObject.h:
        (JSC::JSSymbolTableObject::offsetOfSymbolTable):
        (JSC::symbolTableGet):
        (JSC::symbolTablePut):
        (JSC::symbolTablePutWithAttributes):
        * runtime/JSType.h:
        * runtime/Options.h:
        * runtime/ClonedArguments.cpp: Added.
        (JSC::ClonedArguments::ClonedArguments):
        (JSC::ClonedArguments::createEmpty):
        (JSC::ClonedArguments::createWithInlineFrame):
        (JSC::ClonedArguments::createWithMachineFrame):
        (JSC::ClonedArguments::createByCopyingFrom):
        (JSC::ClonedArguments::createStructure):
        (JSC::ClonedArguments::getOwnPropertySlot):
        (JSC::ClonedArguments::getOwnPropertyNames):
        (JSC::ClonedArguments::put):
        (JSC::ClonedArguments::deleteProperty):
        (JSC::ClonedArguments::defineOwnProperty):
        (JSC::ClonedArguments::materializeSpecials):
        (JSC::ClonedArguments::materializeSpecialsIfNecessary):
        * runtime/ClonedArguments.h: Added.
        (JSC::ClonedArguments::specialsMaterialized):
        * runtime/ScopeOffset.cpp: Added.
        (JSC::ScopeOffset::dump):
        * runtime/ScopeOffset.h: Added.
        (JSC::ScopeOffset::ScopeOffset):
        * runtime/ScopedArguments.cpp: Added.
        (JSC::ScopedArguments::ScopedArguments):
        (JSC::ScopedArguments::finishCreation):
        (JSC::ScopedArguments::createUninitialized):
        (JSC::ScopedArguments::create):
        (JSC::ScopedArguments::createByCopying):
        (JSC::ScopedArguments::createByCopyingFrom):
        (JSC::ScopedArguments::visitChildren):
        (JSC::ScopedArguments::createStructure):
        (JSC::ScopedArguments::overrideThings):
        (JSC::ScopedArguments::overrideThingsIfNecessary):
        (JSC::ScopedArguments::overrideArgument):
        (JSC::ScopedArguments::copyToArguments):
        * runtime/ScopedArguments.h: Added.
        (JSC::ScopedArguments::internalLength):
        (JSC::ScopedArguments::length):
        (JSC::ScopedArguments::canAccessIndexQuickly):
        (JSC::ScopedArguments::getIndexQuickly):
        (JSC::ScopedArguments::setIndexQuickly):
        (JSC::ScopedArguments::callee):
        (JSC::ScopedArguments::overrodeThings):
        (JSC::ScopedArguments::offsetOfOverrodeThings):
        (JSC::ScopedArguments::offsetOfTotalLength):
        (JSC::ScopedArguments::offsetOfTable):
        (JSC::ScopedArguments::offsetOfScope):
        (JSC::ScopedArguments::overflowStorageOffset):
        (JSC::ScopedArguments::allocationSize):
        (JSC::ScopedArguments::overflowStorage):
        * runtime/ScopedArgumentsTable.cpp: Added.
        (JSC::ScopedArgumentsTable::ScopedArgumentsTable):
        (JSC::ScopedArgumentsTable::~ScopedArgumentsTable):
        (JSC::ScopedArgumentsTable::destroy):
        (JSC::ScopedArgumentsTable::create):
        (JSC::ScopedArgumentsTable::clone):
        (JSC::ScopedArgumentsTable::setLength):
        (JSC::ScopedArgumentsTable::set):
        (JSC::ScopedArgumentsTable::createStructure):
        * runtime/ScopedArgumentsTable.h: Added.
        (JSC::ScopedArgumentsTable::length):
        (JSC::ScopedArgumentsTable::get):
        (JSC::ScopedArgumentsTable::lock):
        (JSC::ScopedArgumentsTable::offsetOfLength):
        (JSC::ScopedArgumentsTable::offsetOfArguments):
        (JSC::ScopedArgumentsTable::at):
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTableEntry::prepareToWatch):
        (JSC::SymbolTable::SymbolTable):
        (JSC::SymbolTable::visitChildren):
        (JSC::SymbolTable::localToEntry):
        (JSC::SymbolTable::entryFor):
        (JSC::SymbolTable::cloneScopePart):
        (JSC::SymbolTable::prepareForTypeProfiling):
        (JSC::SymbolTable::uniqueIDForOffset):
        (JSC::SymbolTable::globalTypeSetForOffset):
        (JSC::SymbolTable::cloneCapturedNames): Deleted.
        (JSC::SymbolTable::uniqueIDForRegister): Deleted.
        (JSC::SymbolTable::globalTypeSetForRegister): Deleted.
        * runtime/SymbolTable.h:
        (JSC::SymbolTableEntry::varOffsetFromBits):
        (JSC::SymbolTableEntry::scopeOffsetFromBits):
        (JSC::SymbolTableEntry::Fast::varOffset):
        (JSC::SymbolTableEntry::Fast::scopeOffset):
        (JSC::SymbolTableEntry::Fast::isDontEnum):
        (JSC::SymbolTableEntry::Fast::getAttributes):
        (JSC::SymbolTableEntry::SymbolTableEntry):
        (JSC::SymbolTableEntry::varOffset):
        (JSC::SymbolTableEntry::isWatchable):
        (JSC::SymbolTableEntry::scopeOffset):
        (JSC::SymbolTableEntry::setAttributes):
        (JSC::SymbolTableEntry::constantMode):
        (JSC::SymbolTableEntry::isDontEnum):
        (JSC::SymbolTableEntry::disableWatching):
        (JSC::SymbolTableEntry::pack):
        (JSC::SymbolTableEntry::isValidVarOffset):
        (JSC::SymbolTable::createNameScopeTable):
        (JSC::SymbolTable::maxScopeOffset):
        (JSC::SymbolTable::didUseScopeOffset):
        (JSC::SymbolTable::didUseVarOffset):
        (JSC::SymbolTable::scopeSize):
        (JSC::SymbolTable::nextScopeOffset):
        (JSC::SymbolTable::takeNextScopeOffset):
        (JSC::SymbolTable::add):
        (JSC::SymbolTable::set):
        (JSC::SymbolTable::argumentsLength):
        (JSC::SymbolTable::setArgumentsLength):
        (JSC::SymbolTable::argumentOffset):
        (JSC::SymbolTable::setArgumentOffset):
        (JSC::SymbolTable::arguments):
        (JSC::SlowArgument::SlowArgument): Deleted.
        (JSC::SymbolTableEntry::Fast::getIndex): Deleted.
        (JSC::SymbolTableEntry::getIndex): Deleted.
        (JSC::SymbolTableEntry::isValidIndex): Deleted.
        (JSC::SymbolTable::captureStart): Deleted.
        (JSC::SymbolTable::setCaptureStart): Deleted.
        (JSC::SymbolTable::captureEnd): Deleted.
        (JSC::SymbolTable::setCaptureEnd): Deleted.
        (JSC::SymbolTable::captureCount): Deleted.
        (JSC::SymbolTable::isCaptured): Deleted.
        (JSC::SymbolTable::parameterCount): Deleted.
        (JSC::SymbolTable::parameterCountIncludingThis): Deleted.
        (JSC::SymbolTable::setParameterCountIncludingThis): Deleted.
        (JSC::SymbolTable::slowArguments): Deleted.
        (JSC::SymbolTable::setSlowArguments): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * runtime/VarOffset.cpp: Added.
        (JSC::VarOffset::dump):
        (WTF::printInternal):
        * runtime/VarOffset.h: Added.
        (JSC::VarOffset::VarOffset):
        (JSC::VarOffset::assemble):
        (JSC::VarOffset::isValid):
        (JSC::VarOffset::operator!):
        (JSC::VarOffset::kind):
        (JSC::VarOffset::isStack):
        (JSC::VarOffset::isScope):
        (JSC::VarOffset::isDirectArgument):
        (JSC::VarOffset::stackOffsetUnchecked):
        (JSC::VarOffset::scopeOffsetUnchecked):
        (JSC::VarOffset::capturedArgumentsOffsetUnchecked):
        (JSC::VarOffset::stackOffset):
        (JSC::VarOffset::scopeOffset):
        (JSC::VarOffset::capturedArgumentsOffset):
        (JSC::VarOffset::rawOffset):
        (JSC::VarOffset::checkSanity):
        (JSC::VarOffset::operator==):
        (JSC::VarOffset::operator!=):
        (JSC::VarOffset::hash):
        (JSC::VarOffset::isHashTableDeletedValue):
        (JSC::VarOffsetHash::hash):
        (JSC::VarOffsetHash::equal):
        * tests/stress/arguments-exit-strict-mode.js: Added.
        * tests/stress/arguments-exit.js: Added.
        * tests/stress/arguments-inlined-exit-strict-mode-fixed.js: Added.
        * tests/stress/arguments-inlined-exit-strict-mode.js: Added.
        * tests/stress/arguments-inlined-exit.js: Added.
        * tests/stress/arguments-interference.js: Added.
        * tests/stress/arguments-interference-cfg.js: Added.
        * tests/stress/dead-get-closure-var.js: Added.
        * tests/stress/get-declared-unpassed-argument-in-direct-arguments.js: Added.
        * tests/stress/get-declared-unpassed-argument-in-scoped-arguments.js: Added.
        * tests/stress/varargs-closure-inlined-exit-strict-mode.js: Added.
        * tests/stress/varargs-closure-inlined-exit.js: Added.
        * tests/stress/varargs-exit.js: Added.
        * tests/stress/varargs-inlined-exit.js: Added.
        * tests/stress/varargs-inlined-simple-exit-aliasing-weird-reversed-args.js: Added.
        * tests/stress/varargs-inlined-simple-exit-aliasing-weird.js: Added.
        * tests/stress/varargs-inlined-simple-exit-aliasing.js: Added.
        * tests/stress/varargs-inlined-simple-exit.js: Added.
        * tests/stress/varargs-too-few-arguments.js: Added.
        * tests/stress/varargs-varargs-closure-inlined-exit.js: Added.
        * tests/stress/varargs-varargs-inlined-exit-strict-mode.js: Added.
        * tests/stress/varargs-varargs-inlined-exit.js: Added.

2015-03-25  Andy Estes  <aestes@apple.com>

        [Cocoa] RemoteInspectorXPCConnection::deserializeMessage() leaks a NSDictionary under Objective-C GC
        https://bugs.webkit.org/show_bug.cgi?id=143068

        Reviewed by Dan Bernstein.

        * inspector/remote/RemoteInspectorXPCConnection.mm:
        (Inspector::RemoteInspectorXPCConnection::deserializeMessage): Used RetainPtr::autorelease(), which does the right thing under GC.

2015-03-25  Filip Pizlo  <fpizlo@apple.com>

        Use JITCompilationCanFail in more places, and make the fail path of JITCompilationMustSucceed a crash instead of attempting GC
        https://bugs.webkit.org/show_bug.cgi?id=142993

        Reviewed by Geoffrey Garen and Mark Lam.
        
        This changes the most commonly invoked paths that relied on JITCompilationMustSucceed
        into using JITCompilationCanFail and having a legit fallback path. This mostly involves
        having the FTL JIT do the same trick as the DFG JIT in case of any memory allocation
        failure, but also involves adding the same kind of thing to the stub generators in
        Repatch.
        
        Because of that change, there are relatively few uses of JITCompilationMustSucceed. Most
        of those uses cannot handle a GC, and so cannot do releaseExecutableMemory(). Only a few,
        like host call stub generation, could handle a GC, but those get invoked very rarely. So,
        this patch changes the releaseExecutableMemory() call into a crash with some diagnostic
        printout.
        
        Also add a way of inducing executable allocation failure, so that we can test this.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        (JSC::DFG::JITCompiler::link): Deleted.
        (JSC::DFG::JITCompiler::linkFunction): Deleted.
        * dfg/DFGJITCompiler.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateCodeSection):
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLState.h:
        * jit/ArityCheckFailReturnThunks.cpp:
        (JSC::ArityCheckFailReturnThunks::returnPCsFor):
        * jit/ExecutableAllocationFuzz.cpp: Added.
        (JSC::numberOfExecutableAllocationFuzzChecks):
        (JSC::doExecutableAllocationFuzzing):
        * jit/ExecutableAllocationFuzz.h: Added.
        (JSC::doExecutableAllocationFuzzingIfEnabled):
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC::ExecutableAllocator::allocate):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JITCompilationEffort.h:
        * jit/Repatch.cpp:
        (JSC::generateByIdStub):
        (JSC::tryCacheGetByID):
        (JSC::tryBuildGetByIDList):
        (JSC::emitPutReplaceStub):
        (JSC::emitPutTransitionStubAndGetOldStructure):
        (JSC::tryCachePutByID):
        (JSC::tryBuildPutByIdList):
        (JSC::tryRepatchIn):
        (JSC::linkPolymorphicCall):
        * jsc.cpp:
        (jscmain):
        * runtime/Options.h:
        * runtime/TestRunnerUtils.h:
        * runtime/VM.cpp:
        * tests/executableAllocationFuzz: Added.
        * tests/executableAllocationFuzz.yaml: Added.
        * tests/executableAllocationFuzz/v8-raytrace.js: Added.

2015-03-25  Mark Lam  <mark.lam@apple.com>

        REGRESSION(169139): LLINT intermittently fails JSC testapi tests.
        <https://webkit.org/b/135719>

        Reviewed by Geoffrey Garen.

        This is a regression introduced in http://trac.webkit.org/changeset/169139 which
        changed VM::watchdog from an embedded field into a std::unique_ptr, but did not
        update the LLINT to access it as such.

        The issue has only manifested so far on the CLoop tests because those are LLINT
        only.  In the non-CLoop cases, the JIT kicks in and does the right thing, thereby
        hiding the bug in the LLINT.

        * API/JSContextRef.cpp:
        (createWatchdogIfNeeded):
        (JSContextGroupSetExecutionTimeLimit):
        (JSContextGroupClearExecutionTimeLimit):
        * llint/LowLevelInterpreter.asm:

2015-03-25  Filip Pizlo  <fpizlo@apple.com>

        Change Atomic methods from using the_wrong_naming_conventions to using theRightNamingConventions. Also make seq_cst the default.

        Rubber stamped by Geoffrey Garen.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::visitAggregate):

2015-03-25  Joseph Pecoraro  <pecoraro@apple.com>

        Fix formatting in BuiltinExecutables
        https://bugs.webkit.org/show_bug.cgi?id=143061

        Reviewed by Ryosuke Niwa.

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutableInternal):

2015-03-25  Joseph Pecoraro  <pecoraro@apple.com>

        ES6: Classes: Program level class statement throws exception in strict mode
        https://bugs.webkit.org/show_bug.cgi?id=143038

        Reviewed by Ryosuke Niwa.

        Classes expose a name to the current lexical environment. This treats
        "class X {}" like "var X = class X {}". Ideally it would be "let X = class X {}".
        Also, improve error messages for class statements where the class is missing a name.

        * parser/Parser.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):
        Fill name in info parameter if needed. Better error message if name is needed and missing.

        (JSC::Parser<LexerType>::parseClassDeclaration):
        Pass info parameter to get name, and expose the name as a variable name.

        (JSC::Parser<LexerType>::parsePrimaryExpression):
        Pass info parameter that is ignored.

        * parser/ParserFunctionInfo.h:
        Add a parser info for class, to extract the name.

2015-03-25  Yusuke Suzuki  <utatane.tea@gmail.com>

        New map and set modification tests in r181922 fails
        https://bugs.webkit.org/show_bug.cgi?id=143031

        Reviewed and tweaked by Geoffrey Garen.

        When packing Map/Set backing store, we need to decrement Map/Set iterator's m_index
        to adjust for the packed backing store.

        Consider the following map data.

        x: deleted, o: exists
        0 1 2 3 4
        x x x x o

        And iterator with m_index 3.

        When packing the map data, map data will become,

        0
        o

        At that time, we perfom didRemoveEntry 4 times on iterators.
        times => m_index/index/result
        1 => 3/0/dec
        2 => 2/1/dec
        3 => 1/2/nothing
        4 => 1/3/nothing

        After iteration, iterator's m_index becomes 1. But we expected that becomes 0.
        This is because if we use decremented m_index for comparison,
        while provided deletedIndex is the index in old storage, m_index is the index in partially packed storage.

        In this patch, we compare against the packed index instead.
        times => m_index/packedIndex/result
        1 => 3/0/dec
        2 => 2/0/dec
        3 => 1/0/dec
        4 => 0/0/nothing

        So m_index becomes 0 as expected.

        And according to the spec, once the iterator is closed (becomes done: true),
        its internal [[Map]]/[[Set]] is set to undefined.
        So after the iterator is finished, we don't revive the iterator (e.g. by clearing m_index = 0).

        In this patch, we change 2 things.
        1.
        Compare an iterator's index against the packed index when removing an entry.

        2.
        If the iterator is closed (isFinished()), we don't apply adjustment to the iterator.

        * runtime/MapData.h:
        (JSC::MapDataImpl::IteratorData::finish):
        (JSC::MapDataImpl::IteratorData::isFinished):
        (JSC::MapDataImpl::IteratorData::didRemoveEntry):
        (JSC::MapDataImpl::IteratorData::didRemoveAllEntries):
        (JSC::MapDataImpl::IteratorData::startPackBackingStore):
        * runtime/MapDataInlines.h:
        (JSC::JSIterator>::replaceAndPackBackingStore):
        * tests/stress/modify-map-during-iteration.js:
        * tests/stress/modify-set-during-iteration.js:

2015-03-24  Joseph Pecoraro  <pecoraro@apple.com>

        Setter should have a single formal parameter, Getter no parameters
        https://bugs.webkit.org/show_bug.cgi?id=142903

        Reviewed by Geoffrey Garen.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):
        Enforce no parameters for getters and a single parameter
        for setters, with informational error messages.

2015-03-24  Joseph Pecoraro  <pecoraro@apple.com>

        ES6: Classes: Early return in sub-class constructor results in returning undefined instead of instance
        https://bugs.webkit.org/show_bug.cgi?id=143012

        Reviewed by Ryosuke Niwa.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitReturn):
        Fix handling of "undefined" when returned from a Derived class. It was
        returning "undefined" when it should have returned "this".

2015-03-24  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION (r181458): Heap use-after-free in JSSetIterator destructor
        https://bugs.webkit.org/show_bug.cgi?id=142696

        Reviewed and tweaked by Geoffrey Garen.

        Before r142556, JSSetIterator::destroy was not defined.
        So accidentally MapData::const_iterator in JSSet was never destroyed.
        But it had non trivial destructor, decrementing MapData->m_iteratorCount.

        After r142556, JSSetIterator::destroy works.
        It correctly destruct MapData::const_iterator and m_iteratorCount partially works.
        But JSSetIterator::~JSSetIterator requires owned JSSet since it mutates MapData->m_iteratorCount.

        It is guaranteed that JSSet is live since JSSetIterator has a reference to JSSet
        and marks it in visitChildren (WriteBarrier<Unknown>).
        However, the order of destructions is not guaranteed in GC-ed system.

        Consider the following case,
        allocate JSSet and subsequently allocate JSSetIterator.
        And they resides in the separated MarkedBlock, <1> and <2>.

        JSSet<1> <- JSSetIterator<2>

        And after that, when performing GC, Marker decides that the above 2 objects are not marked.
        And Marker also decides MarkedBlocks <1> and <2> can be sweeped.

        First Sweeper sweep <1>, destruct JSSet<1> and free MarkedBlock<1>.
        Second Sweeper sweep <2>, attempt to destruct JSSetIterator<2>.
        However, JSSetIterator<2>'s destructor,
        JSSetIterator::~JSSetIterator requires live JSSet<1>, it causes use-after-free.

        In this patch, we introduce WeakGCMap into JSMap/JSSet to track live iterators.
        When packing the removed elements in JSSet/JSMap, we apply the change to all live
        iterators tracked by WeakGCMap.

        WeakGCMap can only track JSCell since they are managed by GC.
        So we drop JSSet/JSMap C++ style iterators. Instead of C++ style iterator, this patch
        introduces JS style iterator signatures into C++ class IteratorData.
        If we need to iterate over JSMap/JSSet, use JSSetIterator/JSMapIterator instead of using
        IteratorData directly.

        * runtime/JSMap.cpp:
        (JSC::JSMap::destroy):
        * runtime/JSMap.h:
        (JSC::JSMap::JSMap):
        (JSC::JSMap::begin): Deleted.
        (JSC::JSMap::end): Deleted.
        * runtime/JSMapIterator.cpp:
        (JSC::JSMapIterator::destroy):
        * runtime/JSMapIterator.h:
        (JSC::JSMapIterator::next):
        (JSC::JSMapIterator::nextKeyValue):
        (JSC::JSMapIterator::iteratorData):
        (JSC::JSMapIterator::JSMapIterator):
        * runtime/JSSet.cpp:
        (JSC::JSSet::destroy):
        * runtime/JSSet.h:
        (JSC::JSSet::JSSet):
        (JSC::JSSet::begin): Deleted.
        (JSC::JSSet::end): Deleted.
        * runtime/JSSetIterator.cpp:
        (JSC::JSSetIterator::destroy):
        * runtime/JSSetIterator.h:
        (JSC::JSSetIterator::next):
        (JSC::JSSetIterator::iteratorData):
        (JSC::JSSetIterator::JSSetIterator):
        * runtime/MapData.h:
        (JSC::MapDataImpl::IteratorData::finish):
        (JSC::MapDataImpl::IteratorData::isFinished):
        (JSC::MapDataImpl::shouldPack):
        (JSC::JSIterator>::MapDataImpl):
        (JSC::JSIterator>::KeyType::KeyType):
        (JSC::JSIterator>::IteratorData::IteratorData):
        (JSC::JSIterator>::IteratorData::next):
        (JSC::JSIterator>::IteratorData::ensureSlot):
        (JSC::JSIterator>::IteratorData::applyMapDataPatch):
        (JSC::JSIterator>::IteratorData::refreshCursor):
        (JSC::MapDataImpl::const_iterator::key): Deleted.
        (JSC::MapDataImpl::const_iterator::value): Deleted.
        (JSC::MapDataImpl::const_iterator::operator++): Deleted.
        (JSC::MapDataImpl::const_iterator::finish): Deleted.
        (JSC::MapDataImpl::const_iterator::atEnd): Deleted.
        (JSC::MapDataImpl::begin): Deleted.
        (JSC::MapDataImpl::end): Deleted.
        (JSC::MapDataImpl<Entry>::MapDataImpl): Deleted.
        (JSC::MapDataImpl<Entry>::clear): Deleted.
        (JSC::MapDataImpl<Entry>::KeyType::KeyType): Deleted.
        (JSC::MapDataImpl<Entry>::const_iterator::internalIncrement): Deleted.
        (JSC::MapDataImpl<Entry>::const_iterator::ensureSlot): Deleted.
        (JSC::MapDataImpl<Entry>::const_iterator::const_iterator): Deleted.
        (JSC::MapDataImpl<Entry>::const_iterator::~const_iterator): Deleted.
        (JSC::MapDataImpl<Entry>::const_iterator::operator): Deleted.
        (JSC::=): Deleted.
        * runtime/MapDataInlines.h:
        (JSC::JSIterator>::clear):
        (JSC::JSIterator>::find):
        (JSC::JSIterator>::contains):
        (JSC::JSIterator>::add):
        (JSC::JSIterator>::set):
        (JSC::JSIterator>::get):
        (JSC::JSIterator>::remove):
        (JSC::JSIterator>::replaceAndPackBackingStore):
        (JSC::JSIterator>::replaceBackingStore):
        (JSC::JSIterator>::ensureSpaceForAppend):
        (JSC::JSIterator>::visitChildren):
        (JSC::JSIterator>::copyBackingStore):
        (JSC::JSIterator>::applyMapDataPatch):
        (JSC::MapDataImpl<Entry>::find): Deleted.
        (JSC::MapDataImpl<Entry>::contains): Deleted.
        (JSC::MapDataImpl<Entry>::add): Deleted.
        (JSC::MapDataImpl<Entry>::set): Deleted.
        (JSC::MapDataImpl<Entry>::get): Deleted.
        (JSC::MapDataImpl<Entry>::remove): Deleted.
        (JSC::MapDataImpl<Entry>::replaceAndPackBackingStore): Deleted.
        (JSC::MapDataImpl<Entry>::replaceBackingStore): Deleted.
        (JSC::MapDataImpl<Entry>::ensureSpaceForAppend): Deleted.
        (JSC::MapDataImpl<Entry>::visitChildren): Deleted.
        (JSC::MapDataImpl<Entry>::copyBackingStore): Deleted.
        * runtime/MapPrototype.cpp:
        (JSC::mapProtoFuncForEach):
        * runtime/SetPrototype.cpp:
        (JSC::setProtoFuncForEach):
        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::forEach):
        * tests/stress/modify-map-during-iteration.js: Added.
        (testValue):
        (identityPairs):
        (.set if):
        (var):
        (set map):
        * tests/stress/modify-set-during-iteration.js: Added.
        (testValue):
        (set forEach):
        (set delete):

2015-03-24  Mark Lam  <mark.lam@apple.com>

        The ExecutionTimeLimit test should use its own JSGlobalContextRef.
        <https://webkit.org/b/143024>

        Reviewed by Geoffrey Garen.

        Currently, the ExecutionTimeLimit test is using a JSGlobalContextRef
        passed in from testapi.c.  It should create its own for better
        encapsulation of the test.

        * API/tests/ExecutionTimeLimitTest.cpp:
        (currentCPUTimeAsJSFunctionCallback):
        (testExecutionTimeLimit):
        * API/tests/ExecutionTimeLimitTest.h:
        * API/tests/testapi.c:
        (main):

2015-03-24  Joseph Pecoraro  <pecoraro@apple.com>

        ES6: Object Literal Methods toString is missing method name
        https://bugs.webkit.org/show_bug.cgi?id=142992

        Reviewed by Geoffrey Garen.

        Always stringify functions in the pattern:

          "function " + <function name> + <text from opening parenthesis to closing brace>.

        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):
        Update the path that was not stringifying in this pattern.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedFunctionExecutable::parametersStartOffset):
        * parser/Nodes.h:
        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::FunctionExecutable):
        * runtime/Executable.h:
        (JSC::FunctionExecutable::parametersStartOffset):
        Pass the already known function parameter opening parenthesis
        start offset through to the FunctionExecutable. 

        * tests/mozilla/js1_5/Scope/regress-185485.js:
        (with.g):
        Add back original space in this test that was removed by r181810
        now that we have the space again in stringification.

2015-03-24  Michael Saboff  <msaboff@apple.com>

        REGRESSION (172175-172177): Change in for...in processing causes properties added in loop to be enumerated
        https://bugs.webkit.org/show_bug.cgi?id=142856

        Reviewed by Filip Pizlo.

        Refactored the way the for .. in enumeration over objects is done.  We used to make three C++ calls to
        get info for three loops to iterate over indexed properties, structure properties and other properties,
        respectively.  We still have the three loops, but now we make one C++ call to get all the info needed
        for all loops before we exectue any enumeration.

        The JSPropertyEnumerator has a count of the indexed properties and a list of named properties.
        The named properties are one list, with structured properties in the range [0,m_endStructurePropertyIndex)
        and the generic properties in the range [m_endStructurePropertyIndex, m_endGenericPropertyIndex);

        Eliminated the bytecodes op_get_structure_property_enumerator, op_get_generic_property_enumerator and
        op_next_enumerator_pname.
        Added the bytecodes op_get_property_enumerator, op_enumerator_structure_pname and op_enumerator_generic_pname.
        The bytecodes op_enumerator_structure_pname and op_enumerator_generic_pname are similar except for what
        end value we stop iterating on.

        Made corresponding node changes to the DFG and FTL for the bytecode changes.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitGetPropertyEnumerator):
        (JSC::BytecodeGenerator::emitEnumeratorStructurePropertyName):
        (JSC::BytecodeGenerator::emitEnumeratorGenericPropertyName):
        (JSC::BytecodeGenerator::emitGetStructurePropertyEnumerator): Deleted.
        (JSC::BytecodeGenerator::emitGetGenericPropertyEnumerator): Deleted.
        (JSC::BytecodeGenerator::emitNextEnumeratorPropertyName): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForInNode::emitMultiLoopBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileGetEnumerableLength):
        (JSC::FTL::LowerDFGToLLVM::compileGetPropertyEnumerator):
        (JSC::FTL::LowerDFGToLLVM::compileGetEnumeratorStructurePname):
        (JSC::FTL::LowerDFGToLLVM::compileGetEnumeratorGenericPname):
        (JSC::FTL::LowerDFGToLLVM::compileGetStructurePropertyEnumerator): Deleted.
        (JSC::FTL::LowerDFGToLLVM::compileGetGenericPropertyEnumerator): Deleted.
        (JSC::FTL::LowerDFGToLLVM::compileGetEnumeratorPname): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_enumerator_structure_pname):
        (JSC::JIT::emit_op_enumerator_generic_pname):
        (JSC::JIT::emit_op_get_property_enumerator):
        (JSC::JIT::emit_op_next_enumerator_pname): Deleted.
        (JSC::JIT::emit_op_get_structure_property_enumerator): Deleted.
        (JSC::JIT::emit_op_get_generic_property_enumerator): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_enumerator_structure_pname):
        (JSC::JIT::emit_op_enumerator_generic_pname):
        (JSC::JIT::emit_op_next_enumerator_pname): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LowLevelInterpreter.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::create):
        (JSC::JSPropertyNameEnumerator::finishCreation):
        * runtime/JSPropertyNameEnumerator.h:
        (JSC::JSPropertyNameEnumerator::indexedLength):
        (JSC::JSPropertyNameEnumerator::endStructurePropertyIndex):
        (JSC::JSPropertyNameEnumerator::endGenericPropertyIndex):
        (JSC::JSPropertyNameEnumerator::indexedLengthOffset):
        (JSC::JSPropertyNameEnumerator::endStructurePropertyIndexOffset):
        (JSC::JSPropertyNameEnumerator::endGenericPropertyIndexOffset):
        (JSC::JSPropertyNameEnumerator::cachedInlineCapacityOffset):
        (JSC::propertyNameEnumerator):
        (JSC::JSPropertyNameEnumerator::cachedPropertyNamesLengthOffset): Deleted.
        (JSC::structurePropertyNameEnumerator): Deleted.
        (JSC::genericPropertyNameEnumerator): Deleted.
        * runtime/Structure.cpp:
        (JSC::Structure::setCachedPropertyNameEnumerator):
        (JSC::Structure::cachedPropertyNameEnumerator):
        (JSC::Structure::canCachePropertyNameEnumerator):
        (JSC::Structure::setCachedStructurePropertyNameEnumerator): Deleted.
        (JSC::Structure::cachedStructurePropertyNameEnumerator): Deleted.
        (JSC::Structure::setCachedGenericPropertyNameEnumerator): Deleted.
        (JSC::Structure::cachedGenericPropertyNameEnumerator): Deleted.
        (JSC::Structure::canCacheStructurePropertyNameEnumerator): Deleted.
        (JSC::Structure::canCacheGenericPropertyNameEnumerator): Deleted.
        * runtime/Structure.h:
        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::visitChildren):
        (JSC::StructureRareData::cachedPropertyNameEnumerator):
        (JSC::StructureRareData::setCachedPropertyNameEnumerator):
        (JSC::StructureRareData::cachedStructurePropertyNameEnumerator): Deleted.
        (JSC::StructureRareData::setCachedStructurePropertyNameEnumerator): Deleted.
        (JSC::StructureRareData::cachedGenericPropertyNameEnumerator): Deleted.
        (JSC::StructureRareData::setCachedGenericPropertyNameEnumerator): Deleted.
        * runtime/StructureRareData.h:
        * tests/stress/for-in-delete-during-iteration.js:

2015-03-24  Michael Saboff  <msaboff@apple.com>

        Unreviewed build fix for debug builds.

        * runtime/ExceptionHelpers.cpp:
        (JSC::invalidParameterInSourceAppender):

2015-03-24  Saam Barati  <saambarati1@gmail.com>

        Improve error messages in JSC
        https://bugs.webkit.org/show_bug.cgi?id=141869

        Reviewed by Geoffrey Garen.

        JavaScriptCore has some unintuitive error messages associated
        with certain common errors. This patch changes some specific
        error messages to be more understandable and also creates a
        mechanism that will allow for easy modification of error messages
        in the future. The specific errors we change are not a function
        errors and invalid parameter errors.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * interpreter/Interpreter.cpp:
        (JSC::sizeOfVarargs):
        * jit/JITOperations.cpp:
        op_throw_static_error always has a JSString as its argument.
        There is no need to dance around this, and we should assert
        that this always holds. This JSString represents the error 
        message we want to display to the user, so there is no need
        to pass it into errorDescriptionForValue which will now place
        quotes around the string.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::opIn):
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::ErrorInstance):
        * runtime/ErrorInstance.h:
        (JSC::ErrorInstance::hasSourceAppender):
        (JSC::ErrorInstance::sourceAppender):
        (JSC::ErrorInstance::setSourceAppender):
        (JSC::ErrorInstance::clearSourceAppender):
        (JSC::ErrorInstance::setRuntimeTypeForCause):
        (JSC::ErrorInstance::runtimeTypeForCause):
        (JSC::ErrorInstance::clearRuntimeTypeForCause):
        (JSC::ErrorInstance::appendSourceToMessage): Deleted.
        (JSC::ErrorInstance::setAppendSourceToMessage): Deleted.
        (JSC::ErrorInstance::clearAppendSourceToMessage): Deleted.
        * runtime/ExceptionHelpers.cpp:
        (JSC::errorDescriptionForValue):
        (JSC::defaultApproximateSourceError):
        (JSC::defaultSourceAppender):
        (JSC::functionCallBase):
        (JSC::notAFunctionSourceAppender):
        (JSC::invalidParameterInSourceAppender):
        (JSC::invalidParameterInstanceofSourceAppender):
        (JSC::createError):
        (JSC::createInvalidFunctionApplyParameterError):
        (JSC::createInvalidInParameterError):
        (JSC::createInvalidInstanceofParameterError):
        (JSC::createNotAConstructorError):
        (JSC::createNotAFunctionError):
        (JSC::createNotAnObjectError):
        (JSC::createInvalidParameterError): Deleted.
        * runtime/ExceptionHelpers.h:
        * runtime/JSObject.cpp:
        (JSC::JSObject::hasInstance):
        * runtime/RuntimeType.cpp: Added.
        (JSC::runtimeTypeForValue):
        (JSC::runtimeTypeAsString):
        * runtime/RuntimeType.h: Added.
        * runtime/TypeProfilerLog.cpp:
        (JSC::TypeProfilerLog::processLogEntries):
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::getRuntimeTypeForValue): Deleted.
        * runtime/TypeSet.h:
        * runtime/VM.cpp:
        (JSC::appendSourceToError):
        (JSC::VM::throwException):

2015-03-23  Filip Pizlo  <fpizlo@apple.com>

        JSC should have a low-cost asynchronous disassembler
        https://bugs.webkit.org/show_bug.cgi?id=142997

        Reviewed by Mark Lam.
        
        This adds a JSC_asyncDisassembly option that disassembles on a thread. Disassembly
        doesn't block execution. Some code will live a little longer because of this, since the
        work tasks hold a ref to the code, but other than that there is basically no overhead.
        
        At present, this isn't really a replacement for JSC_showDisassembly, since it doesn't
        provide contextual IR information for Baseline and DFG disassemblies, and it doesn't do
        the separate IR dumps for FTL. Using JSC_showDisassembly and friends along with
        JSC_asyncDisassembly has bizarre behavior - so just choose one.
        
        A simple way of understanding how great this is, is to run a small benchmark like
        V8Spider/earley-boyer.
        
        Performance without any disassembly flags: 60ms
        Performance with JSC_showDisassembly=true: 477ms
        Performance with JSC_asyncDisassembly=true: 65ms
        
        So, the overhead of disassembly goes from 8x to 8%.
        
        Note that JSC_asyncDisassembly=true does make it incorrect to run "time" as a way of
        measuring benchmark performance. This is because at VM exit, we wait for all async
        disassembly requests to finish. For example, for earley-boyer, we spend an extra ~130ms
        after the benchmark completely finishes to finish the disassemblies. This small weirdness
        should be OK for the intended use-cases, since all you have to do to get around it is to
        measure the execution time of the benchmark payload rather than the end-to-end time of
        launching the VM.

        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::finalizeCodeWithDisassembly):
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::wasAlreadyDisassembled):
        (JSC::LinkBuffer::didAlreadyDisassemble):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::disassemble):
        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::finalize):
        (JSC::DFG::JITFinalizer::finalizeFunction):
        * disassembler/Disassembler.cpp:
        (JSC::disassembleAsynchronously):
        (JSC::waitForAsynchronousDisassembly):
        * disassembler/Disassembler.h:
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jsc.cpp:
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::~VM):

2015-03-23  Dean Jackson  <dino@apple.com>

        ES7: Implement Array.prototype.includes
        https://bugs.webkit.org/show_bug.cgi?id=142707

        Reviewed by Geoffrey Garen.

        Add support for the ES7 includes method on Arrays.
        https://github.com/tc39/Array.prototype.includes

        * builtins/Array.prototype.js:
        (includes): Implementation in JS.
        * runtime/ArrayPrototype.cpp: Add 'includes' to the lookup table.

2015-03-23  Joseph Pecoraro  <pecoraro@apple.com>

        __defineGetter__/__defineSetter__ should throw exceptions
        https://bugs.webkit.org/show_bug.cgi?id=142934

        Reviewed by Geoffrey Garen.

        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncDefineGetter):
        (JSC::objectProtoFuncDefineSetter):
        Throw exceptions when these functions are used directly.

2015-03-23  Joseph Pecoraro  <pecoraro@apple.com>

        Fix DO_PROPERTYMAP_CONSTENCY_CHECK enabled build
        https://bugs.webkit.org/show_bug.cgi?id=142952

        Reviewed by Geoffrey Garen.

        * runtime/Structure.cpp:
        (JSC::PropertyTable::checkConsistency):
        The check offset method doesn't exist in PropertyTable, it exists in Structure.

        (JSC::Structure::checkConsistency):
        So move it here, and always put it at the start to match normal behavior.

2015-03-22  Filip Pizlo  <fpizlo@apple.com>

        Remove DFG::ValueRecoveryOverride; it's been dead since we removed forward speculations
        https://bugs.webkit.org/show_bug.cgi?id=142956

        Rubber stamped by Gyuyoung Kim.
        
        Just removing dead code.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGOSRExit.h:
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGValueRecoveryOverride.h: Removed.

2015-03-22  Filip Pizlo  <fpizlo@apple.com>

        DFG OSR exit shouldn't assume that the frame count for exit is greater than the frame count in DFG
        https://bugs.webkit.org/show_bug.cgi?id=142948

        Reviewed by Sam Weinig.
        
        It's necessary to ensure that the stack pointer accounts for the extent of our stack usage
        since a signal may clobber the area below the stack pointer. When the DFG is executing,
        the stack pointer accounts for the DFG's worst-case stack usage. When we OSR exit back to
        baseline, we will use a different amount of stack. This is because baseline is a different
        compiler. It will make different decisions. So it will use a different amount of stack.
        
        This gets tricky when we are in the process of doing an OSR exit, because we are sort of
        incrementally transforming the stack from how it looked in the DFG to how it will look in
        baseline. The most conservative approach would be to set the stack pointer to the max of
        DFG and baseline.
        
        When this code was written, a reckless assumption was made: that the stack usage in
        baseline is always at least as large as the stack usage in DFG. Based on this incorrect
        assumption, the code first adjusts the stack pointer to account for the baseline stack
        usage. This sort of usually works, because usually baseline does happen to use more stack.
        But that's not an invariant. Nobody guarantees this. We will never make any changes that
        would make this be guaranteed, because that would be antithetical to how optimizing
        compilers work. The DFG should be allowed to use however much stack it decides that it
        should use in order to get good performance, and it shouldn't try to guarantee that it
        always uses less stack than baseline.
        
        As such, we must always assume that the frame size for DFG execution (i.e.
        frameRegisterCount) and the frame size in baseline once we exit (i.e.
        requiredRegisterCountForExit) are two independent quantities and they have no
        relationship.
        
        Fortunately, though, this code can be made correct by just moving the stack adjustment to
        just before we do conversions. This is because we have since changed the OSR exit
        algorithm to first lift up all state from the DFG state into a scratch buffer, and then to
        drop it out of the scratch buffer and into the stack according to the baseline layout. The
        point just before conversions is the point where we have finished reading the DFG frame
        and will not read it anymore, and we haven't started writing the baseline frame. So, at
        this point it is safe to set the stack pointer to account for the frame size at exit.
        
        This is benign because baseline happens to create larger frames than DFG.

        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::adjustAndJumpToTarget):

2015-03-22  Filip Pizlo  <fpizlo@apple.com>

        Shorten the number of iterations to 10,000 since that's enough to test all tiers.

        Rubber stamped by Sam Weinig.

        * tests/stress/equals-masquerader.js:

2015-03-22  Filip Pizlo  <fpizlo@apple.com>

        tests/stress/*tdz* tests do 10x more iterations than necessary
        https://bugs.webkit.org/show_bug.cgi?id=142946

        Reviewed by Ryosuke Niwa.
        
        The stress test harness runs all of these tests in various configurations. This includes
        no-cjit, which has tier-up heuristics locked in such a way that 10,000 iterations is
        enough to get to the highest tier. The only exceptions are very large functions or
        functions that have some reoptimizations. That happens rarely, and when it does happen,
        usually 20,000 iterations is enough.
        
        Therefore, these tests use 10x too many iterations. This is bad, since these tests
        allocate on each iteration, and so they run very slowly in debug mode.

        * tests/stress/class-syntax-no-loop-tdz.js:
        * tests/stress/class-syntax-no-tdz-in-catch.js:
        * tests/stress/class-syntax-no-tdz-in-conditional.js:
        * tests/stress/class-syntax-no-tdz-in-loop-no-inline-super.js:
        * tests/stress/class-syntax-no-tdz-in-loop.js:
        * tests/stress/class-syntax-no-tdz.js:
        * tests/stress/class-syntax-tdz-in-catch.js:
        * tests/stress/class-syntax-tdz-in-conditional.js:
        * tests/stress/class-syntax-tdz-in-loop.js:
        * tests/stress/class-syntax-tdz.js:

2015-03-21  Joseph Pecoraro  <pecoraro@apple.com>

        Fix a typo in Parser error message
        https://bugs.webkit.org/show_bug.cgi?id=142942

        Reviewed by Alexey Proskuryakov.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitSlow_op_resolve_scope):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitSlow_op_resolve_scope):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):
        Fix a common identifier typo.

2015-03-21  Joseph Pecoraro  <pecoraro@apple.com>

        Computed Property names should allow only AssignmentExpressions not any Expression
        https://bugs.webkit.org/show_bug.cgi?id=142902

        Reviewed by Ryosuke Niwa.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseProperty):
        Limit computed expressions to just assignment expressions instead of
        any expression (which allowed comma expressions).

2015-03-21  Andreas Kling  <akling@apple.com>

        Make UnlinkedFunctionExecutable fit in a 128-byte cell.
        <https://webkit.org/b/142939>

        Reviewed by Mark Hahnenberg.

        Re-arrange the members of UnlinkedFunctionExecutable so it can fit inside
        a 128-byte heap cell instead of requiring a 256-byte one.

        Threw in a static_assert to catch anyone pushing it over the limit again.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedFunctionExecutable::functionMode):

2015-03-20  Mark Hahnenberg  <mhahnenb@gmail.com>

        GCTimer should know keep track of nested GC phases
        https://bugs.webkit.org/show_bug.cgi?id=142675

        Reviewed by Darin Adler.

        This improves the GC phase timing output in Heap.cpp by linking
        phases nested inside other phases together, allowing tools
        to compute how much time we're spending in various nested phases.

        * heap/Heap.cpp:

2015-03-20  Geoffrey Garen  <ggaren@apple.com>

        FunctionBodyNode should known where its parameters started
        https://bugs.webkit.org/show_bug.cgi?id=142926

        Reviewed by Ryosuke Niwa.

        This will allow us to re-parse parameters instead of keeping the
        parameters piece of the AST around forever.

        I also took the opportunity to initialize most FunctionBodyNode data
        members at construction time, to help clarify that they are set right.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFunctionExpr): No need to pass
        functionKeywordStart here; we now provide it at FunctionBodyNode
        creation time.

        (JSC::ASTBuilder::createFunctionBody): Require everything we need at
        construction time, including the start of our parameters.

        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createFuncDeclStatement):  No need to pass
        functionKeywordStart here; we now provide it at FunctionBodyNode
        creation time.

        (JSC::ASTBuilder::setFunctionNameStart): Deleted.

        * parser/Nodes.cpp:
        (JSC::FunctionBodyNode::FunctionBodyNode): Initialize everything at
        construction time.

        * parser/Nodes.h: Added a field for the location of our parameters.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionBody):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parseGetterSetter):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        * parser/Parser.h: Refactored to match above interface changes.

        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createFunctionExpr):
        (JSC::SyntaxChecker::createFunctionBody):
        (JSC::SyntaxChecker::createFuncDeclStatement):
        (JSC::SyntaxChecker::createGetterOrSetterProperty): Refactored to match
        above interface changes.

        (JSC::SyntaxChecker::setFunctionNameStart): Deleted.

2015-03-20  Filip Pizlo  <fpizlo@apple.com>

        Observably effectful nodes in DFG IR should come last in their bytecode instruction (i.e. forExit section), except for Hint nodes
        https://bugs.webkit.org/show_bug.cgi?id=142920

        Reviewed by Oliver Hunt, Geoffrey Garen, and Mark Lam.
        
        Observably effectful, n.: If we reexecute the bytecode instruction after this node has
        executed, then something other than the bytecode instruction's specified outcome will
        happen.

        We almost never had observably effectful nodes except at the end of the bytecode
        instruction.  The exception is a lowered transitioning PutById:

        PutStructure(@o, S1 -> S2)
        PutByOffset(@o, @o, @v)

        The PutStructure is observably effectful: if you try to reexecute the bytecode after
        doing the PutStructure, then we'll most likely crash.  The generic PutById handling means
        first checking what the old structure of the object is; but if we reexecute, the old
        structure will seem to be the new structure.  But the property ensured by the new
        structure hasn't been stored yet, so any attempt to load it or scan it will crash.

        Intriguingly, however, none of the other operations involved in the PutById are
        observably effectful.  Consider this example:

        PutByOffset(@o, @o, @v)
        PutStructure(@o, S1 -> S2)

        Note that the PutStructure node doesn't reallocate property storage; see further below
        for an example that does that. Because no property storage is happening, we know that we
        already had room for the new property.  This means that the PutByOffset is no observable
        until the PutStructure executes and "reveals" the property.  Hence, PutByOffset is not
        observably effectful.

        Now consider this:

        b: AllocatePropertyStorage(@o)
        PutByOffset(@b, @o, @v)
        PutStructure(@o, S1 -> S2)

        Surprisingly, this is also safe, because the AllocatePropertyStorage is not observably
        effectful. It *does* reallocate the property storage and the new property storage pointer
        is stored into the object. But until the PutStructure occurs, the world will just think
        that the reallocation didn't happen, in the sense that we'll think that the property
        storage is using less memory than what we just allocated. That's harmless.

        The AllocatePropertyStorage is safe in other ways, too. Even if we GC'd after the
        AllocatePropertyStorage but before the PutByOffset (or before the PutStructure),
        everything could be expected to be fine, so long as all of @o, @v and @b are on the
        stack. If they are all on the stack, then the GC will leave the property storage alone
        (so the extra memory we just allocated would be safe). The GC will not scan the part of
        the property storage that contains @v, but that's fine, so long as @v is on the stack.
        
        The better long-term solution is probably bug 142921.
        
        But for now, this:
        
        - Fixes an object materialization bug, exemplified by the two tests, that previously
          crashed 100% of the time with FTL enabled and concurrent JIT disabled.
        
        - Allows us to remove the workaround introduced in r174856.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handlePutById):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::insertCheck):
        (JSC::DFG::FixupPhase::indexOfNode): Deleted.
        (JSC::DFG::FixupPhase::indexOfFirstNodeOfExitOrigin): Deleted.
        * dfg/DFGInsertionSet.h:
        (JSC::DFG::InsertionSet::insertOutOfOrder): Deleted.
        (JSC::DFG::InsertionSet::insertOutOfOrderNode): Deleted.
        * tests/stress/materialize-past-butterfly-allocation.js: Added.
        (bar):
        (foo0):
        (foo1):
        (foo2):
        (foo3):
        (foo4):
        * tests/stress/materialize-past-put-structure.js: Added.
        (foo):

2015-03-20  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION (r179429): Potential Use after free in JavaScriptCore`WTF::StringImpl::ref + 83
        https://bugs.webkit.org/show_bug.cgi?id=142410

        Reviewed by Geoffrey Garen.

        Before this patch, added function JSValue::toPropertyKey returns PropertyName.
        Since PropertyName doesn't have AtomicStringImpl ownership,
        if Identifier is implicitly converted to PropertyName and Identifier is destructed,
        PropertyName may refer freed AtomicStringImpl*.

        This patch changes the result type of JSValue::toPropertyName from PropertyName to Identifier,
        to keep AtomicStringImpl* ownership after the toPropertyName call is done.
        And receive the result value as Identifier type to keep ownership in the caller side.

        To catch the result of toPropertyKey as is, we catch the result of toPropertyName as auto.

        However, now we don't need to have both Identifier and PropertyName.
        So we'll merge PropertyName to Identifier in the subsequent patch.

        * dfg/DFGOperations.cpp:
        (JSC::DFG::operationPutByValInternal):
        * jit/JITOperations.cpp:
        (JSC::getByVal):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::getByVal):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::opIn):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::toPropertyKey):
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetOwnPropertyDescriptor):
        (JSC::objectConstructorDefineProperty):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncPropertyIsEnumerable):

2015-03-18  Geoffrey Garen  <ggaren@apple.com>

        Function.prototype.toString should not decompile the AST
        https://bugs.webkit.org/show_bug.cgi?id=142853

        Reviewed by Sam Weinig.

        To recover the function parameter string, Function.prototype.toString
        decompiles the function parameters from the AST. This is bad for a few
        reasons:

        (1) It requires us to keep pieces of the AST live forever. This is an
        awkward design and a waste of memory.

        (2) It doesn't match Firefox or Chrome (because it changes whitespace
        and ES6 destructuring expressions).

        (3) It doesn't scale to ES6 default argument parameters, which require
        arbitrarily complex decompilation.

        (4) It can counterfeit all the line numbers in a function (because
        whitespace can include newlines).

        (5) It's expensive, and we've seen cases where websites invoke
        Function.prototype.toString a lot by accident.

        The fix is to do what we do for the rest of the function: Just quote the
        original source text.

        Since this change inevitably changes some function stringification, I
        took the opportunity to make our stringification match Firefox's and
        Chrome's.

        * API/tests/testapi.c:
        (assertEqualsAsUTF8String): Be more informative when this fails.

        (main): Updated to match new stringification rules.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::paramString): Deleted. Yay!
        * bytecode/UnlinkedCodeBlock.h:

        * parser/Nodes.h:
        (JSC::StatementNode::isFuncDeclNode): New helper for constructing
        anonymous functions.

        * parser/SourceCode.h:
        (JSC::SourceCode::SourceCode): Allow zero because WebCore wants it.

        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode): Updated for use
        of function declaration over function expression.

        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::paramString): Deleted. Yay!
        * runtime/Executable.h:
        (JSC::FunctionExecutable::parameterCount):

        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck): Added a newline after
        the opening brace to match Firefox and Chrome, and a space after the comma
        to match Firefox and WebKit coding style. Added the function name to
        the text of the function so it would look right when stringify-ing. Switched
        from parentheses to braces to produce a function declaration instead of
        a function expression because we are required to exclude the function's
        name from its scope, and that's what a function declaration does.

        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString): Removed an old workaround because the
        library it worked around doesn't really exist anymore, and the behavior
        doesn't match Firefox or Chrome. Use type profiling offsets instead of
        function body offsets because we want to include the function name and
        the parameter string, rather than stitching them in manually by
        decompiling the AST.

        (JSC::insertSemicolonIfNeeded): Deleted.

        * tests/mozilla/js1_2/function/tostring-1.js:
        * tests/mozilla/js1_5/Scope/regress-185485.js:
        (with.g): Updated these test results for formatting changes.

2015-03-20  Joseph Pecoraro  <pecoraro@apple.com>

        SyntaxChecker assertion is trapped with computed property name and getter
        https://bugs.webkit.org/show_bug.cgi?id=142863

        Reviewed by Ryosuke Niwa.

        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::getName):
        Remove invalid assert. Computed properties will not have a name
        and the calling code is checking for null expecting it. The
        AST path (non-CheckingPath) already does this without the assert
        so it is well tested.

2015-03-19  Mark Lam  <mark.lam@apple.com>

        JSCallbackObject<JSGlobalObject> should not destroy its JSCallbackObjectData before all its finalizers have been called.
        <https://webkit.org/b/142846>

        Reviewed by Geoffrey Garen.

        Currently, JSCallbackObject<JSGlobalObject> registers weak finalizers via 2 mechanisms:
        1. JSCallbackObject<Parent>::init() registers a weak finalizer for all JSClassRef
           that a JSCallbackObject references.
        2. JSCallbackObject<JSGlobalObject>::create() registers a finalizer via
           vm.heap.addFinalizer() which destroys the JSCallbackObject.

        The first finalizer is implemented as a virtual function of a JSCallbackObjectData
        instance that will be destructed if the 2nd finalizer is called.  Hence, if the
        2nd finalizer if called first, the later invocation of the 1st finalizer will
        result in a crash.

        This patch fixes the issue by eliminating the finalizer registration in init().
        Instead, we'll have the JSCallbackObject destructor call all the JSClassRef finalizers
        if needed.  This ensures that these finalizers are called before the JSCallbackObject
        is destructor.

        Also added assertions to a few Heap functions because JSCell::classInfo() expects
        all objects that are allocated from MarkedBlock::Normal blocks to be derived from
        JSDestructibleObject.  These assertions will help us catch violations of this
        expectation earlier.

        * API/JSCallbackObject.cpp:
        (JSC::JSCallbackObjectData::finalize): Deleted.
        * API/JSCallbackObject.h:
        (JSC::JSCallbackObjectData::~JSCallbackObjectData):
        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::~JSCallbackObject):
        (JSC::JSCallbackObject<Parent>::init):
        * API/tests/GlobalContextWithFinalizerTest.cpp: Added.
        (finalize):
        (testGlobalContextWithFinalizer):
        * API/tests/GlobalContextWithFinalizerTest.h: Added.
        * API/tests/testapi.c:
        (main):
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/HeapInlines.h:
        (JSC::Heap::allocateObjectOfType):
        (JSC::Heap::subspaceForObjectOfType):
        (JSC::Heap::allocatorForObjectOfType):

2015-03-19  Andreas Kling  <akling@apple.com>

        JSCallee unnecessarily overrides a bunch of things in the method table.
        <https://webkit.org/b/142855>

        Reviewed by Geoffrey Garen.

        Remove JSCallee method table overrides that simply call to base class.
        This makes JSFunction property slot lookups slightly more efficient since
        they can take the fast path when passing over JSCallee in the base class chain.

        * runtime/JSCallee.cpp:
        (JSC::JSCallee::getOwnPropertySlot): Deleted.
        (JSC::JSCallee::getOwnNonIndexPropertyNames): Deleted.
        (JSC::JSCallee::put): Deleted.
        (JSC::JSCallee::deleteProperty): Deleted.
        (JSC::JSCallee::defineOwnProperty): Deleted.
        * runtime/JSCallee.h:

2015-03-19  Andreas Kling  <akling@apple.com>

        DFGAllocator should use bmalloc's aligned allocator.
        <https://webkit.org/b/142871>

        Reviewed by Geoffrey Garen.

        Switch DFGAllocator to using bmalloc through fastAlignedMalloc().

        * dfg/DFGAllocator.h:
        (JSC::DFG::Allocator<T>::allocateSlow):
        (JSC::DFG::Allocator<T>::freeRegionsStartingAt):
        * heap/CopiedSpace.h:
        * heap/MarkedBlock.h:
        * heap/MarkedSpace.h:

2015-03-18  Joseph Pecoraro  <pecoraro@apple.com>

        ES6 Classes: Extends should accept an expression without parenthesis
        https://bugs.webkit.org/show_bug.cgi?id=142840

        Reviewed by Ryosuke Niwa.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):
        "extends" allows a LeftHandExpression (new expression / call expression,
        which includes a member expression), not a primary expression. Our
        parseMemberExpression does all of these.

2015-03-18  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Debugger Popovers and Probes should use FormattedValue/ObjectTreeView instead of Custom/ObjectPropertiesSection
        https://bugs.webkit.org/show_bug.cgi?id=142830

        Reviewed by Timothy Hatcher.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
        Give Probe Samples object previews.

2015-03-17  Ryuan Choi  <ryuan.choi@navercorp.com>

        [EFL] Expose JavaScript binding interface through ewk_extension
        https://bugs.webkit.org/show_bug.cgi?id=142033

        Reviewed by Gyuyoung Kim.

        * PlatformEfl.cmake: Install Javascript APIs.

2015-03-17  Geoffrey Garen  <ggaren@apple.com>

        Function bodies should always include braces
        https://bugs.webkit.org/show_bug.cgi?id=142795

        Reviewed by Michael Saboff.

        Having a mode for excluding the opening and closing braces from a function
        body was unnecessary and confusing.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock): Adopt the new one true linking function.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::generateFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::link):
        (JSC::UnlinkedFunctionExecutable::codeBlockFor): No need to pass through
        a boolean: there is only one kind of function now.

        (JSC::UnlinkedFunctionExecutable::linkInsideExecutable): Deleted.
        (JSC::UnlinkedFunctionExecutable::linkGlobalCode): Deleted. Let's only
        have one way to do things. This removes the old mode that would pretend
        that a function always started at column 1. That pretense was not true:
        an attribute event listener does not necessarily start at column 1.

        * bytecode/UnlinkedCodeBlock.h:
        * generate-js-builtins: Adopt the new one true linking function.

        * parser/Parser.h:
        (JSC::Parser<LexerType>::parse):
        (JSC::parse): needsReparsingAdjustment is always true now, so I removed it.

        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::FunctionExecutable::FunctionExecutable):
        (JSC::ProgramExecutable::initializeGlobalProperties):
        (JSC::FunctionExecutable::fromGlobalCode):
        * runtime/Executable.h:
        (JSC::FunctionExecutable::create):
        (JSC::FunctionExecutable::bodyIncludesBraces): Deleted. Removed unused stuff.

        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck): Always provide a
        leading space because that's what this function's comment says is required
        for web compatibility. We used to fake this up after the fact when
        stringifying, based on the bodyIncludesBraces flag, but that flag is gone now.

        * runtime/FunctionPrototype.cpp:
        (JSC::insertSemicolonIfNeeded):
        (JSC::functionProtoFuncToString): No need to add braces and/or a space
        after the fact -- we always have them now.

2015-03-17  Mark Lam  <mark.lam@apple.com>

        Refactor execution time limit tests out of testapi.c.
        <https://webkit.org/b/142798>

        Rubber stamped by Michael Saboff.

        These tests were sometimes failing to time out on C loop builds.  Let's
        refactor them out of the big monolith that is testapi.c so that we can
        reason more easily about them and make adjustments if needed.

        * API/tests/ExecutionTimeLimitTest.cpp: Added.
        (currentCPUTime):
        (currentCPUTimeAsJSFunctionCallback):
        (shouldTerminateCallback):
        (cancelTerminateCallback):
        (extendTerminateCallback):
        (testExecutionTimeLimit):
        * API/tests/ExecutionTimeLimitTest.h: Added.
        * API/tests/testapi.c:
        (main):
        (currentCPUTime): Deleted.
        (currentCPUTime_callAsFunction): Deleted.
        (shouldTerminateCallback): Deleted.
        (cancelTerminateCallback): Deleted.
        (extendTerminateCallback): Deleted.
        * JavaScriptCore.xcodeproj/project.pbxproj:

2015-03-17  Geoffrey Garen  <ggaren@apple.com>

        Built-in functions should know that they use strict mode
        https://bugs.webkit.org/show_bug.cgi?id=142788

        Reviewed by Mark Lam.

        Even though all of our builtin functions use strict mode, the parser
        thinks that they don't. This is because Executable::toStrictness treats
        builtin-ness and strict-ness as mutually exclusive.

        The fix is to disambiguate builtin-ness from strict-ness.

        This bug is currently unobservable because of some other parser bugs. But
        it causes lots of test failures once those other bugs are fixed.

        * API/JSScriptRef.cpp:
        (parseScript):
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createBuiltinExecutable): Adopt the new API
        for a separate value to indicate builtin-ness vs strict-ness.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::generateFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::codeBlockFor): Ditto.

        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedFunctionExecutable::toStrictness): Deleted. This function
        was misleading since it pretended that no builtin function was ever
        strict, which is the opposite of true.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::Lexer):
        * parser/Lexer.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        * parser/Parser.h:
        (JSC::parse): Adopt the new API.

        * parser/ParserModes.h: Added JSParserBuiltinMode, and tried to give
        existing modes clearer names.

        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode): Adopt the new API.

        * runtime/CodeCache.h:
        (JSC::SourceCodeKey::SourceCodeKey): Be sure to treat strict-ness and
        bulitin-ness as separate pieces of the code cache key. We would not want
        a user function to match a built-in function in the cache, even if they
        agreed about strictness, since builtin functions have different lexing
        rules.

        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::FunctionExecutable):
        (JSC::ProgramExecutable::checkSyntax):
        * runtime/Executable.h:
        (JSC::FunctionExecutable::create):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock): Adopt the new API.

2015-03-16  Filip Pizlo  <fpizlo@apple.com>

        DFG IR shouldn't have a separate node for every kind of put hint that could be described using PromotedLocationDescriptor
        https://bugs.webkit.org/show_bug.cgi?id=142769

        Reviewed by Michael Saboff.
        
        When we sink an object allocation, we need to have some way of tracking what stores would
        have happened had the allocation not been sunk, so that we know how to rematerialize the
        object on OSR exit. Prior to this change, trunk had two ways of describing such a "put
        hint":
        
        - The PutStrutureHint and PutByOffsetHint node types.
        - The PromotedLocationDescriptor class, which has an enum with cases StructurePLoc and
          NamedPropertyPLoc.
        
        We also had ways of converting from a Node with those two node types to a
        PromotedLocationDescriptor, and we had a way of converting a PromotedLocationDescriptor to
        a Node.
        
        This change removes the redundancy. We now have just one node type that corresponds to a
        put hint, and it's called PutHint. It has a PromotedLocationDescriptor as metadata.
        Converting between a PutHint node and a PromotedLocationDescriptor and vice-versa is now
        trivial.
        
        This means that if we add new kinds of sunken objects, we'll have less pro-forma to write
        for the put hints to those objects. This is mainly to simplify the implementation of
        arguments elimination in bug 141174.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::mergeRelevantToOSR):
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::convertToPutHint):
        (JSC::DFG::Node::convertToPutStructureHint):
        (JSC::DFG::Node::convertToPutByOffsetHint):
        (JSC::DFG::Node::promotedLocationDescriptor):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasIdentifier):
        (JSC::DFG::Node::hasPromotedLocationDescriptor):
        (JSC::DFG::Node::convertToPutByOffsetHint): Deleted.
        (JSC::DFG::Node::convertToPutStructureHint): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::run):
        (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGPromoteHeapAccess.h:
        (JSC::DFG::promoteHeapAccess):
        * dfg/DFGPromotedHeapLocation.cpp:
        (JSC::DFG::PromotedHeapLocation::createHint):
        * dfg/DFGPromotedHeapLocation.h:
        (JSC::DFG::PromotedLocationDescriptor::imm1):
        (JSC::DFG::PromotedLocationDescriptor::imm2):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validateCPS):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):

2015-03-17  Michael Saboff  <msaboff@apple.com>

        Windows X86-64 should use the fixed executable allocator
        https://bugs.webkit.org/show_bug.cgi?id=142749

        Reviewed by Filip Pizlo.

        Added jit/ExecutableAllocatorFixedVMPool.cpp to Windows build.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * jit/ExecutableAllocatorFixedVMPool.cpp: Don't include unistd.h on Windows.

2015-03-17  Matt Baker  <mattbaker@apple.com>

        Web Inspector: Show rendering frames (and FPS) in Layout and Rendering timeline
        https://bugs.webkit.org/show_bug.cgi?id=142029

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Timeline.json:
        Added new event type for runloop timeline records.

2015-03-16  Ryosuke Niwa  <rniwa@webkit.org>

        Enable ES6 classes by default
        https://bugs.webkit.org/show_bug.cgi?id=142774

        Reviewed by Gavin Barraclough.

        Enabled the feature and unskipped tests.

        * Configurations/FeatureDefines.xcconfig:
        * tests/stress/class-syntax-no-loop-tdz.js:
        * tests/stress/class-syntax-no-tdz-in-catch.js:
        * tests/stress/class-syntax-no-tdz-in-conditional.js:
        * tests/stress/class-syntax-no-tdz-in-loop-no-inline-super.js:
        * tests/stress/class-syntax-no-tdz-in-loop.js:
        * tests/stress/class-syntax-no-tdz.js:
        * tests/stress/class-syntax-tdz-in-catch.js:
        * tests/stress/class-syntax-tdz-in-conditional.js:
        * tests/stress/class-syntax-tdz-in-loop.js:
        * tests/stress/class-syntax-tdz.js:

2015-03-16  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Better Console Previews for Arrays / Small Objects
        https://bugs.webkit.org/show_bug.cgi?id=142322

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        Create deep valuePreviews for simple previewable objects,
        such as arrays with 5 values, or basic objects with
        3 properties.

2015-03-16  Ryosuke Niwa  <rniwa@webkit.org>

        Add support for default constructor
        https://bugs.webkit.org/show_bug.cgi?id=142388

        Reviewed by Filip Pizlo.

        Added the support for default constructors. They're generated by ClassExprNode::emitBytecode
        via BuiltinExecutables::createDefaultConstructor.

        UnlinkedFunctionExecutable now has the ability to override SourceCode provided by the owner
        executable. We can't make store SourceCode in UnlinkedFunctionExecutable since CodeCache can use
        the same UnlinkedFunctionExecutable to generate code blocks for multiple functions.

        Parser now has the ability to treat any function expression as a constructor of the kind specified
        by m_defaultConstructorKind member variable.

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createDefaultConstructor): Added.
        (JSC::BuiltinExecutables::createExecutableInternal): Generalized from createBuiltinExecutable.
        Parse default constructors as normal non-builtin functions. Override SourceCode in the unlinked
        function executable since the Miranda function's code is definitely not in the owner executable's
        source code. That's the whole point.
        * builtins/BuiltinExecutables.h:
        (UnlinkedFunctionExecutable::createBuiltinExecutable): Added. Wraps createExecutableInternal.
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedFunctionExecutable::linkInsideExecutable):
        (JSC::UnlinkedFunctionExecutable::linkGlobalCode):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedFunctionExecutable::create):
        (JSC::UnlinkedFunctionExecutable::symbolTable): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitNewDefaultConstructor): Added.
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ClassExprNode::emitBytecode): Generate the default constructor if needed.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseFunctionInfo): Override ownerClassKind and assume the function as
        a constructor if we're parsing a default constructor.
        (JSC::Parser<LexerType>::parseClass): Allow omission of the class constructor.
        * parser/Parser.h:
        (JSC::parse):

2015-03-16  Alex Christensen  <achristensen@webkit.org>

        Progress towards CMake on Mac
        https://bugs.webkit.org/show_bug.cgi?id=142747

        Reviewed by Chris Dumez.

        * CMakeLists.txt:
        Include AugmentableInspectorController.h in CMake build.

2015-03-16  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Enable generating idiv instructions if it is supported
        https://bugs.webkit.org/show_bug.cgi?id=142725

        Reviewed by Michael Saboff.

        * assembler/ARMAssembler.h: Added sdiv and udiv implementation for ARM Traditional instruction set.
        (JSC::ARMAssembler::sdiv):
        (JSC::ARMAssembler::udiv):
        * assembler/ARMv7Assembler.h: Use HAVE(ARM_IDIV_INSTRUCTIONS) instead of CPU(APPLE_ARMV7S).
        * assembler/AbstractMacroAssembler.h:
        (JSC::isARMv7IDIVSupported):
        (JSC::optimizeForARMv7IDIVSupported):
        (JSC::isARMv7s): Renamed to isARMv7IDIVSupported().
        (JSC::optimizeForARMv7s): Renamed to optimizeForARMv7IDIVSupported().
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithDiv):
        (JSC::DFG::SpeculativeJIT::compileArithMod):

2015-03-15  Filip Pizlo  <fpizlo@apple.com>

        DFG::PutStackSinkingPhase should eliminate GetStacks that have an obviously known source, and emit GetStacks when the stack's value is needed and none is deferred
        https://bugs.webkit.org/show_bug.cgi?id=141624

        Reviewed by Geoffrey Garen.

        Not eliminating GetStacks was an obvious omission from the original PutStackSinkingPhase.
        Previously, we would treat GetStacks conservatively and assume that the stack slot
        escaped. That's pretty dumb, since a GetStack is a local load of the stack. This change
        makes GetStack a no-op from the standpoint of this phase's deferral analysis. At the end
        we either keep the GetStack (if there was no concrete deferral) or we replace it with an
        identity over the value that would have been stored by the deferred PutStack. Note that
        this might be a Phi that the phase creates, so this is strictly stronger than what GCSE
        could do.
        
        But this change revealed the fact that this phase never correctly handled side effects in
        case that we had done a GetStack, then a side-effect, and then found ourselves wanting the
        value on the stack due to (for example) a Phi on a deferred PutStack and that GetStack.
        Basically, it's only correct to use the SSA converter's incoming value mapping if we have
        a concrete deferral - since anything but a concrete deferral may imply that the value has
        been clobbered.
        
        This has no performance change. I believe that the bug was previously benign because we
        have so few operations that clobber the stack anymore, and most of those get used in a
        very idiomatic way. The GetStack elimination will be very useful for the varargs
        simplification that is part of bug 141174.
        
        This includes a test for the case that Speedometer hit, plus tests for the other cases I
        thought of once I realized the deeper issue.

        * dfg/DFGPutStackSinkingPhase.cpp:
        * tests/stress/get-stack-identity-due-to-sinking.js: Added.
        (foo):
        (bar):
        * tests/stress/get-stack-mapping-with-dead-get-stack.js: Added.
        (bar):
        (foo):
        * tests/stress/get-stack-mapping.js: Added.
        (bar):
        (foo):
        * tests/stress/weird-put-stack-varargs.js: Added.
        (baz):
        (foo):
        (fuzz):
        (bar):

2015-03-16  Joseph Pecoraro  <pecoraro@apple.com>

        Update Map/Set to treat -0 and 0 as the same value
        https://bugs.webkit.org/show_bug.cgi?id=142709

        Reviewed by Csaba Osztrogonác.

        * runtime/MapData.h:
        (JSC::MapDataImpl<Entry>::KeyType::KeyType):
        No longer special case -0. It will be treated as the same as 0.

2015-03-15  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Better handle displaying -0
        https://bugs.webkit.org/show_bug.cgi?id=142708

        Reviewed by Timothy Hatcher.

        Modeled after a blink change:

        Patch by <aandrey@chromium.org>
        DevTools: DevTools: Show -0 for negative zero in console
        https://src.chromium.org/viewvc/blink?revision=162605&view=revision

        * inspector/InjectedScriptSource.js:
        When creating a description string, or preview value string
        for -0, be sure the string is "-0" and not "0".

2015-03-14  Ryosuke Niwa  <rniwa@webkit.org>

        parseClass should popScope after pushScope
        https://bugs.webkit.org/show_bug.cgi?id=142689

        Reviewed by Benjamin Poulain.

        Pop the parser scope as needed.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):

2015-03-14  Dean Jackson  <dino@apple.com>

        Feature flag for Animations Level 2
        https://bugs.webkit.org/show_bug.cgi?id=142699
        <rdar://problem/20165097>

        Reviewed by Brent Fulgham.

        Add ENABLE_CSS_ANIMATIONS_LEVEL_2 and a runtime flag animationTriggersEnabled.

        * Configurations/FeatureDefines.xcconfig:

2015-03-14  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r181487.
        https://bugs.webkit.org/show_bug.cgi?id=142695

        Caused Speedometer/Full.html to fail (Requested by smfr on
        #webkit).

        Reverted changeset:

        "DFG::PutStackSinkingPhase should eliminate GetStacks that
        have an obviously known source"
        https://bugs.webkit.org/show_bug.cgi?id=141624
        http://trac.webkit.org/changeset/181487

2015-03-14  Michael Saboff  <msaboff@apple.com>

        ES6: Add binary and octal literal support
        https://bugs.webkit.org/show_bug.cgi?id=142681

        Reviewed by Ryosuke Niwa.

        Added a binary literal parser function, parseBinary(), to Lexer patterned after the octal parser.
        Refactored the parseBinary, parseOctal and parseDecimal to use a constant size for the number of
        characters to try and handle directly. Factored out the shifting past any prefix to be handled by
        the caller. Added binary and octal parsing to toDouble() via helper functions.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::parseHex):
        (JSC::Lexer<T>::parseBinary):
        (JSC::Lexer<T>::parseOctal):
        (JSC::Lexer<T>::parseDecimal):
        (JSC::Lexer<T>::lex):
        * parser/Lexer.h:
        * parser/ParserTokens.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::jsBinaryIntegerLiteral):
        (JSC::jsOctalIntegerLiteral):
        (JSC::toDouble):

2015-03-13  Alex Christensen  <achristensen@webkit.org>

        Progress towards CMake on Mac.
        https://bugs.webkit.org/show_bug.cgi?id=142680

        Reviewed by Gyuyoung Kim.

        * PlatformMac.cmake:
        Generate TracingDtrace.h based on project.pbxproj.

2015-03-13  Filip Pizlo  <fpizlo@apple.com>

        Object allocation sinking phase shouldn't re-decorate previously sunken allocations on each fixpoint operation
        https://bugs.webkit.org/show_bug.cgi?id=142686

        Reviewed by Oliver Hunt.
        
        Just because promoteHeapAccess() notifies us of an effect to a heap location in a node doesn't
        mean that we should handle it as if it was for one of our sinking candidates. Instead we should
        prune based on m_sinkCandidates.
        
        This fixes a benign bug where we would generate a lot of repeated IR for some pathological
        tests.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):

2015-03-13  Eric Carlson  <eric.carlson@apple.com>

        [Mac] Enable WIRELESS_PLAYBACK_TARGET
        https://bugs.webkit.org/show_bug.cgi?id=142635

        Reviewed by Darin Adler.

        * Configurations/FeatureDefines.xcconfig:

2015-03-13  Ryosuke Niwa  <rniwa@webkit.org>

        Class constructor should throw TypeError when "called"
        https://bugs.webkit.org/show_bug.cgi?id=142566

        Reviewed by Michael Saboff.

        Added ConstructorKind::None to denote code that doesn't belong to an ES6 class.
        This allows BytecodeGenerator to emit code to throw TypeError when generating code block
        to call ES6 class constructors.

        Most of changes are about increasing the number of bits to store ConstructorKind from one
        bit to two bits.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::generateFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::needsActivation):
        (JSC::ExecutableInfo::usesEval):
        (JSC::ExecutableInfo::isStrictMode):
        (JSC::ExecutableInfo::isConstructor):
        (JSC::ExecutableInfo::isBuiltinFunction):
        (JSC::ExecutableInfo::constructorKind):
        (JSC::UnlinkedFunctionExecutable::constructorKind):
        (JSC::UnlinkedCodeBlock::constructorKind):
        (JSC::UnlinkedFunctionExecutable::constructorKindIsDerived): Deleted.
        (JSC::UnlinkedCodeBlock::constructorKindIsDerived): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate): Don't emit bytecode when we had already emitted code
        to throw TypeError.
        (JSC::BytecodeGenerator::BytecodeGenerator): Emit code to throw TypeError when generating
        code to call.
        (JSC::BytecodeGenerator::emitReturn):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::constructorKind):
        (JSC::BytecodeGenerator::constructorKindIsDerived): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode):
        (JSC::FunctionCallValueNode::emitBytecode):
        * parser/Nodes.cpp:
        (JSC::FunctionBodyNode::FunctionBodyNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo): Renamed the incoming function argument to
        ownerClassKind. Set constructorKind to Base or Derived only if we're parsing a constructor.
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass): Don't parse static methods using MethodMode since that
        would result in BytecodeGenerator erroneously treating static method named "constructor" as
        a class constructor.
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        * parser/Parser.h:
        * parser/ParserModes.h:
        * runtime/Executable.h:
        (JSC::EvalExecutable::executableInfo):
        (JSC::ProgramExecutable::executableInfo):

2015-03-13  Filip Pizlo  <fpizlo@apple.com>

        DFG::PutStackSinkingPhase should eliminate GetStacks that have an obviously known source
        https://bugs.webkit.org/show_bug.cgi?id=141624

        Reviewed by Oliver Hunt.
        
        This was an obvious omission from the original PutStackSinkingPhase. Previously, we would treat
        GetStacks conservatively and assume that the stack slot escaped. That's pretty dumb, since a
        GetStack is a local load of the stack. This change makes GetStack a no-op from the standpoint of
        this phase's deferral analysis. At the end we either keep the GetStack (if there was no concrete
        deferral) or we replace it with an identity over the value that would have been stored by the
        deferred PutStack. Note that this might be a Phi that the phase creates, so this is strictly
        stronger than what GCSE could do.
        
        This is probably not a speed-up now, but it will be very useful for the varargs simplification
        done in bug 141174.

        * dfg/DFGPutStackSinkingPhase.cpp:

2015-03-12  Geoffrey Garen  <ggaren@apple.com>

        Prohibit GC while sweeping
        https://bugs.webkit.org/show_bug.cgi?id=142638

        Reviewed by Andreas Kling.

        I noticed in https://bugs.webkit.org/show_bug.cgi?id=142636 that a GC
        could trigger a sweep which could trigger another GC. Yo Dawg.

        I tried to figure out whether this could cause problems or not and it
        made me cross-eyed.

        (Some clients like to report extra memory cost during deallocation as a
        way to indicate that the GC now owns something exclusively. It's
        arguably a bug to communicate with the GC in this way, but we shouldn't
        do crazy when this happens.)

        This patch makes explicit the fact that we don't allow GC while sweeping.

        Usually, sweeping implicitly defers GC by virtue of happening during
        allocation. But not always.

        * heap/Heap.cpp:
        (JSC::Heap::collectAllGarbage): Defer GC while sweeping due to an
        explicit GC request.

        (JSC::Heap::didFinishCollection): Make sure that zombifying sweep
        defers GC by not returning to the non-GC state until we're all done.

        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::sweepNextBlock): Defer GC while sweeping due
        to a timer.

2015-03-13  Mark Lam  <mark.lam@apple.com>

        Replace TCSpinLock with a new WTF::SpinLock based on WTF::Atomic.
        <https://webkit.org/b/142674>

        Reviewed by Filip Pizlo.

        * API/JSValue.mm:
        (handerForStructTag):
        * API/JSWrapperMap.mm:
        * dfg/DFGCommon.cpp:
        (JSC::DFG::startCrashing):
        (JSC::DFG::isCrashing):
        - Changed to use a StaticSpinLock since that's what this code was trying to do
          anyway.
        * heap/CopiedBlock.h:
        (JSC::CopiedBlock::CopiedBlock):
        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::CopiedSpace):
        * heap/CopiedSpace.h:
        * heap/GCThreadSharedData.cpp:
        (JSC::GCThreadSharedData::GCThreadSharedData):
        * heap/GCThreadSharedData.h:
        * heap/ListableHandler.h:
        (JSC::ListableHandler::List::List):
        * parser/SourceProvider.cpp:
        * profiler/ProfilerDatabase.cpp:
        (JSC::Profiler::Database::addDatabaseToAtExit):
        (JSC::Profiler::Database::removeDatabaseFromAtExit):
        (JSC::Profiler::Database::removeFirstAtExitDatabase):

2015-03-13  Ryosuke Niwa  <rniwa@webkit.org>

        BytecodeGenerator needs to be re-entrant to support miranda functions
        https://bugs.webkit.org/show_bug.cgi?id=142627

        Reviewed by Filip Pizlo.

        Made CodeCache::getGlobalCodeBlock and CodeCache::getFunctionExecutableFromGlobalCode re-entrant
        by not keeping AddResult while invoking BytecodeGenerator::generate.

        This is needed to support Miranda functions since they need to be lazily initialized.

        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        (JSC::CodeCacheMap::findCacheAndUpdateAge): Extracted from add.
        (JSC::CodeCacheMap::addCache): Extracted from add.
        (JSC::CodeCacheMap::add): Deleted.

2015-03-13  Mark Lam  <mark.lam@apple.com>

        Introduce WTF::Atomic to wrap std::atomic for a friendlier CAS.
        <https://webkit.org/b/142661>

        Reviewed by Filip Pizlo.

        Changed CodeBlock, and the DFG's crashLock to use WTF::Atomic instead of
        std::atomic.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::visitAggregate):
        * bytecode/CodeBlock.h:
        * dfg/DFGCommon.cpp:
        (JSC::DFG::startCrashing):

2015-03-12  Mark Lam  <mark.lam@apple.com>

        Change the DFG crashLock to use std::atomic.
        <https://webkit.org/b/142649>

        Reviewed by Filip Pizlo.

        * dfg/DFGCommon.cpp:
        (JSC::DFG::startCrashing):
        (JSC::DFG::isCrashing):

2015-03-12  Filip Pizlo  <fpizlo@apple.com>

        Bytecode liveness analysis should have more lambdas and fewer sets
        https://bugs.webkit.org/show_bug.cgi?id=142647

        Reviewed by Mark Lam.
        
        In bug 141174 I'll need to identify all of the bytecode kill sites. This requires hooking into
        the bytecode analysis' stepOverFunction method, except in such a way that we observe uses that
        are not in outs. This refactors stepOverFunction so that you can pass it use/def functors that
        can either be used to propagate outs (as we do right now) or to additionally detect kills or
        whatever else.
        
        In order to achieve this, the liveness analysis was moved off of maintaining uses/defs
        bitvectors. This wasn't helping the abstraction and was probably inefficient. The new code
        should be a bit faster since we don't have to clear uses/defs bitvectors on each instruction. On
        the other hand, being able to intercept each use means that our code for exception handlers is
        no longer a bitwise-merge; it requires finding set bits. Fortunately, this code only kicks in
        for instructions inside a try, and its performance is O(live at catch), so that's probably not
        bad.

        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::indexForOperand):
        (JSC::stepOverInstruction):
        (JSC::computeLocalLivenessForBytecodeOffset):
        (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
        (JSC::setForOperand): Deleted.
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:

2015-03-12  Ryosuke Niwa  <rniwa@webkit.org>

        "this" should be in TDZ until super is called in the constructor of a derived class
        https://bugs.webkit.org/show_bug.cgi?id=142527

        Reviewed by Mark Hahnenberg.

        DFG and FTL implementations co-authored by Filip Pizlo.

        In ES6 class syntax, "this" register must be in the "temporal dead zone" (TDZ) and throw ReferenceError until
        super() is called inside the constructor of a derived class.

        Added op_check_tdz, a new OP code, which throws a reference error when the first operand is an empty value
        to all tiers of JIT and LLint. The op code throws in the slow path on the basis that a TDZ error should be
        a programming error and not a part of the programs' normal control flow. In DFG, this op code is represented
        by a no-op must-generate node CheckNotEmpty modeled after CheckCell.

        Also made the constructor of a derived class assign the empty value to "this" register rather than undefined
        so that ThisNode can emit the op_check_tdz to check the initialized-ness of "this" in such a constructor.

        * bytecode/BytecodeList.json: Added op_check_tdz.
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset): Ditto.
        (JSC::computeDefsForBytecodeOffset): Ditto.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode): Ditto.
        * bytecode/ExitKind.cpp:
        (JSC::exitKindToString): Added TDZFailure.
        * bytecode/ExitKind.h: Ditto.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator): Assign the empty value to "this" register to indicate it's in TDZ.
        (JSC::BytecodeGenerator::emitTDZCheck): Added.
        (JSC::BytecodeGenerator::emitReturn): Emit the TDZ check since "this" can still be in TDZ if super() was never
        called. e.g. class B extends A { constructor() { } }
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode): Always emit the TDZ check if we're inside the constructor of a derived class.
        We can't omit this check even if the result was ignored per spec.
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Previously, empty value could never appear
        in a local variable. This is no longer true so generalize this code. Also added the support for CheckNotEmpty.
        Like CheckCell, we phantomize this DFG node in the constant folding phase if the type of the operand is already
        found to be not empty. Otherwise filter out SpecEmpty.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock): Added op_check_tdz.
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel): op_check_tdz can be compiled and inlined.
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize): CheckNotEmpty doesn't read or write values.
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants): Convert CheckNotEmpty to a phantom if non-emptiness had already
        been proven for the operand prior to this node.
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC): CheckNotEmpty does not trigger GC.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): CheckNotEmpty is a no-op in the fixup phase.
        * dfg/DFGNodeType.h: CheckNotEmpty cannot be removed even if the result was ignored. See ThisNode::emitBytecode.
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate): CheckNotEmpty doesn't return any value.
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute): CheckNotEmpty doesn't load from heap so it's safe.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Speculative the operand to be not empty. OSR exit if the speculation fails.
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Ditto.
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile): CheckNotEmpty can be compiled in FTL.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode): Calls compileCheckNotEmpty for CheckNotEmpty.
        (JSC::FTL::LowerDFGToLLVM::compileCheckNotEmpty): OSR exit with "TDZFailure" if the operand is not empty.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass): Added op_check_tdz.
        (JSC::JIT::privateCompileSlowCases): Ditto.
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_check_tdz): Implements op_check_tdz in Baseline JIT.
        (JSC::JIT::emitSlow_op_check_tdz): Ditto.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_check_tdz): Ditto.
        (JSC::JIT::emitSlow_op_check_tdz): Ditto.
        * llint/LowLevelInterpreter32_64.asm: Implements op_check_tdz in LLint.
        * llint/LowLevelInterpreter64.asm: Ditto.
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL): Throws a reference error for op_check_tdz. Shared by LLint and Baseline JIT.
        * runtime/CommonSlowPaths.h:
        * tests/stress/class-syntax-no-loop-tdz.js: Added.
        * tests/stress/class-syntax-no-tdz-in-catch.js: Added.
        * tests/stress/class-syntax-no-tdz-in-conditional.js: Added.
        * tests/stress/class-syntax-no-tdz-in-loop-no-inline-super.js: Added.
        * tests/stress/class-syntax-no-tdz-in-loop.js: Added.
        * tests/stress/class-syntax-no-tdz.js: Added.
        * tests/stress/class-syntax-tdz-in-catch.js: Added.
        * tests/stress/class-syntax-tdz-in-conditional.js: Added.
        * tests/stress/class-syntax-tdz-in-loop.js: Added.
        * tests/stress/class-syntax-tdz.js: Added.

2015-03-12  Yusuke Suzuki  <utatane.tea@gmail.com>

        Integrate MapData into JSMap and JSSet
        https://bugs.webkit.org/show_bug.cgi?id=142556

        Reviewed by Filip Pizlo.

        This patch integrates MapData into JSMap and JSSet.
        This removes 2 object allocation per one JSMap / JSSet.

        MapDataImpl is specialized into MapData and SetData.
        In the case of SetData, it does not have the dummy values
        previously stored in the MapDataImpl. So the storage size of SetData
        becomes the half of the previous implementation.

        And now MapData and SetData are completely integrated into JSMap and JSSet,
        these structures are not exposed to the other code even in WebCore world.

        And at the same time, this patch fixes missing destroy functions
        in JSMapIterator and JSSetIterator.
        They are needed because MapData::const_iterator is a non-trivial destructor.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSMap.cpp:
        (JSC::JSMap::destroy):
        (JSC::JSMap::visitChildren):
        (JSC::JSMap::copyBackingStore):
        (JSC::JSMap::has):
        (JSC::JSMap::size):
        (JSC::JSMap::get):
        (JSC::JSMap::set):
        (JSC::JSMap::clear):
        (JSC::JSMap::remove):
        (JSC::JSMap::finishCreation): Deleted.
        * runtime/JSMap.h:
        (JSC::JSMap::Entry::key):
        (JSC::JSMap::Entry::value):
        (JSC::JSMap::Entry::visitChildren):
        (JSC::JSMap::Entry::setKey):
        (JSC::JSMap::Entry::setKeyWithoutWriteBarrier):
        (JSC::JSMap::Entry::setValue):
        (JSC::JSMap::Entry::clear):
        (JSC::JSMap::begin):
        (JSC::JSMap::end):
        (JSC::JSMap::JSMap):
        (JSC::JSMap::mapData): Deleted.
        * runtime/JSMapIterator.cpp:
        (JSC::JSMapIterator::finishCreation):
        (JSC::JSMapIterator::destroy):
        (JSC::JSMapIterator::visitChildren):
        * runtime/JSMapIterator.h:
        (JSC::JSMapIterator::JSMapIterator):
        * runtime/JSSet.cpp:
        (JSC::JSSet::destroy):
        (JSC::JSSet::visitChildren):
        (JSC::JSSet::copyBackingStore):
        (JSC::JSSet::has):
        (JSC::JSSet::size):
        (JSC::JSSet::add):
        (JSC::JSSet::clear):
        (JSC::JSSet::remove):
        (JSC::JSSet::finishCreation): Deleted.
        * runtime/JSSet.h:
        (JSC::JSSet::Entry::key):
        (JSC::JSSet::Entry::value):
        (JSC::JSSet::Entry::visitChildren):
        (JSC::JSSet::Entry::setKey):
        (JSC::JSSet::Entry::setKeyWithoutWriteBarrier):
        (JSC::JSSet::Entry::setValue):
        (JSC::JSSet::Entry::clear):
        (JSC::JSSet::begin):
        (JSC::JSSet::end):
        (JSC::JSSet::JSSet):
        (JSC::JSSet::mapData): Deleted.
        * runtime/JSSetIterator.cpp:
        (JSC::JSSetIterator::finishCreation):
        (JSC::JSSetIterator::visitChildren):
        (JSC::JSSetIterator::destroy):
        * runtime/JSSetIterator.h:
        (JSC::JSSetIterator::JSSetIterator):
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/MapData.h:
        (JSC::MapDataImpl::const_iterator::key):
        (JSC::MapDataImpl::const_iterator::value):
        (JSC::MapDataImpl::size):
        (JSC::MapDataImpl<Entry>::MapDataImpl):
        (JSC::MapDataImpl<Entry>::clear):
        (JSC::MapDataImpl<Entry>::KeyType::KeyType):
        (JSC::MapDataImpl<Entry>::const_iterator::internalIncrement):
        (JSC::MapDataImpl<Entry>::const_iterator::ensureSlot):
        (JSC::MapDataImpl<Entry>::const_iterator::const_iterator):
        (JSC::MapDataImpl<Entry>::const_iterator::~const_iterator):
        (JSC::MapDataImpl<Entry>::const_iterator::operator):
        (JSC::=):
        (JSC::MapData::const_iterator::key): Deleted.
        (JSC::MapData::const_iterator::value): Deleted.
        (JSC::MapData::create): Deleted.
        (JSC::MapData::createStructure): Deleted.
        (JSC::MapData::size): Deleted.
        (JSC::MapData::clear): Deleted.
        (JSC::MapData::KeyType::KeyType): Deleted.
        (JSC::MapData::const_iterator::internalIncrement): Deleted.
        (JSC::MapData::const_iterator::ensureSlot): Deleted.
        (JSC::MapData::const_iterator::const_iterator): Deleted.
        (JSC::MapData::const_iterator::~const_iterator): Deleted.
        (JSC::MapData::const_iterator::operator*): Deleted.
        (JSC::MapData::const_iterator::end): Deleted.
        (JSC::MapData::const_iterator::operator!=): Deleted.
        (JSC::MapData::const_iterator::operator==): Deleted.
        * runtime/MapDataInlines.h: Renamed from Source/JavaScriptCore/runtime/MapData.cpp.
        (JSC::MapDataImpl<Entry>::find):
        (JSC::MapDataImpl<Entry>::contains):
        (JSC::MapDataImpl<Entry>::add):
        (JSC::MapDataImpl<Entry>::set):
        (JSC::MapDataImpl<Entry>::get):
        (JSC::MapDataImpl<Entry>::remove):
        (JSC::MapDataImpl<Entry>::replaceAndPackBackingStore):
        (JSC::MapDataImpl<Entry>::replaceBackingStore):
        (JSC::MapDataImpl<Entry>::ensureSpaceForAppend):
        (JSC::MapDataImpl<Entry>::visitChildren):
        (JSC::MapDataImpl<Entry>::copyBackingStore):
        * runtime/MapPrototype.cpp:
        (JSC::getMap):
        (JSC::mapProtoFuncClear):
        (JSC::mapProtoFuncDelete):
        (JSC::mapProtoFuncForEach):
        (JSC::mapProtoFuncGet):
        (JSC::mapProtoFuncHas):
        (JSC::mapProtoFuncSet):
        (JSC::mapProtoFuncSize):
        (JSC::getMapData): Deleted.
        * runtime/SetPrototype.cpp:
        (JSC::getSet):
        (JSC::setProtoFuncAdd):
        (JSC::setProtoFuncClear):
        (JSC::setProtoFuncDelete):
        (JSC::setProtoFuncForEach):
        (JSC::setProtoFuncHas):
        (JSC::setProtoFuncSize):
        (JSC::getMapData): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2015-03-12  Mark Lam  <mark.lam@apple.com>

        Use std::atomic for CodeBlock::m_visitAggregateHasBeenCalled.
        <https://webkit.org/b/142640>

        Reviewed by Mark Hahnenberg.

        We used to spin our own compare and swap on a uint8_t.  Now that we can
        use C++11, let's use std::atomic instead.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::visitAggregate):
        - The CAS here needs std::memory_order_acquire ordering because it
          requires lock acquisition semantics to visit the CodeBlock.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlockSet::mark):
        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::clearMarksForFullCollection):
        (JSC::CodeBlockSet::clearMarksForEdenCollection):
        - These can go with relaxed ordering because they are all done before
          the GC starts parallel marking.

2015-03-12  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] Fix the incremental build issue revealed by r181419
        https://bugs.webkit.org/show_bug.cgi?id=142613

        Reviewed by Carlos Garcia Campos.

        * CMakeLists.txt:

2015-03-11  Ryosuke Niwa  <rniwa@webkit.org>

        "static" should not be a reserved keyword in non-strict mode even when ES6 class is enabled
        https://bugs.webkit.org/show_bug.cgi?id=142600

        Reviewed by Mark Lam.

        Make "static" RESERVED_IF_STRICT and manually detect it in parseClass.

        No new tests. This is already checked by js/reserved-words.html and js/keywords-and-reserved_words.html

        * parser/Keywords.table:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):
        * parser/ParserTokens.h:

2015-03-11  Geoffrey Garen  <ggaren@apple.com>

        Many users of Heap::reportExtraMemory* are wrong, causing lots of memory growth
        https://bugs.webkit.org/show_bug.cgi?id=142593

        Reviewed by Andreas Kling.

        Adopt deprecatedReportExtraMemory as a short-term fix for runaway
        memory growth in these cases where we have not adopted
        reportExtraMemoryVisited.

        Long-term, we should use reportExtraMemoryAllocated+reportExtraMemoryVisited.
        That's tracked by https://bugs.webkit.org/show_bug.cgi?id=142595.

        * API/JSBase.cpp:
        (JSReportExtraMemoryCost):
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::add):

2015-03-11  Geoffrey Garen  <ggaren@apple.com>

        Refactored the JSC::Heap extra cost API for clarity and to make some known bugs more obvious
        https://bugs.webkit.org/show_bug.cgi?id=142589

        Reviewed by Andreas Kling.

        * API/JSBase.cpp:
        (JSReportExtraMemoryCost): Added a FIXME to annotate a known bug.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::visitAggregate):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setJITCode): Updated for rename.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::reportExtraMemoryAllocatedSlowCase):
        (JSC::Heap::deprecatedReportExtraMemorySlowCase): Renamed our reporting
        APIs to clarify their relationship to each other: One must report extra
        memory at the time of allocation, and at the time the GC visits it.

        (JSC::Heap::extraMemorySize):
        (JSC::Heap::size):
        (JSC::Heap::capacity):
        (JSC::Heap::sizeAfterCollect):
        (JSC::Heap::willStartCollection): Updated for renames. Added explicit
        API for deprecated users who can't use our best API.
 
        (JSC::Heap::reportExtraMemoryCostSlowCase): Deleted.
        (JSC::Heap::extraSize): Deleted.

        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::reportExtraMemoryAllocated):
        (JSC::Heap::reportExtraMemoryVisited):
        (JSC::Heap::deprecatedReportExtraMemory):
        (JSC::Heap::reportExtraMemoryCost): Deleted. Ditto.

        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::reportExtraMemoryVisited):
        (JSC::SlotVisitor::reportExtraMemoryUsage): Deleted. Moved this
        functionality into the Heap since it's pretty detailed in its access
        to the heap.

        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): Updated for
        renames.

        * runtime/JSString.cpp:
        (JSC::JSString::visitChildren):
        (JSC::JSRopeString::resolveRopeToAtomicString):
        (JSC::JSRopeString::resolveRope):
        * runtime/JSString.h:
        (JSC::JSString::finishCreation): Updated for renames.

        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::add): Added FIXME.

        * runtime/WeakMapData.cpp:
        (JSC::WeakMapData::visitChildren): Updated for rename.

2015-03-11  Ryosuke Niwa  <rniwa@webkit.org>

        Calling super() in a base class results in a crash
        https://bugs.webkit.org/show_bug.cgi?id=142563

        Reviewed by Filip Pizlo.

        The bug was caused by BytecodeGenerator trying to generate "super" expression inside the constructor of a base class.
        Disallow that by keeping track of whether "super" has been used in the current scope or not (needsSuperBinding flag)
        and then throwing a syntax error in parseFunctionInfo if it was used and the current scope wasn't the constructor of
        a derived class.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo): Don't allow super() or super.foo outside the constructor of a derived class.
        (JSC::Parser<LexerType>::parseClass): Pass in the constructor kind to parseGetterSetter.
        (JSC::Parser<LexerType>::parseGetterSetter): Ditto to parseFunctionInfo.
        (JSC::Parser<LexerType>::parseMemberExpression): Set needsSuperBinding flag true on the containing scope.
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::needsSuperBinding): Added.
        (JSC::Scope::setNeedsSuperBinding): Added.

2015-03-10  Darin Adler  <darin@apple.com>

        Some event handler fixes
        https://bugs.webkit.org/show_bug.cgi?id=142474

        Reviewed by Anders Carlsson.

        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::createInjectedScript): Call clearException.
        I spotted the fact it was missing by auditing all the calls to JSC::call.

2015-03-10  Matthew Mirman  <mmirman@apple.com>

        Functions should have initialization precedence over arguments. 
        https://bugs.webkit.org/show_bug.cgi?id=142550
        rdar://problem/19702564

        Reviewed by Geoffrey Garen.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeCapturedVariable):
        * tests/stress/initialize_functions_after_arguments.js: Added.

2015-03-10  Andreas Kling  <akling@apple.com>

        Eden collections should trigger sweep of MarkedBlocks containing new objects.
        <https://webkit.org/b/142538>

        Reviewed by Geoffrey Garen.

        Take a snapshot of all MarkedBlocks with new objects as part of Eden collections,
        and append that to the IncrementalSweeper's working set.

        This ensures that we run destructors for objects that were discovered to be garbage during
        Eden collections, instead of delaying their teardown until the next full collection,
        or the next allocation cycle for their block.

        * heap/Heap.cpp:
        (JSC::Heap::snapshotMarkedSpace): For Eden collections, snapshot the list of MarkedBlocks
        that contain new objects, since those are the only ones we're interested in.
        Also use Vector::resizeToFit() to allocate the snapshot for full collections, since we know
        the final size we need up front.

        (JSC::Heap::notifyIncrementalSweeper): For Eden collections, tell the IncrementalSweeper
        to add the block snapshot (taken earlier) to its existing set of blocks instead of replacing
        it entirely. This allows Eden collections and incremental sweeping to occur interleaved with
        each other without missing destruction opportunities.

        * heap/IncrementalSweeper.h:
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::doSweep):
        (JSC::IncrementalSweeper::sweepNextBlock): Change the way we iterate over the sweeper's
        work list: instead of keeping an index for the next block, just pop from the end of the list.
        This allows us to add new blocks and deduplicate the list without disturbing iteration.

        (JSC::IncrementalSweeper::startSweeping): Make this take a Vector<MarkedBlock>&& so we can
        pass ownership of this Vector efficiently from Heap to IncrementalSweeper.

        (JSC::IncrementalSweeper::addBlocksAndContinueSweeping): Added. This is used by Eden
        collections to add a set of MarkedBlocks with new objects to the sweeper's existing
        working set and kick the timer.

        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::blocksWithNewObjects): Expose the list of MarkedBlocks with new objects.

2015-03-10  Alex Christensen  <achristensen@webkit.org>

        Use unsigned for HashSet size.
        https://bugs.webkit.org/show_bug.cgi?id=142518

        Reviewed by Benjamin Poulain.

        * dfg/DFGAvailabilityMap.cpp:
        (JSC::DFG::AvailabilityMap::prune):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * heap/MarkedBlockSet.h:
        (JSC::MarkedBlockSet::remove):
        * runtime/WeakMapData.h:

2015-03-10  Mark Lam  <mark.lam@apple.com>

        Use std::numeric_limits<unsigned>::max() instead of (unsigned)-1.
        <https://webkit.org/b/142539>

        Reviewed by Benjamin Poulain.

        * jit/JIT.cpp:
        (JSC::JIT::JIT):
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        (JSC::JIT::privateCompile):
        (JSC::JIT::privateCompileExceptionHandlers):
        * jit/JITInlines.h:
        (JSC::JIT::emitNakedCall):
        (JSC::JIT::addSlowCase):
        (JSC::JIT::addJump):
        (JSC::JIT::emitJumpSlowToHot):
        (JSC::JIT::emitGetVirtualRegister):
        * jit/SlowPathCall.h:
        (JSC::JITSlowPathCall::call):
        * yarr/Yarr.h:

2015-03-10  Mark Lam  <mark.lam@apple.com>

        [Win] JSC Build Warnings Need to be Resolved.
        <https://webkit.org/b/142366>

        Reviewed by Brent Fulgham.

        Applied some benign changes to make the MSVC compiler happy.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillJSValue):
        * runtime/BasicBlockLocation.cpp:
        (JSC::BasicBlockLocation::getExecutedRanges):
        * runtime/ControlFlowProfiler.cpp:
        (JSC::ControlFlowProfiler::hasBasicBlockAtTextOffsetBeenExecuted):

2015-03-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        Upgrade Map, Set and WeakMap constructor interface
        https://bugs.webkit.org/show_bug.cgi?id=142348

        Reviewed by Filip Pizlo.

        In the latest ES6 spec, Map and Set constructors take initialization data sets
        as iterable value. And iterate it and add the values into the constructed one.

        This is breaking change because the old constructor interface is
        already shipped in Safari 8.

        * runtime/MapConstructor.cpp:
        (JSC::callMap):
        (JSC::constructMap):
        (JSC::MapConstructor::getCallData):
        * runtime/SetConstructor.cpp:
        (JSC::callSet):
        (JSC::constructSet):
        * runtime/WeakMapConstructor.cpp:
        (JSC::callWeakMap):
        (JSC::constructWeakMap):
        (JSC::WeakMapConstructor::getCallData):
        * tests/stress/map-constructor-adder.js: Added.
        * tests/stress/map-constructor.js: Added.
        (testCallTypeError):
        (testTypeError):
        (for):
        * tests/stress/set-constructor-adder.js: Added.
        (Set.prototype.add):
        * tests/stress/set-constructor.js: Added.
        (for):
        * tests/stress/weak-map-constructor-adder.js: Added.
        * tests/stress/weak-map-constructor.js: Added.
        (testCallTypeError):
        (testTypeError):
        (for):

2015-03-10  Michael Catanzaro  <mcatanzaro@igalia.com>

        GCC: CRASH() should be annotated with NORETURN
        https://bugs.webkit.org/show_bug.cgi?id=142524

        Reviewed by Anders Carlsson.

        Don't return from a NORETURN function. This used to avoid a warning from GCC, but now it
        causes one.

        * jsc.cpp:

2015-03-10  Mark Lam  <mark.lam@apple.com>

        Gardening: fix bleeding debug test bots.
        https://webkit.org/b/142513>

        Not reviewed.

        The test needs to initialize WTF threading explicitly before using it.

        * API/tests/CompareAndSwapTest.cpp:
        (testCompareAndSwap):

2015-03-10  Alex Christensen  <achristensen@webkit.org>

        [WinCairo] Unreviewed build fix.

        * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props:
        Added directory containing config.h, like r181304.

2015-03-09  Mark Lam  <mark.lam@apple.com>

        Yet another build fix for Windows.
        https://webkit.org/b/142513>

        Reviewed by Alex Christensen.

        Looks like MSVC requires the function be explicitly declared in a header file
        in order for it to be linkable from another file in the same project.  This is
        strange, but it seems to make MSVC happy.

        Also fixed a typo in testapi.vcxproj.filters.

        * API/tests/CompareAndSwapTest.cpp:
        * API/tests/CompareAndSwapTest.h: Added.
        * API/tests/testapi.c:
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:

2015-03-09  Chris Dumez  <cdumez@apple.com>

        [iOS] Sweep all collected objects on critical memory pressure
        https://bugs.webkit.org/show_bug.cgi?id=142457
        <rdar://problem/20044440>

        Reviewed by Geoffrey Garen.

        All fullSweep() API to IncrementalSweeper so that we can call it in the
        memory pressure handler.

        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::fullSweep):
        * heap/IncrementalSweeper.h:
        (JSC::IncrementalSweeper::hasWork):

2015-03-09  Mark Lam  <mark.lam@apple.com>

        Another build fix for Windows.
        https://webkit.org/b/142513>

        Not reviewed.

        * API/tests/CompareAndSwapTest.cpp:
        - Added JS_EXPORT_PRIVATE attribute.

2015-03-09  Mark Lam  <mark.lam@apple.com>

        Build fix for Windows after r181305.
        https://webkit.org/b/142513>

        Reviewed by Alex Christensen.

        Windows doesn't like pthreads anymore.  Changed test to use WTF threading.

        * API/tests/CompareAndSwapTest.cpp:
        (setBitThreadFunc):
        (testCompareAndSwap):

2015-03-09  Mark Lam  <mark.lam@apple.com>

        8-bit version of weakCompareAndSwap() can cause an infinite loop.
        https://webkit.org/b/142513>

        Reviewed by Filip Pizlo.

        Added a test that exercises the 8-bit CAS from multiple threads.  The threads
        will contend to set bits in a large array of bytes using the CAS function.

        * API/tests/CompareAndSwapTest.cpp: Added.
        (Bitmap::Bitmap):
        (Bitmap::numBits):
        (Bitmap::clearAll):
        (Bitmap::concurrentTestAndSet):
        (setBitThreadFunc):
        (testCompareAndSwap):
        * API/tests/testapi.c:
        (main):
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:

2015-03-09  Brent Fulgham  <bfulgham@apple.com>

        [Win] testapi project is unable to find the 'config.h' file.

        Rubberstamped by Mark Lam.

        * JavaScriptCore.vcxproj/testapi/testapiCommon.props: Add JavaScriptCore source directory
        to the include path.

2015-03-09  Andreas Kling  <akling@apple.com>

        Stale entries in WeakGCMaps are keeping tons of WeakBlocks alive unnecessarily.
        <https://webkit.org/b/142115>
        <rdar://problem/19992268>

        Reviewed by Geoffrey Garen.

        Prune stale entries from WeakGCMaps as part of every full garbage collection.
        This frees up tons of previously-stuck WeakBlocks that were only sitting around
        with finalized handles waiting to die.

        Note that WeakGCMaps register/unregister themselves with the GC heap in their
        ctor/dtor, so creating one now requires passing the VM.

        Average time spent in the PruningStaleEntriesFromWeakGCMaps GC phase appears
        to be between 0.01ms and 0.3ms, though I've seen a few longer ones at ~1.2ms.
        It seems somewhat excessive to do this on every Eden collection, so it's only
        doing work in full collections for now.

        Because the GC may now mutate WeakGCMap below object allocation, I've made it
        so that the classic HashMap::add() optimization can't be used with WeakGCMap.
        This caused intermittent test failures when originally landed due to having
        an invalid iterator on the stack after add() inserted a new entry and we
        proceeded to allocate the new object, triggering GC.

        * API/JSWeakObjectMapRefInternal.h:
        (OpaqueJSWeakObjectMap::create):
        (OpaqueJSWeakObjectMap::OpaqueJSWeakObjectMap):
        * API/JSWeakObjectMapRefPrivate.cpp:
        * API/JSWrapperMap.mm:
        (-[JSWrapperMap initWithContext:]):
        (-[JSWrapperMap jsWrapperForObject:]): Pass VM to WeakGCMap constructor.

        * JavaScriptCore.xcodeproj/project.pbxproj: Add WeakGCMapInlines.h and make
        it project-private so WebCore clients can access it.

        * heap/Heap.cpp:
        (JSC::Heap::collect):
        (JSC::Heap::pruneStaleEntriesFromWeakGCMaps): Added a new GC phase for pruning
        stale entries from WeakGCMaps. This is only executed during full collections.

        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::registerWeakGCMap):
        (JSC::Heap::unregisterWeakGCMap): Added a mechanism for WeakGCMaps to register
        themselves with the Heap and provide a pruning callback.

        * runtime/PrototypeMap.h:
        (JSC::PrototypeMap::PrototypeMap):
        * runtime/Structure.cpp:
        (JSC::StructureTransitionTable::add): Pass VM to WeakGCMap constructor.

        * runtime/JSCInlines.h: Add "WeakGCMapInlines.h"

        * runtime/JSGlobalObject.cpp: Include "WeakGCMapInlines.h" so this builds.

        * runtime/JSString.cpp:
        (JSC::jsStringWithCacheSlowCase):
        * runtime/PrototypeMap.cpp:
        (JSC::PrototypeMap::addPrototype):
        (JSC::PrototypeMap::emptyObjectStructureForPrototype): Remove HashMap add()
        optimization since it's not safe in the GC-managed WeakGCMap world.

        * runtime/VM.cpp:
        (JSC::VM::VM): Pass VM to WeakGCMap constructor.

        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::set):
        (JSC::WeakGCMap::add):
        (JSC::WeakGCMap::WeakGCMap): Deleted.
        (JSC::WeakGCMap::gcMap): Deleted.
        (JSC::WeakGCMap::gcMapIfNeeded): Deleted.
        * runtime/WeakGCMapInlines.h: Added.
        (JSC::WeakGCMap::WeakGCMap):
        (JSC::WeakGCMap::~WeakGCMap):
        (JSC::WeakGCMap::pruneStaleEntries): Moved ctor, dtor and pruning callback
        to WeakGCMapInlines.h to fix interdependent header issues. Removed code that
        prunes WeakGCMap at certain growth milestones and instead rely on the GC
        callback for housekeeping.

2015-03-09  Ryosuke Niwa  <rniwa@webkit.org>

        Support extends and super keywords
        https://bugs.webkit.org/show_bug.cgi?id=142200

        Reviewed by Filip Pizlo.

        Added the support for ES6 class syntax inheritance.

        Added ConstructorKind as well as boolean flags indicating the constructor kind to
        various classes in UnlinkedCodeBlock as well as AST nodes.

        Each method stores the associated class as its homeObjectPrivateName. This value is used to
        make super calls.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::generateFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):

        * bytecode/UnlinkedCodeBlock.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::UnlinkedFunctionExecutable::constructorKindIsDerived): Added.
        (JSC::UnlinkedCodeBlock::constructorKindIsDerived): Added.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator): Don't emit op_create_this in a derived class
        as the object is allocated by the highest base class's constructor. Also set "this" to null
        and store the original value in m_newTargetRegister. "this" is supposed to be in TDZ but
        that will be implemented in a separate patch.
        (JSC::BytecodeGenerator::emitReturn): Allow "undefined" to be returned from a derived class.
        In a derived class's constructor, not returning "undefined" or an object results in a type
        error instead of "this" being returned.
        (JSC::BytecodeGenerator::emitThrowTypeError): Added.

        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::constructorKindIsDerived): Added.
        (JSC::BytecodeGenerator::newTarget): Added.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::SuperNode::emitBytecode): Added. Emits the code to obtain the callee's parent class.
        (JSC::emitSuperBaseForCallee): Added. Emits the code to obtain the parent class's prototype.
        (JSC::emitPutHomeObject): Added.
        (JSC::PropertyListNode::emitBytecode): Stores the home object when adding methods.
        (JSC::PropertyListNode::emitPutConstantProperty): Ditto.
        (JSC::BracketAccessorNode::emitBytecode): Added the support for super['foo'].
        (JSC::DotAccessorNode::emitBytecode): Added the support for super.foo.
        (JSC::FunctionCallValueNode::emitBytecode): Added the support for super().
        (JSC::FunctionCallBracketNode::emitBytecode): Added the support for super['foo']().
        (JSC::FunctionCallDotNode::emitBytecode): Added the support for super.foo().
        (JSC::DeleteBracketNode::emitBytecode): Forbid "delete super.foo".
        (JSC::DeleteDotNode::emitBytecode): Forbid "delete super['foo']".
        (JSC::ClassExprNode::emitBytecode): Added the support for "classHeritage". This is the main
        logic for inheritance. When a class B inherits from a class A, set B.__proto__ to A and set
        B.prototype.__proto__ to A.prototype. Throw exceptions when either A or A.__proto__ is not
        an object.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::superExpr): Added.

        * parser/NodeConstructors.h:
        (JSC::SuperNode::SuperNode): Added.

        * parser/Nodes.cpp:
        (JSC::FunctionBodyNode::FunctionBodyNode):

        * parser/Nodes.h:
        (JSC::ExpressionNode::isSuperNode):
        (JSC::PropertyNode::type):
        (JSC::PropertyNode::needsSuperBinding):

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionBody):
        (JSC::Parser<LexerType>::parseFunctionInfo): Throw a parser error if super() is used outside
        of class constructors.
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass): ConstructorKind is "derived" if and only if the parent
        class is specified in the declaration / expression.
        (JSC::Parser<LexerType>::parseGetterSetter):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression): Added the support for "super()", "super.foo",
        and "super['foo']". Throw a semantic error if "super" appears by itself.

        * parser/Parser.h:
        (JSC::Scope::Scope): Added m_hasDirectSuper. This variable keeps track of the use of "super()"
        so that parseFunctionInfo can spit an error if it's used outside of class constructors.
        (JSC::Scope::hasDirectSuper): Added.
        (JSC::Scope::setHasDirectSuper): Added.

        * parser/ParserModes.h:
        (JSC::ConstructorKind): Added.

        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::superExpr): Added.

        * runtime/CommonIdentifiers.h: Added homeObjectPrivateName.

        * runtime/Executable.h:
        (JSC::EvalExecutable::executableInfo): 
        (JSC::ProgramExecutable::executableInfo):

2015-03-08  Andreas Kling  <akling@apple.com>

        JITThunks keeps finalized Weaks around, pinning WeakBlocks.
        <https://webkit.org/b/142454>

        Reviewed by Darin Adler.

        Make JITThunks a WeakHandleOwner so it can keep its host function map free of stale entries.
        This fixes an issue I was seeing where a bunch of WeakBlocks stuck around with nothing but
        finalized Weak<NativeExecutable> entries.

        * jit/JITThunks.h:
        * jit/JITThunks.cpp:
        (JSC::JITThunks::finalize): Make JITThunks inherit from WeakHandleOwner so it can receive
        a callback when the NativeExecutables get garbage collected.

        (JSC::JITThunks::hostFunctionStub): Pass 'this' as the handle owner when creating Weaks.

2015-03-08  Andreas Kling  <akling@apple.com>

        BuiltinExecutables keeps finalized Weaks around, pinning WeakBlocks.
        <https://webkit.org/b/142460>

        Reviewed by Geoffrey Garen.

        Make BuiltinExecutables a WeakHandleOwner so it can clear out its respective Weak members
        if and when their pointees get garbage collected.

        This fixes an issue I've seen locally where a WeakBlock is pinned down by a single one of
        these Weak<BuiltinExecutables>.

        * builtins/BuiltinExecutables.h: Make BuiltinExecutables inherit from WeakHandleOwner.

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::finalize): Clear out the relevant member pointer when it's been
        garbage collected. We use the WeakImpl's "context" field to pass the address of the member.

2015-03-07  Geoffrey Garen  <ggaren@apple.com>

        Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
        https://bugs.webkit.org/show_bug.cgi?id=140900

        Reviewed by Mark Hahnenberg.

        Re-landing just the removal of BlockAllocator, which is now unused.

        * API/JSBase.cpp:
        * CMakeLists.txt:
        * JavaScriptCore.order:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/BlockAllocator.cpp: Removed.
        * heap/BlockAllocator.h: Removed.
        * heap/GCThreadSharedData.h:
        * heap/HandleBlockInlines.h:
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::blockAllocator): Deleted.
        * heap/HeapTimer.cpp:
        * heap/MarkedBlock.h:
        * heap/MarkedSpace.h:
        * heap/Region.h: Removed.
        * heap/SuperRegion.cpp: Removed.
        * heap/SuperRegion.h: Removed.

2015-03-07  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r181010.
        https://bugs.webkit.org/show_bug.cgi?id=142442

        Broke media/video-src-invalid-poster.html (Requested by kling
        on #webkit).

        Reverted changeset:

        "Stale entries in WeakGCMaps are keeping tons of WeakBlocks
        alive unnecessarily."
        https://bugs.webkit.org/show_bug.cgi?id=142115
        http://trac.webkit.org/changeset/181010

2015-03-07  Ryosuke Niwa  <rniwa@webkit.org>

        The code to link FunctionExecutable is duplicated everywhere
        https://bugs.webkit.org/show_bug.cgi?id=142436

        Reviewed by Darin Adler.

        Reduced code duplication by factoring out linkInsideExecutable and linkGlobalCode.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock): Calls linkInsideExecutable.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::linkInsideExecutable): Renamed from link. Now takes care of startOffset.
        This change was needed to use this function in CodeBlock::CodeBlock. Also, this function no longer takes
        lineOffset since this information is already stored in the source code.
        (JSC::UnlinkedFunctionExecutable::linkGlobalCode): Extracted from FunctionExecutable::fromGlobalCode.

        * bytecode/UnlinkedCodeBlock.h:

        * generate-js-builtins: Calls linkGlobalCode.

        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties): Calls linkGlobalCode.
        (JSC::FunctionExecutable::fromGlobalCode): Calls linkGlobalCode.

2015-03-06  Geoffrey Garen  <ggaren@apple.com>

        Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
        https://bugs.webkit.org/show_bug.cgi?id=140900

        Reviewed by Mark Hahnenberg.

        Re-landing just the MarkedBlock piece of this patch.

        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateBlock):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::destroy):
        (JSC::MarkedBlock::MarkedBlock):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::capacity):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::freeBlock):

2015-03-07  Ryosuke Niwa  <rniwa@webkit.org>

        fromGlobalCode has an unused Debugger* argument
        https://bugs.webkit.org/show_bug.cgi?id=142430

        Reviewed by Darin Adler.

        Removed the debugger argument from UnlinkedFunctionExecutable::fromGlobalCode and
        FunctionExecutable::fromGlobalCode since it's not used in either function.

        Also use reference in other arguments.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        * bytecode/UnlinkedCodeBlock.h:
        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::fromGlobalCode):
        * runtime/Executable.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):

2015-03-06  Brent Fulgham  <bfulgham@apple.com>

        [Win] Turn off a warning on Windows.

        Reduce build logging noise on Windows.

        * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:

2015-03-06  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: ES6: Improved Support for Iterator Objects
        https://bugs.webkit.org/show_bug.cgi?id=142420

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Runtime.json:
        Add new object subtype "iterator" for built-in iterator objects.

        * inspector/InjectedScriptSource.js:
        Return iterator values as Entry objects.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        Identify "iterator" typed objects.

        (Inspector::JSInjectedScriptHost::getInternalProperties):
        Provide internal properties for the different Iterator objects.

        (Inspector::JSInjectedScriptHost::iteratorEntries):
        Fetch the next few iterator entries of a built-in iterator object.

        * inspector/JSInjectedScriptHost.h:
        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        (Inspector::jsInjectedScriptHostPrototypeFunctionIteratorEntries):
        Call through to JSInjectedScriptHost.

        * runtime/JSArgumentsIterator.cpp:
        (JSC::JSArgumentsIterator::clone):
        * runtime/JSArgumentsIterator.h:
        (JSC::JSArgumentsIterator::iteratedValue):
        * runtime/JSArrayIterator.cpp:
        (JSC::JSArrayIterator::kind):
        (JSC::JSArrayIterator::iteratedValue):
        (JSC::JSArrayIterator::clone):
        * runtime/JSArrayIterator.h:
        * runtime/JSMapIterator.cpp:
        (JSC::JSMapIterator::finishCreation):
        (JSC::JSMapIterator::clone):
        * runtime/JSMapIterator.h:
        (JSC::JSMapIterator::kind):
        (JSC::JSMapIterator::iteratedValue):
        * runtime/JSSetIterator.cpp:
        (JSC::JSSetIterator::finishCreation):
        (JSC::JSSetIterator::clone):
        * runtime/JSSetIterator.h:
        (JSC::JSSetIterator::kind):
        (JSC::JSSetIterator::iteratedValue):
        * runtime/JSStringIterator.cpp:
        (JSC::JSStringIterator::iteratedValue):
        (JSC::JSStringIterator::clone):
        * runtime/JSStringIterator.h:
        Add accessors for internal properties and provide a way to clone the
        iterator so we can be at the same index and peek at the next few
        objects without modifying the original iterator object.

2015-03-06  Ryosuke Niwa  <rniwa@webkit.org>

        REGRESSION(r180595): construct varargs fails in FTL
        https://bugs.webkit.org/show_bug.cgi?id=142030

        Reviewed by Michael Saboff.

        Increase sizeOfCallVarargs as done for sizeOfConstructVarargs in r180651.

        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfCallVarargs):

2015-03-06  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Adopt Object Literal Shorthand Property Construction Syntax
        https://bugs.webkit.org/show_bug.cgi?id=142374

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:

2015-03-06  Joseph Pecoraro  <pecoraro@apple.com>

        ES6: Object Literal Extensions - Methods
        https://bugs.webkit.org/show_bug.cgi?id=142390

        Reviewed by Geoffrey Garen.

        Support method syntax in object literals.

        * parser/Parser.h:
        * parser/Parser.cpp:
        (JSC::stringForFunctionMode):
        (JSC::Parser<LexerType>::parseProperty):
        Methods are allowed for identifier, string, and numeric names,
        and computed property names.

        (JSC::Parser<LexerType>::parsePropertyMethod):
        Helper for parsing a property method.

2015-03-05  Joseph Pecoraro  <pecoraro@apple.com>

        __proto__ shorthand property should not modify prototype in Object Literal construction
        https://bugs.webkit.org/show_bug.cgi?id=142382

        Reviewed by Geoffrey Garen.

        When parsing shorthand property syntax we know we will do a
        put direct, even if the property name is __proto__. Pass that
        information through to bytecode generation.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitDirectPutById):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitPutConstantProperty):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createProperty):
        * parser/NodeConstructors.h:
        (JSC::PropertyNode::PropertyNode):
        * parser/Nodes.h:
        (JSC::PropertyNode::putType):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseProperty):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createProperty):

2015-03-06  Geoffrey Garen  <ggaren@apple.com>

        Fix crashes seen on the the 32-bit buildbots after my last patch.

        Unreviewed.

        * heap/CopiedBlock.h:
        (JSC::CopiedBlock::payload):
        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::tryAllocateOversize): Round up to the right alignment,
        since the size of the CopiedBlock class is not guaranteed to be the
        right alignment, and is in fact the wrong alignment on 32-bit.

2015-03-05  Geoffrey Garen  <ggaren@apple.com>

        Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
        https://bugs.webkit.org/show_bug.cgi?id=140900

        Reviewed by Mark Hahnenberg.

        Re-landing just the CopiedBlock piece of this patch.

        * heap/CopiedBlock.h:
        (JSC::CopiedBlock::createNoZeroFill):
        (JSC::CopiedBlock::destroy):
        (JSC::CopiedBlock::create):
        (JSC::CopiedBlock::CopiedBlock):
        (JSC::CopiedBlock::isOversize):
        (JSC::CopiedBlock::payloadEnd):
        (JSC::CopiedBlock::capacity):
        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::~CopiedSpace):
        (JSC::CopiedSpace::tryAllocateOversize):
        (JSC::CopiedSpace::tryReallocateOversize):
        * heap/CopiedSpaceInlines.h:
        (JSC::CopiedSpace::recycleEvacuatedBlock):
        (JSC::CopiedSpace::recycleBorrowedBlock):
        (JSC::CopiedSpace::allocateBlockForCopyingPhase):
        (JSC::CopiedSpace::allocateBlock):
        (JSC::CopiedSpace::startedCopying):
        * heap/CopyWorkList.h:

2015-03-06  Myles C. Maxfield  <mmaxfield@apple.com>

        [iOS] SVG fonts are garbled
        https://bugs.webkit.org/show_bug.cgi?id=142377

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig:

2015-03-05  Joseph Pecoraro  <pecoraro@apple.com>

        ES6: Object Literal Extensions - Shorthand Properties (Identifiers)
        https://bugs.webkit.org/show_bug.cgi?id=142353

        Reviewed by Geoffrey Garen.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseProperty):
        Parsing an identifier property followed by a comma or end brace treat
        as a shorthand property and create a property that has the same
        property name as the identifier name and value of a variable with that
        identifier. Otherwise, fall through to getter/setter parsing.

2015-03-05  Brent Fulgham  <bfulgham@apple.com>

        [Win] Unreviewed gardening.

        Confirmed with JSC that warning 4611 (interaction between '_setjmp' and C++ object
        destruction is non-portable) should be ignored in the JavaScriptCore project.

        * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: Silence warning 4611.

2015-03-05  Chris Dumez  <cdumez@apple.com>

        Regression(r173761): ASSERTION FAILED: !is8Bit() in StringImpl::characters16()
        https://bugs.webkit.org/show_bug.cgi?id=142350

        Reviewed by Michael Saboff and Benjamin Poulain.

        Call WTFString::hasInfixStartingAt() / hasInfixEndingAt() now that these
        methods have been renamed for clarity.

        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncStartsWith):
        (JSC::stringProtoFuncEndsWith):

2015-03-05  Yusuke Suzuki  <utatane.tea@gmail.com>

        Implement ES6 StringIterator
        https://bugs.webkit.org/show_bug.cgi?id=142080

        Reviewed by Filip Pizlo.

        This patch introduces ES6 String Iterator.
        It enumerates code points instead of elements in String.
        So surrogate pairs should be handled correctly.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/StringIterator.prototype.js: Added.
        (next):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
        * runtime/JSStringIterator.cpp: Added.
        (JSC::JSStringIterator::finishCreation):
        * runtime/JSStringIterator.h: Added.
        (JSC::JSStringIterator::createStructure):
        (JSC::JSStringIterator::create):
        (JSC::JSStringIterator::JSStringIterator):
        * runtime/StringIteratorConstructor.cpp: Added.
        (JSC::StringIteratorConstructor::finishCreation):
        * runtime/StringIteratorConstructor.h: Added.
        (JSC::StringIteratorConstructor::create):
        (JSC::StringIteratorConstructor::createStructure):
        (JSC::StringIteratorConstructor::StringIteratorConstructor):
        * runtime/StringIteratorPrototype.cpp: Added.
        (JSC::StringIteratorPrototype::finishCreation):
        (JSC::StringIteratorPrototype::getOwnPropertySlot):
        (JSC::stringIteratorPrototypeIterator):
        * runtime/StringIteratorPrototype.h: Added.
        (JSC::StringIteratorPrototype::create):
        (JSC::StringIteratorPrototype::createStructure):
        (JSC::StringIteratorPrototype::StringIteratorPrototype):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::stringProtoFuncIterator):
        * tests/stress/string-iterators.js: Added.
        (testSurrogatePair):
        (increment):
        (for):

2015-03-05  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Fix the FTL build on Aarch64 Linux after r177421
        https://bugs.webkit.org/show_bug.cgi?id=142040

        Reviewed by Mark Lam.

        * llvm/library/LLVMExports.cpp:
        (initializeAndGetJSCLLVMAPI):

2015-03-05  Yusuke Suzuki  <utatane.tea@gmail.com>

        Upgrade ES6 Iterator interfaces
        https://bugs.webkit.org/show_bug.cgi?id=141351

        Reviewed by Filip Pizlo.

        This patch upgrades the exising ES6 iterator to align the latest spec.
        In the latest spec,
        1. `Iterator.next` returns object that implements IteratorResult interface { value: value, done, boolean }.
        2. `Iterator.return` is introduced. When the iteration is terminated by the abrupt completion,
        it is called to close iterator state.
        3. Iterator.next of Array is moved from an iterator object to `%ArrayIteratorPrototype%`.

        To upgrade it, we changes the bytecode that represents for-of loops.
        And to embody the efficient iteration with an iterator object,
        we implemented %ArrayIteratorPrototype%.next in JavaScript and
        it is located in builtins/ArrayIterator.prototype.js.
        Implementing it in JavaScript encourages inlining and
        utilizes escape analysis for an iterator result object in DFG JIT.
        And we dropped the intrinsic version of %ArrayIteratorPrototype%.next.

        And we introduced IteratorOperations that is defined in the spec.
        It aligns the iteration in the runtime to the latest spec.
        Currently, Promise.all and Promise.race uses an iterable object.
        However, Promise.all and Promise.race implementation is also based on the old spec.
        Subsequent patches will upgrade it.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ArrayIterator.prototype.js: Copied from Source/JavaScriptCore/runtime/ArrayIteratorPrototype.h.
        (next):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitReturn):
        (JSC::BytecodeGenerator::emitThrowTypeError):
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::emitIsObject):
        (JSC::BytecodeGenerator::emitIsUndefined):
        * bytecompiler/BytecodeGenerator.h:
        * jit/ThunkGenerators.cpp:
        (JSC::arrayIteratorNextThunkGenerator): Deleted.
        (JSC::arrayIteratorNextKeyThunkGenerator): Deleted.
        (JSC::arrayIteratorNextValueThunkGenerator): Deleted.
        * jit/ThunkGenerators.h:
        * runtime/ArgumentsIteratorPrototype.cpp:
        (JSC::ArgumentsIteratorPrototype::finishCreation):
        (JSC::argumentsIteratorPrototypeFuncNext):
        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation):
        (JSC::ArrayIteratorPrototype::getOwnPropertySlot):
        (JSC::arrayIteratorProtoFuncIterator):
        (JSC::arrayIteratorPrototypeIterate): Deleted.
        * runtime/ArrayIteratorPrototype.h:
        * runtime/CommonIdentifiers.h:
        * runtime/Intrinsic.h:
        * runtime/IteratorOperations.cpp: Added.
        (JSC::iteratorNext):
        (JSC::iteratorValue):
        (JSC::iteratorComplete):
        (JSC::iteratorStep):
        (JSC::iteratorClose):
        (JSC::createIterResultObject):
        * runtime/IteratorOperations.h: Copied from Source/JavaScriptCore/runtime/ArrayIteratorPrototype.cpp.
        * runtime/JSArrayIterator.cpp:
        (JSC::JSArrayIterator::finishCreation):
        (JSC::JSArrayIterator::visitChildren): Deleted.
        (JSC::createIteratorResult): Deleted.
        (JSC::arrayIteratorNext): Deleted.
        (JSC::arrayIteratorNextKey): Deleted.
        (JSC::arrayIteratorNextValue): Deleted.
        (JSC::arrayIteratorNextGeneric): Deleted.
        * runtime/JSArrayIterator.h:
        (JSC::JSArrayIterator::JSArrayIterator):
        (JSC::JSArrayIterator::iterationKind): Deleted.
        (JSC::JSArrayIterator::iteratedObject): Deleted.
        (JSC::JSArrayIterator::nextIndex): Deleted.
        (JSC::JSArrayIterator::setNextIndex): Deleted.
        (JSC::JSArrayIterator::finish): Deleted.
        (JSC::JSArrayIterator::offsetOfIterationKind): Deleted.
        (JSC::JSArrayIterator::offsetOfIteratedObject): Deleted.
        (JSC::JSArrayIterator::offsetOfNextIndex): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSPromiseConstructor.cpp:
        (JSC::performPromiseRaceLoop):
        (JSC::JSPromiseConstructorFuncRace):
        (JSC::performPromiseAll):
        (JSC::JSPromiseConstructorFuncAll):
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototype::finishCreation):
        (JSC::MapIteratorPrototypeFuncNext):
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototype::finishCreation):
        (JSC::SetIteratorPrototypeFuncNext):
        * runtime/VM.cpp:
        (JSC::thunkGeneratorForIntrinsic):
        * tests/stress/array-iterators-next-with-call.js: Added.
        (increment):
        (for):
        * tests/stress/array-iterators-next.js: Added.

        Revive the older Array iterator tests that manually call 'next' method.

        * tests/stress/custom-iterators.js: Added.
        (iter.next):
        (iter.Symbol.iterator):
        (iter.return):
        (iter.get next):
        (iter.get return):
        (iteratorInterfaceErrorTest.iter.next):
        (iteratorInterfaceErrorTest.iter.Symbol.iterator):
        (iteratorInterfaceErrorTest.iter.return):
        (iteratorInterfaceErrorTest):
        (iteratorInterfaceErrorTestReturn.iter.next):
        (iteratorInterfaceErrorTestReturn.iter.Symbol.iterator):
        (iteratorInterfaceErrorTestReturn.iter.return):
        (iteratorInterfaceErrorTestReturn):
        (iteratorInterfaceBreakTestReturn.iter.next):
        (iteratorInterfaceBreakTestReturn.iter.Symbol.iterator):
        (iteratorInterfaceBreakTestReturn.iter.return):
        (iteratorInterfaceBreakTestReturn):

        This tests the behavior of custom iterators.
        'next' and 'return' of iterator work with for-of.

        * tests/stress/iterators-shape.js: Added.
        (iteratorShape):
        (sameNextMethods):
        (set var):

        This tests the shape of iterators; iterators of Array have 'next' method in %ArrayIteratorPrototype%.

        * tests/stress/map-iterators-next.js: Added.
        (set var):
        (.get if):
        (otherKey):
        * tests/stress/set-iterators-next.js: Added.
        (otherKey):

2015-03-04  Yusuke Suzuki  <utatane.tea@gmail.com>

        Hide Promise with runtime flags under Cocoa JSContext API
        https://bugs.webkit.org/show_bug.cgi?id=141965

        Reviewed by Filip Pizlo.

        Since there's no run loop in JavaScriptCore APIs, Promises don't work currently.
        So until they work, we hide Promise from a global object.
        Introduce new JSC runtime flag, PromiseDisabled. When `isPromiseDisabled` is true,
        Promise constructor is not attached to JSGlobalObject.

        To make 0 as default runtime flags, we choose PromiseDisabled flag
        instead of PromiseEnabled flag. So by default, Promise is enabled.

        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::JSCallbackObject):
        * API/JSContextRef.cpp:
        (javaScriptRuntimeFlags):
        (JSGlobalContextCreateInGroup):
        * API/tests/testapi.c:
        (main):
        * API/tests/testapi.mm:
        (testObjectiveCAPI):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::create):
        * runtime/RuntimeFlags.h:
        (JSC::RuntimeFlags::createAllEnabled):

2015-03-04  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Array/Collection Sizes should be visible and distinct
        https://bugs.webkit.org/show_bug.cgi?id=142254

        Reviewed by Timothy Hatcher.

        * runtime/WeakMapData.h:
        (JSC::WeakMapData::size):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::weakMapSize):
        * inspector/JSInjectedScriptHost.h:
        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        (Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapSize):
        Add a way to get a WeakMap's size.

        * inspector/protocol/Runtime.json:
        Include size in RemoteObject and ObjectPreview.

        * inspector/InjectedScriptSource.js:
        Set the size of RemoteObjects and previews if they
        are array/collection types.

2015-03-04  Andreas Kling  <akling@apple.com>

        GC should compute stack bounds and dump registers at the earliest opportunity.
        <https://webkit.org/b/142310>
        <rdar://problem/20045624>

        Reviewed by Geoffrey Garen.

        Make Heap::collect() a wrapper function around a collectImpl() where the work is actually done.
        The wrapper function that grabs a snapshot of the current stack boundaries and register values
        on entry, and sanitizes the stack on exit.

        This is a speculative fix for what appears to be overly conservative behavior in the garbage
        collector following r178364 which caused a measurable regression in memory usage on Membuster.
        The theory being that we were putting pointers to dead things on the stack before scanning it,
        and by doing that ended up marking things that we'd otherwise discover to be garbage.

        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::gatherStackRoots):
        (JSC::Heap::collect):
        (JSC::Heap::collectImpl):
        * heap/Heap.h:
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::gatherFromCurrentThread):
        (JSC::MachineThreads::gatherConservativeRoots):
        * heap/MachineStackMarker.h:

2015-03-04  Debarshi Ray  <debarshir@gnome.org>

        Silence GCC's -Wstrict-prototypes
        https://bugs.webkit.org/show_bug.cgi?id=142278

        Reviewed by Alexey Proskuryakov.

        * API/JSContextRef.h:

2015-03-04  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add a node for Math.log()
        https://bugs.webkit.org/show_bug.cgi?id=142126

        Reviewed by Geoffrey Garen.

        This patch adds the DFG node ArithLog for LogIntrinsic.

        Having a direct call to log has very little value by itself, the implementation
        in DFG and FTL is a simple function call.

        What is useful in ArithLog is that we know the operation is pure.
        This allow us to hoist it out of loops when the argument is independent
        is an invariant of the loop.

        Perf wise, this patch gives:
        -Kraken's imaging-darkroom: definitely 1.2372x faster.
        -AsmBench's Towers.c: definitely 1.0261x faster.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithLog):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileArithLog):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::doubleLog):
        * tests/stress/math-log-basics.js: Added.
        * tests/stress/math-log-with-constants.js: Added.

2015-03-04  Filip Pizlo  <fpizlo@apple.com>

        Only Heap should be in charge of deciding how to select a subspace for a type
        https://bugs.webkit.org/show_bug.cgi?id=142304

        Reviewed by Mark Lam.
        
        This slightly reduces the code duplication for selecting subspace based on type, and what
        duplication is left is at least localized in HeapInlines.h. The immediate effect is that
        the DFG and FTL don't have to duplicate this pattern.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
        (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::allocateObject):
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::allocateObjectOfType):
        (JSC::Heap::subspaceForObjectOfType):
        (JSC::Heap::allocatorForObjectOfType):
        * runtime/JSCellInlines.h:
        (JSC::allocateCell):

2015-03-04  Andreas Kling  <akling@apple.com>

        Stale entries in WeakGCMaps are keeping tons of WeakBlocks alive unnecessarily.
        <https://webkit.org/b/142115>
        <rdar://problem/19992268>

        Reviewed by Geoffrey Garen.

        Prune stale entries from WeakGCMaps as part of every full garbage collection.
        This frees up tons of previously-stuck WeakBlocks that were only sitting around
        with finalized handles waiting to die.

        Note that WeakGCMaps register/unregister themselves with the GC heap in their
        ctor/dtor, so creating one now requires passing the VM.

        Average time spent in the PruningStaleEntriesFromWeakGCMaps GC phase appears
        to be between 0.01ms and 0.3ms, though I've seen a few longer ones at ~1.2ms.
        It seems somewhat excessive to do this on every Eden collection, so it's only
        doing work in full collections for now.

        * API/JSWeakObjectMapRefInternal.h:
        (OpaqueJSWeakObjectMap::create):
        (OpaqueJSWeakObjectMap::OpaqueJSWeakObjectMap):
        * API/JSWeakObjectMapRefPrivate.cpp:
        * API/JSWrapperMap.mm:
        (-[JSWrapperMap initWithContext:]):
        (-[JSWrapperMap jsWrapperForObject:]): Pass VM to WeakGCMap constructor.

        * JavaScriptCore.xcodeproj/project.pbxproj: Add WeakGCMapInlines.h and make
        it project-private so WebCore clients can access it.

        * heap/Heap.cpp:
        (JSC::Heap::collect):
        (JSC::Heap::pruneStaleEntriesFromWeakGCMaps): Added a new GC phase for pruning
        stale entries from WeakGCMaps. This is only executed during full collections.

        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::registerWeakGCMap):
        (JSC::Heap::unregisterWeakGCMap): Added a mechanism for WeakGCMaps to register
        themselves with the Heap and provide a pruning callback.

        * runtime/PrototypeMap.h:
        (JSC::PrototypeMap::PrototypeMap):
        * runtime/Structure.cpp:
        (JSC::StructureTransitionTable::add): Pass VM to WeakGCMap constructor.

        * runtime/JSCInlines.h: Add "WeakGCMapInlines.h"

        * runtime/JSGlobalObject.cpp: Include "WeakGCMapInlines.h" so this builds.

        * runtime/VM.cpp:
        (JSC::VM::VM): Pass VM to WeakGCMap constructor.

        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::set):
        (JSC::WeakGCMap::add):
        (JSC::WeakGCMap::WeakGCMap): Deleted.
        (JSC::WeakGCMap::gcMap): Deleted.
        (JSC::WeakGCMap::gcMapIfNeeded): Deleted.
        * runtime/WeakGCMapInlines.h: Added.
        (JSC::WeakGCMap::WeakGCMap):
        (JSC::WeakGCMap::~WeakGCMap):
        (JSC::WeakGCMap::pruneStaleEntries): Moved ctor, dtor and pruning callback
        to WeakGCMapInlines.h to fix interdependent header issues. Removed code that
        prunes WeakGCMap at certain growth milestones and instead rely on the GC
        callback for housekeeping.

2015-03-03  Filip Pizlo  <fpizlo@apple.com>

        DFG IR should refer to FunctionExecutables directly and not via the CodeBlock
        https://bugs.webkit.org/show_bug.cgi?id=142229

        Reviewed by Mark Lam and Benjamin Poulain.
        
        Anytime a DFG IR node refers to something in CodeBlock, it has three effects:

        - Cumbersome API for accessing the thing that the node refers to.
        
        - Not obvious how to create a new such node after bytecode parsing, especially if the
          thing it refers to isn't already in the CodeBlock. We have done this in the past, but
          it usually involves subtle changes to CodeBlock.
        
        - Not obvious how to inline code that ends up using such nodes. Again, when we have done
          this, it involved subtle changes to CodeBlock.
        
        Prior to this change, the NewFunction* node types used an index into tables in CodeBlock.
        For this reason, those operations were not inlineable. But the functin tables in CodeBlock
        just point to FunctionExecutables, which are cells; this means that we can just abstract
        these operands in DFG IR as cellOperands. cellOperands use DFG::FrozenValue, which means
        that GC registration happens automagically. Even better, our dumping for cellOperand
        already did FunctionExecutable dumping - so that functionality gets to be deduplicated.
        
        Because this change increases the number of users of cellOperand, it also adds some
        convenience methods for using it. For example, whereas before you'd say things like:
        
            jsCast<Foo*>(node->cellOperand()->value())
        
        you can now just say:
        
            node->castOperand<Foo*>()
        
        This change also changes existing cellOperand users to use the new conveniance API when
        applicable.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::jettisonFunctionDeclsAndExprs):
        * bytecode/CodeBlock.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGFrozenValue.h:
        (JSC::DFG::FrozenValue::cell):
        (JSC::DFG::FrozenValue::dynamicCast):
        (JSC::DFG::FrozenValue::cast):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::registerFrozenValues):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasCellOperand):
        (JSC::DFG::Node::castOperand):
        (JSC::DFG::Node::hasFunctionDeclIndex): Deleted.
        (JSC::DFG::Node::functionDeclIndex): Deleted.
        (JSC::DFG::Node::hasFunctionExprIndex): Deleted.
        (JSC::DFG::Node::functionExprIndex): Deleted.
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck):
        (JSC::DFG::SpeculativeJIT::compileNewFunctionExpression):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGWatchpointCollectionPhase.cpp:
        (JSC::DFG::WatchpointCollectionPhase::handle):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileCheckCell):
        (JSC::FTL::LowerDFGToLLVM::compileNativeCallOrConstruct):

2015-03-03  Michael Saboff  <msaboff@apple.com>

        DelayedReleaseScope drops locks during GC which can cause a thread switch and code reentry
        https://bugs.webkit.org/show_bug.cgi?id=141275

        Reviewed by Geoffrey Garen.

        The original issue is that the CodeCache uses an unsafe method to add new UnlinkedCodeBlocks.
        It basically adds a null UnlinkedCodeBlock if there isn't a cached entry and then later
        updates the null entry to the result of the compilation.  If during that compilation and
        related processing we need to garbage collect, the DelayedReleaseScope would drop locks
        possibly allowing another thread to try to get the same source out of the CodeCache.
        This second thread would find the null entry and crash.  The fix is to move the processing of
        DelayedReleaseScope to when we drop locks and not drop locks during GC.  That was done in
        the original patch with the new function releaseDelayedReleasedObjects().

        Updated releaseDelayedReleasedObjects() so that objects are released with all locks
        dropped.  Now its processing follows these steps
            Increment recursion counter and do recursion check and exit if recursing
            While there are objects to release
                ASSERT that lock is held by current thread
                Take all items from delayed release Vector and put into temporary Vector
                Release API lock
                Release and clear items from temporary vector
                Reaquire API lock
        This meets the requirement that we release while the API lock is released and it is
        safer processing of the delayed release Vector.

        Added new regression test to testapi.

        Also added comment describing how recursion into releaseDelayedReleasedObjects() is
        prevented.

        * API/tests/Regress141275.h: Added.
        * API/tests/Regress141275.mm: Added.
        (+[JSTEvaluatorTask evaluatorTaskWithEvaluateBlock:completionHandler:]):
        (-[JSTEvaluator init]):
        (-[JSTEvaluator initWithScript:]):
        (-[JSTEvaluator _accessPendingTasksWithBlock:]):
        (-[JSTEvaluator insertSignPostWithCompletion:]):
        (-[JSTEvaluator evaluateScript:completion:]):
        (-[JSTEvaluator evaluateBlock:completion:]):
        (-[JSTEvaluator waitForTasksDoneAndReportResults]):
        (__JSTRunLoopSourceScheduleCallBack):
        (__JSTRunLoopSourcePerformCallBack):
        (__JSTRunLoopSourceCancelCallBack):
        (-[JSTEvaluator _jsThreadMain]):
        (-[JSTEvaluator _sourceScheduledOnRunLoop:]):
        (-[JSTEvaluator _setupEvaluatorThreadContextIfNeeded]):
        (-[JSTEvaluator _callCompletionHandler:ifNeededWithError:]):
        (-[JSTEvaluator _sourcePerform]):
        (-[JSTEvaluator _sourceCanceledOnRunLoop:]):
        (runRegress141275):
        * API/tests/testapi.mm:
        (testObjectiveCAPI):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/Heap.cpp:
        (JSC::Heap::releaseDelayedReleasedObjects):
        * runtime/JSLock.cpp:
        (JSC::JSLock::unlock):

2015-03-03  Filip Pizlo  <fpizlo@apple.com>

        DFG should constant fold GetScope, and accesses to the scope register in the ByteCodeParser should not pretend that it's a constant as that breaks OSR exit liveness tracking
        https://bugs.webkit.org/show_bug.cgi?id=106202

        Rubber stamped by Benjamin Poulain.
        
        This fixes a bug discovered by working on https://bugs.webkit.org/show_bug.cgi?id=142229,
        which was in turn discovered by working on https://bugs.webkit.org/show_bug.cgi?id=141174.
        Our way of dealing with scopes known to be constant is very sketchy, and only really works
        when a function is inlined. When it is, we pretend that every load of the scopeRegister sees
        a constant. But this breaks the DFG's tracking of the liveness of the scopeRegister. The way
        this worked made us miss oppportunities for optimizing based on a constant scope, and it also
        meant that in some cases - particularly like when we inline code that uses NewFuction and
        friends, as I do in bug 142229 - it makes OSR exit think that the scope is dead even though
        it's most definitely alive and it's a constant.
        
        The problem here is that we were doing too many optimizations in the ByteCodeParser, and not
        later. Later optimization phases know how to preserve OSR exit liveness. They're actually
        really good at it. Also, later phases know how to infer that any variable is a constant no
        matter how that constant arose - rather than the inlining-specific thing in ByteCodeParser.
        
        This changes the ByteCodeParser to largely avoid doing constant folding on the scope, except
        making the GetScope operation itself a constant. This is a compilation-time hack for small
        functions, and it doesn't break the loads of local variables - so OSR exit liveness still
        sees that the scopeRegister is in use. This then adds a vastly more powerful GetScope and
        GetClosureVar constant folder in the AbstractInterpreter. This handles most general cases
        including those that arise in complex control flow. This will catch cases where the scope
        is constant for any number of reasons. Basically anytime that the callee is inferred constant
        this will give us a constant scope. Also, we still have the parse-time constant folding of
        ResolveScope based on the reentry watchpoint, which luckily did the right thing with respect
        to OSR exit liveness (it splats a Phantom on its inputs, and it produces a constant result
        which is then set() normally).
        
        This appears to be a broad speed-up, albeit a small one. But mainly it unblocks bug 142229,
        which then should unblock bug 141174.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::get):
        (JSC::DFG::ByteCodeParser::getLocal):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::tryGetConstantClosureVar):
        (JSC::DFG::Graph::tryGetRegisters):
        (JSC::DFG::Graph::tryGetActivation): Deleted.
        * dfg/DFGGraph.h:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasVariableWatchpointSet):
        (JSC::DFG::Node::hasSymbolTable): Deleted.
        (JSC::DFG::Node::symbolTable): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGWatchpointCollectionPhase.cpp:
        (JSC::DFG::WatchpointCollectionPhase::handle):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileGetClosureVar):
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::visitChildren):
        (JSC::SymbolTable::localToEntry):
        (JSC::SymbolTable::entryFor):
        * runtime/SymbolTable.h:
        (JSC::SymbolTable::add):
        (JSC::SymbolTable::set):
        * tests/stress/function-expression-exit.js: Added.
        * tests/stress/function-reentry-infer-on-self.js: Added.
        (thingy):
        * tests/stress/goofy-function-reentry-incorrect-inference.js: Added.

2015-03-03  Anders Carlsson  <andersca@apple.com>

        Remove unused compression code
        https://bugs.webkit.org/show_bug.cgi?id=142237

        Reviewed by Geoffrey Garen.

        * bytecode/UnlinkedCodeBlock.h:

2015-03-03  Filip Pizlo  <fpizlo@apple.com>

        JIT debugging features that selectively disable the JITs for code blocks need to stay out of the way of the critical path of JIT management
        https://bugs.webkit.org/show_bug.cgi?id=142234

        Reviewed by Mark Lam and Benjamin Poulain.
        
        Long ago, we used to selectively disable compilation of CodeBlocks for debugging purposes by
        adding hacks to DFGDriver.cpp.  This was all well and good.  It used the existing
        CompilationFailed mode of the DFG driver to signal failure of CodeBlocks that we didn't want
        to compile.  That's great because CompilationFailed is a well-supported return value on the
        critical path, usually used for when we run out of JIT memory.

        Later, this was moved into DFGCapabilities. This was basically incorrect. It introduced a bug
        where disabling compiling of a CodeBlock meant that we stopped inlining it as well.  So if
        you had a compiler bug that arose if foo was inlined into bar, and you bisected down to bar,
        then foo would no longer get inlined and you wouldn't see the bug.  That's busted.

        So then we changed the code in DFGCapabilities to mark bar as CanCompile and foo as
        CanInline. Now, foo wouldn't get compiled alone but it would get inlined.

        But then we removed CanCompile because that capability mode only existed for the purpose of
        our old varargs hacks.  After that removal, "CanInline" became CannotCompile.  This means
        that if you bisect down on bar in the "foo inlined into bar" case, you'll crash in the DFG
        because the baseline JIT wouldn't have known to insert profiling on foo.

        We could fix this by bringing back CanInline.

        But this is all a pile of nonsense.  The debug support to selectively disable compilation of
        some CodeBlocks shouldn't cross-cut our entire engine and should most certainly never involve
        adding new capability modes.  This support is a hack at best and is for use by JSC hackers
        only.  It should be as unintrusive as possible.

        So, as in the ancient times, the only proper place to put this hack is in DFGDriver.cpp, and
        return CompilationFailed.  This is correct not just because it takes capability modes out of
        the picture (and obviates the need to introduce new ones), but also because it means that
        disabling compilation doesn't change the profiling mode of other CodeBlocks in the Baseline
        JIT.  Capability mode influences profiling mode which in turn influences code generation in
        the Baseline JIT, sometimes in very significant ways - like, we sometimes do additional
        double-to-int conversions in Baseline if we know that we might tier-up into the DFG, since
        this buys us more precise profiling.
        
        This change reduces the intrusiveness of debugging hacks by making them use the very simple
        CompilationFailed mechanism rather than trying to influence capability modes. Capability
        modes have very subtle effects on the whole engine, while CompilationFailed just makes the
        engine pretend like the DFG compilation will happen at timelike infinity. That makes these
        hacks much more likely to continue working as we make other changes to the system.
        
        This brings back the ability to bisect down onto a function bar when bar inlines foo. Prior
        to this change, we would crash in that case.

        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::isSupported):
        (JSC::DFG::mightCompileEval):
        (JSC::DFG::mightCompileProgram):
        (JSC::DFG::mightCompileFunctionForCall):
        (JSC::DFG::mightCompileFunctionForConstruct):
        * dfg/DFGCapabilities.h:
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):

2015-03-03  peavo@outlook.com  <peavo@outlook.com>

        [Win64] JSC compile error.
        https://bugs.webkit.org/show_bug.cgi?id=142216

        Reviewed by Mark Lam.

        There is missing a version of setupArgumentsWithExecState when NUMBER_OF_ARGUMENT_REGISTERS == 4.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):

2015-03-02  Filip Pizlo  <fpizlo@apple.com>

        DFG compile time measurements should really report milliseconds
        https://bugs.webkit.org/show_bug.cgi?id=142209

        Reviewed by Benjamin Poulain.
        
        Fix this to record milliseconds instead of seconds.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::compileInThreadImpl):

2015-03-02  Filip Pizlo  <fpizlo@apple.com>

        Remove op_get_callee, it's unused
        https://bugs.webkit.org/show_bug.cgi?id=142206

        Reviewed by Andreas Kling.
        
        It's a bit of a shame that we stopped using this opcode since it gives us same-callee
        profiling. But, if we were to add this functionality back in, we would almost certainly do
        it by adding a JSFunction allocation watchpoint on FunctionExecutable.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finalizeUnconditionally):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_get_callee): Deleted.
        (JSC::JIT::emitSlow_op_get_callee): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_get_callee): Deleted.
        (JSC::JIT::emitSlow_op_get_callee): Deleted.
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL): Deleted.

2015-03-02  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Context Menu to Log a Particular Object
        https://bugs.webkit.org/show_bug.cgi?id=142198

        Reviewed by Timothy Hatcher.

        Add a protocol method to assign a $n index to a value. For an object
        use the injected script context for that object. For a value, use
        the execution context to know where to save the value.

        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::saveResult):
        * inspector/InjectedScript.h:
        * inspector/InjectedScriptSource.js:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::saveResult):
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/protocol/Debugger.json:
        * inspector/protocol/Runtime.json:

2015-03-02  Filip Pizlo  <fpizlo@apple.com>

        SpeculativeJIT::emitAllocateArguments() should be a bit faster, and shouldn't do destructor initialization
        https://bugs.webkit.org/show_bug.cgi?id=142197

        Reviewed by Geoffrey Garen.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateArguments): Use shift instead of mul, since mul doesn't automatically strength-reduce to shift. Also pass the structure as a TrustedImmPtr.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject): Rationalize this a bit. The other emitAllocate... methods take a templated structure so that it can be either a TrustedImmPtr or a register. Also don't do destructor initialization, since its one client doesn't need it, and it's actually probably wrong.

2015-03-02  Mark Lam  <mark.lam@apple.com>

        Exception stack unwinding in JSC hangs while the Timeline Profiler is enabled.
        <https://webkit.org/b/142191>

        Reviewed by Geoffrey Garen.

        Imagine a scenario where the Inspector is paused / suspended at a breakpoint or
        while the user is stepping through JS code. The user then tries to evaluate an
        expression in the console, and that evaluation results in an exception being
        thrown. Currently, if the Timeline Profiler is enabled while this exception is
        being thrown, the WebProcess will hang while trying to handle that exception.

        The issue is that the Timeline Profiler's ProfileGenerator::didExecute() will
        return early and decline to process ProfileNodes if the Inspector is paused.
        This is proper because it does not want to count work done for injected scripts
        (e.g. from the console) towards the timeline profile of the webpage being run.
        However, this is in conflict with ProfileGenerator::exceptionUnwind()'s
        expectation that didExecute() will process ProfileNodes in order to do the stack
        unwinding for the exception handling. As a result,
        ProfileGenerator::exceptionUnwind() hangs.

        ProfileGenerator::exceptionUnwind() is in error. While the Inspector is paused,
        there will not be any ProfileNodes that it needs to "unwind". Hence, the fix is
        simply to return early also in ProfileGenerator::exceptionUnwind() if the
        Inspector is paused.

        * profiler/ProfileGenerator.cpp:
        (JSC::ProfileGenerator::exceptionUnwind):

2015-03-02  Filip Pizlo  <fpizlo@apple.com>

        FTL should correctly document where it puts the argument count for inlined varargs frames
        https://bugs.webkit.org/show_bug.cgi?id=142187

        Reviewed by Geoffrey Garn.
        
        After LLVM tells us where the captured variables alloca landed in the frame, we need to
        tell all of our meta-data about it. We were forgetting to do so for the argument count
        register, which is used by inlined varargs calls.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * tests/stress/inline-varargs-get-arguments.js: Added.
        (foo):
        (bar):
        (baz):

2015-03-02  Filip Pizlo  <fpizlo@apple.com>

        Deduplicate slow path calling code in JITOpcodes.cpp/JITOpcodes32_64.cpp
        https://bugs.webkit.org/show_bug.cgi?id=142184

        Reviewed by Michael Saboff.

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_get_enumerable_length):
        (JSC::JIT::emitSlow_op_has_structure_property):
        (JSC::JIT::emit_op_has_generic_property):
        (JSC::JIT::emit_op_get_structure_property_enumerator):
        (JSC::JIT::emit_op_get_generic_property_enumerator):
        (JSC::JIT::emit_op_to_index_string):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_get_enumerable_length): Deleted.
        (JSC::JIT::emitSlow_op_has_structure_property): Deleted.
        (JSC::JIT::emit_op_has_generic_property): Deleted.
        (JSC::JIT::emit_op_get_structure_property_enumerator): Deleted.
        (JSC::JIT::emit_op_get_generic_property_enumerator): Deleted.
        (JSC::JIT::emit_op_to_index_string): Deleted.
        (JSC::JIT::emit_op_profile_control_flow): Deleted.

2015-03-02  Antti Koivisto  <antti@apple.com>

        Add way to dump cache meta data to file
        https://bugs.webkit.org/show_bug.cgi?id=142183

        Reviewed by Andreas Kling.

        Export appendQuotedJSONStringToBuilder.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ObjectPatternNode::toString):
        * runtime/JSONObject.cpp:
        (JSC::appendQuotedJSONStringToBuilder):
        (JSC::Stringifier::appendQuotedString):
        (JSC::escapeStringToBuilder): Deleted.
        * runtime/JSONObject.h:

2015-03-02  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Add Context Menus to Object Tree properties
        https://bugs.webkit.org/show_bug.cgi?id=142125

        Reviewed by Timothy Hatcher.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::functionDetails):
        Update to include columnNumber.

2015-03-01  Filip Pizlo  <fpizlo@apple.com>

        BytecodeGenerator shouldn't emit op_resolve_scope as a roundabout way of returning the scopeRegister
        https://bugs.webkit.org/show_bug.cgi?id=142153

        Reviewed by Michael Saboff.
        
        We don't need a op_resolve_scope if we know that it will simply return the scope register.
        This changes the BytecodeGenerator to use the scope register directly in those cases where
        we know statically that we would just have returned that from op_resolve_scope.
        
        This doesn't appear to have a significant impact on performance.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitResolveScope):
        (JSC::BytecodeGenerator::emitReturn):
        (JSC::BytecodeGenerator::emitGetOwnScope): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ResolveNode::emitBytecode):
        (JSC::EvalFunctionCallNode::emitBytecode):
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::PostfixNode::emitResolve):
        (JSC::DeleteResolveNode::emitBytecode):
        (JSC::TypeOfResolveNode::emitBytecode):
        (JSC::PrefixNode::emitResolve):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::ConstDeclNode::emitCodeSingle):
        (JSC::EmptyVarExpression::emitBytecode):
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForOfNode::emitBytecode):
        (JSC::BindingNode::bindValue):

2015-02-27  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Use the way number constants are written to help type speculation
        https://bugs.webkit.org/show_bug.cgi?id=142072

        Reviewed by Filip Pizlo.

        This patch changes how we interpret numeric constant based on how they appear
        in the source.

        Constants that are integers but written with a decimal point now carry that information
        to the optimizating tiers. From there, we use that to be more aggressive about typing
        math operations toward double operations.

        For example, in:
            var a = x + 1.0;
            var b = y + 1;
        The Add for a would be biased toward doubles, the Add for b would speculate
        integer as usual.


        The gains are tiny but this is a prerequisite to make my next patch useful:
        -SunSpider's access-fannkuch: definitely 1.0661x faster
        -SunSpider's math-cordic: definitely 1.0266x slower
            overal: might be 1.0066x slower.
        -Kraken's imaging-darkroom: definitely 1.0333x faster.

        * parser/Lexer.cpp:
        (JSC::tokenTypeForIntegerLikeToken):
        (JSC::Lexer<T>::lex):
        The lexer now create two types of tokens for number: INTEGER and DOUBLE.
        Those token types only carry information about how the values were
        entered, an INTEGER does not have to be an integer, it is only written like one.
        Large integer still end up represented as double in memory.

        One trap I fell into was typing numbers like 12e3 as double. This kind of literal
        is frequently used in integer-typed code, while 12.e3 would appear in double-typed
        code.
        Because of that, the only signals for double are: decimal point, negative zero,
        and ridiculously large values.

        * parser/NodeConstructors.h:
        (JSC::DoubleNode::DoubleNode):
        (JSC::IntegerNode::IntegerNode):
        * parser/Nodes.h:
        (JSC::NumberNode::value):
        (JSC::NumberNode::setValue): Deleted.
        Number get specialized in two new kind of nodes in the AST: IntegerNode and DoubleNode.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::NumberNode::emitBytecode):

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createDoubleExpr):
        (JSC::ASTBuilder::createIntegerExpr):
        (JSC::ASTBuilder::createIntegerLikeNumber):
        (JSC::ASTBuilder::createDoubleLikeNumber):
        (JSC::ASTBuilder::createNumberFromBinaryOperation):
        (JSC::ASTBuilder::createNumberFromUnaryOperation):
        (JSC::ASTBuilder::makeNegateNode):
        (JSC::ASTBuilder::makeBitwiseNotNode):
        (JSC::ASTBuilder::makeMultNode):
        (JSC::ASTBuilder::makeDivNode):
        (JSC::ASTBuilder::makeModNode):
        (JSC::ASTBuilder::makeAddNode):
        (JSC::ASTBuilder::makeSubNode):
        (JSC::ASTBuilder::makeLeftShiftNode):
        (JSC::ASTBuilder::makeRightShiftNode):
        (JSC::ASTBuilder::makeURightShiftNode):
        (JSC::ASTBuilder::makeBitOrNode):
        (JSC::ASTBuilder::makeBitAndNode):
        (JSC::ASTBuilder::makeBitXOrNode):
        (JSC::ASTBuilder::createNumberExpr): Deleted.
        (JSC::ASTBuilder::createNumber): Deleted.
        The AST has some optimization to resolve constants before emitting bytecode.
        In the new code, the intger representation is kept if both operands where
        also represented as integers.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseDeconstructionPattern):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parseGetterSetter):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::printUnexpectedTokenText):
        * parser/ParserTokens.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createDoubleExpr):
        (JSC::SyntaxChecker::createIntegerExpr):
        (JSC::SyntaxChecker::createNumberExpr): Deleted.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::registerName):
        (JSC::CodeBlock::constantName):
        Change constantName(r, getConstant(r)) -> constantName(r) to simplify
        the dump code.

        (JSC::CodeBlock::dumpBytecode):
        Dump thre soure representation information we have with each constant.

        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::shrinkToFit):
        (JSC::constantName): Deleted.
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::constantsSourceCodeRepresentation):
        (JSC::CodeBlock::addConstant):
        (JSC::CodeBlock::addConstantLazily):
        (JSC::CodeBlock::constantSourceCodeRepresentation):
        (JSC::CodeBlock::setConstantRegisters):

        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::addConstant):
        (JSC::UnlinkedCodeBlock::constantsSourceCodeRepresentation):
        (JSC::UnlinkedCodeBlock::shrinkToFit):

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addConstantValue):
        (JSC::BytecodeGenerator::emitLoad):
        * bytecompiler/BytecodeGenerator.h:
        We have to differentiate between constants that have the same values but are
        represented differently in the source. Values like 1.0 and 1 now end up
        as different constants.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::get):
        (JSC::DFG::ByteCodeParser::addConstantToGraph):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::registerFrozenValues):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addSpeculationMode):
        (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
        ArithAdd is very aggressive toward using Int52, which is quite useful
        in many benchmarks.

        Here we need to specialize to make sure we don't force our literals
        to Int52 if there were represented as double.

        There is one exception to that rule: when the other operand is guaranteed
        to come from a NodeResultInt32. This is because there is some weird code
        doing stuff like:
            var b = a|0;
            var c = b*2.0;

        * dfg/DFGNode.h:
        (JSC::DFG::Node::Node):
        (JSC::DFG::Node::setOpAndDefaultFlags):
        (JSC::DFG::Node::sourceCodeRepresentation):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * runtime/JSCJSValue.h:
        (JSC::EncodedJSValueWithRepresentationHashTraits::emptyValue):
        (JSC::EncodedJSValueWithRepresentationHashTraits::constructDeletedValue):
        (JSC::EncodedJSValueWithRepresentationHashTraits::isDeletedValue):
        (JSC::EncodedJSValueWithRepresentationHash::hash):
        (JSC::EncodedJSValueWithRepresentationHash::equal):
        * tests/stress/arith-add-with-constants.js: Added.
        * tests/stress/arith-mul-with-constants.js: Added.

2015-02-26  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, roll out r180723. It broke a bunch of tests.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::constLocal):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ConstDeclNode::emitCodeSingle):
        * tests/stress/const-arguments.js: Removed.

2015-02-26  Mark Lam  <mark.lam@apple.com>

        Assertion fix for r180711: The bool returning form of BytecodeGenerator::addVar() can be removed.
        <https://webkit.org/b/142064>

        Reviewed by Joseph Pecoraro.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addVar):

2015-02-26  Mark Lam  <mark.lam@apple.com>

        MachineThreads::Thread clean up has a use after free race condition.
        <https://webkit.org/b/141990>

        Reviewed by Filip Pizlo.

        MachineThreads::Thread clean up relies on the clean up mechanism
        implemented in _pthread_tsd_cleanup_key(), which looks like this:

        void _pthread_tsd_cleanup_key(pthread_t self, pthread_key_t key)
        {
            void (*destructor)(void *);
            if (_pthread_key_get_destructor(key, &destructor)) {
                void **ptr = &self->tsd[key];
                void *value = *ptr;

            // === Start of window for the bug to manifest =================

                // At this point, this thread has cached "destructor" and "value"
                // (which is a MachineThreads*).  If the VM gets destructed (along
                // with its MachineThreads registry) by another thread, then this
                // thread will have no way of knowing that the MachineThreads* is
                // now pointing to freed memory.  Calling the destructor below will
                // therefore result in a use after free scenario when it tries to
                // access the MachineThreads' data members.

                if (value) {
                    *ptr = NULL;
                    if (destructor) {

            // === End of window for the bug to manifest ==================

                        destructor(value);
                    }
                }
            }
        }

        The fix is to add each active MachineThreads to an ActiveMachineThreadsManager,
        and always check if the manager still contains that MachineThreads object
        before we call removeCurrentThread() on it.  When MachineThreads is destructed,
        it will remove itself from the manager.  The add, remove, and checking
        operations are all synchronized on the manager's lock, thereby ensuring that
        the MachineThreads object, if found in the manager, will remain alive for the
        duration of time we call removeCurrentThread() on it.

        There's also possible for the MachineThreads object to already be destructed
        and another one happened to have been instantiated at the same address.
        Hence, we should only remove the exiting thread if it is found in the
        MachineThreads object.

        There is no test for this issue because this bug requires a race condition
        between 2 threads where:
        1. Thread B, which had previously used the VM, exiting and
           getting to the bug window shown in _pthread_tsd_cleanup_key() above.
        2. Thread A destructing the VM (and its MachineThreads object)
           within that window of time before Thread B calls the destructor.

        It is not possible to get a reliable test case without invasively
        instrumenting _pthread_tsd_cleanup_key() or MachineThreads::removeCurrentThread()
        to significantly increase that window of opportunity.

        * heap/MachineStackMarker.cpp:
        (JSC::ActiveMachineThreadsManager::Locker::Locker):
        (JSC::ActiveMachineThreadsManager::add):
        (JSC::ActiveMachineThreadsManager::remove):
        (JSC::ActiveMachineThreadsManager::contains):
        (JSC::ActiveMachineThreadsManager::ActiveMachineThreadsManager):
        (JSC::activeMachineThreadsManager):
        (JSC::MachineThreads::MachineThreads):
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::removeThread):
        (JSC::MachineThreads::removeThreadIfFound):
        (JSC::MachineThreads::removeCurrentThread): Deleted.
        * heap/MachineStackMarker.h:

2015-02-26  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Save Console Evaluations into Command Line variables $1-$99 ($n)
        https://bugs.webkit.org/show_bug.cgi?id=142061

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Debugger.json:
        * inspector/protocol/Runtime.json:
        Input flag "saveResult" on whether we should try to save a result.
        Output int "savedResultIndex" to tell the frontend the saved state.

        * inspector/InjectedScriptSource.js:
        Handle saving and clearing $1-$99 values.
        Include in BasicCommandLineAPI for JSContext inspection.

        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::makeEvalCall):
        * inspector/InjectedScriptBase.h:
        Allow an optional "savedResultIndex" out value on evals.

        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::evaluate):
        (Inspector::InjectedScript::evaluateOnCallFrame):
        * inspector/InjectedScript.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::evaluate):
        * inspector/agents/InspectorRuntimeAgent.h:
        Plumbing for new in and out parameters.

2015-02-26  Filip Pizlo  <fpizlo@apple.com>

        The bool returning form of BytecodeGenerator::addVar() can be removed
        https://bugs.webkit.org/show_bug.cgi?id=142064

        Reviewed by Mark Lam.
        
        It's easier to implement addVar() when you don't have to return whether it's a new
        variable or not.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addVar):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::addVar): Deleted.

2015-02-26  Filip Pizlo  <fpizlo@apple.com>

        Various array access corner cases should take OSR exit feedback
        https://bugs.webkit.org/show_bug.cgi?id=142056

        Reviewed by Geoffrey Garen.
        
        Two major changes here:
        
        - Don't keep converting GetById into GetArrayLength if we exited due to any kind of array
          type check.
        
        - Use a generic form of GetByVal/PutByVal if we exited due to any kind of exotic checks,
          like the Arguments safety checks. We use the "ExoticObjectMode" for out-of-bounds on
          arguments for now, since it's a convenient way of forcing out-of-bounds to be handled by
          the Generic array mode.

        * bytecode/ExitKind.cpp:
        (JSC::exitKindToString):
        * bytecode/ExitKind.h:
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::refine):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
        (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength):
        * tests/stress/array-length-array-storage-plain-object.js: Added.
        (foo):
        * tests/stress/array-length-plain-object.js: Added.
        (foo):

2015-02-25  Filip Pizlo  <fpizlo@apple.com>

        DFG SSA stack accesses shouldn't speak of VariableAccessDatas
        https://bugs.webkit.org/show_bug.cgi?id=142036

        Reviewed by Michael Saboff.
        
        VariableAccessData is a useful thing in LoadStore and ThreadedCPS, but it's purely harmful in
        SSA because you can't cook up new VariableAccessDatas. So, if you know that you want to load
        or store to the stack, and you know what format to use as well as the location, then prior to
        this patch you couldn't do it unless you found some existing VariableAccessData that matched
        your requirements. That can be a hard task.
        
        It's better if SSA doesn't speak of VariableAccessDatas but instead just has stack accesses
        that speak of the things that a stack access needs: local, machineLocal, and format. This
        patch changes the SSA way of accessing the stack to do just that.
        
        Also add more IR validation.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGFlushFormat.h:
        (JSC::DFG::isConcrete):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGGraph.h:
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::hasVariableAccessData):
        * dfg/DFGNode.h:
        (JSC::DFG::StackAccessData::StackAccessData):
        (JSC::DFG::StackAccessData::flushedAt):
        (JSC::DFG::Node::convertToPutStack):
        (JSC::DFG::Node::convertToGetStack):
        (JSC::DFG::Node::hasUnlinkedLocal):
        (JSC::DFG::Node::hasStackAccessData):
        (JSC::DFG::Node::stackAccessData):
        (JSC::DFG::Node::willHaveCodeGenOrOSR):
        * dfg/DFGNodeType.h:
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGPutLocalSinkingPhase.cpp: Removed.
        * dfg/DFGPutLocalSinkingPhase.h: Removed.
        * dfg/DFGPutStackSinkingPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPutLocalSinkingPhase.cpp.
        (JSC::DFG::performPutStackSinking):
        (JSC::DFG::performPutLocalSinking): Deleted.
        * dfg/DFGPutStackSinkingPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPutLocalSinkingPhase.h.
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validate):
        (JSC::DFG::Validate::validateCPS):
        (JSC::DFG::Validate::validateSSA):
        * dfg/DFGVirtualRegisterAllocationPhase.cpp:
        (JSC::DFG::VirtualRegisterAllocationPhase::run):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::lower):
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileGetStack):
        (JSC::FTL::LowerDFGToLLVM::compilePutStack):
        (JSC::FTL::LowerDFGToLLVM::compileGetLocal): Deleted.
        (JSC::FTL::LowerDFGToLLVM::compilePutLocal): Deleted.
        * ftl/FTLOSRExit.h:
        * tests/stress/many-sunken-locals.js: Added. This failure mode was caught by some miscellaneous test, so I figured I should write an explicit test for it.
        (foo):
        (bar):
        (baz):
        (fuzz):
        (buzz):

2015-02-26  Mark Lam  <mark.lam@apple.com>

        Rolling out r180602, r180608, r180613, r180617, r180671.
        <https://webkit.org/b/141990>

        Not reviewed.

        The r180602 solution does result in more work for GC when worker
        threads are in use.  Filip is uncomfortable with that.
        The EFL and GTK ports also seem to be unhappy with this change.
        Rolling out while we investigate.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::gatherStackRoots):
        (JSC::Heap::machineThreads): Deleted.
        * heap/Heap.h:
        (JSC::Heap::machineThreads):
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThreads):
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::addCurrentThread):
        * heap/MachineStackMarker.h:
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):

2015-02-26  Myles C. Maxfield  <mmaxfield@apple.com>

        [Mac] [iOS] Parsing support for -apple-trailing-word
        https://bugs.webkit.org/show_bug.cgi?id=141939

        Reviewed by Andreas Kling.

        * Configurations/FeatureDefines.xcconfig:

2015-02-26  Michael Saboff  <msaboff@apple.com>

        [Win] Debug-only JavaScriptCore failures
        https://bugs.webkit.org/show_bug.cgi?id=142045

        Rubber stamped by Filip Pizlo.

        Reduced loop count to a more reasonable value of 10,000.  This still gets us to tier up
        to the FTL, but doesn't take too long to run.

        * tests/stress/repeated-arity-check-fail.js:

2015-02-26  Brent Fulgham  <bfulgham@apple.com>

        [Win] Make build logs more legible by reducing noise
        https://bugs.webkit.org/show_bug.cgi?id=142034

        Reviewed by Alexey Proskuryakov.

        Modify batch files, makefiles, and DOS commands to remove
        uninteresting/unhelpful output.

        * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
        * JavaScriptCore.vcxproj/JavaScriptCorePreBuild.cmd:
        * JavaScriptCore.vcxproj/copy-files.cmd:
        * JavaScriptCore.vcxproj/jsc/jscLauncherPreBuild.cmd:
        * JavaScriptCore.vcxproj/jsc/jscPreBuild.cmd:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreBuild.cmd:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpPreBuild.cmd:
        * JavaScriptCore.vcxproj/testapi/testapiLauncherPostBuild.cmd:
        * JavaScriptCore.vcxproj/testapi/testapiLauncherPreBuild.cmd:
        * JavaScriptCore.vcxproj/testapi/testapiPostBuild.cmd:
        * JavaScriptCore.vcxproj/testapi/testapiPreBuild.cmd:

2015-02-26  Csaba Osztrogonác  <ossy@webkit.org>

        Add calleeSaveRegisters() implementation for ARM Traditional
        https://bugs.webkit.org/show_bug.cgi?id=141903

        Reviewed by Darin Adler.

        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::calleeSaveRegisters):

2015-02-25  Michael Saboff  <msaboff@apple.com>

        Web Inspector: CRASH when debugger pauses inside a Promise handler
        https://bugs.webkit.org/show_bug.cgi?id=141396

        Reviewed by Mark Lam.

        For frames that don't have a scope, typically native frames, use the lexicalGlobalObject to
        create the DebuggerScope for that frame.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::scope):

2015-02-25  Filip Pizlo  <fpizlo@apple.com>

        DFG abstract heaps should respect the difference between heap and stack
        https://bugs.webkit.org/show_bug.cgi?id=142022

        Reviewed by Geoffrey Garen.
        
        We will soon (https://bugs.webkit.org/show_bug.cgi?id=141174) be in a world where a "world
        clobbering" operation cannot write to our stack, but may be able to read from it. This
        means that we need to change the DFG abstract heap hierarchy to have a notion of Heap that
        subsumes all that World previously subsumed, and a new notion of Stack that is a subtype
        of World and a sibling of Heap.

        So, henceforth "clobbering the world" means reading World and writing Heap.
        
        This makes a bunch of changes to make this work, including changing the implementation of
        disjointness in AbstractHeap to make it support a more general hierarchy. I was expecting
        a slow-down, but I measured the heck out of this and found no perf difference.

        * dfg/DFGAbstractHeap.cpp:
        (JSC::DFG::AbstractHeap::dump):
        * dfg/DFGAbstractHeap.h:
        (JSC::DFG::AbstractHeap::supertype):
        (JSC::DFG::AbstractHeap::isStrictSubtypeOf):
        (JSC::DFG::AbstractHeap::isSubtypeOf):
        (JSC::DFG::AbstractHeap::overlaps):
        (JSC::DFG::AbstractHeap::isDisjoint):
        * dfg/DFGClobberize.cpp:
        (JSC::DFG::clobbersHeap):
        (JSC::DFG::clobbersWorld): Deleted.
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

2015-02-25  Ryosuke Niwa  <rniwa@webkit.org>

        REGRESSION(r180595): construct varargs fails in FTL
        https://bugs.webkit.org/show_bug.cgi?id=142030

        Reviewed by Geoffrey Garen.

        The bug was caused by IC size being too small for construct_varargs even though we've added a new argument.
        Fixed the bug by increasing the IC size to match call_varargs.

        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfConstructVarargs):

2015-02-25  Mark Lam  <mark.lam@apple.com>

        ASan does not like JSC::MachineThreads::tryCopyOtherThreadStack.
        <https://webkit.org/b/141672>

        Reviewed by Alexey Proskuryakov.

        ASan does not like the fact that we memcpy the stack for GC scans.  So,
        we're working around this by using our own memcpy (asanUnsafeMemcpy)
        implementation that we can tell ASan to ignore.

        * heap/MachineStackMarker.cpp:
        (JSC::asanUnsafeMemcpy):

2015-02-25  Benjamin Poulain  <bpoulain@apple.com>

        CodeBlock crashes when dumping op_push_name_scope
        https://bugs.webkit.org/show_bug.cgi?id=141953

        Reviewed by Filip Pizlo and Csaba Osztrogonác.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * tests/stress/op-push-name-scope-crashes-profiler.js: Added.

2015-02-25  Benjamin Poulain  <benjamin@webkit.org>

        Make ParserError immutable by design
        https://bugs.webkit.org/show_bug.cgi?id=141955

        Reviewed by Geoffrey Garen.

        This patch enforce that no field of ParserError can
        be modified after the constructor.

        * parser/ParserError.h:
        Move the attributes to pack the integer + 2 bytes together.
        This is irrelevant for memory impact, it is to remve a load-store
        when copying by value.

        Also move the attributes to be private.

        (JSC::ParserError::isValid):
        To client of the interface cared about the type of the error,
        the only information needed was: is there an error.

        (JSC::ParserError::ParserError):
        (JSC::ParserError::syntaxErrorType):
        (JSC::ParserError::token):
        (JSC::ParserError::message):
        (JSC::ParserError::line):
        (JSC::ParserError::toErrorObject):
        * API/JSScriptRef.cpp:
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createBuiltinExecutable):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::generateFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        (JSC::UnlinkedFunctionExecutable::codeBlockFor):
        * bytecode/UnlinkedCodeBlock.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::parse):
        * jsc.cpp:
        (runInteractive):
        * parser/Parser.h:
        (JSC::parse):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        * runtime/Completion.h:
        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::checkSyntax):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock):

2015-02-25  Filip Pizlo  <fpizlo@apple.com>

        Need to pass RTLD_DEEPBIND to dlopen() to ensure that our LLVMOverrides take effect on Linux
        https://bugs.webkit.org/show_bug.cgi?id=142006

        Reviewed by Csaba Osztrogonác.

        This fixes hard-to-reproduce concurrency-related crashes when running stress tests with FTL and
        concurrent JIT enabled.

        * llvm/InitializeLLVMPOSIX.cpp:
        (JSC::initializeLLVMPOSIX):

2015-02-24  Filip Pizlo  <fpizlo@apple.com>

        CMake build of libllvmForJSC.so should limit its export list like the Xcode build does
        https://bugs.webkit.org/show_bug.cgi?id=141989

        Reviewed by Gyuyoung Kim.

        * CMakeLists.txt:
        * llvm/library/libllvmForJSC.version: Added.

2015-02-24  Alexey Proskuryakov  <ap@apple.com>

        More iOS build fix after r180602.

        * heap/Heap.h: Export Heap::machineThreads().

2015-02-24  Brent Fulgham  <bfulgham@apple.com>

        Unreviewed build fix after r180602.

        * heap/MachineStackMarker.h: Add missing 'no return'
        declaration for Windows.

2015-02-24  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r180599.
        https://bugs.webkit.org/show_bug.cgi?id=141998

        Lots of new test failures (Requested by smfr on #webkit).

        Reverted changeset:

        "Parsing support for -webkit-trailing-word"
        https://bugs.webkit.org/show_bug.cgi?id=141939
        http://trac.webkit.org/changeset/180599

2015-02-24  Mark Lam  <mark.lam@apple.com>

        MachineThreads::Thread clean up has a use after free race condition.
        <https://webkit.org/b/141990>

        Reviewed by Michael Saboff.

        MachineThreads::Thread clean up relies on the clean up mechanism
        implemented in _pthread_tsd_cleanup_key(), which looks like this:

        void _pthread_tsd_cleanup_key(pthread_t self, pthread_key_t key)
        {
            void (*destructor)(void *);
            if (_pthread_key_get_destructor(key, &destructor)) {
                void **ptr = &self->tsd[key];
                void *value = *ptr;

                // At this point, this thread has cached "destructor" and "value"
                // (which is a MachineThreads*).  If the VM gets destructed (along
                // with its MachineThreads registry) by another thread, then this
                // thread will have no way of knowing that the MachineThreads* is
                // now pointing to freed memory.  Calling the destructor below will
                // therefore result in a use after free scenario when it tries to
                // access the MachineThreads' data members.

                if (value) {
                    *ptr = NULL;
                    if (destructor) {
                        destructor(value);
                    }
                }
            }
        }

        The solution is simply to change MachineThreads from a per VM thread
        registry to a process global singleton thread registry i.e. the
        MachineThreads registry is now immortal and we cannot have a use after
        free scenario since we never free it.

        The cost of this change is that all VM instances will have to scan
        stacks of all threads ever touched by a VM, and not just those that
        touched a specific VM.  However, stacks tend to be shallow.  Hence,
        those additional scans will tend to be cheap.

        Secondly, it is not common for there to be multiple JSC VMs in use
        concurrently on multiple threads.  Hence, this cost should rarely
        manifest in real world applications.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::machineThreads):
        (JSC::Heap::gatherStackRoots):
        * heap/Heap.h:
        (JSC::Heap::machineThreads): Deleted.
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThreads):
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::addCurrentThread):
        * heap/MachineStackMarker.h:
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):

2015-02-24  Myles C. Maxfield  <mmaxfield@apple.com>

        [Mac] [iOS] Parsing support for -apple-trailing-word
        https://bugs.webkit.org/show_bug.cgi?id=141939

        Reviewed by Andreas Kling.

        * Configurations/FeatureDefines.xcconfig:

2015-02-24  Ryosuke Niwa  <rniwa@webkit.org>

        Use "this" instead of "callee" to get the constructor
        https://bugs.webkit.org/show_bug.cgi?id=141019

        Reviewed by Filip Pizlo.

        This patch uses "this" register to pass the constructor (newTarget) to op_create_this from
        op_construct or op_construct_varargs. This will allow future patches that implement ES6 class
        to pass in the most derived class' constructor through "this" argument.

        BytecodeGenerator's emitConstruct and emitConstructVarargs now passes thisRegister like
        regular calls and emitCreateThis passes in this register to op_create_this as constructor.

        The rest of the code change removes the code for special casing "this" register not being used
        in call to construct.

        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCreateThis):
        (JSC::BytecodeGenerator::emitConstructVarargs):
        (JSC::BytecodeGenerator::emitConstruct):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::NewExprNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::emitArgumentPhantoms):
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::reconstruct):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * ftl/FTLJSCallVarargs.cpp:
        (JSC::FTL::JSCallVarargs::emit):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNativeCallOrConstruct):
        (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
        (JSC::FTL::LowerDFGToLLVM::compileCallOrConstructVarargs):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::executeConstruct):
        * jit/JITOperations.cpp:

2015-02-24  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Make Getter/Setter RemoteObject property and ObjectPreview handling consistent
        https://bugs.webkit.org/show_bug.cgi?id=141587

        Reviewed by Timothy Hatcher.

        Convert getProperties(ownAndGetterProperties) to getDisplayableProperties().
        Mark PropertyDescriptors that are presumed to be native getters / bindings
        separately so that the frontend may display them differently.

        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::getProperties):
        (Inspector::InjectedScript::getDisplayableProperties):
        * inspector/InjectedScript.h:
        * inspector/InjectedScriptSource.js:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::getProperties):
        (Inspector::InspectorRuntimeAgent::getDisplayableProperties):
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/protocol/Runtime.json:

2015-02-24  Mark Lam  <mark.lam@apple.com>

        Rolling out r179753.  The fix was invalid.
        <https://webkit.org/b/141990>

        Not reviewed.

        * API/tests/testapi.mm:
        (threadMain):
        (useVMFromOtherThread): Deleted.
        (useVMFromOtherThreadAndOutliveVM): Deleted.
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::~Heap):
        (JSC::Heap::gatherStackRoots):
        * heap/Heap.h:
        (JSC::Heap::machineThreads):
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::Thread::Thread):
        (JSC::MachineThreads::MachineThreads):
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::addCurrentThread):
        (JSC::MachineThreads::removeThread):
        (JSC::MachineThreads::removeCurrentThread):
        * heap/MachineStackMarker.h:

2015-02-24  Yusuke Suzuki  <utatane.tea@gmail.com>

        Constructor returning null should construct an object instead of null
        https://bugs.webkit.org/show_bug.cgi?id=141640

        Reviewed by Filip Pizlo.

        When constructor code doesn't return object, constructor should return `this` object instead.
        Since we used `op_is_object` for this check and `op_is_object` is intended to be used for `typeof`,
        it allows `null` as an object.
        This patch fixes it by introducing an new bytecode `op_is_object_or_null` for `typeof` use cases.
        Instead, constructor uses simplified `is_object`.

        As a result, `op_is_object` becomes fairly simple. So we introduce optimization for `op_is_object`.

        1. LLInt and baseline JIT support `op_is_object` as a fast path.
        2. DFG abstract interpreter support `op_is_object`. And recognize its speculated type and read-write effects.
        3. DFG introduces inlined asm for `op_is_object` rather than calling a C++ function.
        4. FTL lowers DFG's IsObject into LLVM IR.

        And at the same time, this patch fixes isString / isObject predicate used for `op_is_object` and others
        in LLInt, JIT, DFG and FTL.
        Before introducing ES6 Symbol, JSCell is only used for object and string in user observable area.
        So in many places, when the cell is not object, we recognize it as a string, and vice versa.
        However, now ES6 Symbol is implemented as a JSCell, this assumption is broken.
        So this patch stop using !isString as isObject.
        To check whether a cell is an object, instead of seeing that structure ID of a cell is not stringStructure,
        we examine typeInfo in JSCell.

        * JavaScriptCore.order:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitEqualityOp):
        (JSC::BytecodeGenerator::emitReturn):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):

        IsObject operation only touches JSCell typeInfoType.
        And this value would be changed through structure transition.
        As a result, IsObject can report that it doesn't read any information.

        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

        Just like IsString, IsObject is also fixed up.

        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
        (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
        (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
        (JSC::DFG::SpeculativeJIT::speculateObject):
        (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
        (JSC::DFG::SpeculativeJIT::speculateString):
        (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
        (JSC::DFG::SpeculativeJIT::emitSwitchChar):
        (JSC::DFG::SpeculativeJIT::emitSwitchString):
        (JSC::DFG::SpeculativeJIT::branchIsObject):
        (JSC::DFG::SpeculativeJIT::branchNotObject):
        (JSC::DFG::SpeculativeJIT::branchIsString):
        (JSC::DFG::SpeculativeJIT::branchNotString):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileToString):
        (JSC::FTL::LowerDFGToLLVM::compileIsObject):
        (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
        (JSC::FTL::LowerDFGToLLVM::speculateTruthyObject):
        (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
        (JSC::FTL::LowerDFGToLLVM::isObject):
        (JSC::FTL::LowerDFGToLLVM::isNotObject):
        (JSC::FTL::LowerDFGToLLVM::isNotString):
        (JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::emitJumpIfCellObject):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_object):
        (JSC::JIT::emit_op_to_primitive):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_object):
        (JSC::JIT::emit_op_to_primitive):
        (JSC::JIT::compileOpStrictEq):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * runtime/Operations.cpp:
        (JSC::jsIsObjectTypeOrNull):
        (JSC::jsIsObjectType): Deleted.
        * runtime/Operations.h:
        * tests/stress/constructor-with-return.js: Added.
        (Test):

        When constructor doesn't return an object, `this` should be returned instead.
        In this test, we check all primitives. And test object, array and wrappers.

        * tests/stress/dfg-to-primitive-pass-symbol.js: Added.
        (toPrimitiveTarget):
        (doToPrimitive):

        op_to_primitive operation passes Symbol in fast path.

2015-02-24  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION(r179429): Can't type comments in Facebook
        https://bugs.webkit.org/show_bug.cgi?id=141859

        Reviewed by Brent Fulgham.

        When window.Symbol is exposed to user-space pages,
        Facebook's JavaScript use it (maybe, for immutable-js and React.js's unique key).
        However, to work with Symbols completely, it also requires
        1) Object.getOwnPropertySymbols (for mixin including Symbols)
        2) the latest ES6 Iterator interface that uses Iterator.next and it returns { done: boolean, value: value }.
        Since they are not landed yet, comments in Facebook don't work.

        This patch introduces RuntimeFlags for JavaScriptCore.
        Specifying SymbolEnabled flag under test runner and inspector to continue to work with Symbol.
        And drop JavaScriptExperimentsEnabled flag
        because it is no longer used and use case of this is duplicated to runtime flags.

        * JavaScriptCore.order:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jsc.cpp:
        (GlobalObject::javaScriptRuntimeFlags):
        (GlobalObject::javaScriptExperimentsEnabled): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::finishCreation):
        (JSC::JSGlobalObject::javaScriptRuntimeFlags):
        (JSC::JSGlobalObject::javaScriptExperimentsEnabled): Deleted.
        * runtime/RuntimeFlags.h: Added.
        (JSC::RuntimeFlags::RuntimeFlags):
        (JSC::RuntimeFlags::createAllEnabled):

2015-02-23  Filip Pizlo  <fpizlo@apple.com>

        Our bizarre behavior on Arguments::defineOwnProperty should be deliberate rather than a spaghetti incident
        https://bugs.webkit.org/show_bug.cgi?id=141951

        Reviewed by Benjamin Poulain.
        
        This patch has no behavioral change, but it simplifies a bunch of wrong code. The code is
        still wrong in exactly the same way, but at least it's obvious what's going on. The wrongness
        is covered by this bug: https://bugs.webkit.org/show_bug.cgi?id=141952.

        * runtime/Arguments.cpp:
        (JSC::Arguments::copyBackingStore): We should only see the arguments token; assert otherwise. This works because if the GC sees the butterfly token it calls the JSObject::copyBackingStore method directly.
        (JSC::Arguments::defineOwnProperty): Make our bizarre behavior deliberate rather than an accident of a decade of patches.
        * tests/stress/arguments-bizarre-behavior.js: Added.
        (foo):
        * tests/stress/arguments-bizarre-behaviour-disable-enumerability.js: Added. My choice of spellings of the word "behavio[u]r" is almost as consistent as our implementation of arguments.
        (foo):
        * tests/stress/arguments-custom-properties-gc.js: Added. I added this test because at first I was unsure if we GCd arguments correctly.
        (makeBaseArguments):
        (makeArray):
        (cons):

2015-02-23  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r180547 and r180550.
        https://bugs.webkit.org/show_bug.cgi?id=141957

        Broke 10 Windows tests. (Requested by bfulgham_ on #webkit).

        Reverted changesets:

        "REGRESSION(r179429): Can't type comments in Facebook"
        https://bugs.webkit.org/show_bug.cgi?id=141859
        http://trac.webkit.org/changeset/180547

        "Constructor returning null should construct an object instead
        of null"
        https://bugs.webkit.org/show_bug.cgi?id=141640
        http://trac.webkit.org/changeset/180550

2015-02-23  Yusuke Suzuki  <utatane.tea@gmail.com>

        Constructor returning null should construct an object instead of null
        https://bugs.webkit.org/show_bug.cgi?id=141640

        Reviewed by Geoffrey Garen.

        When constructor code doesn't return object, constructor should return `this` object instead.
        Since we used `op_is_object` for this check and `op_is_object` is intended to be used for `typeof`,
        it allows `null` as an object.
        This patch fixes it by introducing an new bytecode `op_is_object_or_null` for `typeof` use cases.
        Instead, constructor uses simplified `is_object`.

        As a result, `op_is_object` becomes fairly simple. So we introduce optimization for `op_is_object`.

        1. LLInt and baseline JIT support `op_is_object` as a fast path.
        2. DFG abstract interpreter support `op_is_object`. And recognize its speculated type and read-write effects.
        3. DFG introduces inlined asm for `op_is_object` rather than calling a C++ function.
        4. FTL lowers DFG's IsObject into LLVM IR.

        And at the same time, this patch fixes isString / isObject predicate used for `op_is_object` and others
        in LLInt, JIT, DFG and FTL.
        Before introducing ES6 Symbol, JSCell is only used for object and string in user observable area.
        So in many places, when the cell is not object, we recognize it as a string, and vice versa.
        However, now ES6 Symbol is implemented as a JSCell, this assumption is broken.
        So this patch stop using !isString as isObject.
        To check whether a cell is an object, instead of seeing that structure ID of a cell is not stringStructure,
        we examine typeInfo in JSCell.

        * JavaScriptCore.order:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitEqualityOp):
        (JSC::BytecodeGenerator::emitReturn):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):

        IsObject operation only touches JSCell typeInfoType.
        And this value would not be changed through structure transition.
        As a result, IsObject can report that it doesn't read any information.

        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

        Just like IsString, IsObject is also fixed up.

        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
        (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
        (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
        (JSC::DFG::SpeculativeJIT::speculateObject):
        (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
        (JSC::DFG::SpeculativeJIT::speculateString):
        (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
        (JSC::DFG::SpeculativeJIT::emitSwitchChar):
        (JSC::DFG::SpeculativeJIT::emitSwitchString):
        (JSC::DFG::SpeculativeJIT::branchIsObject):
        (JSC::DFG::SpeculativeJIT::branchNotObject):
        (JSC::DFG::SpeculativeJIT::branchIsString):
        (JSC::DFG::SpeculativeJIT::branchNotString):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileToString):
        (JSC::FTL::LowerDFGToLLVM::compileIsObject):
        (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
        (JSC::FTL::LowerDFGToLLVM::speculateTruthyObject):
        (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
        (JSC::FTL::LowerDFGToLLVM::isObject):
        (JSC::FTL::LowerDFGToLLVM::isNotObject):
        (JSC::FTL::LowerDFGToLLVM::isNotString):
        (JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::emitJumpIfCellObject):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_object):
        (JSC::JIT::emit_op_to_primitive):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_object):
        (JSC::JIT::emit_op_to_primitive):
        (JSC::JIT::compileOpStrictEq):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * runtime/Operations.cpp:
        (JSC::jsIsObjectTypeOrNull):
        (JSC::jsIsObjectType): Deleted.
        * runtime/Operations.h:

2015-02-23  Ryosuke Niwa  <rniwa@webkit.org>

        Disable font loading events until our implementation gets updated to match the latest spec
        https://bugs.webkit.org/show_bug.cgi?id=141938

        Reviewed by Andreas Kling.

        * Configurations/FeatureDefines.xcconfig:

2015-02-23  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION(r179429): Can't type comments in Facebook
        https://bugs.webkit.org/show_bug.cgi?id=141859

        Reviewed by Geoffrey Garen.

        When window.Symbol is exposed to user-space pages,
        Facebook's JavaScript use it (maybe, for immutable-js and React.js's unique key).
        However, to work with Symbols completely, it also requires
        1) Object.getOwnPropertySymbols (for mixin including Symbols)
        2) the latest ES6 Iterator interface that uses Iterator.next and it returns { done: boolean, value: value }.
        Since they are not landed yet, comments in Facebook don't work.

        This patch introduces RuntimeFlags for JavaScriptCore.
        Specifying SymbolEnabled flag under test runner and inspector to continue to work with Symbol.
        And drop JavaScriptExperimentsEnabled flag
        because it is no longer used and use case of this is duplicated to runtime flags.

        * JavaScriptCore.order:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jsc.cpp:
        (GlobalObject::javaScriptRuntim