2016-08-22  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Module should not allow HTML comments
        https://bugs.webkit.org/show_bug.cgi?id=161041

        Reviewed by Saam Barati.

        ES6 Modules intentionally disable HTML comments[1].

        [1]: https://tc39.github.io/ecma262/#sec-html-like-comments

        * API/JSScriptRef.cpp:
        (parseScript):
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutable):
        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::CacheKey::CacheKey):
        * bytecode/ExecutableInfo.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::commentMode):
        (JSC::ExecutableInfo::superBinding): Deleted.
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::commentMode):
        (JSC::UnlinkedCodeBlock::superBinding): Deleted.
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::commentMode):
        (JSC::BytecodeGenerator::makeFunction):
        (JSC::BytecodeGenerator::superBinding): Deleted.
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::Lexer):
        (JSC::Lexer<T>::lex):
        * parser/Lexer.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        * parser/Parser.h:
        (JSC::parse):
        * parser/ParserModes.h:
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeFlags::SourceCodeFlags):
        (JSC::SourceCodeKey::SourceCodeKey):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        (JSC::checkModuleSyntax):
        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::checkSyntax):
        * runtime/Executable.h:
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeParseModule):

2016-08-21  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG] Should not fixup AnyIntUse in 32_64
        https://bugs.webkit.org/show_bug.cgi?id=161029

        Reviewed by Saam Barati.

        DFG fixup phase uses AnyIntUse even in 32bit DFG. This patch removes this incorrect filtering.
        If the 32bit DFG see the TypeAnyInt, it should fallback to the NumberUse case.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

2016-08-21  Yusuke Suzuki  <utatane.tea@gmail.com>

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

        32bit is OK. DFGSpeculativeJIT64.cpp shortcut also need some cares.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

2016-08-21  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG] Should not fixup AnyIntUse in 32_64
        https://bugs.webkit.org/show_bug.cgi?id=161029

        Reviewed by Saam Barati.

        DFG fixup phase uses AnyIntUse even in 32bit DFG. This patch removes this incorrect filtering.
        If the 32bit DFG see the TypeAnyInt, it should fallback to the NumberUse case.

        And this patch also fixes the case that the type set only contains TypeNumber. Previously,
        we used NumberUse edge filtering. But it misses AnyInt logging: While the NumberUse filter
        passes both TypeAnyInt and TypeNumber, the type set only logged TypeNumber.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

2016-08-20  Brian Burg  <bburg@apple.com>

        Remote Inspector: some methods don't need to be marked virtual anymore
        https://bugs.webkit.org/show_bug.cgi?id=161033

        Reviewed by Darin Adler.

        This probably happened when this code was last refactored and moved around.

        * inspector/remote/RemoteConnectionToTarget.h:

2016-08-19  Sam Weinig  <sam@webkit.org>

        Location.ancestorOrigins should return a FrozenArray<USVString>
        https://bugs.webkit.org/show_bug.cgi?id=161018

        Reviewed by Ryosuke Niwa and Chris Dumez.

        * runtime/ObjectConstructor.h:
        (JSC::objectConstructorFreeze):
        Export objectConstructorFreeze so it can be used to freeze DOM FrozenArrays.

2016-08-19  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] ArithSqrt should work with any argument type
        https://bugs.webkit.org/show_bug.cgi?id=160954

        Reviewed by Saam Barati.

        Previsouly, ArithSqrt would always OSR Exit if the argument
        is not typed Integer, Double, or Boolean.
        Since we can't recover by generalizing to those, we continuously
        OSR Exit and recompile the same code over and over again.

        This patch introduces a fallback to handle the remaining types.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

        * dfg/DFGMayExit.cpp:
        This is somewhat unrelated. While discussing the design of this
        with Filip, we decided not to use ToNumber+ArithSqrt despite
        the guarantee that ToNumber does not OSR Exit.
        Since it does not OSR Exit, we should say so in mayExitImpl().

        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithSqrt):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArithSqrt):

2016-08-19  Joseph Pecoraro  <pecoraro@apple.com>

        Make custom Error properties (line, column, sourceURL) configurable and writable
        https://bugs.webkit.org/show_bug.cgi?id=160984
        <rdar://problem/27905979>

        Reviewed by Saam Barati.

        * runtime/Error.cpp:
        (JSC::addErrorInfoAndGetBytecodeOffset):
        (JSC::addErrorInfo):

2016-08-19  Joseph Pecoraro  <pecoraro@apple.com>

        Remove empty files and empty namespace blocks
        https://bugs.webkit.org/show_bug.cgi?id=160990

        Reviewed by Alex Christensen.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/ValueProfile.cpp: Removed.
        * runtime/WatchdogMac.cpp: Removed.
        * runtime/WatchdogNone.cpp: Removed.

        * runtime/StringIteratorPrototype.cpp:
        Remove empty namespace block.

        * runtime/JSDestructibleObject.h:
        Drive-by add missing copyright.

2016-08-19  Per Arne Vollan  <pvollan@apple.com>

        [Win] Warning fix.
        https://bugs.webkit.org/show_bug.cgi?id=160995

        Avoid setting unknown compile option on source file.

        Reviewed by Anders Carlsson.

        * CMakeLists.txt:

2016-08-18  Mark Lam  <mark.lam@apple.com>

        ScopedArguments is using the wrong owner object for a write barrier.
        https://bugs.webkit.org/show_bug.cgi?id=160976
        <rdar://problem/27328506>

        Reviewed by Keith Miller.

        * runtime/ScopedArguments.h:
        (JSC::ScopedArguments::setIndexQuickly):

2016-08-18  Mark Lam  <mark.lam@apple.com>

        Add LLINT probe() macro for X86_64.
        https://bugs.webkit.org/show_bug.cgi?id=160968

        Reviewed by Geoffrey Garen.

        * llint/LowLevelInterpreter.asm:

2016-08-18  Mark Lam  <mark.lam@apple.com>

        Remove unused SlotVisitor::append() variant.
        https://bugs.webkit.org/show_bug.cgi?id=160961

        Reviewed by Saam Barati.

        * heap/SlotVisitor.h:
        * jit/JITWriteBarrier.h:
        (JSC::JITWriteBarrier::get):
        (JSC::SlotVisitor::append): Deleted.

2016-08-18  Saam Barati  <sbarati@apple.com>

        Make @Array(size) a bytecode intrinsic
        https://bugs.webkit.org/show_bug.cgi?id=160867

        Reviewed by Mark Lam.

        There were a few places in the code where we were emitting `@Array(size)`
        or `new @Array(size)`. Since we have a bytecode operation that already
        represents this, called new_array_with_size, it's faster to just make a
        bytecode intrinsic for the this operation. This patch does that and
        the intrinsic is called `@newArrayWithSize`. This might be around a
        1% speedup on ES6 sample bench, but it's within the noise. This is just
        a good bytecode operation to have because it's common enough to
        create arrays and it's good to make that fast in all tiers.

        * builtins/ArrayConstructor.js:
        (of):
        (from):
        * builtins/ArrayPrototype.js:
        (filter):
        (map):
        (sort.stringSort):
        (sort):
        (concatSlowPath):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_isObject):
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_newArrayWithSize):

2016-08-18  Rawinder Singh  <rawinder.singh-webkit@cisra.canon.com.au>

        [web-animations] Add Animatable, AnimationEffect, KeyframeEffect and Animation interface
        https://bugs.webkit.org/show_bug.cgi?id=156096

        Reviewed by Dean Jackson.

        Adds:
        - Animatable interface and implementation of getAnimations in Element.
        - Interface and implementation for Document getAnimations method.
        - AnimationEffect interface and class stub.
        - KeyframeEffect interface and constructor implementation.
        - 'Animation' interface, constructor and query methods for effect and timeline.
        - Remove runtime condition on Web animation interfaces (compile time flag is specified).

        * runtime/CommonIdentifiers.h:

2016-08-17  Keith Miller  <keith_miller@apple.com>

        Add WASM support for i64 simple opcodes.
        https://bugs.webkit.org/show_bug.cgi?id=160928

        Reviewed by Michael Saboff.

        This patch also removes the unsigned int32 mod operator, which is not supported by B3 yet.

        * wasm/WASMB3IRGenerator.cpp:
        (JSC::WASM::toB3Op):
        (JSC::WASM::B3IRGenerator::unaryOp):
        * wasm/WASMFunctionParser.h:
        (JSC::WASM::WASMFunctionParser<Context>::parseExpression):
        * wasm/WASMOps.h:

2016-08-17  JF Bastien  <jfbastien@apple.com>

        We allow assignments to const variables when in a for-in/for-of loop
        https://bugs.webkit.org/show_bug.cgi?id=156673

        Reviewed by Filip Pizlo.

        for-in and for-of weren't checking whether iteration variable from
        parent scopes were const. Assigning to such variables should
        throw, but used not to.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForOfNode::emitBytecode):

2016-08-17  Geoffrey Garen  <ggaren@apple.com>

        Fixed a potential bug in MarkedArgumentBuffer.
        https://bugs.webkit.org/show_bug.cgi?id=160948
        <rdar://problem/27889416>

        Reviewed by Oliver Hunt.

        I haven't been able to produce an observable test case after some trying.

        * runtime/ArgList.cpp:
        (JSC::MarkedArgumentBuffer::addMarkSet): New helper function -- I broke
        this out from existing code for clarity, but the behavior is the same.

        (JSC::MarkedArgumentBuffer::expandCapacity): Ditto.

        (JSC::MarkedArgumentBuffer::slowAppend): Always addMarkSet() on the slow
        path. This is faster than the old linear scan, and I think it might
        avoid cases the old scan could miss.

        * runtime/ArgList.h:
        (JSC::MarkedArgumentBuffer::append): Account for the case where someone
        has called clear() or removeLast().

        (JSC::MarkedArgumentBuffer::mallocBase): No behavior change -- but it's
        clearer to test the buffers directly instead of inferring what they
        might be based on capacity.

2016-08-17  Mark Lam  <mark.lam@apple.com>

        Remove an invalid assertion in the DFG backend's GetById emitter.
        https://bugs.webkit.org/show_bug.cgi?id=160925
        <rdar://problem/27248961>

        Reviewed by Filip Pizlo.

        The DFG backend's GetById assertion that the node's prediction not be SpecNone
        is just plain wrong.  It assumes that we can never have a GetById node without a
        type prediction, but this is not true.  The following test case proves otherwise:

            function foo() {
                "use strict";
                return --arguments["callee"];
            }

        Will remove the assertion.  Nothing else needs to change as the DFG is working
        correctly without the assertion.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2016-08-16  Mark Lam  <mark.lam@apple.com>

        Heap::collectAllGarbage() should work with JSC_useImmortalObjects=true.
        https://bugs.webkit.org/show_bug.cgi?id=160917

        Reviewed by Filip Pizlo.

        If we do an synchronous GC when JSC_useImmortalObjects=true, we'll get a
        RELEASE_ASSERT failure:

            $ JSC_useImmortalObjects=true jsc
            >>> gc()
            Trace/BPT trap: 5

        This is because Heap::collectAllGarbage() is doing an explicit sweep of the
        MarkedSpace, and the sweeper is expecting to see no RetiredBlocks.  However, we
        make objects immortal by retiring their blocks.  As a result, there is a mismatch
        in expectancy.

        The fix is simply to not run the sweeper when JSC_useImmortalObjects=true.

        * heap/Heap.cpp:
        (JSC::Heap::collectAllGarbage):

2016-08-16  Keith Miller  <keith_miller@apple.com>

        Add WASM I32 simple operators.
        https://bugs.webkit.org/show_bug.cgi?id=160914

        Reviewed by Benjamin Poulain.

        This patch adds support for the i32 simple binary operators.

        * wasm/WASMB3IRGenerator.cpp:
        (JSC::WASM::toB3Op):
        (JSC::WASM::B3IRGenerator::binaryOp):
        * wasm/WASMFunctionParser.h:
        (JSC::WASM::WASMFunctionParser<Context>::parseExpression):
        * wasm/WASMOps.h:

2016-08-15  Ryosuke Niwa  <rniwa@webkit.org>

        Conversion to sequence<T> is broken for iterable objects
        https://bugs.webkit.org/show_bug.cgi?id=160801

        Reviewed by Darin Adler.

        Export functions used to iterate over iterable objects.

        * runtime/IteratorOperations.h:
        (JSC::forEachInIterable):

2016-08-15  Benjamin Poulain  <bpoulain@apple.com>

        [Regression 204203-204210] 32-bit ASSERTION FAILED: !m_data[index].name.isValid()
        https://bugs.webkit.org/show_bug.cgi?id=160881

        Reviewed by Mark Lam.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        We were trying to set the result of the Identity node to the same
        value as the source of the Identity.
        That is pretty messed up.

2016-08-15  Saam Barati  <sbarati@apple.com>

        Web Inspector: Introduce a method to enable code coverage profiler without enabling type profiler
        https://bugs.webkit.org/show_bug.cgi?id=160750
        <rdar://problem/27793469>

        Reviewed by Joseph Pecoraro.

        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::disableTypeProfiler):
        (Inspector::InspectorRuntimeAgent::enableControlFlowProfiler):
        (Inspector::InspectorRuntimeAgent::disableControlFlowProfiler):
        (Inspector::InspectorRuntimeAgent::setTypeProfilerEnabledState):
        (Inspector::InspectorRuntimeAgent::setControlFlowProfilerEnabledState):
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/protocol/Runtime.json:

2016-08-15  Saam Barati  <sbarati@apple.com>

        Array.prototype.map builtin should go on the fast path when constructor===@Array
        https://bugs.webkit.org/show_bug.cgi?id=160836

        Reviewed by Keith Miller.

        In the FTL, we were not compiling the result array in Array.prototype.map
        efficiently when the result array should use the Array constructor
        (which is the common case). We used to compile it as:
        x: JSConstant(Array)
        y: Construct(@x, ...)
        instead of
        y: NewArrayWithSize(...)

        This patch changes the builtin to go down the fast path when certain
        conditions are met. Often, the check to go down the fast path will
        be constant folded because we always create a normal array from the
        Array constructor.

        This is around a 5% speedup on ES6 Sample Bench.

        I also made similar changes for Array.prototype.filter
        and Array.prototype.concat on its slow path.

        * builtins/ArrayPrototype.js:

2016-08-15  Mark Lam  <mark.lam@apple.com>

        Make JSValue::strictEqual() handle failures to resolve JSRopeStrings.
        https://bugs.webkit.org/show_bug.cgi?id=160832
        <rdar://problem/27577556>

        Reviewed by Geoffrey Garen.

        Currently, JSValue::strictEqualSlowCaseInline() (and peers) will blindly try to
        access the StringImpl of a JSRopeString that fails to resolve its rope.  As a
        result, we'll crash with null pointer dereferences.

        We can fix this by introducing a JSString::equal() method that will do the
        equality comparison, but is aware of the potential failures to resolve ropes.
        JSValue::strictEqualSlowCaseInline() (and peers) will now call JSString::equal()
        instead of accessing the underlying StringImpl directly.

        Also added some exception checks.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/JITOperations.cpp:
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncIndexOf):
        (JSC::arrayProtoFuncLastIndexOf):
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::equalSlowCaseInline):
        (JSC::JSValue::strictEqualSlowCaseInline):
        * runtime/JSString.cpp:
        (JSC::JSString::equalSlowCase):
        * runtime/JSString.h:
        * runtime/JSStringInlines.h: Added.
        (JSC::JSString::equal):

2016-08-15  Keith Miller  <keith_miller@apple.com>

        Implement WASM Parser and B3 IR generator
        https://bugs.webkit.org/show_bug.cgi?id=160681

        Reviewed by Benjamin Poulain.

        This patch adds the skeleton for a WebAssembly pipeline. The
        pipeline is designed in order to make it easy to have as much of
        the compilation process threaded as possible. The flow of the
        pipeline roughly goes as follows:

        1) Create a WASMPlan with the VM and a Vector of the
        assembly. Currently the plan will process all the work
        synchronously, however, in the future this can be offloaded to
        other threads.

        2) The plan will run the WASMModuleParser, which collates all the
        information needed to compile each module function
        independently. Since, we are still in the early phases, the only
        information is the starting and ending byte of the function's
        body. The module parser, however, still scans both and
        semi-validates the type and the function sections.

        3) Each function is decoded and compiled. In the future this
        should also include a opcode validation phase. The
        WASMFunctionParser is templatized so that a validator should be
        able to use most of the same code the B3 IR generator does.

        4) When the plan has finished it will fill a Vector of
        B3::Compilation objects that correspond to the respective function
        in the WASM module.


        The current testing plan for the modules is to inline the the
        binary generated by the spec's OCaml prototype. The inlined binary
        is passed to a WASMPlan then invoked to check the result of the
        function. In the future we should add a more robust testing
        infrastructure.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * testWASM.cpp:
        (printUsageStatement):
        (CommandLine::parseArguments):
        (invoke):
        (runWASMTests):
        (main):
        * wasm/JSWASMModule.h:
        (JSC::JSWASMModule::globalVariableTypes):
        * wasm/WASMB3IRGenerator.cpp: Added.
        (JSC::WASM::B3IRGenerator::B3IRGenerator):
        (JSC::WASM::B3IRGenerator::addLocal):
        (JSC::WASM::B3IRGenerator::binaryOp):
        (JSC::WASM::B3IRGenerator::addConstant):
        (JSC::WASM::B3IRGenerator::addBlock):
        (JSC::WASM::B3IRGenerator::endBlock):
        (JSC::WASM::B3IRGenerator::addReturn):
        (JSC::WASM::B3IRGenerator::unify):
        (JSC::WASM::B3IRGenerator::initializeIncommingTypes):
        (JSC::WASM::B3IRGenerator::unifyValuesWithLevel):
        (JSC::WASM::B3IRGenerator::stackForControlLevel):
        (JSC::WASM::B3IRGenerator::blockForControlLevel):
        (JSC::WASM::parseAndCompile):
        * wasm/WASMB3IRGenerator.h: Copied from Source/WTF/wtf/DataLog.h.
        * wasm/WASMFormat.h:
        * wasm/WASMFunctionParser.h: Added.
        (JSC::WASM::WASMFunctionParser<Context>::WASMFunctionParser):
        (JSC::WASM::WASMFunctionParser<Context>::parse):
        (JSC::WASM::WASMFunctionParser<Context>::parseBlock):
        (JSC::WASM::WASMFunctionParser<Context>::parseExpression):
        * wasm/WASMModuleParser.cpp: Added.
        (JSC::WASM::WASMModuleParser::parse):
        (JSC::WASM::WASMModuleParser::parseFunctionTypes):
        (JSC::WASM::WASMModuleParser::parseFunctionSignatures):
        (JSC::WASM::WASMModuleParser::parseFunctionDefinitions):
        * wasm/WASMModuleParser.h: Copied from Source/WTF/wtf/DataLog.h.
        (JSC::WASM::WASMModuleParser::WASMModuleParser):
        (JSC::WASM::WASMModuleParser::functionInformation):
        * wasm/WASMOps.h: Copied from Source/WTF/wtf/DataLog.h.
        * wasm/WASMParser.h: Added.
        (JSC::WASM::WASMParser::parseVarUInt32):
        (JSC::WASM::WASMParser::WASMParser):
        (JSC::WASM::WASMParser::consumeCharacter):
        (JSC::WASM::WASMParser::consumeString):
        (JSC::WASM::WASMParser::parseUInt32):
        (JSC::WASM::WASMParser::parseUInt7):
        (JSC::WASM::WASMParser::parseVarUInt1):
        (JSC::WASM::WASMParser::parseValueType):
        * wasm/WASMPlan.cpp: Copied from Source/WTF/wtf/DataLog.h.
        (JSC::WASM::Plan::Plan):
        * wasm/WASMPlan.h: Copied from Source/WTF/wtf/DataLog.h.
        * wasm/WASMSections.cpp: Copied from Source/WTF/wtf/DataLog.h.
        (JSC::WASM::WASMSections::lookup):
        * wasm/WASMSections.h: Copied from Source/WTF/wtf/DataLog.h.
        (JSC::WASM::WASMSections::validateOrder):

2016-08-15  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] B3 Neg opcode should support float
        https://bugs.webkit.org/show_bug.cgi?id=160795

        Reviewed by Geoffrey Garen.

        This is required to implement WASM f32.neg opcode.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::negateFloat):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3ReduceDoubleToFloat.cpp:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testNegDouble):
        (JSC::B3::testNegFloat):
        (JSC::B3::testNegFloatWithUselessDoubleConversion):
        (JSC::B3::run):

2016-08-15  Joseph Pecoraro  <pecoraro@apple.com>

        Use #pragma once in inspector headers
        https://bugs.webkit.org/show_bug.cgi?id=160861

        Reviewed by Mark Lam.

        * inspector/*.h:

2016-08-15  Daniel Bates  <dabates@apple.com>

        Cannot build WebKit for iOS device using Xcode 7.3/iOS 9.3 public SDK due to missing
        private frameworks and libraries
        https://bugs.webkit.org/show_bug.cgi?id=155931
        <rdar://problem/25807989>

        Reviewed by Dan Bernstein.

        Add directory WebKitLibraries/WebKitPrivateFrameworkStubs/iOS/X to the framework search path
        where X is the major version of the active iOS SDK.

        * Configurations/Base.xcconfig:

2016-08-15  Joseph Pecoraro  <pecoraro@apple.com>

        Reduce includes of Debugger.h
        https://bugs.webkit.org/show_bug.cgi?id=160827

        Reviewed by Mark Lam.

        * API/JSTypedArray.cpp:
        * bytecode/UnlinkedCodeBlock.h:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        * dfg/DFGPlan.cpp:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        * dfg/DFGSpeculativeJIT64.cpp:
        * ftl/FTLJITCode.h:
        * inspector/ScriptCallStackFactory.cpp:
        * inspector/agents/InspectorDebuggerAgent.h:
        * jit/JITOpcodes.cpp:
        * jit/JITOpcodes32_64.cpp:
        * jit/JITOperations.cpp:
        * llint/LLIntOffsetsExtractor.cpp:
        * parser/Nodes.cpp:
        * parser/Parser.cpp:
        * parser/Parser.h:
        * runtime/Completion.cpp:
        * runtime/Executable.cpp:
        * runtime/Executable.h:
        * runtime/FunctionConstructor.cpp:
        * runtime/SamplingProfiler.cpp:
        * runtime/SamplingProfiler.h:
        * runtime/VMEntryScope.cpp:

2016-08-15  Joseph Pecoraro  <pecoraro@apple.com>

        Remove unused includes of wtf headers
        https://bugs.webkit.org/show_bug.cgi?id=160839

        Reviewed by Alex Christensen.

        * Lots of files.

2016-08-13  Per Arne Vollan  <pvollan@apple.com>

        [Win] Warning fixes.
        https://bugs.webkit.org/show_bug.cgi?id=160803

        Reviewed by Brent Fulgham.

        Initialize local variables.

        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * runtime/Error.cpp:
        (JSC::addErrorInfoAndGetBytecodeOffset):

2016-08-12  Joseph Pecoraro  <pecoraro@apple.com>

        Remove always true JSC::Debugger::needPauseHandling virtual method
        https://bugs.webkit.org/show_bug.cgi?id=160822

        Reviewed by Mark Lam.

        All subclasses return true for this method. Just remove the method.

        * debugger/Debugger.cpp:
        (JSC::Debugger::pauseIfNeeded):
        * inspector/ScriptDebugServer.h:

2016-08-12  Saam Barati  <sbarati@apple.com>

        Inline store loop for CopyRest in DFG and FTL for certain array modes
        https://bugs.webkit.org/show_bug.cgi?id=159612

        Reviewed by Filip Pizlo.

        This patch changes the old copy_rest bytecode to actually allocate the rest array itself.
        The bytecode is now called create_rest with an analogous CreateRest node in the DFG/FTL.
        This allows the bytecode to be in control of what type of indexingType the array is allocated
        with. We always allocate using ArrayWithContiguous storage unless we're havingABadTime().
        This also makes allocating and writing into the array fast. On the fast path, the DFG/FTL
        JIT will fast allocate the array and its storage, and we will do a memmove from the rest
        region of arguments into the array's storage.

        I'm seeing a 1-2% speedup on ES6SampleBench, and about a 2x speedup
        on micro benchmarks that just test rest creation speed.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitRestParameter):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
        (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator):
        * 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/DFGGraph.h:
        (JSC::DFG::Graph::uses):
        (JSC::DFG::Graph::isWatchingHavingABadTimeWatchpoint):
        (JSC::DFG::Graph::compilation):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::numberOfArgumentsToSkip):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
        (JSC::DFG::SpeculativeJIT::compileCreateRest):
        (JSC::DFG::SpeculativeJIT::compileGetRestLength):
        (JSC::DFG::SpeculativeJIT::compileCopyRest): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileArithRandom):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileArithRandom):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateClonedArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateRest):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetRestLength):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer):
        (JSC::FTL::DFG::LowerDFGToB3::compileAllocateArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileCopyRest): Deleted.
        * interpreter/CallFrame.h:
        (JSC::ExecState::addressOfArgumentsStart):
        (JSC::ExecState::argument):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_argument_count):
        (JSC::JIT::emit_op_create_rest):
        (JSC::JIT::emit_op_copy_rest): Deleted.
        * jit/JITOperations.h:
        * llint/LowLevelInterpreter.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:

2016-08-12  Ryosuke Niwa  <rniwa@webkit.org>

        Add a helper class for enumerating elements in an iterable object
        https://bugs.webkit.org/show_bug.cgi?id=160800

        Reviewed by Benjamin Poulain.

        Added iteratorForIterable which provides an abstraction for iterating over an iterable object,
        and deployed it in the constructors of Set, WeakSet, Map, and WeakMap.

        Also added a helper function iteratorForIterable, which retrieves the iterator out of an iterable object.

        * runtime/IteratorOperations.cpp:
        (JSC::iteratorForIterable): Added.
        * runtime/IteratorOperations.h:
        (JSC::forEachInIterable): Added.
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):
        * runtime/WeakMapConstructor.cpp:
        (JSC::constructWeakMap):
        * runtime/WeakSetConstructor.cpp:
        (JSC::constructWeakSet):

2016-08-12  Joseph Pecoraro  <pecoraro@apple.com>

        Remove unused includes of RefCountedLeakCounter.h
        https://bugs.webkit.org/show_bug.cgi?id=160817

        Reviewed by Mark Lam.

        * parser/Nodes.cpp:
        * runtime/Structure.cpp:

2016-08-12  Pranjal Jumde  <pjumde@apple.com>

        ASSERTION FAILED: : line >= firstLine in BytecodeGenerator::emitExpressionInfo.
        https://bugs.webkit.org/show_bug.cgi?id=160535
        <rdar://problem/27328151>
        
        Reviewed by Saam Barati.

        lineNumber from the savePoint was not being restored before calling next() causing discrepancy in the offset and line for the token

        * parser/Parser.h:
        (JSC::Parser::restoreLexerState):

2016-08-12  Skachkov Oleksandr  <gskachkov@gmail.com>

        [ES2016] Implement Object.entries
        https://bugs.webkit.org/show_bug.cgi?id=160412

        Reviewed by Saam Barati.

        This patch adds entries function to Object that returns list of 
        key+values pairs. Patch did according to the point of
        spec https://tc39.github.io/ecma262/#sec-object.entries

        * builtins/ObjectConstructor.js:
        (globalPrivate.enumerableOwnProperties):
        (entries):
        * runtime/ObjectConstructor.cpp:

2016-08-11  Mark Lam  <mark.lam@apple.com>

        OverridesHasInstance should not branch across register allocations.
        https://bugs.webkit.org/show_bug.cgi?id=160792
        <rdar://problem/27361778>

        Reviewed by Benjamin Poulain.

        The OverrideHasInstance node has a branch test that is emitted conditionally.
        It also has a bug where it allocated a register after this branch, which is not
        allowed and would fail an assertion introduced in https://trac.webkit.org/r145931.
        From the ChangeLog for r145931:

        "This [assertion that register allocations are not branched around] protects
        against the case where an allocation could have spilled register contents to free
        up a register and that spill only occurs on one path of many through the code.
        A subsequent fill of the spilled register may load garbage."

        Because the branch isn't always emitted, this bug has gone unnoticed until now.
        This patch fixes this issue by pre-allocating the registers before emitting the
        branch in OverrideHasInstance.

        Note: this issue is only present in DFGSpeculativeJIT64.cpp.  The 32-bit version
        is doing it right.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2016-08-11  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Make B3 Return opcode work without arguments
        https://bugs.webkit.org/show_bug.cgi?id=160787

        Reviewed by Keith Miller.

        We need a way to create functions that do not return values.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::retVoid):
        * b3/B3BasicBlock.cpp:
        (JSC::B3::BasicBlock::appendNewControlValue):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Validate.cpp:
        * b3/B3Value.h:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testReturnVoid):
        (JSC::B3::run):

2016-08-11  Mark Lam  <mark.lam@apple.com>

        Gardening: fix gcc builds after r204387. 

        Not reviewed.

        Apparently, gcc is not sophisticated enough to realize that the end of the
        function is unreachable, and is wrongly complaining about "control reaches end of
        non-void function".  I'm restoring the RELEASE_ASSERT_NOT_REACHED() and return
        statement at the end of MarkedBlock::sweepHelper() to appease gcc.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::sweepHelper):

2016-08-11  Alex Christensen  <achristensen@webkit.org>

        Use StringBuilder::appendLiteral when possible don't append result of makeString
        https://bugs.webkit.org/show_bug.cgi?id=160772

        Reviewed by Sam Weinig.

        * API/tests/ExecutionTimeLimitTest.cpp:
        (testExecutionTimeLimit):
        * API/tests/PingPongStackOverflowTest.cpp:
        (PingPongStackOverflowObject_hasInstance):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrayPatternNode::toString):
        (JSC::RestParameterNode::toString):
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::sanitizedToString):
        * runtime/Options.cpp:
        (JSC::Options::dumpOption):

2016-08-11  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Revert most of r203808
        https://bugs.webkit.org/show_bug.cgi?id=160784

        Reviewed by Geoffrey Garen.

        Switching to fastMalloc() caused regressions on Jetstream and Octane
        on MacBook Air. I was able to get back some of it in the following
        patches but the tests that never go to FTL are still regressed.

        This patch revert r203808 except of the node index.
        Nodes are allocated with the custom allocator like before but they are
        now also kept in a table, addressed by the node index.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3SparseCollection.h:
        (JSC::B3::SparseCollection::packIndices): Deleted.
        * dfg/DFGAllocator.h: Added.
        (JSC::DFG::Allocator::Region::size):
        (JSC::DFG::Allocator::Region::headerSize):
        (JSC::DFG::Allocator::Region::numberOfThingsPerRegion):
        (JSC::DFG::Allocator::Region::data):
        (JSC::DFG::Allocator::Region::isInThisRegion):
        (JSC::DFG::Allocator::Region::regionFor):
        (JSC::DFG::Allocator<T>::Allocator):
        (JSC::DFG::Allocator<T>::~Allocator):
        (JSC::DFG::Allocator<T>::allocate):
        (JSC::DFG::Allocator<T>::free):
        (JSC::DFG::Allocator<T>::freeAll):
        (JSC::DFG::Allocator<T>::reset):
        (JSC::DFG::Allocator<T>::indexOf):
        (JSC::DFG::Allocator<T>::allocatorOf):
        (JSC::DFG::Allocator<T>::bumpAllocate):
        (JSC::DFG::Allocator<T>::freeListAllocate):
        (JSC::DFG::Allocator<T>::allocateSlow):
        (JSC::DFG::Allocator<T>::freeRegionsStartingAt):
        (JSC::DFG::Allocator<T>::startBumpingIn):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::~Graph):
        (JSC::DFG::Graph::addNodeToMapByIndex):
        (JSC::DFG::Graph::deleteNode):
        (JSC::DFG::Graph::packNodeIndices):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addNode):
        (JSC::DFG::Graph::maxNodeCount):
        (JSC::DFG::Graph::nodeAt):
        * dfg/DFGLongLivedState.cpp: Added.
        (JSC::DFG::LongLivedState::LongLivedState):
        (JSC::DFG::LongLivedState::~LongLivedState):
        (JSC::DFG::LongLivedState::shrinkToFit):
        * dfg/DFGLongLivedState.h: Added.
        * dfg/DFGNode.h:
        * dfg/DFGNodeAllocator.h: Added.
        (operator new ):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPlan.h:
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::runThread):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2016-08-11  Mark Lam  <mark.lam@apple.com>

        The jsc shell's Element host constructor should throw if it fails to construct an object.
        https://bugs.webkit.org/show_bug.cgi?id=160773
        <rdar://problem/27328608>

        Reviewed by Saam Barati.

        The Element object is a test object provided in the jsc shell for testing use only.
        JavaScriptCore expects host constructors to either throw an error or return a
        constructed object.  Element has a host constructor that did not obey this contract.
        As a result, the following statement will fail a RELEASE_ASSERT:

            new (Element.bind())

        This is now fixed.

        * jsc.cpp:
        (functionCreateElement):

2016-08-11  Mark Lam  <mark.lam@apple.com>

        Disallow synchronous sweeping for eden GCs.
        https://bugs.webkit.org/show_bug.cgi?id=160716

        Reviewed by Geoffrey Garen.

        * heap/Heap.cpp:
        (JSC::Heap::collectAllGarbage):
        (JSC::Heap::collectAndSweep): Deleted.
        * heap/Heap.h:
        (JSC::Heap::collectAllGarbage): Deleted.
        - No need for a separate collectAndSweep() anymore since we only call it for
          FullCollections.
        - Since we've already swept all the blocks, I cleared m_blockSnapshot so that the
          IncrementalSweeper can bail earlier when it runs later.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::sweepHelper):
        - Removed the unreachable return statement.

        * heap/MarkedBlock.h:
        - Document what "Retired" means.

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

2016-08-11  Per Arne Vollan  <pvollan@apple.com>

        [Win] Warning fix.
        https://bugs.webkit.org/show_bug.cgi?id=160734

        Reviewed by Sam Weinig.

        Add static cast from int to uint32_t.

        * bytecode/ArithProfile.h:

2016-08-10  Michael Saboff  <msaboff@apple.com>

        Baseline GetByVal and PutByVal for cache ID stubs need to handle exceptions
        https://bugs.webkit.org/show_bug.cgi?id=160749

        Reviewed by Filip Pizlo.

        We were emitting "callOperation()" calls in emitGetByValWithCachedId() and
        emitPutByValWithCachedId() without linking the exception checks created by the
        code emitted.  This manifested itself in various ways depending on the processor.
        This is due to what the destination is for an unlinked branch.  On X86, an unlinked
        branch goes tot he next instructions.  On ARM64, we end up with an infinite loop
        as we branch to the same instruction.  On ARM we branch to 0 as the branch is to
        an absolute address of 0.

        Now we save the exception handler address for the original generated function and
        link the exception cases for these by-val stubs to this handler.

        * bytecode/ByValInfo.h:
        (JSC::ByValInfo::ByValInfo): Added the address of the exception handler we should
        link to.

        * jit/JIT.cpp:
        (JSC::JIT::link): Compute the linked exception handler address and pass it to
        the ByValInfo constructor.
        (JSC::JIT::privateCompileExceptionHandlers): Make sure that we generate the
        exception handler if we have any by-val handlers.

        * jit/JIT.h:
        Added a label for the exception handler.  We'll link this later for the
        by value handlers.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompileGetByValWithCachedId):
        (JSC::JIT::privateCompilePutByValWithCachedId):
        Link exception branches to the exception handler for the main function.

2016-08-10  Mark Lam  <mark.lam@apple.com>

        DFG's flushForTerminal() needs to add PhantomLocals for bytecode live locals.
        https://bugs.webkit.org/show_bug.cgi?id=160755
        <rdar://problem/27488507>

        Reviewed by Filip Pizlo.

        If the DFG sees that an inlined function will result in an OSR exit every time,
        it will treat all downstream blocks as dead.  However, it still needs to keep
        locals that are alive in the bytecode alive for the compiled function so that
        those locals are properly written to the stack by the OSR exit ramp.

        The existing code neglected to do this.  This patch remedies this issue.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::flushDirect):
        (JSC::DFG::ByteCodeParser::addFlushOrPhantomLocal):
        (JSC::DFG::ByteCodeParser::phantomLocalDirect):
        (JSC::DFG::ByteCodeParser::flushForTerminal):

2016-08-09  Skachkov Oleksandr  <gskachkov@gmail.com>

        [ES2016] Implement Object.values
        https://bugs.webkit.org/show_bug.cgi?id=160410

        Reviewed by Saam Barati, Yusuke Suzuki.

        This patch adds values function to Object that return list of 
        own values of the object. Patch did according to the point of 
        spec http://tc39.github.io/ecma262/#sec-object.values
        
        Also patch adds generic builtin intrinsic constants: 
        @IterationKindKey/@IterationKindValue/@IterationKindKeyValue 
        that is used in  EnumerableOwnProperties to set Kind of operation  
        and replace own IterationKind enums in following iterators: 
        ArrayIterator, MapIterator, and SetIterator 

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ObjectConstructor.js:
        (globalPrivate.enumerableOwnProperties):
        (values):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        * runtime/ArrayIteratorPrototype.h:
        * runtime/IterationKind.h: Copied from Source/JavaScriptCore/builtins/ObjectConstructor.js.
        * runtime/JSMapIterator.h:
        (JSC::JSMapIterator::create):
        (JSC::JSMapIterator::next):
        (JSC::JSMapIterator::kind):
        (JSC::JSMapIterator::JSMapIterator):
        * runtime/JSSetIterator.h:
        (JSC::JSSetIterator::create):
        (JSC::JSSetIterator::next):
        (JSC::JSSetIterator::kind):
        (JSC::JSSetIterator::JSSetIterator):
        * runtime/MapPrototype.cpp:
        (JSC::mapProtoFuncValues):
        (JSC::mapProtoFuncEntries):
        (JSC::mapProtoFuncKeys):
        (JSC::privateFuncMapIterator):
        * runtime/ObjectConstructor.cpp:
        * runtime/SetPrototype.cpp:
        (JSC::setProtoFuncValues):
        (JSC::setProtoFuncEntries):
        (JSC::privateFuncSetIterator):

2016-08-10  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Speed up SparseCollection & related maps
        https://bugs.webkit.org/show_bug.cgi?id=160733

        Reviewed by Saam Barati.

        On MBA, Graph::addNode() shows up in profiles due to SparseCollection::add().
        This is unfortunate.

        The first improvement is to build the new unique_ptr in the empty slot
        instead of moving a new value into it.

        Previously, the code would load the previous value, test if it is null
        then invoke the destructor and finally fastFree(). The initial test
        obviously fails so that's a whole bunch of code that is never executed.

        With the new code, we just have a store.

        I also removed the bounds checking on our maps based on node index.
        Those bounds checks are never eliminated by clang because the index
        is always loaded from memory instead of being computed.
        There are unfortunately too many nodes processed and the bounds checks
        get costly.

        * b3/B3SparseCollection.h:
        (JSC::B3::SparseCollection::add):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::abstractValuesCache):
        * dfg/DFGInPlaceAbstractState.h:

2016-08-10  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove some useless code I left when rewriting CSE's large maps
        https://bugs.webkit.org/show_bug.cgi?id=160720

        Reviewed by Michael Saboff.

        * dfg/DFGCSEPhase.cpp:
        The maps m_worldMap && m_sideStateMap are useless. They come from the previous
        iteration that had weaker constraints.

        Also move m_heapMap after m_fallbackStackMap since that is the order
        in which they are used in the algorithm.

2016-08-10  Benjamin Poulain  <bpoulain@apple.com>

        Remove AbstractInterpreter::executeEdges(unsigned), it is no longer used anywhere
        https://bugs.webkit.org/show_bug.cgi?id=160708

        Reviewed by Mark Lam.

        * dfg/DFGAbstractInterpreter.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEdges): Deleted.

2016-08-10  Simon Fraser  <simon.fraser@apple.com>

        Sort the feature flags in the FEATURE_DEFINES lines
        https://bugs.webkit.org/show_bug.cgi?id=160742

        Reviewed by Anders Carlsson.

        * Configurations/FeatureDefines.xcconfig:

2016-08-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Add ModuleLoaderPrototype and move methods to it
        https://bugs.webkit.org/show_bug.cgi?id=160633

        Reviewed by Saam Barati.

        In the future, we need to add the ability to create the new Loader object (by users).
        So rather than holding all the methods in the ModuleLoaderObject instance, moving them
        to ModuleLoaderPrototype and create the default JSModuleLoader instance is better.

        No behavior change.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ModuleLoaderObject.js:
        (setStateToMax): Deleted.
        (newRegistryEntry): Deleted.
        (ensureRegistered): Deleted.
        (forceFulfillPromise): Deleted.
        (fulfillFetch): Deleted.
        (fulfillTranslate): Deleted.
        (fulfillInstantiate): Deleted.
        (commitInstantiated): Deleted.
        (instantiation): Deleted.
        (requestFetch): Deleted.
        (requestTranslate): Deleted.
        (requestInstantiate): Deleted.
        (requestResolveDependencies.): Deleted.
        (requestResolveDependencies): Deleted.
        (requestInstantiateAll): Deleted.
        (requestLink): Deleted.
        (requestReady): Deleted.
        (link): Deleted.
        (moduleEvaluation): Deleted.
        (provide): Deleted.
        (loadAndEvaluateModule): Deleted.
        (loadModule): Deleted.
        (linkAndEvaluateModule): Deleted.
        * builtins/ModuleLoaderPrototype.js: Renamed from Source/JavaScriptCore/builtins/ModuleLoaderObject.js.
        (setStateToMax):
        (newRegistryEntry):
        (ensureRegistered):
        (forceFulfillPromise):
        (fulfillFetch):
        (fulfillTranslate):
        (fulfillInstantiate):
        (commitInstantiated):
        (instantiation):
        (requestFetch):
        (requestTranslate):
        (requestInstantiate):
        (requestResolveDependencies.):
        (requestResolveDependencies):
        (requestInstantiateAll):
        (requestLink):
        (requestReady):
        (link):
        (moduleEvaluation):
        (provide):
        (loadAndEvaluateModule):
        (loadModule):
        (linkAndEvaluateModule):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * jsc.cpp:
        (GlobalObject::moduleLoaderResolve):
        (GlobalObject::moduleLoaderFetch):
        * runtime/Completion.cpp:
        (JSC::loadAndEvaluateModule):
        (JSC::loadModule):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::moduleLoader):
        (JSC::JSGlobalObject::moduleLoaderStructure):
        * runtime/JSModuleLoader.cpp: Added.
        (JSC::JSModuleLoader::JSModuleLoader):
        (JSC::JSModuleLoader::finishCreation):
        (JSC::printableModuleKey):
        (JSC::JSModuleLoader::provide):
        (JSC::JSModuleLoader::loadAndEvaluateModule):
        (JSC::JSModuleLoader::loadModule):
        (JSC::JSModuleLoader::linkAndEvaluateModule):
        (JSC::JSModuleLoader::resolve):
        (JSC::JSModuleLoader::fetch):
        (JSC::JSModuleLoader::translate):
        (JSC::JSModuleLoader::instantiate):
        (JSC::JSModuleLoader::evaluate):
        * runtime/JSModuleLoader.h: Copied from Source/JavaScriptCore/runtime/ModuleLoaderObject.h.
        (JSC::JSModuleLoader::create):
        (JSC::JSModuleLoader::createStructure):
        * runtime/JSModuleRecord.h:
        * runtime/ModuleLoaderObject.cpp: Removed.
        (JSC::ModuleLoaderObject::ModuleLoaderObject): Deleted.
        (JSC::ModuleLoaderObject::finishCreation): Deleted.
        (JSC::printableModuleKey): Deleted.
        (JSC::ModuleLoaderObject::provide): Deleted.
        (JSC::ModuleLoaderObject::loadAndEvaluateModule): Deleted.
        (JSC::ModuleLoaderObject::loadModule): Deleted.
        (JSC::ModuleLoaderObject::linkAndEvaluateModule): Deleted.
        (JSC::ModuleLoaderObject::resolve): Deleted.
        (JSC::ModuleLoaderObject::fetch): Deleted.
        (JSC::ModuleLoaderObject::translate): Deleted.
        (JSC::ModuleLoaderObject::instantiate): Deleted.
        (JSC::ModuleLoaderObject::evaluate): Deleted.
        (JSC::moduleLoaderObjectParseModule): Deleted.
        (JSC::moduleLoaderObjectRequestedModules): Deleted.
        (JSC::moduleLoaderObjectModuleDeclarationInstantiation): Deleted.
        (JSC::moduleLoaderObjectResolve): Deleted.
        (JSC::moduleLoaderObjectFetch): Deleted.
        (JSC::moduleLoaderObjectTranslate): Deleted.
        (JSC::moduleLoaderObjectInstantiate): Deleted.
        (JSC::moduleLoaderObjectEvaluate): Deleted.
        * runtime/ModuleLoaderObject.h:
        (JSC::ModuleLoaderObject::create): Deleted.
        (JSC::ModuleLoaderObject::createStructure): Deleted.
        * runtime/ModuleLoaderPrototype.cpp: Added.
        (JSC::ModuleLoaderPrototype::ModuleLoaderPrototype):
        (JSC::moduleLoaderPrototypeParseModule):
        (JSC::moduleLoaderPrototypeRequestedModules):
        (JSC::moduleLoaderPrototypeModuleDeclarationInstantiation):
        (JSC::moduleLoaderPrototypeResolve):
        (JSC::moduleLoaderPrototypeFetch):
        (JSC::moduleLoaderPrototypeTranslate):
        (JSC::moduleLoaderPrototypeInstantiate):
        (JSC::moduleLoaderPrototypeEvaluate):
        * runtime/ModuleLoaderPrototype.h: Renamed from Source/JavaScriptCore/runtime/ModuleLoaderObject.h.
        (JSC::ModuleLoaderPrototype::create):
        (JSC::ModuleLoaderPrototype::createStructure):

2016-08-09  Saam Barati  <sbarati@apple.com>

        JSBoundFunction should lazily generate its name string
        https://bugs.webkit.org/show_bug.cgi?id=160678
        <rdar://problem/27043194>

        Reviewed by Mark Lam.

        We were eagerly allocating the BoundFunction's 'name' string
        by prepending the "bound " prefix. This patch makes the 'name'
        string creation lazy like we do with ordinary JSFunctions.

        This is a 25% speedup on the microbenchmark I added that measures
        bound function creation speed. Hopefully this also helps us recover
        from a 1% Speedometer regression that was introduced in the original
        bound function "bound " prefixing patch.

        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::create):
        (JSC::JSBoundFunction::JSBoundFunction):
        (JSC::JSBoundFunction::finishCreation):
        * runtime/JSBoundFunction.h:
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::finishCreation):
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::getOwnNonIndexPropertyNames):
        (JSC::JSFunction::put):
        (JSC::JSFunction::deleteProperty):
        (JSC::JSFunction::defineOwnProperty):
        (JSC::JSFunction::reifyLazyPropertyIfNeeded):
        (JSC::JSFunction::reifyBoundNameIfNeeded):
        * runtime/JSFunction.h:

2016-08-09  George Ruan  <gruan@apple.com>

        Implement functionality of media capture on iOS
        https://bugs.webkit.org/show_bug.cgi?id=158945
        <rdar://problem/26893343>

        Reviewed by Tim Horton.

        * Configurations/FeatureDefines.xcconfig: Enable media capture feature
        for iOS.

2016-08-09  Saam Barati  <sbarati@apple.com>

        Parser<LexerType>::parseFunctionInfo() has the wrong info about captured vars when a function is not cached.
        https://bugs.webkit.org/show_bug.cgi?id=160671
        <rdar://problem/27756112>

        Reviewed by Mark Lam.

        There was a bug in our captured variable analysis when a function has a default
        parameter expression that is a function that captures something from the parent scope.
        The bug was that we were relying on the SourceProviderCache to succeed for the
        analysis to work. This is obviously wrong. I've fixed this to work regardless
        of getting a cache hit. To prevent future bugs that rely on the success of the
        SourceProviderCache, I've made the validate testing mode disable the SourceProviderCache

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/Parser.h:
        (JSC::Scope::setInnerArrowFunctionUsesEvalAndUseArgumentsIfNeeded):
        (JSC::Scope::addClosedVariableCandidateUnconditionally):
        (JSC::Scope::collectFreeVariables):
        * runtime/Options.h:

2016-08-08  Mark Lam  <mark.lam@apple.com>

        ASSERTION FAILED: hasInlineStorage() in JSFinalObject::visitChildren().
        https://bugs.webkit.org/show_bug.cgi?id=160666

        Reviewed by Keith Miller.

        This assertion is benign.  JSFinalObject::visitChildren() calls
        JSObject::inlineStorage() to get a pointer to the object's inline storage, and
        later passes it to visitor.appendValuesHidden() with a previously computed
        storageSize.  When storageSize is 0, appendValuesHidden() ends up doing nothing.
        However, before we get there, JSObject::inlineStorage() will be asserting
        hasInlineStorage() and this assertion will fail when storageSize is 0.

        We can fix this assertion failure by simply adding a storageSize check before
        calling hasInlineStorage() and visitor.appendValuesHidden().

        * runtime/JSObject.cpp:
        (JSC::JSFinalObject::visitChildren):

2016-08-08  Brian Burg  <bburg@apple.com>

        Web Inspector: clean up prefixing of Automation protocol generated files
        https://bugs.webkit.org/show_bug.cgi?id=160635
        <rdar://problem/27735327>

        Reviewed by Timothy Hatcher.

        Introduce different settings for the 'protocol group' name for C++ vs. Objective-C.

        Use 'WD' as the prefix for generated Objective-C frontend dispatchers and helpers.
        Continue using 'Automation' as the prefix for generated C++ backend dispatchers.

        * inspector/scripts/codegen/cpp_generator.py:
        (CppGenerator.protocol_name):
        * inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py:
        (ObjCProtocolTypeConversionsImplementationGenerator.generate_output):
        (ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_category_interface):
        (ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_category_implementation):
        Adjust the class name. Generate one category per protocol domain to keep it easy to read.

        * inspector/scripts/codegen/models.py:
        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator.protocol_name):

        * 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 test results.

2016-08-07  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Module namespace object should not allow unset IC
        https://bugs.webkit.org/show_bug.cgi?id=160553

        Reviewed by Saam Barati.

        Previously, module namespace object accidentally allow "unset IC". But this "unsetness" does not rely on
        the structure. We should disable inline caching onto the namespace object. Once it is needed, we should
        create the special caching for namespace object like the following: it should be similar to monomorphic IC,
        but it caches the object itself instead of the structure. It checks the object itself (And in DFG, it should be
        CheckCell) and loads the value from the target module environment directly[1].

        And this patch also set setIsTaintedByProxy for the module namespace object to notify to the caller that
        this object has impure ::getOwnPropertySlot. Then this function is now renamed to setIsTaintedByOpaqueObject.

        We drop the hack in JSModuleNamespaceObject::getOwnPropertySlot since we already introduced InternalMethodType
        for ProxyObject. Previously we cannot distinguish ::HasProperty and ::GetOwnProperty. So not to throw any
        errors for ::HasProperty case, we used slot.setCustom to delay the observable operation.
        But, this hack lacks the support for hasOwnProperty: hasOwnProperty uses [[GetOwnProperty]], so it should throw an error.
        However the previous implementation does not throw an error since the delayed observable part (custom function part) is
        skipped in hasOwnProperty implementation. We now remove this custom property hack and fix the corresponding failure
        in test262.

        [1]: https://bugs.webkit.org/show_bug.cgi?id=160590

        * jit/JITOperations.cpp:
        * runtime/ArrayPrototype.cpp:
        (JSC::getProperty):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewWithArguments):
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::getOwnPropertySlot):
        (JSC::callbackGetter): Deleted.
        * runtime/JSModuleNamespaceObject.h:
        * runtime/PropertySlot.cpp:
        (JSC::PropertySlot::getPureResult):
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::PropertySlot):
        (JSC::PropertySlot::setIsTaintedByOpaqueObject):
        (JSC::PropertySlot::isTaintedByOpaqueObject):
        (JSC::PropertySlot::setIsTaintedByProxy): Deleted.
        (JSC::PropertySlot::isTaintedByProxy): Deleted.
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::getOwnPropertySlotCommon):

2016-08-05  Keith Miller  <keith_miller@apple.com>

        Add LEBDecoder and tests
        https://bugs.webkit.org/show_bug.cgi?id=160625

        Reviewed by Benjamin Poulain.

        Adds a new target testWASM that is currently used to test the LEB decoder.
        In the future, if we add more support for WASM we will put more tests
        here.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * testWASM.cpp: Added.
        (CommandLine::CommandLine):
        (printUsageStatement):
        (CommandLine::parseArguments):
        (runLEBTests):
        (main):

2016-08-05  Keith Miller  <keith_miller@apple.com>

        32-bit JSC test failure: stress/instanceof-late-constant-folding.js
        https://bugs.webkit.org/show_bug.cgi?id=160620

        Reviewed by Filip Pizlo.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2016-08-05  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove the first LocalCSE
        https://bugs.webkit.org/show_bug.cgi?id=160615

        Reviewed by Saam Barati.

        LocalCSE is the most expensive phase in DFG (excluding FTL).

        The combination of two LocalCSEs does not seem to pay for its cost.
        Doing a single LocalCSE is always after ConstantFolding and StrengthReduction
        is always a win on my machine.

        * dfg/DFGCleanUpPhase.cpp:
        (JSC::DFG::CleanUpPhase::run):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):

2016-08-05  Saam Barati  <sbarati@apple.com>

        various math operations don't properly check for an exception after calling toNumber() on the lhs
        https://bugs.webkit.org/show_bug.cgi?id=160154

        Reviewed by Mark Lam.

        We must check for an exception after calling toNumber() on the lhs
        because this can throw an exception. If we called toNumber() on
        the rhs without first checking for an exception after the toNumber()
        on the lhs, this can lead us to execute effectful code or deviate
        from the standard in subtle ways. I fixed this bug in various places
        by always checking for an exception after calling toNumber() on the
        lhs for the various bit and arithmetic operations.

        This patch also found a commutativity bug inside DFGStrengthReduction.
        We could end up commuting the lhs and rhs of say an "|" expression
        even when the lhs/rhs may not be numbers. This is wrong because
        executing toNumber() on the lhs/rhs has strict ordering guarantees
        by the specification and is observable by user programs.

        * dfg/DFGOperations.cpp:
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleCommutativity):
        * jit/JITOperations.cpp:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/Operations.cpp:
        (JSC::jsAddSlowCase):

2016-08-05  Michael Saboff  <msaboff@apple.com>

        compilePutByValForIntTypedArray() has a slow path in the middle of its processing
        https://bugs.webkit.org/show_bug.cgi?id=160614

        Reviewed by Keith Miller.

        In compilePutByValForIntTypedArray() we were calling out to the slow path
        operationToInt32() and then returning back to the middle of code to finish
        the processing of writing the value to the array.  When we make the slow
        path call, we trash any temporary registers that have been allocated.
        In general slow path calls should finish the operation in progress and
        continue processing at the beginning of the next node.

        This was discovered while working on the register argument changes, when
        we SpeculateStrictInt32Operand on the value child node.  That child node's
        value was live in register with a spill format of DataFormatJSInt32.  In that
        case we allocate a new temporary register and copy just the lower 32 bits from
        the child register to the new temp register.  That temp register gets trashed
        when we make the operationToInt32() slow path call.

        I spent some time trying to devise a test with the current code base and wasn't
        successful.  This case is tested with the register argument changes in progress.

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

2016-08-05  Saam Barati  <sbarati@apple.com>

        Assertion failure when accessing TDZ variable in catch through eval
        https://bugs.webkit.org/show_bug.cgi?id=160554

        Reviewed by Mark Lam and Keith Miller.

        When we were calculating the variables under TDZ from a JSScope,
        the algorithm was not taking into account that a catch scope
        has variables under TDZ.

        * runtime/JSScope.cpp:
        (JSC::JSScope::collectVariablesUnderTDZ):

2016-08-05  Keith Miller  <keith_miller@apple.com>

        Delete out of date WASM code.
        https://bugs.webkit.org/show_bug.cgi?id=160603

        Reviewed by Saam Barati.

        This patch removes a bunch of the wasm files that we are unlikey to use
        with the newer wasm spec. If we end up needing any of the deleted code
        later we can restore it at that time.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/JITOperations.cpp:
        * jsc.cpp:
        (GlobalObject::finishCreation): Deleted.
        (functionLoadWebAssembly): Deleted.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setUpCall): Deleted.
        * runtime/Executable.cpp:
        (JSC::WebAssemblyExecutable::prepareForExecution): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Deleted.
        (JSC::JSGlobalObject::visitChildren): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::wasmModuleStructure): Deleted.
        * wasm/WASMConstants.h: Removed.
        * wasm/WASMFunctionB3IRGenerator.h: Removed.
        (JSC::WASMFunctionB3IRGenerator::MemoryAddress::MemoryAddress): Deleted.
        (JSC::WASMFunctionB3IRGenerator::startFunction): Deleted.
        (JSC::WASMFunctionB3IRGenerator::endFunction): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildSetLocal): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildSetGlobal): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildReturn): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildImmediateI32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildImmediateF32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildImmediateF64): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildGetLocal): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildGetGlobal): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildConvertType): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildLoad): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildStore): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildUnaryI32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildUnaryF32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildUnaryF64): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildBinaryI32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildBinaryF32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildBinaryF64): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildRelationalI32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildRelationalF32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildRelationalF64): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildMinOrMaxI32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildMinOrMaxF64): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildCallInternal): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildCallIndirect): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildCallImport): Deleted.
        (JSC::WASMFunctionB3IRGenerator::appendExpressionList): Deleted.
        (JSC::WASMFunctionB3IRGenerator::discard): Deleted.
        (JSC::WASMFunctionB3IRGenerator::linkTarget): Deleted.
        (JSC::WASMFunctionB3IRGenerator::jumpToTarget): Deleted.
        (JSC::WASMFunctionB3IRGenerator::jumpToTargetIf): Deleted.
        (JSC::WASMFunctionB3IRGenerator::startLoop): Deleted.
        (JSC::WASMFunctionB3IRGenerator::endLoop): Deleted.
        (JSC::WASMFunctionB3IRGenerator::startSwitch): Deleted.
        (JSC::WASMFunctionB3IRGenerator::endSwitch): Deleted.
        (JSC::WASMFunctionB3IRGenerator::startLabel): Deleted.
        (JSC::WASMFunctionB3IRGenerator::endLabel): Deleted.
        (JSC::WASMFunctionB3IRGenerator::breakTarget): Deleted.
        (JSC::WASMFunctionB3IRGenerator::continueTarget): Deleted.
        (JSC::WASMFunctionB3IRGenerator::breakLabelTarget): Deleted.
        (JSC::WASMFunctionB3IRGenerator::continueLabelTarget): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildSwitch): Deleted.
        * wasm/WASMFunctionCompiler.h: Removed.
        (JSC::operationConvertJSValueToInt32): Deleted.
        (JSC::operationConvertJSValueToDouble): Deleted.
        (JSC::operationDiv): Deleted.
        (JSC::operationMod): Deleted.
        (JSC::operationUnsignedDiv): Deleted.
        (JSC::operationUnsignedMod): Deleted.
        (JSC::operationConvertUnsignedInt32ToDouble): Deleted.
        (JSC::sizeOfMemoryType): Deleted.
        (JSC::WASMFunctionCompiler::MemoryAddress::MemoryAddress): Deleted.
        (JSC::WASMFunctionCompiler::WASMFunctionCompiler): Deleted.
        (JSC::WASMFunctionCompiler::startFunction): Deleted.
        (JSC::WASMFunctionCompiler::endFunction): Deleted.
        (JSC::WASMFunctionCompiler::buildSetLocal): Deleted.
        (JSC::WASMFunctionCompiler::buildSetGlobal): Deleted.
        (JSC::WASMFunctionCompiler::buildReturn): Deleted.
        (JSC::WASMFunctionCompiler::buildImmediateI32): Deleted.
        (JSC::WASMFunctionCompiler::buildImmediateF32): Deleted.
        (JSC::WASMFunctionCompiler::buildImmediateF64): Deleted.
        (JSC::WASMFunctionCompiler::buildGetLocal): Deleted.
        (JSC::WASMFunctionCompiler::buildGetGlobal): Deleted.
        (JSC::WASMFunctionCompiler::buildConvertType): Deleted.
        (JSC::WASMFunctionCompiler::buildLoad): Deleted.
        (JSC::WASMFunctionCompiler::buildStore): Deleted.
        (JSC::WASMFunctionCompiler::buildUnaryI32): Deleted.
        (JSC::WASMFunctionCompiler::buildUnaryF32): Deleted.
        (JSC::WASMFunctionCompiler::buildUnaryF64): Deleted.
        (JSC::WASMFunctionCompiler::buildBinaryI32): Deleted.
        (JSC::WASMFunctionCompiler::buildBinaryF32): Deleted.
        (JSC::WASMFunctionCompiler::buildBinaryF64): Deleted.
        (JSC::WASMFunctionCompiler::buildRelationalI32): Deleted.
        (JSC::WASMFunctionCompiler::buildRelationalF32): Deleted.
        (JSC::WASMFunctionCompiler::buildRelationalF64): Deleted.
        (JSC::WASMFunctionCompiler::buildMinOrMaxI32): Deleted.
        (JSC::WASMFunctionCompiler::buildMinOrMaxF64): Deleted.
        (JSC::WASMFunctionCompiler::buildCallInternal): Deleted.
        (JSC::WASMFunctionCompiler::buildCallIndirect): Deleted.
        (JSC::WASMFunctionCompiler::buildCallImport): Deleted.
        (JSC::WASMFunctionCompiler::appendExpressionList): Deleted.
        (JSC::WASMFunctionCompiler::discard): Deleted.
        (JSC::WASMFunctionCompiler::linkTarget): Deleted.
        (JSC::WASMFunctionCompiler::jumpToTarget): Deleted.
        (JSC::WASMFunctionCompiler::jumpToTargetIf): Deleted.
        (JSC::WASMFunctionCompiler::startLoop): Deleted.
        (JSC::WASMFunctionCompiler::endLoop): Deleted.
        (JSC::WASMFunctionCompiler::startSwitch): Deleted.
        (JSC::WASMFunctionCompiler::endSwitch): Deleted.
        (JSC::WASMFunctionCompiler::startLabel): Deleted.
        (JSC::WASMFunctionCompiler::endLabel): Deleted.
        (JSC::WASMFunctionCompiler::breakTarget): Deleted.
        (JSC::WASMFunctionCompiler::continueTarget): Deleted.
        (JSC::WASMFunctionCompiler::breakLabelTarget): Deleted.
        (JSC::WASMFunctionCompiler::continueLabelTarget): Deleted.
        (JSC::WASMFunctionCompiler::buildSwitch): Deleted.
        (JSC::WASMFunctionCompiler::localAddress): Deleted.
        (JSC::WASMFunctionCompiler::temporaryAddress): Deleted.
        (JSC::WASMFunctionCompiler::appendCall): Deleted.
        (JSC::WASMFunctionCompiler::appendCallWithExceptionCheck): Deleted.
        (JSC::WASMFunctionCompiler::emitNakedCall): Deleted.
        (JSC::WASMFunctionCompiler::appendCallSetResult): Deleted.
        (JSC::WASMFunctionCompiler::callOperation): Deleted.
        (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer): Deleted.
        (JSC::WASMFunctionCompiler::callAndUnboxResult): Deleted.
        (JSC::WASMFunctionCompiler::convertValueToInt32): Deleted.
        (JSC::WASMFunctionCompiler::convertValueToDouble): Deleted.
        (JSC::WASMFunctionCompiler::convertDoubleToValue): Deleted.
        * wasm/WASMFunctionParser.cpp: Removed.
        (JSC::nameOfType): Deleted.
        (JSC::WASMFunctionParser::checkSyntax): Deleted.
        (JSC::WASMFunctionParser::compile): Deleted.
        (JSC::WASMFunctionParser::parseFunction): Deleted.
        (JSC::WASMFunctionParser::parseLocalVariables): Deleted.
        (JSC::WASMFunctionParser::parseStatement): Deleted.
        (JSC::WASMFunctionParser::parseReturnStatement): Deleted.
        (JSC::WASMFunctionParser::parseBlockStatement): Deleted.
        (JSC::WASMFunctionParser::parseIfStatement): Deleted.
        (JSC::WASMFunctionParser::parseIfElseStatement): Deleted.
        (JSC::WASMFunctionParser::parseWhileStatement): Deleted.
        (JSC::WASMFunctionParser::parseDoStatement): Deleted.
        (JSC::WASMFunctionParser::parseLabelStatement): Deleted.
        (JSC::WASMFunctionParser::parseBreakStatement): Deleted.
        (JSC::WASMFunctionParser::parseBreakLabelStatement): Deleted.
        (JSC::WASMFunctionParser::parseContinueStatement): Deleted.
        (JSC::WASMFunctionParser::parseContinueLabelStatement): Deleted.
        (JSC::WASMFunctionParser::parseSwitchStatement): Deleted.
        (JSC::WASMFunctionParser::parseExpression): Deleted.
        (JSC::WASMFunctionParser::parseExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseConstantPoolIndexExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseImmediateExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseUnaryExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseBinaryExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseRelationalI32ExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseRelationalF32ExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseRelationalF64ExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseMinOrMaxExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseExpressionF32): Deleted.
        (JSC::WASMFunctionParser::parseConstantPoolIndexExpressionF32): Deleted.
        (JSC::WASMFunctionParser::parseImmediateExpressionF32): Deleted.
        (JSC::WASMFunctionParser::parseUnaryExpressionF32): Deleted.
        (JSC::WASMFunctionParser::parseBinaryExpressionF32): Deleted.
        (JSC::WASMFunctionParser::parseExpressionF64): Deleted.
        (JSC::WASMFunctionParser::parseConstantPoolIndexExpressionF64): Deleted.
        (JSC::WASMFunctionParser::parseImmediateExpressionF64): Deleted.
        (JSC::WASMFunctionParser::parseUnaryExpressionF64): Deleted.
        (JSC::WASMFunctionParser::parseBinaryExpressionF64): Deleted.
        (JSC::WASMFunctionParser::parseMinOrMaxExpressionF64): Deleted.
        (JSC::WASMFunctionParser::parseExpressionVoid): Deleted.
        (JSC::WASMFunctionParser::parseGetLocalExpression): Deleted.
        (JSC::WASMFunctionParser::parseGetGlobalExpression): Deleted.
        (JSC::WASMFunctionParser::parseSetLocal): Deleted.
        (JSC::WASMFunctionParser::parseSetGlobal): Deleted.
        (JSC::WASMFunctionParser::parseMemoryAddress): Deleted.
        (JSC::WASMFunctionParser::parseLoad): Deleted.
        (JSC::WASMFunctionParser::parseStore): Deleted.
        (JSC::WASMFunctionParser::parseCallArguments): Deleted.
        (JSC::WASMFunctionParser::parseCallInternal): Deleted.
        (JSC::WASMFunctionParser::parseCallIndirect): Deleted.
        (JSC::WASMFunctionParser::parseCallImport): Deleted.
        (JSC::WASMFunctionParser::parseConditional): Deleted.
        (JSC::WASMFunctionParser::parseComma): Deleted.
        (JSC::WASMFunctionParser::parseConvertType): Deleted.
        * wasm/WASMFunctionParser.h: Removed.
        (JSC::WASMFunctionParser::WASMFunctionParser): Deleted.
        * wasm/WASMFunctionSyntaxChecker.h: Removed.
        (JSC::WASMFunctionSyntaxChecker::MemoryAddress::MemoryAddress): Deleted.
        (JSC::WASMFunctionSyntaxChecker::startFunction): Deleted.
        (JSC::WASMFunctionSyntaxChecker::endFunction): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildSetLocal): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildSetGlobal): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildReturn): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildImmediateI32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildImmediateF32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildImmediateF64): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildGetLocal): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildGetGlobal): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildConvertType): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildLoad): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildStore): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildUnaryI32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildUnaryF32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildUnaryF64): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildBinaryI32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildBinaryF32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildBinaryF64): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildRelationalI32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildRelationalF32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildRelationalF64): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildMinOrMaxI32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildMinOrMaxF64): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildCallInternal): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildCallImport): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildCallIndirect): Deleted.
        (JSC::WASMFunctionSyntaxChecker::appendExpressionList): Deleted.
        (JSC::WASMFunctionSyntaxChecker::discard): Deleted.
        (JSC::WASMFunctionSyntaxChecker::linkTarget): Deleted.
        (JSC::WASMFunctionSyntaxChecker::jumpToTarget): Deleted.
        (JSC::WASMFunctionSyntaxChecker::jumpToTargetIf): Deleted.
        (JSC::WASMFunctionSyntaxChecker::startLoop): Deleted.
        (JSC::WASMFunctionSyntaxChecker::endLoop): Deleted.
        (JSC::WASMFunctionSyntaxChecker::startSwitch): Deleted.
        (JSC::WASMFunctionSyntaxChecker::endSwitch): Deleted.
        (JSC::WASMFunctionSyntaxChecker::startLabel): Deleted.
        (JSC::WASMFunctionSyntaxChecker::endLabel): Deleted.
        (JSC::WASMFunctionSyntaxChecker::breakTarget): Deleted.
        (JSC::WASMFunctionSyntaxChecker::continueTarget): Deleted.
        (JSC::WASMFunctionSyntaxChecker::breakLabelTarget): Deleted.
        (JSC::WASMFunctionSyntaxChecker::continueLabelTarget): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildSwitch): Deleted.
        (JSC::WASMFunctionSyntaxChecker::stackHeight): Deleted.
        (JSC::WASMFunctionSyntaxChecker::updateTempStackHeight): Deleted.
        (JSC::WASMFunctionSyntaxChecker::updateTempStackHeightForCall): Deleted.
        * wasm/WASMModuleParser.cpp: Removed.
        (JSC::WASMModuleParser::WASMModuleParser): Deleted.
        (JSC::WASMModuleParser::parse): Deleted.
        (JSC::WASMModuleParser::parseModule): Deleted.
        (JSC::WASMModuleParser::parseConstantPoolSection): Deleted.
        (JSC::WASMModuleParser::parseSignatureSection): Deleted.
        (JSC::WASMModuleParser::parseFunctionImportSection): Deleted.
        (JSC::WASMModuleParser::parseGlobalSection): Deleted.
        (JSC::WASMModuleParser::parseFunctionDeclarationSection): Deleted.
        (JSC::WASMModuleParser::parseFunctionPointerTableSection): Deleted.
        (JSC::WASMModuleParser::parseFunctionDefinitionSection): Deleted.
        (JSC::WASMModuleParser::parseFunctionDefinition): Deleted.
        (JSC::WASMModuleParser::parseExportSection): Deleted.
        (JSC::WASMModuleParser::getImportedValue): Deleted.
        (JSC::parseWebAssembly): Deleted.
        * wasm/WASMModuleParser.h: Removed.
        * wasm/WASMReader.cpp: Removed.
        (JSC::WASMReader::readUInt32): Deleted.
        (JSC::WASMReader::readFloat): Deleted.
        (JSC::WASMReader::readDouble): Deleted.
        (JSC::WASMReader::readCompactInt32): Deleted.
        (JSC::WASMReader::readCompactUInt32): Deleted.
        (JSC::WASMReader::readString): Deleted.
        (JSC::WASMReader::readType): Deleted.
        (JSC::WASMReader::readExpressionType): Deleted.
        (JSC::WASMReader::readExportFormat): Deleted.
        (JSC::WASMReader::readByte): Deleted.
        (JSC::WASMReader::readOpStatement): Deleted.
        (JSC::WASMReader::readOpExpressionI32): Deleted.
        (JSC::WASMReader::readOpExpressionF32): Deleted.
        (JSC::WASMReader::readOpExpressionF64): Deleted.
        (JSC::WASMReader::readOpExpressionVoid): Deleted.
        (JSC::WASMReader::readVariableTypes): Deleted.
        (JSC::WASMReader::readOp): Deleted.
        (JSC::WASMReader::readSwitchCase): Deleted.
        * wasm/WASMReader.h: Removed.
        (JSC::WASMReader::WASMReader): Deleted.
        (JSC::WASMReader::offset): Deleted.
        (JSC::WASMReader::setOffset): Deleted.

2016-08-05  Keith Miller  <keith_miller@apple.com>

        Fix 32-bit OverridesHasInstance in the DFG.
        https://bugs.webkit.org/show_bug.cgi?id=160600

        Reviewed by Mark Lam.

        In https://trac.webkit.org/changeset/204140, we fixed an issue where the DFG might
        do the wrong thing if it proved that the Symbol.hasInstance value for a constructor
        was a constant late in compilation. That fix was ommited from the 32-bit version,
        causing the new test to fail.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2016-08-04  Saam Barati  <sbarati@apple.com>

        Restore CodeBlock jettison code to jettison when a CodeBlock has been alive for a long time
        https://bugs.webkit.org/show_bug.cgi?id=151241

        Reviewed by Benjamin Poulain.

        This patch rolls back in the jettisoning policy from https://bugs.webkit.org/show_bug.cgi?id=149727.
        We can now jettison a CodeBlock when it has been alive for a long time
        and is only pointed to by its owner executable. I haven't been able to get this
        patch to crash on anything it used to crash on, so I suspect we've fixed the bugs that
        were causing this before. I've also added some stress options for this feature that
        will cause us to either eagerly old-age jettison or to old-age jettison whenever it's legal.
        These options helped me find a bug where we would ask an Executable to create a CodeBlock,
        and then the Executable would do some other allocations, causing a GC, immediately causing
        the CodeBlock to jettison. There is a small chance that this was the bug we were seeing before,
        however, it's unlikely given that the previous timing metrics require at least 5 second between
        compiling to jettisoning.

        This patch also enables the stress options for various modes
        of JSC stress tests.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::shouldJettisonDueToWeakReference):
        (JSC::timeToLive):
        (JSC::CodeBlock::shouldJettisonDueToOldAge):
        * interpreter/CallFrame.h:
        (JSC::ExecState::callee):
        (JSC::ExecState::unsafeCallee):
        (JSC::ExecState::codeBlock):
        (JSC::ExecState::addressOfCodeBlock):
        (JSC::ExecState::unsafeCodeBlock):
        (JSC::ExecState::scope):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setUpCall):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::installCode):
        (JSC::setupJIT):
        (JSC::ScriptExecutable::prepareForExecutionImpl):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::prepareForExecution):
        * runtime/Options.h:

2016-08-04  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] JSModuleNamespaceObject's Symbol.iterator function should have name
        https://bugs.webkit.org/show_bug.cgi?id=160549

        Reviewed by Saam Barati.

        ES6 Module's namespace[Symbol.iterator] function should have the name, "[Symbol.iterator]".

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

2016-08-04  Keith Miller  <keith_miller@apple.com>

        ASSERTION FAILED: !hasInstanceValueNode->isCellConstant() || defaultHasInstanceFunction == hasInstanceValueNode->asCell()
        https://bugs.webkit.org/show_bug.cgi?id=160562
        <rdar://problem/27704825>

        Reviewed by Mark Lam.

        This patch fixes an issue where we would emit incorrect code in the DFG when constant folding would
        convert a GetByOffset into a constant late in compilation. Additionally, it removes invalid assertions
        associated with the assumption that this could not happen.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileOverridesHasInstance): Deleted.

2016-08-04  Keith Miller  <keith_miller@apple.com>

        Remove unused intrinsic member of NativeExecutable
        https://bugs.webkit.org/show_bug.cgi?id=160560

        Reviewed by Saam Barati.

        NativeExecutable has an Intrinsic member. It appears that this member is never
        used. Instead we use the Intrinsic member NativeExecutable's super class,
        ExecutableBase.

        * runtime/Executable.h:

2016-08-04  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Speed up InPlaceAbstractState::endBasicBlock()
        https://bugs.webkit.org/show_bug.cgi?id=160539

        Reviewed by Mark Lam.

        This patch does small improvements to our handling
        of value propagation to the successors.

        One key insight is that using HashMap to map Nodes
        to Value in valuesAtTail is too inefficient at the scale
        we use it. Instead, I reuse our existing mapping
        from every Node to its value, abstracted by forNode().

        Since we are not going to use the mapping after endBasicBlock()
        I can replace whatever we had there. The next beginBasicBlock()
        will setup the new value as needed.

        In endBasicBlock(), valuesAtTail is now a vector of all values live
        at tail. For each node, I merge the previous live at tail with
        the new value, then replace the value in the mapping.
        Liveness Analysis guarantees we won't have duplicates there which
        make the replacement sound.

        Next, when propagating, I take the vector of values lives at head
        and use the global node->value mapping to find its new abstract value.
        Again, Liveness Analysis guarantees I won't find a value live at head
        that was not replaced by the merging at tail of the predecessor.

        All our live lists have become vectors instead of HashTable.
        The mapping from Node to Value is always done by array indexing.
        Same big-O, much smaller constant.

        * dfg/DFGAtTailAbstractState.cpp:
        (JSC::DFG::AtTailAbstractState::AtTailAbstractState):
        (JSC::DFG::AtTailAbstractState::createValueForNode):
        (JSC::DFG::AtTailAbstractState::forNode):
        * dfg/DFGAtTailAbstractState.h:
        I did not look much into this state, I just made it equivalent
        to the previous mapping.

        * dfg/DFGBasicBlock.h:
        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::CFAPhase::performBlockCFA):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::endBasicBlock):

        (JSC::DFG::InPlaceAbstractState::mergeStateAtTail):
        AbstractValue is big enough that we really don't want to copy it twice.

        (JSC::DFG::InPlaceAbstractState::merge):
        (JSC::DFG::setLiveValues): Deleted.
        * dfg/DFGInPlaceAbstractState.h:

        * dfg/DFGPhiChildren.h:
        This is heap allocated by AbstractInterpreter. It should use fastMalloc().

2016-08-04  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES7] Update features.json for exponentiation expression
        https://bugs.webkit.org/show_bug.cgi?id=160541

        Reviewed by Mark Lam.

        * features.json:

2016-08-03  Chris Dumez  <cdumez@apple.com>

        Drop DocumentType.internalSubset attribute
        https://bugs.webkit.org/show_bug.cgi?id=160530

        Reviewed by Alex Christensen.

        Drop DocumentType.internalSubset attribute.

        * inspector/protocol/DOM.json:

2016-08-03  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Improve the memory locality of DFG Node's AbstractValues
        https://bugs.webkit.org/show_bug.cgi?id=160443

        Reviewed by Mark Lam.

        The AbstractInterpreter spends a lot of time on memory operations
        for AbstractValues. This patch attempts to improve the situation
        by putting the values closer together in memory.

        First, AbstractValue is moved out of DFG::Node and it kept in
        a vector addressed by node indices.

        I initially moved them to InPlaceAbstractState but I quickly discovered
        initializing the values in the vector was costly.
        I moved the vector to Graph as a cache shared by every instantiation of
        InPlaceAbstractState. It is mainly there to avoid constructors and destructors
        of AbstractValue. The patch of https://bugs.webkit.org/show_bug.cgi?id=160370
        should also help eventually.

        I instrumented CFA to find how packed is SparseCollection.
        The answer is it can be very sparse, which is bad for CFA.
        I added packIndices() to repack the collection before running
        liveness since that's where we start using the memory intensively.
        This is a measurable improvement but it implies we can no longer
        keep indices on a side channel between phases since they may change.

        * b3/B3SparseCollection.h:
        (JSC::B3::SparseCollection::packIndices):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::packNodeIndices):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::abstractValuesCache):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::InPlaceAbstractState):
        * dfg/DFGInPlaceAbstractState.h:
        (JSC::DFG::InPlaceAbstractState::forNode):
        * dfg/DFGLivenessAnalysisPhase.cpp:
        (JSC::DFG::performLivenessAnalysis):
        * dfg/DFGNode.h:

2016-08-03  Caitlin Potter  <caitp@igalia.com>

        Clarify SyntaxErrors around yield and unskip tests
        https://bugs.webkit.org/show_bug.cgi?id=158460

        Reviewed by Saam Barati.

        Fix and unskip tests which erroneously asserted that `yield` is not a
        valid BindingIdentifier, and improve error message for YieldExpressions
        occuring in Arrow formal parameters.

        * parser/Parser.cpp:
        (JSC::Scope::MaybeParseAsGeneratorForScope::MaybeParseAsGeneratorForScope):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseYieldExpression):
        * parser/Parser.h:

2016-08-03  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(r203368): broke some test262 tests
        https://bugs.webkit.org/show_bug.cgi?id=160479

        Reviewed by Mark Lam.
        
        The optimization in r203368 overlooked a subtle detail: freezing should not set ReadOnly on
        Accessor properties.

        * runtime/Structure.cpp:
        (JSC::Structure::nonPropertyTransition):
        * runtime/StructureTransitionTable.h:
        (JSC::setsDontDeleteOnAllProperties):
        (JSC::setsReadOnlyOnNonAccessorProperties):
        (JSC::setsReadOnlyOnAllProperties): Deleted.

2016-08-03  Csaba Osztrogonác  <ossy@webkit.org>

        Lacking support on a arm-traditional disassembler.
        https://bugs.webkit.org/show_bug.cgi?id=123717

        Reviewed by Mark Lam.

        * CMakeLists.txt:
        * disassembler/ARMLLVMDisassembler.cpp: Added, based on pre r196729 LLVMDisassembler, but it is ARM traditional only now.
        (JSC::tryToDisassemble):

2016-08-03  Saam Barati  <sbarati@apple.com>

        Implement nested rest destructuring w.r.t the ES7 spec
        https://bugs.webkit.org/show_bug.cgi?id=160423

        Reviewed by Filip Pizlo.

        The spec has updated the BindingRestElement grammar production to be:
        BindingRestElement:
           BindingIdentifier
           BindingingPattern.

        It used to only allow BindingIdentifier in the grammar production.
        I've updated our engine to account for this. The semantics are exactly
        what you'd expect.  For example:
        `let [a, ...[b, ...c]] = expr();`
        means that we create an array for the first rest element `...[b, ...c]`
        and then perform the binding of `[b, ...c]` to that array. And so on, 
        applied recursively through the pattern.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::RestParameterNode::collectBoundIdentifiers):
        (JSC::RestParameterNode::toString):
        (JSC::RestParameterNode::bindValue):
        (JSC::RestParameterNode::emit):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createBindingLocation):
        (JSC::ASTBuilder::createRestParameter):
        (JSC::ASTBuilder::createAssignmentElement):
        * parser/NodeConstructors.h:
        (JSC::AssignmentElementNode::AssignmentElementNode):
        (JSC::RestParameterNode::RestParameterNode):
        (JSC::DestructuringAssignmentNode::DestructuringAssignmentNode):
        * parser/Nodes.h:
        (JSC::RestParameterNode::name): Deleted.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        (JSC::Parser<LexerType>::parseFormalParameters):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::operatorStackPop):

2016-08-03  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Fix Windows build after r204065

        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::observeTransitions):
        AbstractValue is bigger on Windows for an unknown reason.

2016-08-02  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Fix 32bits jsc after r204065

        Default constructed JSValue() are not equal to zero in 32bits.

        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::AbstractValue):

2016-08-02  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Simplify the initialization of AbstractValue in the AbstractInterpreter
        https://bugs.webkit.org/show_bug.cgi?id=160370

        Reviewed by Saam Barati.

        We use a ton of AbstractValue to run the Abstract Interpreter.

        When we set up the initial values, the compiler sets
        a zero on a first word, a one on a second word, and a zero
        again on a third word.
        Since no vector or double-store can deal with 3 words, unrolling
        is done by repeating those instructions.

        The reason for the one was TinyPtrSet. It needed a flag for
        empty value to identify the set as thin. I flipped the flag to "fat"
        to make sure TinyPtrSet is initialized to zero.

        With that done, I just had to clean some places to make
        the initialization shorter.
        It makes the binary easier to follow but this does not help with
        the bigger problem: the time spent per block on Abstract Interpreter.

        * bytecode/Operands.h:
        The traits were useless, no client code defines it.

        (JSC::Operands::Operands):
        (JSC::Operands::ensureLocals):
        Because of the size of the function, llvm is not inlining it.
        We were literally loading 3 registers from memory and storing
        them in the vector.
        Now that AbstractValue has a VectorTraits, we should just rely
        on the memset of Vector when possible.

        (JSC::Operands::getLocal):
        (JSC::Operands::setArgumentFirstTime):
        (JSC::Operands::setLocalFirstTime):
        (JSC::Operands::clear):
        (JSC::OperandValueTraits::defaultValue): Deleted.
        (JSC::OperandValueTraits::isEmptyForDump): Deleted.
        * bytecode/OperandsInlines.h:
        (JSC::Operands<T>::dumpInContext):
        (JSC::Operands<T>::dump):
        (JSC::Traits>::dumpInContext): Deleted.
        (JSC::Traits>::dump): Deleted.
        * dfg/DFGAbstractValue.cpp:
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::AbstractValue):

2016-08-02  Saam Barati  <sbarati@apple.com>

        update a class extending null w.r.t the ES7 spec
        https://bugs.webkit.org/show_bug.cgi?id=160417

        Reviewed by Keith Miller.

        When a class extends null, it should not be marked as a derived class.
        This was changed in the ES2016 spec, and this patch makes the needed
        changes in JSC to follow the spec. This allows classes to extend
        null and have their default constructor invoked without throwing an exception.
        This also prevents |this| from being under TDZ at the start of the constructor.
        Because ES6 allows arbitrary expressions in the `class <ident> extends <expr>`
        syntax, we don't know statically if a constructor is extending null or not.
        Therefore, we don't always know statically if it's a base or derived constructor.
        I solved this by putting a boolean on the constructor function under a private
        symbol named isDerivedConstructor when doing class construction. We only need
        to put this boolean on constructors that may extend null. Constructors that are
        declared in a class with no extends syntax can tell statically that they are a base constructor.

        I've also renamed the ConstructorKind::Derived enum value to be
        ConstructorKind::Extends to better indicate that we can't answer
        the "am I a derived constructor?" question statically.

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createDefaultConstructor):
        * builtins/BuiltinNames.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::emitReturn):
        (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::ensureThis):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::makeFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::EvalFunctionCallNode::emitBytecode):
        (JSC::FunctionCallValueNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode):
        (JSC::ClassExprNode::emitBytecode):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/ParserModes.h:

2016-08-02  Enrica Casucci  <enrica@apple.com>

        Allow building with content filtering disabled.
        https://bugs.webkit.org/show_bug.cgi?id=160454

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig:

2016-08-02  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Disable Inline Caching on ARMv7 traditional until proper fix
        https://bugs.webkit.org/show_bug.cgi?id=159759

        Reviewed by Saam Barati.

        * jit/JITMathIC.h:
        (JSC::JITMathIC::generateInline):

2016-08-01  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION (r203990): JSC Debug test stress/arity-check-ftl-throw.js failing
        https://bugs.webkit.org/show_bug.cgi?id=160438

        Reviewed by Mark Lam.
        
        In r203990 I fixed a bug where CommonSlowPaths.h/arityCheckFor() was basically failing at
        catching stack overflow due to large parameter count. It would only catch regular old stack
        overflow, like if the frame pointer was already past the limit.
        
        This had a secondary problem: unfortunately all of our tests for what happens when you overflow
        the stack due to large parameter count were not going down that path at all, so we haven't had
        test coverage for this in ages.  There were bugs in all tiers of the engine when handling this
        case.

        We need to be able to roll back the topCallFrame on paths that are meant to throw an exception
        from the caller. Otherwise, we'd crash in StackVisitor because it would see a busted stack
        frame. Rolling back like this "just works" except when the caller is the VM entry frame. I had
        some choices here. I could have forced anyone who is rolling back to always skip VM entry
        frames. They can't do it in a way that changes the value of VM::topVMEntryFrame, which is what
        a stack frame roll back normally does, since exception unwinding needs to see the current value
        of topVMEntryFrame. So, we have a choice to either try to magically avoid all of the paths that
        look at topCallFrame, or give topCallFrame a state that unambiguously signals that we are
        sitting right on top of a VM entry frame without having succeeded at making a JS call. The only
        place that really needs to know is StackVisitor, which wants to start scanning at topCallFrame.
        To signal this, I could have either made topCallFrame point to the real top JS call frame
        without also rolling back topVMEntryFrame, or I could make topCallFrame == topVMEntryFrame. The
        latter felt somehow cleaner. I filed a bug (https://bugs.webkit.org/show_bug.cgi?id=160441) for
        converting topCallFrame to a void*, which would give us a chance to harden the rest of the
        engine against this case.
        
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::StackVisitor):
        We may do ShadowChicken processing, which invokes StackVisitor, when we have topCallFrame
        pointing at topVMEntryFrame. This teaches StackVisitor how to handle this case. I believe that
        StackVisitor is the only place that needs to be taught about this at this time, because it's
        one of the few things that access topCallFrame along this special path.
        
        * jit/JITOperations.cpp: Roll back the top call frame.
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL): Roll back the top call frame.

2016-08-01  Benjamin Poulain  <bpoulain@apple.com>

        [JSC][ARM64] Fix branchTest32/64 taking an immediate as mask
        https://bugs.webkit.org/show_bug.cgi?id=160439

        Reviewed by Filip Pizlo.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::branchTest64):
        * b3/air/AirOpcode.opcodes:
        Fix the ARM64 codegen to lower BitImm64 without using a scratch register.

2016-07-22  Filip Pizlo  <fpizlo@apple.com>

        [B3] Fusing immediates into test instructions should work again
        https://bugs.webkit.org/show_bug.cgi?id=160073

        Reviewed by Sam Weinig.

        When we introduced BitImm, we forgot to change the Branch(BitAnd(value, constant))
        fusion.  This emits test instructions, so it should use BitImm for the constant.  But it
        was still using Imm!  This meant that isValidForm() always returned false.
        
        This fixes the code path to use BitImm, and turns off our use of BitImm64 on x86 since
        it provides no benefit on x86 and has some risk (the code appears to play fast and loose
        with the scratch register).
        
        This is not an obvious progression on anything, so I added comprehensive tests to
        testb3, which check that we selected the optimal instruction in a variety of situations.
        We should add more tests like this!

        Rolling this back in after fixing ARM64. The bug was that branchTest32|64 on ARM64 doesn't
        actually support BitImm or BitImm64, at least not yet. Disabling that in AirOpcodes makes
        this patch not a regression on ARM64. That change was reviewed by Benjamin Poulain.

        * b3/B3BasicBlock.h:
        (JSC::B3::BasicBlock::successorBlock):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createGenericCompare):
        * b3/B3LowerToAir.h:
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::isRepresentableAs):
        (JSC::B3::Air::Arg::usesTmp):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isRepresentableAs):
        (JSC::B3::Air::Arg::castToType):
        (JSC::B3::Air::Arg::asNumber):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::size):
        (JSC::B3::Air::Code::at):
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirValidate.h:
        * b3/air/opcode_generator.rb:
        * b3/testb3.cpp:
        (JSC::B3::compile):
        (JSC::B3::compileAndRun):
        (JSC::B3::lowerToAirForTesting):
        (JSC::B3::testSomeEarlyRegister):
        (JSC::B3::testBranchBitAndImmFusion):
        (JSC::B3::zero):
        (JSC::B3::run):

2016-08-01  Filip Pizlo  <fpizlo@apple.com>

        Rationalize varargs stack overflow checks
        https://bugs.webkit.org/show_bug.cgi?id=160425

        Reviewed by Michael Saboff.

        * ftl/FTLLink.cpp:
        (JSC::FTL::link): AboveOrEqual 0 is a tautology. The code meant GreaterThanOrEqual, since the error code is -1.
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor): Use roundUpToMultipleOf(), which is almost certainly what we meant when we said %.

2016-08-01  Saam Barati  <sbarati@apple.com>

        Sub should be a Math IC
        https://bugs.webkit.org/show_bug.cgi?id=160270

        Reviewed by Mark Lam.

        This makes Sub an IC like Mul and Add. I'm seeing the following
        improvements of average Sub size on Unity and JetStream:

                   |   JetStream  |  Unity 3D  |
             ------| -------------|--------------
              Old  |   202 bytes  |  205 bytes |
             ------| -------------|--------------
              New  |   134  bytes |  134 bytes |
             ------------------------------------

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::addJITMulIC):
        (JSC::CodeBlock::addJITSubIC):
        (JSC::CodeBlock::findStubInfo):
        (JSC::CodeBlock::dumpMathICStats):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::stubInfoBegin):
        (JSC::CodeBlock::stubInfoEnd):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithSub):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_sub):
        (JSC::JIT::emitSlow_op_sub):
        (JSC::JIT::emit_op_pow):
        * jit/JITMathIC.h:
        * jit/JITMathICForwards.h:
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITSubGenerator.cpp:
        (JSC::JITSubGenerator::generateInline):
        (JSC::JITSubGenerator::generateFastPath):
        * jit/JITSubGenerator.h:
        (JSC::JITSubGenerator::JITSubGenerator):
        (JSC::JITSubGenerator::isLeftOperandValidConstant):
        (JSC::JITSubGenerator::isRightOperandValidConstant):
        (JSC::JITSubGenerator::arithProfile):
        (JSC::JITSubGenerator::didEmitFastPath): Deleted.
        (JSC::JITSubGenerator::endJumpList): Deleted.
        (JSC::JITSubGenerator::slowPathJumpList): Deleted.

2016-08-01  Keith Miller  <keith_miller@apple.com>

        We should not keep the JavaScript tests inside the Source/JavaScriptCore/ directory.
        https://bugs.webkit.org/show_bug.cgi?id=160372

        Rubber stamped by Geoffrey Garen.

        This patch moves all the JavaScript tests from Source/JavaScriptCore/tests to
        a new top level directory, JSTests. Having the tests in the Source directory
        was both confusing an inconvenient for people that just want to checkout the
        source code of WebKit. Since there is no other obvious place to put all the
        JavaScript tests a new top level directory seemed the most sensible.

        * tests/: Deleted.

2016-07-31  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Should check Test262Error correctly
        https://bugs.webkit.org/show_bug.cgi?id=159862

        Reviewed by Saam Barati.

        Test262Error in the harness does not have "name" property.
        Rather than checking "name" property, peforming `instanceof` is better to check the class of the exception.

        * jsc.cpp:
        (checkUncaughtException):
        * runtime/JSObject.h:
        * tests/test262.yaml:

2016-07-31  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Module binding can be exported by multiple names
        https://bugs.webkit.org/show_bug.cgi?id=160343

        Reviewed by Saam Barati.

        ES6 Module can export the same local binding by using multiple names.
        For example,

            ```
            var value = 42;

            export { value };
            export { value as value2 };
            ```

        Currently, we only allowed one local binding to be exported with one name. So, in the above case,
        the local binding "value" is exported as "value2" and "value" name is not exported. This is wrong.

        To fix this issue, we collect the correspondence (local name => exported name) to the local bindings
        in the parser. Previously, we only maintained the exported local bindings in the parser. And utilize
        this information when creating the export entries in ModuleAnalyzer.

        And this patch also moves ModuleScopeData from the Scope object to the Parser class since exported
        names should be managed per-module, not per-scope.

        This change fixes several test262 failures.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * parser/ModuleAnalyzer.cpp:
        (JSC::ModuleAnalyzer::exportVariable):
        (JSC::ModuleAnalyzer::analyze):
        (JSC::ModuleAnalyzer::exportedBinding): Deleted.
        (JSC::ModuleAnalyzer::declareExportAlias): Deleted.
        * parser/ModuleAnalyzer.h:
        * parser/ModuleScopeData.h: Copied from Source/JavaScriptCore/parser/ModuleAnalyzer.h.
        (JSC::ModuleScopeData::create):
        (JSC::ModuleScopeData::exportedBindings):
        (JSC::ModuleScopeData::exportName):
        (JSC::ModuleScopeData::exportBinding):
        * parser/Nodes.cpp:
        (JSC::ProgramNode::ProgramNode):
        (JSC::ModuleProgramNode::ModuleProgramNode):
        (JSC::EvalNode::EvalNode):
        (JSC::FunctionNode::FunctionNode):
        * parser/Nodes.h:
        (JSC::ModuleProgramNode::moduleScopeData):
        * parser/NodesAnalyzeModule.cpp:
        (JSC::ExportDefaultDeclarationNode::analyzeModule):
        (JSC::ExportNamedDeclarationNode::analyzeModule): Deleted.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseModuleSourceElements):
        (JSC::Parser<LexerType>::parseVariableDeclarationList):
        (JSC::Parser<LexerType>::createBindingPattern):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClassDeclaration):
        (JSC::Parser<LexerType>::parseExportSpecifier):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        * parser/Parser.h:
        (JSC::Parser::exportName):
        (JSC::Parser<LexerType>::parse):
        (JSC::ModuleScopeData::create): Deleted.
        (JSC::ModuleScopeData::exportedBindings): Deleted.
        (JSC::ModuleScopeData::exportName): Deleted.
        (JSC::ModuleScopeData::exportBinding): Deleted.
        (JSC::Scope::Scope): Deleted.
        (JSC::Scope::setSourceParseMode): Deleted.
        (JSC::Scope::moduleScopeData): Deleted.
        (JSC::Scope::setIsModule): Deleted.
        * tests/modules/aliased-names.js: Added.
        * tests/modules/aliased-names/main.js: Added.
        (change):
        * tests/stress/modules-syntax-error-with-names.js:
        (export.Cocoa):
        (SyntaxError.Cannot.export.a.duplicate.name):
        * tests/test262.yaml:

2016-07-30  Mark Lam  <mark.lam@apple.com>

        Assertion failure while setting the length of an ArrayClass array.
        https://bugs.webkit.org/show_bug.cgi?id=160381
        <rdar://problem/27328703>

        Reviewed by Filip Pizlo.

        When setting large length values, we're currently treating ArrayClass as a
        ContiguousIndexingType array.  This results in an assertion failure.  This is
        now fixed.

        There are currently only 2 places where we create arrays with indexing type
        ArrayClass: ArrayPrototype and RuntimeArray.  The fix in JSArray:;setLength()
        takes care of ArrayPrototype.

        RuntimeArray already checks for the setting of its length property, and will
        throw a RangeError.  Hence, there's no change is needed for the RuntimeArray.
        Instead, I added some test cases ensure that the check and throw behavior does
        not change without notice.

        * runtime/JSArray.cpp:
        (JSC::JSArray::setLength):
        * tests/stress/array-setLength-on-ArrayClass-with-large-length.js: Added.
        (toString):
        (assertEqual):
        * tests/stress/array-setLength-on-ArrayClass-with-small-length.js: Added.
        (toString):
        (assertEqual):

2016-07-29  Keith Miller  <keith_miller@apple.com>

        TypedArray super constructor has some incompatabilities
        https://bugs.webkit.org/show_bug.cgi?id=160369

        Reviewed by Filip Pizlo.

        This patch fixes the length proprety of the TypedArray super constructor.
        Additionally, the TypedArray super constructor should no longer be callable.

        Also, this patch fixes the expected result of some test262 tests.

        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::JSTypedArrayViewConstructor::finishCreation):
        (JSC::constructTypedArrayView):
        (JSC::JSTypedArrayViewConstructor::getCallData):
        * tests/test262.yaml:

2016-07-29  Jonathan Bedard  <jbedard@apple.com>

        Undefined Behavior in JSValue cast from NaN
        https://bugs.webkit.org/show_bug.cgi?id=160322

        Reviewed by Mark Lam.

        JSValues can be constructed from doubles, and in some cases, are deliberately constructed with NaN values.

        In circumstances where NaN is bound through the default JSValue constructor, however, an undefined conversion
        to int32_t occurs.  While the subsequent if statement should fail and construct the JSValue through the explicit
        double constructor, given that the deliberate use of NaN is fairly common, it seems that the jsNaN() function
        should immediately call the explicit double constructor both for efficiency and to prevent inadvertent
        suppressing of any other bugs which may be instantiating a JSValue with a NaN double.

        * runtime/JSCJSValueInlines.h:
        (JSC::jsNaN): Explicit double construction for NaN JSValues to avoid undefined behavior.

2016-07-29  Michael Saboff  <msaboff@apple.com>

        Refactor DFG::Node::hasLocal() to accessesStack()
        https://bugs.webkit.org/show_bug.cgi?id=160357

        Reviewed by Filip Pizlo.

        Refactoring in preparation for using register arguments for JavaScript calls.

        Renamed Node::hasLocal() to Node::accessesStack() and changed all uses accordingly.
        Also changed uses of Node::hasVariableAccessData() to accessesStack() where that
        use guards stack operation logic associated with the Node's VariableAccessData.

        The hasVariableAccessData() check now implies no more than the node has a
        VariableAccessData and nothing about its use of that data to coordinate stack   
        accesses.

        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
        (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock):
        * dfg/DFGMaximalFlushInsertionPhase.cpp:
        (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
        (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::containsMovHint):
        (JSC::DFG::Node::accessesStack):
        (JSC::DFG::Node::hasLocal): Deleted.
        * dfg/DFGPredictionInjectionPhase.cpp:
        (JSC::DFG::PredictionInjectionPhase::run):
        * dfg/DFGValidate.cpp:

2016-07-29  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Use the same data structures for DFG and Air Liveness Analysis
        https://bugs.webkit.org/show_bug.cgi?id=160346

        Reviewed by Geoffrey Garen.

        In Air, we minimized memory accesses during liveness analysis
        with a couple of tricks:
        -Use a single Sparse Set ADT for the live value of each block.
        -Manipulate compact positive indices instead of hashing values.

        This patch brings the same ideas to DFG.

        This patch still uses the same fixpoint algorithms.
        The reason is Edge's KillStatus used by other phases. We cannot
        use a block-boundary liveness algorithm and update KillStatus
        simultaneously. It's something I'll probably revisit at some point.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::forAllValues):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::dump):
        * dfg/DFGBasicBlock.h:
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::maxNodeCount):
        (JSC::DFG::Graph::nodeAt):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::setLiveValues):
        (JSC::DFG::InPlaceAbstractState::endBasicBlock):
        * dfg/DFGLivenessAnalysisPhase.cpp:
        (JSC::DFG::LivenessAnalysisPhase::LivenessAnalysisPhase):
        (JSC::DFG::LivenessAnalysisPhase::run):
        (JSC::DFG::LivenessAnalysisPhase::processBlock):
        (JSC::DFG::LivenessAnalysisPhase::addChildUse):
        (JSC::DFG::LivenessAnalysisPhase::process): Deleted.

2016-07-29  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, ByValInfo is only used in JIT enabled environments
        https://bugs.webkit.org/show_bug.cgi?id=158908

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::stronglyVisitStrongReferences):

2016-07-28  Yusuke Suzuki  <utatane.tea@gmail.com>

        JSC::Symbol should be hash-consed
        https://bugs.webkit.org/show_bug.cgi?id=158908

        Reviewed by Filip Pizlo.

        Previously, SymbolImpls held by symbols represent identity of symbols.
        When we check the equality between symbols, we need to load SymbolImpls of symbols and compare them.

        This patch performs hash-consing onto the symbols. We cache symbols in per-VM's SymbolImpl-keyed WeakGCMap.
        When creating a new symbol from SymbolImpl, we first query to this map and reuse the previously created symbol
        if it is found. This ensures that one-on-one correspondence between SymbolImpl and symbol. So now, we can use
        pointer-comparison to query the equality of symbols.

        This change drops SymbolImpl loads when checking the equality. Furthermore, we can use DFG CheckCell to symbol
        when we would like to ensure that the given value is the expected symbol. This cleans up GetByVal's symbol-keyd
        caching. Then, we changed CheckIdent to CheckStringIdent since it only checks the string case now. The symbol
        case is handled by CheckCell.

        Additionally, this patch also cleans up Map / Set implementation since we can use the logic for JSCell to symbols.

        The performance effects in the related benchmarks are the followings.

                                                               baseline                   patch

            bigswitch-indirect-symbol-or-undefined         85.6214+-1.0063     ^     63.0522+-0.8615        ^ definitely 1.3579x faster
            bigswitch-indirect-symbol                      84.9653+-0.6258     ^     80.4900+-0.8008        ^ definitely 1.0556x faster
            fold-put-by-val-with-symbol-to-multi-put-by-offset
                                                            9.4396+-0.3726            9.2941+-0.3311          might be 1.0157x faster
            inlined-put-by-val-with-symbol-transition
                                                           49.5477+-0.2401     ?     49.7533+-0.3369        ?
            get-by-val-with-symbol-self-or-proto           11.9740+-0.0798     ?     12.1706+-0.2723        ? might be 1.0164x slower
            get-by-val-with-symbol-quadmorphic-check-structure-elimination-simple
                                                            4.1364+-0.0841            4.0872+-0.0925          might be 1.0120x faster
            put-by-val-with-symbol                         11.3709+-0.0223           11.3613+-0.0264
            get-by-val-with-symbol-proto-or-self           11.8984+-0.0706     ?     11.9030+-0.0787        ?
            polymorphic-put-by-val-with-symbol             31.4176+-0.0558           31.3825+-0.0447
            implicit-bigswitch-indirect-symbol             61.3115+-0.6577     ^     58.0098+-0.1212        ^ definitely 1.0569x faster
            get-by-val-with-symbol-bimorphic-check-structure-elimination-simple
                                                            3.3139+-0.0565     ^      2.9947+-0.0732        ^ definitely 1.1066x faster
            get-by-val-with-symbol-chain-from-try-block
                                                            2.2316+-0.0179            2.2137+-0.0210
            get-by-val-with-symbol-bimorphic-check-structure-elimination
                                                           10.6031+-0.2216     ^     10.0939+-0.1977        ^ definitely 1.0504x faster
            get-by-val-with-symbol-check-structure-elimination
                                                            8.5576+-0.1521     ^      7.7107+-0.1308        ^ definitely 1.1098x faster
            put-by-val-with-symbol-slightly-polymorphic
                                                            3.1957+-0.0538     ^      2.9181+-0.0708        ^ definitely 1.0951x faster
            put-by-val-with-symbol-replace-and-transition
                                                           11.8253+-0.0757     ^     11.6590+-0.0351        ^ definitely 1.0143x faster

            <geometric>                                    13.3911+-0.0527     ^     12.7376+-0.0457        ^ definitely 1.0513x faster

        * bytecode/ByValInfo.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::stronglyVisitStrongReferences):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * 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/DFGNode.h:
        (JSC::DFG::Node::hasUidOperand):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileSymbolEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleSymbolEquality):
        (JSC::DFG::SpeculativeJIT::compileCheckStringIdent):
        (JSC::DFG::SpeculativeJIT::extractStringImplFromBinarySymbols): Deleted.
        (JSC::DFG::SpeculativeJIT::compileCheckIdent): Deleted.
        (JSC::DFG::SpeculativeJIT::compileSymbolUntypedEquality): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileSymbolUntypedEquality):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileSymbolUntypedEquality):
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckStringIdent):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckIdent): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::lowSymbolUID): Deleted.
        * jit/JIT.h:
        * jit/JITOperations.cpp:
        (JSC::tryGetByValOptimize):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emitPutByValWithCachedId):
        (JSC::JIT::emitByValIdentifierCheck):
        (JSC::JIT::privateCompileGetByValWithCachedId):
        (JSC::JIT::privateCompilePutByValWithCachedId):
        (JSC::JIT::emitIdentifierCheck): Deleted.
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emitPutByValWithCachedId):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::dumpInContextAssumingStructure):
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::equalSlowCaseInline):
        (JSC::JSValue::strictEqualSlowCaseInline): Deleted.
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::setFunctionName):
        * runtime/MapData.h:
        * runtime/MapDataInlines.h:
        (JSC::JSIterator>::clear): Deleted.
        (JSC::JSIterator>::find): Deleted.
        (JSC::JSIterator>::add): Deleted.
        (JSC::JSIterator>::remove): Deleted.
        (JSC::JSIterator>::replaceAndPackBackingStore): Deleted.
        * runtime/Symbol.cpp:
        (JSC::Symbol::finishCreation):
        (JSC::Symbol::create):
        * runtime/Symbol.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * tests/stress/symbol-equality-over-gc.js: Added.
        (shouldBe):
        (test):

2016-07-28  Mark Lam  <mark.lam@apple.com>

        ASSERTION FAILED in errorProtoFuncToString() when Error name is a single char string.
        https://bugs.webkit.org/show_bug.cgi?id=160324
        <rdar://problem/27389572>

        Reviewed by Keith Miller.

        The issue is that errorProtoFuncToString() was using jsNontrivialString() to
        generate the error string even when the name string can be a single character
        string.  This is incorrect.  We should be using jsString() instead.

        * runtime/ErrorPrototype.cpp:
        (JSC::errorProtoFuncToString):
        * tests/stress/errors-with-simple-names-or-messages-should-not-crash-toString.js: Added.

2016-07-28  Michael Saboff  <msaboff@apple.com>

        ARM64: Fused left shift with a right shift can create NaNs from integers
        https://bugs.webkit.org/show_bug.cgi?id=160329

        Reviewed by Geoffrey Garen.

        When we fuse a left shift and a right shift of integers where the shift amounts
        are the same and the size of the quantity being shifted is 8 bits, we rightly
        generate a sign extend byte instruction.  On ARM64, we were sign extending
        to a 64 bit quantity, when we really wanted to sign extend to a 32 bit quantity.

        Checking the ARM64 marco assembler and we were extending to 64 bits for all
        four combinations of zero / sign and 8 / 16 bits.
        
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::zeroExtend16To32):
        (JSC::MacroAssemblerARM64::signExtend16To32):
        (JSC::MacroAssemblerARM64::zeroExtend8To32):
        (JSC::MacroAssemblerARM64::signExtend8To32):
        * tests/stress/regress-160329.js: New test added.
        (narrow):

2016-07-28  Mark Lam  <mark.lam@apple.com>

        StringView should have an explicit m_is8Bit field.
        https://bugs.webkit.org/show_bug.cgi?id=160282
        <rdar://problem/27327943>

        Reviewed by Benjamin Poulain.

        * tests/stress/string-joining-long-strings-should-not-crash.js: Added.
        (catch):

2016-07-28  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Typo fix after r121885
        https://bugs.webkit.org/show_bug.cgi?id=160288

        Reviewed by Zoltan Herczeg.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::maxJumpReplacementSize):

2016-07-28  Csaba Osztrogonác  <ossy@webkit.org>

        64-bit alignment check isn't necessary in ARMAssembler::prepareExecutableCopy after r202214
        https://bugs.webkit.org/show_bug.cgi?id=159711

        Reviewed by Mark Lam.

        * assembler/ARMAssembler.cpp:
        (JSC::ARMAssembler::prepareExecutableCopy):

2016-07-27  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove some unused code from FTL
        https://bugs.webkit.org/show_bug.cgi?id=160285

        Reviewed by Mark Lam.

        All the liveness and swapping is done inside B3,
        this code is no longer needed.

        * dfg/DFGEdge.h:
        (JSC::DFG::Edge::doesNotKill): Deleted.
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::doesKill): Deleted.

2016-07-27  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] DFG::Node should not have its own allocator
        https://bugs.webkit.org/show_bug.cgi?id=160098

        Reviewed by Geoffrey Garen.

        We need some design changes for DFG::Node:
        -Accessing the index must be fast. B3 uses indices for sets
         and maps, it is a lot faster than hashing pointers.
        -We should be able to subclass DFG::Node to specialize it.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAllocator.h: Removed.
        (JSC::DFG::Allocator::Region::size): Deleted.
        (JSC::DFG::Allocator::Region::headerSize): Deleted.
        (JSC::DFG::Allocator::Region::numberOfThingsPerRegion): Deleted.
        (JSC::DFG::Allocator::Region::data): Deleted.
        (JSC::DFG::Allocator::Region::isInThisRegion): Deleted.
        (JSC::DFG::Allocator::Region::regionFor): Deleted.
        (JSC::DFG::Allocator<T>::Allocator): Deleted.
        (JSC::DFG::Allocator<T>::~Allocator): Deleted.
        (JSC::DFG::Allocator<T>::allocate): Deleted.
        (JSC::DFG::Allocator<T>::free): Deleted.
        (JSC::DFG::Allocator<T>::freeAll): Deleted.
        (JSC::DFG::Allocator<T>::reset): Deleted.
        (JSC::DFG::Allocator<T>::indexOf): Deleted.
        (JSC::DFG::Allocator<T>::allocatorOf): Deleted.
        (JSC::DFG::Allocator<T>::bumpAllocate): Deleted.
        (JSC::DFG::Allocator<T>::freeListAllocate): Deleted.
        (JSC::DFG::Allocator<T>::allocateSlow): Deleted.
        (JSC::DFG::Allocator<T>::freeRegionsStartingAt): Deleted.
        (JSC::DFG::Allocator<T>::startBumpingIn): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addToGraph):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
        (JSC::DFG::CPSRethreadingPhase::addPhiSilently):
        * dfg/DFGCleanUpPhase.cpp:
        (JSC::DFG::CleanUpPhase::run):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::run):
        * dfg/DFGConstantHoistingPhase.cpp:
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::fixupBlock):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::deleteNode):
        (JSC::DFG::Graph::killBlockAndItsContents):
        (JSC::DFG::Graph::~Graph): Deleted.
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addNode):
        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::attemptHoist):
        * dfg/DFGLongLivedState.cpp: Removed.
        (JSC::DFG::LongLivedState::LongLivedState): Deleted.
        (JSC::DFG::LongLivedState::~LongLivedState): Deleted.
        (JSC::DFG::LongLivedState::shrinkToFit): Deleted.
        * dfg/DFGLongLivedState.h: Removed.
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::index): Deleted.
        * dfg/DFGNode.h:
        (JSC::DFG::Node::index):
        * dfg/DFGNodeAllocator.h: Removed.
        (operator new ): Deleted.
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPlan.h:
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::runThread):
        * runtime/VM.cpp:
        (JSC::VM::VM): Deleted.
        * runtime/VM.h:

2016-07-27  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Fix a bunch of use-after-free of DFG::Node
        https://bugs.webkit.org/show_bug.cgi?id=160228

        Reviewed by Mark Lam.

        FTL had a few places where we use a node after it has been
        deleted. The dangling pointers come from the SSA liveness information
        kept on the basic blocks.

        This patch fixes the issues I could find and adds liveness invalidation
        to help finding dependencies like these.

        * dfg/DFGBasicBlock.h:
        (JSC::DFG::BasicBlock::SSAData::invalidate):

        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::run):
        Constant folding phase was deleting nodes in the loop over basic blocks.
        The problem is the deleted nodes can be referenced by other blocks.
        When the abstract interpreter was manipulating the abstract values of those
        it was doing so on the dead nodes.

        * dfg/DFGConstantHoistingPhase.cpp:
        Just invalidation. Nothing wrong here since the useless nodes were
        kept live while iterating the blocks.

        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::killBlockAndItsContents):
        (JSC::DFG::Graph::killUnreachableBlocks):
        (JSC::DFG::Graph::invalidateNodeLiveness):

        * dfg/DFGGraph.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        We had a lot of use-after-free in LCIM because we were using the stale
        live nodes deleted by previous phases.

2016-07-27  Keith Miller  <keith_miller@apple.com>

        concatAppendOne should allocate using the indexing type of the array if it cannot merge
        https://bugs.webkit.org/show_bug.cgi?id=160261
        <rdar://problem/27530122>

        Reviewed by Mark Lam.

        Before, if we could not merge the indexing types for copying, we would allocate the
        the array as ArrayWithUndecided. Instead, we should allocate an array with the original
        array's indexing type.

        * runtime/ArrayPrototype.cpp:
        (JSC::concatAppendOne):
        * tests/stress/concat-append-one-with-sparse-array.js: Added.

2016-07-27  Saam Barati  <sbarati@apple.com>

        We don't optimize for-in properly in baseline JIT (maybe other JITs too) with an object with symbols
        https://bugs.webkit.org/show_bug.cgi?id=160211
        <rdar://problem/27572612>

        Reviewed by Geoffrey Garen.

        The fast for-in iteration mode assumes all inline/out-of-line properties
        can be iterated in linear order. This is not true if we have Symbols
        because Symbols should not be iterated by for-in.

        * runtime/Structure.cpp:
        (JSC::Structure::add):
        * tests/stress/symbol-should-not-break-for-in.js: Added.
        (assert):
        (foo):

2016-07-27  Mark Lam  <mark.lam@apple.com>

        The second argument for Function.prototype.apply should be array-like or null/undefined.
        https://bugs.webkit.org/show_bug.cgi?id=160212
        <rdar://problem/27328525>

        Reviewed by Filip Pizlo.

        The spec for Function.prototype.apply says its second argument can only be null,
        undefined, or must be array-like.  See
        https://tc39.github.io/ecma262/#sec-function.prototype.apply and
        https://tc39.github.io/ecma262/#sec-createlistfromarraylike.

        Our previous implementation was not handling this correctly for SymbolType.
        This is now fixed.

        * interpreter/Interpreter.cpp:
        (JSC::sizeOfVarargs):
        * tests/stress/apply-second-argument-must-be-array-like.js: Added.

2016-07-27  Saam Barati  <sbarati@apple.com>

        MathICs should be able to emit only a jump along the inline path when they don't have any type data
        https://bugs.webkit.org/show_bug.cgi?id=160110

        Reviewed by Mark Lam.

        This patch allows for MathIC fast-path generation to be delayed.
        We delay when we don't see any observed type information for
        the lhs/rhs operand, which implies that the MathIC has never
        executed. This is profitable for two main reasons:
        1. If the math operation never executes, we emit much less code.
        2. Once we get type information for the lhs/rhs, we can emit better code.

        To implement this, we just emit a jump to the slow path call
        that will repatch on first execution.

        New data for add:
                   |   JetStream  |  Unity 3D  |
             ------| -------------|--------------
              Old  |   148 bytes  |  143 bytes |
             ------| -------------|--------------
              New  |   116  bytes |  113 bytes |
             ------------------------------------

        New data for mul:
                   |   JetStream  |  Unity 3D  |
             ------| -------------|--------------
              Old  |   210 bytes  |  185 bytes |
             ------| -------------|--------------
              New  |   170  bytes |  137 bytes |
             ------------------------------------

        * jit/JITAddGenerator.cpp:
        (JSC::JITAddGenerator::generateInline):
        * jit/JITAddGenerator.h:
        (JSC::JITAddGenerator::isLeftOperandValidConstant):
        (JSC::JITAddGenerator::isRightOperandValidConstant):
        (JSC::JITAddGenerator::arithProfile):
        * jit/JITMathIC.h:
        (JSC::JITMathIC::generateInline):
        (JSC::JITMathIC::generateOutOfLine):
        (JSC::JITMathIC::finalizeInlineCode):
        * jit/JITMathICInlineResult.h:
        * jit/JITMulGenerator.cpp:
        (JSC::JITMulGenerator::generateInline):
        * jit/JITMulGenerator.h:
        (JSC::JITMulGenerator::isLeftOperandValidConstant):
        (JSC::JITMulGenerator::isRightOperandValidConstant):
        (JSC::JITMulGenerator::arithProfile):
        * jit/JITOperations.cpp:

2016-07-26  Saam Barati  <sbarati@apple.com>

        rollout r203666
        https://bugs.webkit.org/show_bug.cgi?id=160226

        Unreviewed rollout.

        * b3/B3BasicBlock.h:
        (JSC::B3::BasicBlock::successorBlock):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createGenericCompare):
        * b3/B3LowerToAir.h:
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::isRepresentableAs):
        (JSC::B3::Air::Arg::usesTmp):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isRepresentableAs):
        (JSC::B3::Air::Arg::asNumber):
        (JSC::B3::Air::Arg::castToType): Deleted.
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::size):
        (JSC::B3::Air::Code::at):
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirValidate.h:
        * b3/air/opcode_generator.rb:
        * b3/testb3.cpp:
        (JSC::B3::compileAndRun):
        (JSC::B3::testSomeEarlyRegister):
        (JSC::B3::zero):
        (JSC::B3::run):
        (JSC::B3::lowerToAirForTesting): Deleted.
        (JSC::B3::testBranchBitAndImmFusion): Deleted.

2016-07-26  Caitlin Potter  <caitp@igalia.com>

        [JSC] Object.getOwnPropertyDescriptors should not add undefined props to result
        https://bugs.webkit.org/show_bug.cgi?id=159409

        Reviewed by Geoffrey Garen.

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetOwnPropertyDescriptors):
        * tests/es6.yaml:
        * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors-proxy.js:
        (testPropertiesIndexedSetterOnPrototypeThrows.set get var): Deleted.
        (testPropertiesIndexedSetterOnPrototypeThrows): Deleted.
        * tests/stress/Object_static_methods_Object.getOwnPropertyDescriptors-proxy.js: Renamed from Source/JavaScriptCore/tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors-proxy.js.
        * tests/stress/Object_static_methods_Object.getOwnPropertyDescriptors.js: Renamed from Source/JavaScriptCore/tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js.

2016-07-26  Mark Lam  <mark.lam@apple.com>

        Remove unused DEBUG_WITH_BREAKPOINT configuration.
        https://bugs.webkit.org/show_bug.cgi?id=160203

        Reviewed by Keith Miller.

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

2016-07-25  Benjamin Poulain  <benjamin@webkit.org>

        Unreviewed, rolling out r203703.

        It breaks some internal tests

        Reverted changeset:

        "[JSC] DFG::Node should not have its own allocator"
        https://bugs.webkit.org/show_bug.cgi?id=160098
        http://trac.webkit.org/changeset/203703

2016-07-25  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] DFG::Node should not have its own allocator
        https://bugs.webkit.org/show_bug.cgi?id=160098

        Reviewed by Geoffrey Garen.

        We need some design changes for DFG::Node:
        -Accessing the index must be fast. B3 uses indices for sets
         and maps, it is a lot faster than hashing pointers.
        -We should be able to subclass DFG::Node to specialize it.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAllocator.h: Removed.
        (JSC::DFG::Allocator::Region::size): Deleted.
        (JSC::DFG::Allocator::Region::headerSize): Deleted.
        (JSC::DFG::Allocator::Region::numberOfThingsPerRegion): Deleted.
        (JSC::DFG::Allocator::Region::data): Deleted.
        (JSC::DFG::Allocator::Region::isInThisRegion): Deleted.
        (JSC::DFG::Allocator::Region::regionFor): Deleted.
        (JSC::DFG::Allocator<T>::Allocator): Deleted.
        (JSC::DFG::Allocator<T>::~Allocator): Deleted.
        (JSC::DFG::Allocator<T>::allocate): Deleted.
        (JSC::DFG::Allocator<T>::free): Deleted.
        (JSC::DFG::Allocator<T>::freeAll): Deleted.
        (JSC::DFG::Allocator<T>::reset): Deleted.
        (JSC::DFG::Allocator<T>::indexOf): Deleted.
        (JSC::DFG::Allocator<T>::allocatorOf): Deleted.
        (JSC::DFG::Allocator<T>::bumpAllocate): Deleted.
        (JSC::DFG::Allocator<T>::freeListAllocate): Deleted.
        (JSC::DFG::Allocator<T>::allocateSlow): Deleted.
        (JSC::DFG::Allocator<T>::freeRegionsStartingAt): Deleted.
        (JSC::DFG::Allocator<T>::startBumpingIn): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addToGraph):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
        (JSC::DFG::CPSRethreadingPhase::addPhiSilently):
        * dfg/DFGCleanUpPhase.cpp:
        (JSC::DFG::CleanUpPhase::run):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::run):
        * dfg/DFGConstantHoistingPhase.cpp:
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::fixupBlock):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::deleteNode):
        (JSC::DFG::Graph::killBlockAndItsContents):
        (JSC::DFG::Graph::~Graph): Deleted.
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addNode):
        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::attemptHoist):
        * dfg/DFGLongLivedState.cpp: Removed.
        (JSC::DFG::LongLivedState::LongLivedState): Deleted.
        (JSC::DFG::LongLivedState::~LongLivedState): Deleted.
        (JSC::DFG::LongLivedState::shrinkToFit): Deleted.
        * dfg/DFGLongLivedState.h: Removed.
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::index): Deleted.
        * dfg/DFGNode.h:
        (JSC::DFG::Node::index):
        * dfg/DFGNodeAllocator.h: Removed.
        (operator new ): Deleted.
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPlan.h:
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::runThread):
        * runtime/VM.cpp:
        (JSC::VM::VM): Deleted.
        * runtime/VM.h:

2016-07-25  Filip Pizlo  <fpizlo@apple.com>

        AssemblyHelpers should own all of the cell allocation methods
        https://bugs.webkit.org/show_bug.cgi?id=160171

        Reviewed by Saam Barati.
        
        Prior to this change we had some code in DFGSpeculativeJIT.h and some code in JIT.h that
        did cell allocation.
        
        This change moves all of that code into AssemblyHelpers.h.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObjectWithKnownSize):
        (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
        (JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocate):
        (JSC::AssemblyHelpers::emitAllocateJSCell):
        (JSC::AssemblyHelpers::emitAllocateJSObject):
        (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
        (JSC::AssemblyHelpers::emitAllocateVariableSized):
        (JSC::AssemblyHelpers::emitAllocateVariableSizedJSObject):
        (JSC::AssemblyHelpers::emitAllocateDestructibleObject):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::isOperandConstantChar):
        (JSC::JIT::emitValueProfilingSite):
        (JSC::JIT::emitAllocateJSObject): Deleted.
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_object):
        (JSC::JIT::emit_op_create_this):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_new_object):
        (JSC::JIT::emit_op_create_this):

2016-07-25  Saam Barati  <sbarati@apple.com>

        MathICs should be able to take and dump stats about code size
        https://bugs.webkit.org/show_bug.cgi?id=160148

        Reviewed by Filip Pizlo.

        This will make testing changes on MathIC going forward much easier.
        We will be able to easily see if modifications to MathIC will lead
        to us generating smaller code. We now only dump average size when we
        regenerate any MathIC. This works out for large tests/pages, but is not
        great for testing small programs. We can add more dump points later if
        we find that we want to dump stats while running small small programs.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::jitSoon):
        (JSC::CodeBlock::dumpMathICStats):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::isStrictMode):
        (JSC::CodeBlock::ecmaMode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileMathIC):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileMathIC):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitMathICFast):
        (JSC::JIT::emitMathICSlow):
        * jit/JITMathIC.h:
        (JSC::JITMathIC::finalizeInlineCode):
        (JSC::JITMathIC::codeSize):
        * jit/JITOperations.cpp:

2016-07-25  Saam Barati  <sbarati@apple.com>

        op_mul/ArithMul(Untyped,Untyped) should be an IC
        https://bugs.webkit.org/show_bug.cgi?id=160108

        Reviewed by Mark Lam.

        This patch makes Mul a type based IC in much the same way that we made
        Add a type-based IC. I implemented Mul in the same way. I abstracted the
        implementation of the Add IC in the various JITs to allow for it to
        work over arbitrary IC snippets. This will make adding Div/Sub/Pow in the
        future easy. This patch also adds a new boolean argument to the various
        snippet generateFastPath() methods to indicate if we should emit result profiling.
        I added this because we want this profiling to be emitted for Mul in
        the baseline, but not in the DFG. We used to indicate this through passing
        in a nullptr for the ArithProfile, but we no longer do that in the upper
        JIT tiers. So we are passing an explicit request from the JIT tier about
        whether or not it's worth it for the IC to emit profiling.

        We now emit much less code for Mul. Here is some data on the average
        Mul snippet/IC size:

                   |   JetStream  |  Unity 3D  |
             ------| -------------|--------------
              Old  |  ~280 bytes  | ~280 bytes |
             ------| -------------|--------------
              New  |   210  bytes |  185 bytes |
             ------------------------------------

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::addJITAddIC):
        (JSC::CodeBlock::addJITMulIC):
        (JSC::CodeBlock::findStubInfo):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::stubInfoBegin):
        (JSC::CodeBlock::stubInfoEnd):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::GPRTemporary::adopt):
        (JSC::DFG::FPRTemporary::FPRTemporary):
        (JSC::DFG::SpeculativeJIT::compileValueAdd):
        (JSC::DFG::SpeculativeJIT::compileMathIC):
        (JSC::DFG::SpeculativeJIT::compileArithMul):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::GPRTemporary::GPRTemporary):
        (JSC::DFG::GPRTemporary::operator=):
        (JSC::DFG::FPRTemporary::~FPRTemporary):
        (JSC::DFG::FPRTemporary::fpr):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileToThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToB3::compileMathIC):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
        * jit/JIT.h:
        (JSC::JIT::getSlowCase):
        * jit/JITAddGenerator.cpp:
        (JSC::JITAddGenerator::generateInline):
        (JSC::JITAddGenerator::generateFastPath):
        * jit/JITAddGenerator.h:
        (JSC::JITAddGenerator::JITAddGenerator):
        (JSC::JITAddGenerator::isLeftOperandValidConstant):
        (JSC::JITAddGenerator::isRightOperandValidConstant):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitSlow_op_add):
        (JSC::JIT::emitMathICFast):
        (JSC::JIT::emitMathICSlow):
        (JSC::JIT::emit_op_mul):
        (JSC::JIT::emitSlow_op_mul):
        (JSC::JIT::emit_op_sub):
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITMathIC.h:
        (JSC::JITMathIC::slowPathStartLocation):
        (JSC::JITMathIC::slowPathCallLocation):
        (JSC::JITMathIC::isLeftOperandValidConstant):
        (JSC::JITMathIC::isRightOperandValidConstant):
        (JSC::JITMathIC::generateInline):
        (JSC::JITMathIC::generateOutOfLine):
        * jit/JITMathICForwards.h:
        * jit/JITMulGenerator.cpp:
        (JSC::JITMulGenerator::generateInline):
        (JSC::JITMulGenerator::generateFastPath):
        * jit/JITMulGenerator.h:
        (JSC::JITMulGenerator::JITMulGenerator):
        (JSC::JITMulGenerator::isLeftOperandValidConstant):
        (JSC::JITMulGenerator::isRightOperandValidConstant):
        (JSC::JITMulGenerator::didEmitFastPath): Deleted.
        (JSC::JITMulGenerator::endJumpList): Deleted.
        (JSC::JITMulGenerator::slowPathJumpList): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:

2016-07-25  Darin Adler  <darin@apple.com>

        Speed up make process slightly by improving "list of files" idiom
        https://bugs.webkit.org/show_bug.cgi?id=160164

        Reviewed by Mark Lam.

        * DerivedSources.make: Change rules that build lists of files to only run when
        DerivedSources.make has been modified since the last time they were run. Since the
        list of files are inside this file, this is safe, and this is faster than always
        comparing and regenerating the file containing the list of files each time.

2016-07-24  Youenn Fablet  <youenn@apple.com>

        [Fetch API] Request should be created with any HeadersInit data
        https://bugs.webkit.org/show_bug.cgi?id=159672

        Reviewed by Sam Weinig.

        * Scripts/builtins/builtins_generator.py:
        (WK_lcfirst): Synchronized with CodeGenerator.pm version.

2016-07-24  Filip Pizlo  <fpizlo@apple.com>

        B3 should support multiple entrypoints
        https://bugs.webkit.org/show_bug.cgi?id=159391

        Reviewed by Saam Barati.
        
        This teaches B3 how to compile procedures with multiple entrypoints in the best way ever.
        
        Multiple entrypoints are useful. We could use them to reduce the cost of compiling OSR
        entrypoints. We could use them to implement better try/catch.
        
        Multiple entrypoints are hard to support. All of the code that assumed that the root block
        is the entrypoint would have to be changed. Transformations like moveConstants() would have
        to do crazy things if the existence of multiple entrypoints prevented it from finding a
        single common dominator.
        
        Therefore, we want to add multiple entrypoints without actually teaching the compiler that
        there is such a thing. That's sort of what this change does.
        
        This adds a new opcode to both B3 and Air called EntrySwitch. It's a terminal that takes
        one or more successors and no value children. The number of successors must match
        Procedure::numEntrypoints(), which could be arbitrarily large. The semantics of EntrySwitch
        are:
        
        - Each of the entrypoints sets a hidden Entry variable to that entrypoint's index and jumps
          to the procedure's root block.
        
        - An EntrySwitch is a switch statement over this hidden Entry variable.
        
        The way that we actually implement this is that Air has a very late phase - after all
        register and stack layout - that clones all code where the Entry variable is live; i.e all
        code in the closure over predecessors of all blocks that do EntrySwitch.
        
        Usually, you would use this by creating an EntrySwitch in the root block, but you don't
        have to do that. Just remember that the code before EntrySwitch gets cloned for each
        entrypoint. We allow cloning of an arbitrarily large amount of code because restricting it,
        and so restricing the placement of EntrySwitches, would be unelegant. It would be hard to
        preserve this invariant. For example we wouldn't be able to lower any value before an
        EntrySwitch to a control flow diamond.
        
        This patch gives us an easy-to-use way to use B3 to compile code with multiple entrypoints.
        Inside the compiler, only code that runs very late in Air has to know about this feature.
        We get the best of both worlds!
        
        Also, I finally got rid of the requirement that you explicitly cast BasicBlock* to
        FrequentedBlock. I can no longer remember why I thought that was a good idea. Removing it
        doesn't cause any problems and it makes code easier to write.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3BasicBlockUtils.h:
        (JSC::B3::updatePredecessorsAfter):
        (JSC::B3::clearPredecessors):
        (JSC::B3::recomputePredecessors):
        * b3/B3FrequencyClass.h:
        (JSC::B3::maxFrequency):
        * b3/B3Generate.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3MoveConstants.cpp:
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::isFastConstant):
        (JSC::B3::Procedure::entrypointLabel):
        (JSC::B3::Procedure::addDataSection):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::numEntrypoints):
        (JSC::B3::Procedure::setNumEntrypoints):
        (JSC::B3::Procedure::setLastPhaseName):
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h:
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::cCallSpecial):
        (JSC::B3::Air::Code::isEntrypoint):
        (JSC::B3::Air::Code::resetReachability):
        (JSC::B3::Air::Code::dump):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::setFrameSize):
        (JSC::B3::Air::Code::numEntrypoints):
        (JSC::B3::Air::Code::entrypoints):
        (JSC::B3::Air::Code::entrypoint):
        (JSC::B3::Air::Code::setEntrypoints):
        (JSC::B3::Air::Code::entrypointLabel):
        (JSC::B3::Air::Code::setEntrypointLabels):
        (JSC::B3::Air::Code::calleeSaveRegisters):
        * b3/air/AirCustom.h:
        (JSC::B3::Air::PatchCustom::isTerminal):
        (JSC::B3::Air::PatchCustom::hasNonArgEffects):
        (JSC::B3::Air::PatchCustom::hasNonArgNonControlEffects):
        (JSC::B3::Air::PatchCustom::generate):
        (JSC::B3::Air::CommonCustomBase::hasNonArgEffects):
        (JSC::B3::Air::CCallCustom::forEachArg):
        (JSC::B3::Air::ColdCCallCustom::forEachArg):
        (JSC::B3::Air::ShuffleCustom::forEachArg):
        (JSC::B3::Air::EntrySwitchCustom::forEachArg):
        (JSC::B3::Air::EntrySwitchCustom::isValidFormStatic):
        (JSC::B3::Air::EntrySwitchCustom::isValidForm):
        (JSC::B3::Air::EntrySwitchCustom::admitsStack):
        (JSC::B3::Air::EntrySwitchCustom::isTerminal):
        (JSC::B3::Air::EntrySwitchCustom::hasNonArgNonControlEffects):
        (JSC::B3::Air::EntrySwitchCustom::generate):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        (JSC::B3::Air::generate):
        * b3/air/AirLowerEntrySwitch.cpp: Added.
        (JSC::B3::Air::lowerEntrySwitch):
        * b3/air/AirLowerEntrySwitch.h: Added.
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirOptimizeBlockOrder.cpp:
        (JSC::B3::Air::blocksInOptimizedOrder):
        * b3/air/AirSpecial.cpp:
        (JSC::B3::Air::Special::isTerminal):
        (JSC::B3::Air::Special::hasNonArgEffects):
        (JSC::B3::Air::Special::hasNonArgNonControlEffects):
        * b3/air/AirSpecial.h:
        * b3/air/AirValidate.cpp:
        * b3/air/opcode_generator.rb:
        * b3/testb3.cpp:

2016-07-24  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix broken test. I don't know why I goofed this up without seeing it before landing.

        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::run):

2016-07-22  Filip Pizlo  <fpizlo@apple.com>

        [B3] Fusing immediates into test instructions should work again
        https://bugs.webkit.org/show_bug.cgi?id=160073

        Reviewed by Sam Weinig.

        When we introduced BitImm, we forgot to change the Branch(BitAnd(value, constant))
        fusion.  This emits test instructions, so it should use BitImm for the constant.  But it
        was still using Imm!  This meant that isValidForm() always returned false.
        
        This fixes the code path to use BitImm, and turns off our use of BitImm64 on x86 since
        it provides no benefit on x86 and has some risk (the code appears to play fast and loose
        with the scratch register).
        
        This is not an obvious progression on anything, so I added comprehensive tests to
        testb3, which check that we selected the optimal instruction in a variety of situations.
        We should add more tests like this!

        * b3/B3BasicBlock.h:
        (JSC::B3::BasicBlock::successorBlock):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createGenericCompare):
        * b3/B3LowerToAir.h:
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::isRepresentableAs):
        (JSC::B3::Air::Arg::usesTmp):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isRepresentableAs):
        (JSC::B3::Air::Arg::castToType):
        (JSC::B3::Air::Arg::asNumber):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::size):
        (JSC::B3::Air::Code::at):
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirValidate.h:
        * b3/air/opcode_generator.rb:
        * b3/testb3.cpp:
        (JSC::B3::compile):
        (JSC::B3::compileAndRun):
        (JSC::B3::lowerToAirForTesting):
        (JSC::B3::testSomeEarlyRegister):
        (JSC::B3::testBranchBitAndImmFusion):
        (JSC::B3::zero):
        (JSC::B3::run):

2016-07-24  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, update the exponentiation expression error message
        https://bugs.webkit.org/show_bug.cgi?id=159969

        Follow up patch for r203499.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseBinaryExpression):
        * tests/stress/pow-expects-update-expression-on-lhs.js:
        (throw.new.Error):

2016-07-24  Darin Adler  <darin@apple.com>

        Adding a new WebCore JavaScript built-in source file does not trigger rebuild of WebCoreJSBuiltins*
        https://bugs.webkit.org/show_bug.cgi?id=160115

        Reviewed by Youenn Fablet.

        * make-generated-sources.sh: Removed. Was unused.

2016-07-23  Commit Queue  <commit-queue@webkit.org>

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

        It broke make-based builds (Requested by youenn on #webkit).

        Reverted changeset:

        "[Fetch API] Request should be created with any HeadersInit
        data"
        https://bugs.webkit.org/show_bug.cgi?id=159672
        http://trac.webkit.org/changeset/203641

2016-07-23  Youenn Fablet  <youenn@apple.com>

        [Fetch API] Request should be created with any HeadersInit data
        https://bugs.webkit.org/show_bug.cgi?id=159672

        Reviewed by Sam Weinig.

        * Scripts/builtins/builtins_generator.py:
        (WK_lcfirst): Synchronized with CodeGenerator.pm version.

2016-07-21  Filip Pizlo  <fpizlo@apple.com>

        Teach MarkedSpace how to allocate auxiliary storage
        https://bugs.webkit.org/show_bug.cgi?id=160053

        Reviewed by Sam Weinig.
        
        Previously, we had two kinds of subspaces in MarkedSpace: destructor and non-destructor. This
        was described using "bool needsDestruction" that would get passed around. We'd iterate over
        these spaces using duplicated code - one loop for destructors and one for non-destructors, or
        a single loop that does one thing for destructors and one for non-destructors.
        
        But now we want a third subspace: non-destructor non-JSCell, aka Auxiliary.
        
        So, this changes all of the reflection and iteration over subspaces to use functors, so that
        the looping is written once and reused. Most places don't even have to know that there is a
        third subspace; they just know that they must do things for each subspace, for each
        allocator, or for each block - and the functor magic handles it for you.
        
        To make this somewhat nice, this change also fixes how we describe subspaces. Instead of a
        bool, we now have AllocatorAttributes, which is a struct. If we ever add more subspaces, we
        can add fields to AllocatorAttributes to describe how those subspaces differ. For now it just
        contains two properties: a DestructionMode and a HeapCell::Kind. The DesctructionMode
        replaces bool needsDestruction. I deliberately used a non-class enum to avoid tautologies.
        DestructionMode has two members: NeedsDestruction and DoesNotNeedDestruction. I almost went
        with DestructionMode::Needed and DestructionMode::NotNeeded, but I felt like that involves
        more typing and doesn't actually avoid any kind of namespace issues.
        
        This is intended to have no behavior change other than the addition of a totally unused
        space, which should always be empty. So hopefully it doesn't cost anything.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/AllocatorAttributes.cpp: Added.
        (JSC::AllocatorAttributes::dump):
        * heap/AllocatorAttributes.h: Added.
        (JSC::AllocatorAttributes::AllocatorAttributes):
        * heap/DestructionMode.cpp: Added.
        (WTF::printInternal):
        * heap/DestructionMode.h: Added.
        * heap/Heap.h:
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateBlock):
        (JSC::MarkedAllocator::addBlock):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::cellSize):
        (JSC::MarkedAllocator::attributes):
        (JSC::MarkedAllocator::needsDestruction):
        (JSC::MarkedAllocator::destruction):
        (JSC::MarkedAllocator::cellKind):
        (JSC::MarkedAllocator::heap):
        (JSC::MarkedAllocator::takeLastActiveBlock):
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::init):
        (JSC::MarkedAllocator::allocate):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::destroy):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC::MarkedBlock::callDestructor):
        (JSC::MarkedBlock::sweep):
        (JSC::MarkedBlock::stopAllocating):
        (JSC::MarkedBlock::didRetireBlock):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::cellSize):
        (JSC::MarkedBlock::attributes):
        (JSC::MarkedBlock::needsDestruction):
        (JSC::MarkedBlock::destruction):
        (JSC::MarkedBlock::cellKind):
        (JSC::MarkedBlock::size):
        (JSC::MarkedBlock::forEachCell):
        (JSC::MarkedBlock::forEachLiveCell):
        (JSC::MarkedBlock::forEachDeadCell):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::~MarkedSpace):
        (JSC::MarkedSpace::lastChanceToFinalize):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::forEachAllocator):
        (JSC::MarkedSpace::stopAllocating):
        (JSC::MarkedSpace::resumeAllocating):
        (JSC::MarkedSpace::isPagedOut):
        (JSC::MarkedSpace::freeBlock):
        (JSC::MarkedSpace::shrink):
        (JSC::MarkedSpace::clearNewlyAllocated):
        (JSC::clearNewlyAllocatedInBlock): Deleted.
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::subspaceForObjectsWithDestructor):
        (JSC::MarkedSpace::subspaceForObjectsWithoutDestructor):
        (JSC::MarkedSpace::subspaceForAuxiliaryData):
        (JSC::MarkedSpace::allocatorFor):
        (JSC::MarkedSpace::destructorAllocatorFor):
        (JSC::MarkedSpace::auxiliaryAllocatorFor):
        (JSC::MarkedSpace::allocateWithoutDestructor):
        (JSC::MarkedSpace::allocateWithDestructor):
        (JSC::MarkedSpace::allocateAuxiliary):
        (JSC::MarkedSpace::forEachBlock):
        (JSC::MarkedSpace::didAddBlock):
        (JSC::MarkedSpace::capacity):
        (JSC::MarkedSpace::forEachSubspace):

2016-07-22  Saam Barati  <sbarati@apple.com>

        REGRESSION(r203537): It made many tests crash on ARMv7 Linux platforms
        https://bugs.webkit.org/show_bug.cgi?id=160082

        Reviewed by Keith Miller.

        We were improperly linking the Jump in the link buffer.
        It caused us to be linking against the executable address
        which always has bit 0 set. We shouldn't be doing that.
        This patch fixes this, by using the same idiom that
        PolymorphicAccess uses to link a jump to out of line code.

        * jit/JITMathIC.h:
        (JSC::JITMathIC::generateOutOfLine):

2016-07-22  Commit Queue  <commit-queue@webkit.org>

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

        Caused CLoop tests to fail with assertions (Requested by
        perarne on #webkit).

        Reverted changeset:

        "[Win] jsc.exe sometimes never exits."
        https://bugs.webkit.org/show_bug.cgi?id=158073
        http://trac.webkit.org/changeset/203603

2016-07-22  Per Arne Vollan  <pvollan@apple.com>

        [Win] jsc.exe sometimes never exits.
        https://bugs.webkit.org/show_bug.cgi?id=158073

        Reviewed by Mark Lam.

        Make sure the VM is deleted after the test has finished. This will gracefully stop the sampling profiler thread,
        and give the thread the opportunity to release the machine thread lock aquired in SamplingProfiler::takeSample.  
        If the sampling profiler thread was terminated while holding the machine thread lock, the machine thread will
        not be able to grab the lock afterwards. 
 
        * jsc.cpp:
        (jscmain):

2016-07-22  Per Arne Vollan  <pvollan@apple.com>

        Fix the Windows 64-bit build after r203537
        https://bugs.webkit.org/show_bug.cgi?id=160080

        Reviewed by Csaba Osztrogonác.

        Added new version of setupArgumentsWithExecState method.

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

2016-07-22  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Unreviewed EABI buildfix after r203537.

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

2016-07-22  Youenn Fablet  <youenn@apple.com>

        run-builtins-generator-tests should be able to test WebCore builtins wrapper with more than one file
        https://bugs.webkit.org/show_bug.cgi?id=159921

        Reviewed by Brian Burg.

        Updated built-in generator to generate only wrapper files when passed the --wrappers-only option.
        When this option is used, wrapper files are generated but no individual file is generated.
        When this option is not used, individual files are generated but not wrapper file is generated.
        This allows the builtin generator test runner to generate a single WebCore-Wrappers.h-result generated for all
        WebCore test files, like used for real in WebCore.
        Previously wrapper code was generated individually for each WebCore test file.

        Added new built-in test file to cover the case of concatenating several guards in generated WebCore wrapper files.

        * Scripts/generate-js-builtins.py:
        (concatenated_output_filename): Compute a decent name for wrapper files in case of test mode.
        (generate_bindings_for_builtins_files): When --wrappers-only is activated, this generates only the wrapper files, not the individual files.
        * Scripts/tests/builtins/WebCore-AnotherGuardedInternalBuiltin-Separate.js: Added.
        * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result: Added.
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: Removed wrapper code.
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: Removed wrapper code.
        * Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result: Added, contains wrapper code for all WebCore valid test cases.

2016-07-21  Saam Barati  <sbarati@apple.com>

        callOperation(.) variants in the DFG that explicitly take a tag/payload register should take a JSValueRegs instead
        https://bugs.webkit.org/show_bug.cgi?id=160007

        Reviewed by Filip Pizlo.

        This patch is the first step in my plan to remove all callOperation(.) variants
        in the various JITs and to unify them using a couple template variations.
        The steps are as follows:
        1. Replace all explicit tag/payload pairs with JSValueRegs in the DFG
        2. Replace all explicit tag/payload pairs with JSValueRegs in the baseline
        3. remove callOperation(.) variants and teach setupArgumentsWithExecState
           about JSValueRegs.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        (JSC::DFG::SpeculativeJIT::compileValueAdd):
        (JSC::DFG::SpeculativeJIT::compileGetDynamicVar):
        (JSC::DFG::SpeculativeJIT::compilePutDynamicVar):
        (JSC::DFG::SpeculativeJIT::compilePutAccessorByVal):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
        (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::generateInternal):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        (JSC::DFG::SpeculativeJIT::compile):

2016-07-21  Saam Barati  <sbarati@apple.com>

        op_add/ValueAdd should be an IC in all JIT tiers
        https://bugs.webkit.org/show_bug.cgi?id=159649

        Reviewed by Benjamin Poulain.

        This patch makes Add an IC inside all JIT tiers. It does so in a
        simple, but effective, way. We will try to generate an int+int add
        that will repatch itself if its type checks fail. Sometimes though,
        we have runtime type data saying that the add won't be int+int.
        In those cases, we will just generate a full snippet that doesn't patch itself.
        Other times, we may generate no inline code and defer to making a C call. A lot
        of this patch is just refactoring ResultProfile into what we're now calling ArithProfile.
        ArithProfile does everything ResultProfile used to do, and more. It records simple type
        data about the LHS/RHS operands it sees. This allows us to determine if an op_add
        has only seen int+int operands, etc. ArithProfile will also contain the ResultType
        for the LHS/RHS that the parser feeds into op_add. ArithProfile now fits into 32-bits.
        This means instead of having a side table like we did for ResultProfile, we just
        inject the ArithProfile into the bytecode instruction stream. This makes asking
        for ArithProfile faster; we no longer need to lock around this operation.

        The size of an Add has gone down on average, but we can still do better.
        We still generate a lot of code because we generate calls to the slow path.
        I think we can make this better by moving the slow path to a shared thunk
        system. This patch mostly lays the foundation for future improvements to Add,
        and a framework to move all other arithmetic operations to be typed-based ICs.

        Here is some data I took on the average op_add/ValueAdd size on various benchmarks:
                   |   JetStream  |  Speedometer |  Unity 3D  |
             ------| -------------|-----------------------------
              Old  |  189 bytes   |  169 bytes   |  192 bytes |
             ------| -------------|-----------------------------
              New  |  148 bytes   |  124 bytes   |  143 bytes |
             ---------------------------------------------------

        Making an arithmetic IC is now easy. The JITMathIC class will hold a snippet
        generator as a member variable. To make a snippet an IC, you need to implement
        a generateInline(.) method, which generates the inline IC. Then, you need to
        generate the IC where you used to generate the snippet. When generating the
        IC, we need to inform JITMathIC of various data like we do with StructureStubInfo.
        We need to tell it about where the slow path starts, where the slow path call is, etc.
        When generating a JITMathIC, it may tell you that it didn't generate any code inline.
        This is a request to the user of JITMathIC to just generate a C call along the
        fast path. JITMathIC may also have the snippet tell it to just generate the full
        snippet instead of the int+int path along the fast path.

        In subsequent patches, we can improve upon how we decide to generate int+int or
        the full snippet. I tried to get clever by having double+double, double+int, int+double,
        fast paths, but they didn't work out nearly as well as the int+int fast path. I ended up
        generating a lot of code when I did this and ended up using more memory than just generating
        the full snippet. There is probably some way we can be clever and generate specialized fast
        paths that are more successful than what I tried implementing, but I think that's worth deferring
        this to follow up patches once the JITMathIC foundation has landed.

        This patch also fixes a bug inside the slow path lambdas in the DFG.
        Before, it was not legal to emit an exception check inside them. Now,
        it is. So it's now easy to define arbitrary late paths using the DFG
        slow path lambda API.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/ArithProfile.cpp: Added.
        (JSC::ArithProfile::emitObserveResult):
        (JSC::ArithProfile::shouldEmitSetDouble):
        (JSC::ArithProfile::emitSetDouble):
        (JSC::ArithProfile::shouldEmitSetNonNumber):
        (JSC::ArithProfile::emitSetNonNumber):
        (WTF::printInternal):
        * bytecode/ArithProfile.h: Added.
        (JSC::ObservedType::ObservedType):
        (JSC::ObservedType::sawInt32):
        (JSC::ObservedType::isOnlyInt32):
        (JSC::ObservedType::sawNumber):
        (JSC::ObservedType::isOnlyNumber):
        (JSC::ObservedType::sawNonNumber):
        (JSC::ObservedType::isOnlyNonNumber):
        (JSC::ObservedType::isEmpty):
        (JSC::ObservedType::bits):
        (JSC::ObservedType::withInt32):
        (JSC::ObservedType::withNumber):
        (JSC::ObservedType::withNonNumber):
        (JSC::ObservedType::withoutNonNumber):
        (JSC::ObservedType::operator==):
        (JSC::ArithProfile::ArithProfile):
        (JSC::ArithProfile::fromInt):
        (JSC::ArithProfile::lhsResultType):
        (JSC::ArithProfile::rhsResultType):
        (JSC::ArithProfile::lhsObservedType):
        (JSC::ArithProfile::rhsObservedType):
        (JSC::ArithProfile::setLhsObservedType):
        (JSC::ArithProfile::setRhsObservedType):
        (JSC::ArithProfile::tookSpecialFastPath):
        (JSC::ArithProfile::didObserveNonInt32):
        (JSC::ArithProfile::didObserveDouble):
        (JSC::ArithProfile::didObserveNonNegZeroDouble):
        (JSC::ArithProfile::didObserveNegZeroDouble):
        (JSC::ArithProfile::didObserveNonNumber):
        (JSC::ArithProfile::didObserveInt32Overflow):
        (JSC::ArithProfile::didObserveInt52Overflow):
        (JSC::ArithProfile::setObservedNonNegZeroDouble):
        (JSC::ArithProfile::setObservedNegZeroDouble):
        (JSC::ArithProfile::setObservedNonNumber):
        (JSC::ArithProfile::setObservedInt32Overflow):
        (JSC::ArithProfile::setObservedInt52Overflow):
        (JSC::ArithProfile::addressOfBits):
        (JSC::ArithProfile::observeResult):
        (JSC::ArithProfile::lhsSawInt32):
        (JSC::ArithProfile::lhsSawNumber):
        (JSC::ArithProfile::lhsSawNonNumber):
        (JSC::ArithProfile::rhsSawInt32):
        (JSC::ArithProfile::rhsSawNumber):
        (JSC::ArithProfile::rhsSawNonNumber):
        (JSC::ArithProfile::observeLHSAndRHS):
        (JSC::ArithProfile::bits):
        (JSC::ArithProfile::hasBits):
        (JSC::ArithProfile::setBit):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpRareCaseProfile):
        (JSC::CodeBlock::dumpArithProfile):
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::addStubInfo):
        (JSC::CodeBlock::addJITAddIC):
        (JSC::CodeBlock::findStubInfo):
        (JSC::CodeBlock::resetJITData):
        (JSC::CodeBlock::shrinkToFit):
        (JSC::CodeBlock::dumpValueProfiles):
        (JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
        (JSC::CodeBlock::arithProfileForBytecodeOffset):
        (JSC::CodeBlock::arithProfileForPC):
        (JSC::CodeBlock::couldTakeSpecialFastCase):
        (JSC::CodeBlock::dumpResultProfile): Deleted.
        (JSC::CodeBlock::resultProfileForBytecodeOffset): Deleted.
        (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset): Deleted.
        (JSC::CodeBlock::ensureResultProfile): Deleted.
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::stubInfoBegin):
        (JSC::CodeBlock::stubInfoEnd):
        (JSC::CodeBlock::couldTakeSlowCase):
        (JSC::CodeBlock::numberOfResultProfiles): Deleted.
        * bytecode/MethodOfGettingAValueProfile.cpp:
        (JSC::MethodOfGettingAValueProfile::emitReportValue):
        * bytecode/MethodOfGettingAValueProfile.h:
        (JSC::MethodOfGettingAValueProfile::MethodOfGettingAValueProfile):
        * bytecode/ValueProfile.cpp:
        (JSC::ResultProfile::emitDetectNumericness): Deleted.
        (JSC::ResultProfile::emitSetDouble): Deleted.
        (JSC::ResultProfile::emitSetNonNumber): Deleted.
        (WTF::printInternal): Deleted.
        * bytecode/ValueProfile.h:
        (JSC::getRareCaseProfileBytecodeOffset):
        (JSC::ResultProfile::ResultProfile): Deleted.
        (JSC::ResultProfile::bytecodeOffset): Deleted.
        (JSC::ResultProfile::specialFastPathCount): Deleted.
        (JSC::ResultProfile::didObserveNonInt32): Deleted.
        (JSC::ResultProfile::didObserveDouble): Deleted.
        (JSC::ResultProfile::didObserveNonNegZeroDouble): Deleted.
        (JSC::ResultProfile::didObserveNegZeroDouble): Deleted.
        (JSC::ResultProfile::didObserveNonNumber): Deleted.
        (JSC::ResultProfile::didObserveInt32Overflow): Deleted.
        (JSC::ResultProfile::didObserveInt52Overflow): Deleted.
        (JSC::ResultProfile::setObservedNonNegZeroDouble): Deleted.
        (JSC::ResultProfile::setObservedNegZeroDouble): Deleted.
        (JSC::ResultProfile::setObservedNonNumber): Deleted.
        (JSC::ResultProfile::setObservedInt32Overflow): Deleted.
        (JSC::ResultProfile::setObservedInt52Overflow): Deleted.
        (JSC::ResultProfile::addressOfFlags): Deleted.
        (JSC::ResultProfile::addressOfSpecialFastPathCount): Deleted.
        (JSC::ResultProfile::detectNumericness): Deleted.
        (JSC::ResultProfile::hasBits): Deleted.
        (JSC::ResultProfile::setBit): Deleted.
        (JSC::getResultProfileBytecodeOffset): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitBinaryOp):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::makeSafe):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::exceptionCheck):
        * dfg/DFGSlowPathGenerator.h:
        (JSC::DFG::SlowPathGenerator::generate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
        (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
        (JSC::DFG::SpeculativeJIT::compileValueAdd):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::silentSpillAllRegistersImpl):
        (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters):
        (JSC::DFG::SpeculativeJIT::callOperation):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToB3::compileStrCat):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        (JSC::CCallHelpers::setupArguments):
        * jit/JIT.h:
        * jit/JITAddGenerator.cpp:
        (JSC::JITAddGenerator::generateInline):
        (JSC::JITAddGenerator::generateFastPath):
        * jit/JITAddGenerator.h:
        (JSC::JITAddGenerator::JITAddGenerator):
        (JSC::JITAddGenerator::didEmitFastPath): Deleted.
        (JSC::JITAddGenerator::endJumpList): Deleted.
        (JSC::JITAddGenerator::slowPathJumpList): Deleted.
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_jless):
        (JSC::JIT::emitSlow_op_urshift):
        (JSC::getOperandTypes):
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitSlow_op_add):
        (JSC::JIT::emit_op_div):
        (JSC::JIT::emit_op_mul):
        (JSC::JIT::emitSlow_op_mul):
        (JSC::JIT::emit_op_sub):
        (JSC::JIT::emitSlow_op_sub):
        * jit/JITDivGenerator.cpp:
        (JSC::JITDivGenerator::generateFastPath):
        * jit/JITDivGenerator.h:
        (JSC::JITDivGenerator::JITDivGenerator):
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITMathIC.h: Added.
        (JSC::JITMathIC::doneLocation):
        (JSC::JITMathIC::slowPathStartLocation):
        (JSC::JITMathIC::slowPathCallLocation):
        (JSC::JITMathIC::generateInline):
        (JSC::JITMathIC::generateOutOfLine):
        (JSC::JITMathIC::finalizeInlineCode):
        * jit/JITMathICForwards.h: Added.
        * jit/JITMathICInlineResult.h: Added.
        * jit/JITMulGenerator.cpp:
        (JSC::JITMulGenerator::generateFastPath):
        * jit/JITMulGenerator.h:
        (JSC::JITMulGenerator::JITMulGenerator):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITSubGenerator.cpp:
        (JSC::JITSubGenerator::generateFastPath):
        * jit/JITSubGenerator.h:
        (JSC::JITSubGenerator::JITSubGenerator):
        * jit/Repatch.cpp:
        (JSC::readCallTarget):
        (JSC::ftlThunkAwareRepatchCall):
        (JSC::tryCacheGetByID):
        (JSC::repatchGetByID):
        (JSC::appropriateGenericPutByIdFunction):
        (JSC::tryCachePutByID):
        (JSC::repatchPutByID):
        (JSC::tryRepatchIn):
        (JSC::repatchIn):
        (JSC::linkSlowFor):
        (JSC::resetGetByID):
        (JSC::resetPutByID):
        (JSC::repatchCall): Deleted.
        * jit/Repatch.h:
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/ResultType.h:
        (JSC::ResultType::ResultType):
        (JSC::ResultType::isInt32):
        (JSC::ResultType::definitelyIsNumber):
        (JSC::ResultType::definitelyIsString):
        (JSC::ResultType::definitelyIsBoolean):
        (JSC::ResultType::mightBeNumber):
        (JSC::ResultType::isNotNumber):
        (JSC::ResultType::forBitOp):
        (JSC::ResultType::bits):
        (JSC::OperandTypes::OperandTypes):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        (JSC::updateArithProfileForBinaryArithOp):
        (JSC::updateResultProfileForBinaryArithOp): Deleted.
        * tests/stress/op-add-exceptions.js: Added.
        (assert):
        (f1):
        (f2):
        (f3):
        (let.oException.valueOf):
        (foo):
        (ident):
        (bar):

2016-07-21  Csaba Osztrogonác  <ossy@webkit.org>

        Clarify testing mode names in run-jsc-stress-tests
        https://bugs.webkit.org/show_bug.cgi?id=160021

        Reviewed by Mark Lam.

        Default should mean really default, not default with disabled FTL, renamed
        - runMozillaTestDefault to runMozillaTestNoFTL
        - runMozillaTestDefaultFTL to runMozillaTestDefault
        - runDefault to runNoFTL
        - runDefaultFTL to runDefault
        - runLayoutTestDefault to runLayoutTestNoFTL
        - runLayoutTestDefaultFTL to runLayoutTestDefault
        - runNoisyTestDefault to runNoisyTestNoFTL
        - runNoisyTestDefaultFTL to runNoisyTestDefault

        * tests/mozilla/mozilla-tests.yaml:
        * tests/stress/lift-tdz-bypass-catch.js:
        * tests/stress/obscure-error-message-dont-crash.js:
        * tests/stress/shadow-chicken-disabled.js:

2016-07-20  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES7] Introduce exponentiation expression
        https://bugs.webkit.org/show_bug.cgi?id=159969

        Reviewed by Saam Barati.

        This patch implements the exponentiation expression, e.g. `x ** y`.
        The exponentiation expression is introduced in ECMA262 2016 and ECMA262 2016
        is already released. So this is not the draft spec.

        The exponentiation expression has 2 interesting points.

        1. Right associative

            To follow the Math expression, ** operator is right associative.
            When we execute `x ** y ** z`, this is handled as `x ** (y ** z)`, not `(x ** y) ** z`.
            This patch introduces the right associativity to the binary operator and handles it
            in the operator precedence parser in Parser.cpp.

        2. LHS of the exponentiation expression is UpdateExpression

            ExponentiationExpression[Yield]:
                UnaryExpression[?Yield]
                UpdateExpression[?Yield] ** ExponentiationExpression[?Yield]

            As we can see, the left hand side of the ExponentiationExpression is UpdateExpression, not UnaryExpression.
            It means that `+x ** y` becomes a syntax error. This is intentional. Without superscript in JS,
            `-x**y` is confusing between `-(x ** y)` and `(-x) ** y`. So ECMA262 intentionally avoids UnaryExpression here.
            If we need to use a negated value, we need to write parentheses explicitly e.g. `(-x) ** y`.
            In this patch, we ensure that the left hand side is not an unary expression by checking an operator in
            parseBinaryExpression. This works since `**` has the highest operator precedence in the binary operators.

        We introduce a new bytecode, op_pow. That simply works as similar as the other binary operators.
        And it is converted to ArithPow in DFG and handled in DFG and FTL.
        In this patch, we take the approach just introducing a new bytecode instead of calling Math.pow.
        This is because we would like to execute ToNumber in the caller side, not in the callee (Math.pow) side.
        And we don't want to compile ** into the following.

            lhsNumber = to_number (lhs)
            rhsNumber = to_number (rhs)
            call Math.pow(lhsNumber, rhsNumber)

        We ensure that this patch passes all the test262 tests related to the exponentiation expression.

        The only sensitive part to the performance is the parser changes.
        So we measured the code-load performance and it is neutral in my x64 Linux box (hanayamata).

            Collected 30 samples per benchmark/VM, with 30 VM invocations per benchmark. Emitted a call to
            gc() between sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used
            the jsc-specific preciseTime() function to get microsecond-level timing. Reporting benchmark
            execution times with 95% confidence intervals in milliseconds.

                                     baseline                  patched

            closure              0.60499+-0.00250          0.60180+-0.00244
            jquery               7.89175+-0.02433    ?     7.91287+-0.04759       ?

            <geometric>          2.18499+-0.00523          2.18207+-0.00689         might be 1.0013x faster

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::emitReadModifyAssignment):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_pow):
        * llint/LowLevelInterpreter.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::operatorStackShouldReduce):
        (JSC::ASTBuilder::makePowNode):
        (JSC::ASTBuilder::makeMultNode):
        (JSC::ASTBuilder::makeDivNode):
        (JSC::ASTBuilder::makeModNode):
        (JSC::ASTBuilder::makeSubNode):
        (JSC::ASTBuilder::makeBinaryNode):
        (JSC::ASTBuilder::operatorStackHasHigherPrecedence): Deleted.
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::lex):
        * parser/NodeConstructors.h:
        (JSC::PowNode::PowNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::isUnaryOpExcludingUpdateOp):
        (JSC::Parser<LexerType>::parseBinaryExpression):
        (JSC::isUnaryOp): Deleted.
        * parser/ParserTokens.h:
        (JSC::isUpdateOp):
        (JSC::isUnaryOp):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::operatorStackPop):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * tests/stress/pow-basics.js: Added.
        (valuesAreClose):
        (mathPowDoubleDouble1):
        (mathPowDoubleInt1):
        (test1):
        (mathPowDoubleDouble2):
        (mathPowDoubleInt2):
        (test2):
        (mathPowDoubleDouble3):
        (mathPowDoubleInt3):
        (test3):
        (mathPowDoubleDouble4):
        (mathPowDoubleInt4):
        (test4):
        (mathPowDoubleDouble5):
        (mathPowDoubleInt5):
        (test5):
        (mathPowDoubleDouble6):
        (mathPowDoubleInt6):
        (test6):
        (mathPowDoubleDouble7):
        (mathPowDoubleInt7):
        (test7):
        (mathPowDoubleDouble8):
        (mathPowDoubleInt8):
        (test8):
        (mathPowDoubleDouble9):
        (mathPowDoubleInt9):
        (test9):
        (mathPowDoubleDouble10):
        (mathPowDoubleInt10):
        (test10):
        (mathPowDoubleDouble11):
        (mathPowDoubleInt11):
        (test11):
        * tests/stress/pow-coherency.js: Added.
        (pow42):
        (build42AsDouble.opaqueAdd):
        (build42AsDouble):
        (powDouble42):
        (clobber):
        (pow42NoConstantFolding):
        (powDouble42NoConstantFolding):
        * tests/stress/pow-evaluation-order.js: Added.
        (shouldBe):
        (throw.new.Error):
        * tests/stress/pow-expects-update-expression-on-lhs.js: Added.
        (testSyntax):
        (testSyntaxError):
        (throw.new.Error):
        (let.token.of.tokens.testSyntax.pow):
        (testSyntax.pow):
        * tests/stress/pow-integer-exponent-fastpath.js: Added.
        (valuesAreClose):
        (mathPowDoubleDoubleTestExponentFifty):
        (mathPowDoubleIntTestExponentFifty):
        (testExponentFifty):
        (mathPowDoubleDoubleTestExponentTenThousands):
        (mathPowDoubleIntTestExponentTenThousands):
        (testExponentTenThousands):
        * tests/stress/pow-nan-behaviors.js: Added.
        (testIntegerBaseWithNaNExponentStatic):
        (mathPowIntegerBaseWithNaNExponentDynamic):
        (testIntegerBaseWithNaNExponentDynamic):
        (testFloatingPointBaseWithNaNExponentStatic):
        (mathPowFloatingPointBaseWithNaNExponentDynamic):
        (testFloatingPointBaseWithNaNExponentDynamic):
        (testNaNBaseStatic):
        (mathPowNaNBaseDynamic1):
        (mathPowNaNBaseDynamic2):
        (mathPowNaNBaseDynamic3):
        (mathPowNaNBaseDynamic4):
        (testNaNBaseDynamic):
        (infiniteExponentsStatic):
        (mathPowInfiniteExponentsDynamic1):
        (mathPowInfiniteExponentsDynamic2):
        (mathPowInfiniteExponentsDynamic3):
        (mathPowInfiniteExponentsDynamic4):
        (infiniteExponentsDynamic):
        * tests/stress/pow-simple.js: Added.
        (shouldBe):
        (throw.new.Error):
        * tests/stress/pow-stable-results.js: Added.
        (opaquePow):
        (isIdentical):
        * tests/stress/pow-to-number-should-be-executed-in-code-side.js: Added.
        (shouldBe):
        (throw.new.Error):
        * tests/stress/pow-with-constants.js: Added.
        (exponentIsZero):
        (testExponentIsZero):
        (exponentIsOne):
        (testExponentIsOne):
        (powUsedAsSqrt):
        (testPowUsedAsSqrt):
        (powUsedAsOneOverSqrt):
        (testPowUsedAsOneOverSqrt):
        (powUsedAsSquare):
        (testPowUsedAsSquare):
        (intIntConstantsSmallNumbers):
        (intIntConstantsLargeNumbers):
        (intIntSmallConstants):
        (intDoubleConstants):
        (doubleDoubleConstants):
        (doubleIntConstants):
        (testBaseAndExponentConstantLiterals):
        (exponentIsIntegerConstant):
        (testExponentIsIntegerConstant):
        (exponentIsDoubleConstant):
        (testExponentIsDoubleConstant):
        (exponentIsInfinityConstant):
        (testExponentIsInfinityConstant):
        (exponentIsNegativeInfinityConstant):
        (testExponentIsNegativeInfinityConstant):
        * tests/stress/pow-with-never-NaN-exponent.js: Added.
        (exponentIsNonNanDouble1):
        (exponentIsNonNanDouble2):
        (testExponentIsDoubleConstant):
        * tests/test262.yaml:

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

        Switching on symbols should be fast
        https://bugs.webkit.org/show_bug.cgi?id=158892

        Reviewed by Keith Miller.
        
        This does two things: fixes some goofs in our lowering of symbol equality and adds a new phase
        to B3 to infer switch statements from linear chains of branches.
        
        This changes how we compile equality to Symbols to constant-fold the load of the Symbol's UID.
        This is necessary for making switches on Symbols inferrable. This also gives us the ability to
        efficiently compile strict equality comparisons of SymbolUse and UntypedUse.

        This adds a new phase to B3, which finds chains of branches that test for (in)equality on the
        same value and constants, and turns them into a Switch. This can turn O(n) code into
        O(log n) code, or even O(1) code if the switch cases are dense.
        
        This can make a big difference in JS. Say you write a switch in which the case statements are
        variable resolutions. The bytecode generator cannot use a bytecode switch in this case, since
        we're required to evaluate the resolutions in order. But in DFG IR, we will often turn those
        variable resolutions into constants, since we do that for any immutable singleton. This means
        that B3 will see a chain of Branches: the else case of one Branch will point to a basic block
        that does nothing but Branch on equality on the same value as the first Branch.

        The inference algorithm is quite simple. The basic building block is the ability to summarize
        a block's switch behavior. For a block that ends in a switch, this is just the collection of
        switch cases. For a block that ends in a branch, we recognize Branch(Equal(value, const)),
        Branch(NotEqual(value, const)), and Branch(value). Each of these are summarized as if they
        were one-case switches. We infer a new switch if both some block and its sole predecessor
        can be described as switches on the same value, nothing shady is going on (like loops), and
        the block in question does no work other than this switch. In that case, the block is killed
        and its cases (which we get from the summary) are added to the predecessor's switch. This
        algorithm runs to fixpoint.
        
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir):
        * b3/B3InferSwitches.cpp: Added.
        (JSC::B3::inferSwitches):
        * b3/B3InferSwitches.h: Added.
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::cfg):
        * b3/B3ReduceStrength.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::performSubstitution):
        (JSC::B3::Value::isFree):
        (JSC::B3::Value::dumpMeta):
        * b3/B3Value.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckIdent):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        (JSC::FTL::DFG::LowerDFGToB3::lowSymbol):
        (JSC::FTL::DFG::LowerDFGToB3::lowSymbolUID):
        (JSC::FTL::DFG::LowerDFGToB3::lowNonNullObject):

2016-07-20  Filip Pizlo  <fpizlo@apple.com>

        FTL snippet generators should be able to request a different register for output and input
        https://bugs.webkit.org/show_bug.cgi?id=160010
        rdar://problem/27439330

        Reviewed by Saam Barati.
        
        The BitOr and BitXor snippet generators have problems if the register for the right input is
        the same as the register for the result. We could fix those generators, but I'm not convinced
        that the other snippet generators don't have this bug. So, the approach that this patch takes
        is to teach the FTL to request that B3 to use a different register for the result than for
        any input to the snippet patchpoint.
        
        Air already has the ability to let any instruction do an EarlyDef, which means exactly this.
        But B3 did not expose this via ValueRep. This patch exposes this in ValueRep as
        SomeEarlyRegister. That's most of the change.
        
        This adds a testb3 test for SomeEarlyRegister and a regression test for this particular
        problem. The regression test failed on trunk JSC before this.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::forEachArg):
        (JSC::B3::PatchpointSpecial::admitsStack):
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        (JSC::B3::StackmapSpecial::isArgValidForRep):
        * b3/B3Validate.cpp:
        * b3/B3ValueRep.cpp:
        (JSC::B3::ValueRep::addUsedRegistersTo):
        (JSC::B3::ValueRep::dump):
        (WTF::printInternal):
        * b3/B3ValueRep.h:
        (JSC::B3::ValueRep::ValueRep):
        (JSC::B3::ValueRep::reg):
        (JSC::B3::ValueRep::isAny):
        (JSC::B3::ValueRep::isReg):
        (JSC::B3::ValueRep::isSomeRegister): Deleted.
        * b3/testb3.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet):
        (JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet):
        (JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet):
        * tests/stress/ftl-bit-xor-right-result-interference.js: Added.

2016-07-20  Michael Saboff  <msaboff@apple.com>

        CrashOnOverflow in JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets
        https://bugs.webkit.org/show_bug.cgi?id=159954

        Reviewed by Benjamin Poulain.

        YarrPatternConstructor::setupAlternativeOffsets() is using the checked arithmetic class
        Checked<>, for offset calculations.  However the default use will just crash on
        overflow.  Instead we should stop processing and propagate the error up the call stack.

        Consolidated explicit error string with the common RegExp parsing error logic.
        Moved that logic to YarrPattern as that seems like a better common place to put it.

        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * tests/stress/regress-159954.js: New test.
        * yarr/YarrParser.h:
        (JSC::Yarr::Parser::CharacterClassParserDelegate::CharacterClassParserDelegate):
        (JSC::Yarr::Parser::CharacterClassParserDelegate::atomPatternCharacter):
        (JSC::Yarr::Parser::Parser):
        (JSC::Yarr::Parser::isIdentityEscapeAnError):
        (JSC::Yarr::Parser::parseEscape):
        (JSC::Yarr::Parser::parseCharacterClass):
        (JSC::Yarr::Parser::parseParenthesesBegin):
        (JSC::Yarr::Parser::parseParenthesesEnd):
        (JSC::Yarr::Parser::parseQuantifier):
        (JSC::Yarr::Parser::parseTokens):
        (JSC::Yarr::Parser::parse):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::disjunction):
        (JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets):
        (JSC::Yarr::YarrPatternConstructor::setupOffsets):
        (JSC::Yarr::YarrPattern::errorMessage):
        (JSC::Yarr::YarrPattern::compile):
        * yarr/YarrPattern.h:
        (JSC::Yarr::YarrPattern::reset):

2016-07-19  Filip Pizlo  <fpizlo@apple.com>

        The default testing mode should not involve disabling the FTL JIT
        https://bugs.webkit.org/show_bug.cgi?id=159929

        Rubber stamped by Mark Lam and Saam Barati.
        
        Use the new powers to make some tests run only in the default configuration (i.e. FTL,
        concurrent JIT).

        * tests/mozilla/mozilla-tests.yaml:

2016-07-19  Keith Miller  <keith_miller@apple.com>

        Test262 should have a file with the revision and url
        https://bugs.webkit.org/show_bug.cgi?id=159937

        Reviewed by Mark Lam.

        The file.

        * tests/test262/test262-Revision.txt: Added.

2016-07-19  Anders Carlsson  <andersca@apple.com>

        WebCore-7602.1.42 fails to build: error: private field 'm_vm' is not used
        https://bugs.webkit.org/show_bug.cgi?id=159944
        rdar://problem/27420308

        Reviewed by Dan Bernstein.

        Wrap the m_vm declaration and initialization in conditional guards.

        * Scripts/builtins/builtins_generate_internals_wrapper_header.py:
        (generate_members):
        * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
        (BuiltinsInternalsWrapperImplementationGenerator.generate_constructor):
        Add guards.

        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
        Update expected results.

2016-07-19  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION (r203348-r203368): ASSERTION FAILED: from.isCell() && from.asCell()->JSCell::inherits(std::remove_pointer<To>::type::info())
        https://bugs.webkit.org/show_bug.cgi?id=159930

        Reviewed by Geoffrey Garen.
        
        The problem is that the 32-bit DFG can flush the scope register as an unboxed cell, but the
        Register::scope() method was causing us to assert that it's a JSValue with proper cell
        boxing. We could have forced the DFG to flush it as a boxed JSValue, but I don't think that
        would have made anything better. This fixes the issue by teaching Register::scope() that it
        might see unboxed cells.

        * runtime/JSScope.h:
        (JSC::Register::scope):
        (JSC::ExecState::lexicalGlobalObject):

2016-07-19  Filip Pizlo  <fpizlo@apple.com>

        B3 methods that mutate the successors array should take FrequentedBlock by value
        https://bugs.webkit.org/show_bug.cgi?id=159935

        Reviewed by Michael Saboff.
        
        This bug was found by ASan testing. setSuccessors() takes a const FrequentedBlock&, and the
        caller that caused the ASan crash was doing:

        block->setSuccessors(block->notTaken())

        So, inside setSuccessors(), after we resize() the successors array, the const
        FrequentedBlock& points to nonsense.

        The fix is to pass FrequentedBlock by value in all of these kinds of methods.
        
        No new tests, but ASan testing catches this instantly for anything that triggers CFG
        simplification in B3. So like half of our tests.

        * b3/B3BasicBlock.cpp:
        (JSC::B3::BasicBlock::clearSuccessors):
        (JSC::B3::BasicBlock::appendSuccessor):
        (JSC::B3::BasicBlock::setSuccessors):
        * b3/B3BasicBlock.h:
        (JSC::B3::BasicBlock::successors):
        (JSC::B3::BasicBlock::successorBlock):
        * b3/B3Value.cpp:
        (JSC::B3::Value::replaceWithPhi):
        (JSC::B3::Value::replaceWithJump):
        (JSC::B3::Value::replaceWithOops):
        * b3/B3Value.h:

2016-07-18  Joseph Pecoraro  <pecoraro@apple.com>

        Make builtin TypeErrors consistent
        https://bugs.webkit.org/show_bug.cgi?id=159899

        Reviewed by Keith Miller.

        Converge on the single TypeError for non-coercible this objects in builtins.
        Also update some other style to be more consistent with-in builtins.

        * builtins/ArrayIteratorPrototype.js:
        (next):
        * builtins/ArrayPrototype.js:
        (values):
        (keys):
        (entries):
        (reduce):
        (reduceRight):
        (every):
        (forEach):
        (filter):
        (map):
        (some):
        (fill):
        (find):
        (findIndex):
        (includes):
        (sort):
        (concatSlowPath):
        (copyWithin):
        * builtins/StringPrototype.js:
        (match):
        (repeat):
        (padStart):
        (padEnd):
        (intrinsic.StringPrototypeReplaceIntrinsic.replace):
        (localeCompare):
        (search):
        (split):
        * tests/es6/String.prototype_methods_String.prototype.padEnd.js:
        * tests/es6/String.prototype_methods_String.prototype.padStart.js:
        * tests/stress/array-iterators-next-error-messages.js:
        (catch):
        * tests/stress/array-iterators-next-with-call.js:
        * tests/stress/regexp-match.js:
        (shouldThrow):
        * tests/stress/regexp-search.js:
        (shouldThrow):

2016-07-17  Filip Pizlo  <fpizlo@apple.com>

        Implement table-based switches in B3/Air
        https://bugs.webkit.org/show_bug.cgi?id=151141

        Reviewed by Benjamin Poulain.

        If a switch statement gets large, it's better to express it as an indirect jump rather than
        using a binary switch (divide-and-conquer tree of comparisons leading to O(log n) branches to
        get to the switch case). When dealing with integer switches, FTL will already use the B3
        Switch and expect this to get lowered as efficiently as possible; it's a bug that B3 will
        always use a binary switch rather than indirect jumps. When dealing with switches over some
        more sophisticated types, we'd want FTL to build an indirect jump table itself and use
        something like a hashtable to feed it. In that case, there will be no B3 Switch; we'll want
        some way for the FTL to directly express an indirection jump when emitting B3.
        
        This implies that we want B3 to have the ability to lower Switch to indirect jumps and to
        expose those indirect jumps in IR so that the FTL could do its own indirect jumps for
        switches over more complicated things like strings. But indirect jumps are tough to express
        in IR. For example, the LLVM approach ("indirectbr" and "blockaddress", see
        http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html) means that some
        control flow edges cannot be split. Indirectbr takes an address as input and jumps to it, and
        blockaddress lets you build jump tables out of basic block addresses. This means that the
        compiler can never change any successor of an indirectbr, since the client will have already
        arranged for that indirectbr to jump to exactly those successors. We don't want such
        restrictions in B3, since B3 relies on being able to break critical edges for SSA conversion.
        Also, indirectbr is not cloneable, which would break any hope of doing specialization-based
        transformations like we want to do for multiple entrypoints (bug 159391). The goal of this
        change is to let clients do indirect jumps without placing any restrictions on IR.
        
        The trick is to allow Patchpoints to be used as block terminals. Patchpoints already allow
        clients of B3 to emit whatever code they like. Patchpoints are friendly to B3's other
        transformations because the client of the patchpoint has to play along with whatever
        decisions B3 had made around the patchpoint: what registers got used, what the control flow
        looks like, etc. Patchpoints can even be cloned by B3, and the client has to accommodate this
        in their patchpoint generator. It turns out that using Patchpoints as terminals is quite
        natural. We accomplish this by moving the successor edges out of ControlValue and into
        BasicBlock, and removing ControlValue entirely. This way, any Value subclass can be a
        terminal. It was already true that a Value is a terminal if value->effects().terminal, which
        works great with Patchpoints since they control their effects via PatchpointValue::effects.
        You can make your Patchpoint into a terminal by placing it at the end of a block and doing:
        
        patchpoint->effects.terminal = true;
        
        A Patchpoints in terminal position gets access to additional API in StackmapGenerationParams.
        The generator can get a Box<Label> for each successor to its owning block. For example, to
        implement a jump-table-based switch, you would make your patchpoint take the table index as
        its sole input. Inside the generator, you allocate the jump table and emit a BaseIndex jump
        that uses the jump table pointer (which will be a constant known to the generator since it
        just allocated it) as the base and the patchpoint input as an index. The jump table can be
        populated by MacroAssemblerCodePtr's computed by installing a link task to resolve the labels
        to concrete locations. This change makes LowerMacros do such a lowering for Switches that can
        benefit from jump tables. This happens recursively: if the original Switch is too sparse, we
        will divide-and-conquer as before. If at any recursion step we find that the remaining cases
        are dense and large enough to profit from a jump table, then those cases will be lowered to a
        Patchpoint that does the table jump. This is a fun way to do stepwise lowering: LowerMacros
        is essentially pre-lowering the Switch directly to machine code, and wrapping that machine
        code in a Patchpoint so that the rest of the compiler doesn't have to know anything about
        what happened. I suspect that in the future we will want to do other pre-lowerings this way,
        whenever the B3 IR phases have some special knowledge about what machine code should be
        emitted and it would be annoying to drag that knowledge through the rest of the compiler.
        
        One downside of this change is that we used ControlValue in so many places. Most of this
        patch involves removing references to ControlValue. It would be less than 100kb if it wasn't
        for that. To make this a bit easier, I added "appendNewControlValue" methods to BasicBlock,
        which allocate a Value and set the successors as if you had done "appendNew<ControlValue>".
        This made for an easy search-and-replace in testb3 and FTLOutput. I filed bug 159440 to
        remove this ugly stopgap method.
        
        I think that we will also end up using this facility to extend our use of snippets. We
        already use shared snippet generators for the generic forms of arithmetic. We will probably
        also want to do this for generic forms of branches. This wouldn't have been possible prior to
        this change, since there would have been no way to emit a control snippet in FTL. Now we can
        emit control snippets using terminal patchpoints.

        This is a ~30% speed-up on microbenchmarks that have big switch statements (~60 cases). It's
        not a speed-up on mainstream benchmarks.
        
        This also adds a new test to testb3 for terminal Patchpoints, Get, and Set. The FTL does not
        currently use terminal Patchpoints directly, but we want this to be possible. It also doesn't
        use Get/Set directly even though we want this to be possible. It's important to test these
        since opcodes that result from lowering don't affect early phases, so we could have
        regressions in early phases related to these opcodes that wouldn't be caught by any JS test.
        So, this adds a very basic threaded interpreter to testb3 for a Brainfuck-style language, and
        tests it by having it run a program that prints the numbers 1..100 in a loop. Unlike a real
        threaded interpreter, it uses a common dispatch block rather than having dispatch at the
        terminus of each opcode. That's necessary because PolyJump is not cloneable. The state of the
        interpreter is represented using Variables that we Get and Set, so it tests Get/Set as well.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::jump):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::jump):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::jmp_m):
        * b3/B3BasicBlock.cpp:
        (JSC::B3::BasicBlock::append):
        (JSC::B3::BasicBlock::appendNonTerminal):
        (JSC::B3::BasicBlock::removeLast):
        (JSC::B3::BasicBlock::appendIntConstant):
        (JSC::B3::BasicBlock::clearSuccessors):
        (JSC::B3::BasicBlock::appendSuccessor):
        (JSC::B3::BasicBlock::setSuccessors):
        (JSC::B3::BasicBlock::replaceSuccessor):
        (JSC::B3::BasicBlock::addPredecessor):
        (JSC::B3::BasicBlock::deepDump):
        (JSC::B3::BasicBlock::appendNewControlValue):
        * b3/B3BasicBlock.h:
        (JSC::B3::BasicBlock::numSuccessors):
        (JSC::B3::BasicBlock::successor):
        (JSC::B3::BasicBlock::successors):
        (JSC::B3::BasicBlock::successorBlock):
        (JSC::B3::BasicBlock::successorBlocks):
        (JSC::B3::BasicBlock::numPredecessors):
        (JSC::B3::BasicBlock::predecessor):
        (JSC::B3::BasicBlock::frequency):
        * b3/B3BasicBlockInlines.h:
        (JSC::B3::BasicBlock::replaceLastWithNew):
        (JSC::B3::BasicBlock::taken):
        (JSC::B3::BasicBlock::notTaken):
        (JSC::B3::BasicBlock::fallThrough):
        (JSC::B3::BasicBlock::numSuccessors): Deleted.
        (JSC::B3::BasicBlock::successor): Deleted.
        (JSC::B3::BasicBlock::successors): Deleted.
        (JSC::B3::BasicBlock::successorBlock): Deleted.
        (JSC::B3::BasicBlock::successorBlocks): Deleted.
        * b3/B3BlockInsertionSet.cpp:
        (JSC::B3::BlockInsertionSet::splitForward):
        * b3/B3BreakCriticalEdges.cpp:
        (JSC::B3::breakCriticalEdges):
        * b3/B3CaseCollection.cpp: Added.
        (JSC::B3::CaseCollection::dump):
        * b3/B3CaseCollection.h: Added.
        (JSC::B3::CaseCollection::CaseCollection):
        (JSC::B3::CaseCollection::operator[]):
        (JSC::B3::CaseCollection::iterator::iterator):
        (JSC::B3::CaseCollection::iterator::operator*):
        (JSC::B3::CaseCollection::iterator::operator++):
        (JSC::B3::CaseCollection::iterator::operator==):
        (JSC::B3::CaseCollection::iterator::operator!=):
        (JSC::B3::CaseCollection::begin):
        (JSC::B3::CaseCollection::end):
        * b3/B3CaseCollectionInlines.h: Added.
        (JSC::B3::CaseCollection::fallThrough):
        (JSC::B3::CaseCollection::size):
        (JSC::B3::CaseCollection::at):
        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::CheckSpecial):
        (JSC::B3::CheckSpecial::hiddenBranch):
        * b3/B3Common.h:
        (JSC::B3::is64Bit):
        * b3/B3ControlValue.cpp: Removed.
        * b3/B3ControlValue.h: Removed.
        * b3/B3DataSection.cpp:
        (JSC::B3::DataSection::DataSection):
        * b3/B3DuplicateTails.cpp:
        * b3/B3FixSSA.cpp:
        * b3/B3FoldPathConstants.cpp:
        * b3/B3LowerMacros.cpp:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3MathExtras.cpp:
        (JSC::B3::powDoubleInt32):
        * b3/B3Opcode.h:
        (JSC::B3::isConstant):
        (JSC::B3::isDefinitelyTerminal):
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::generate):
        (JSC::B3::PatchpointSpecial::isTerminal):
        (JSC::B3::PatchpointSpecial::dumpImpl):
        * b3/B3PatchpointSpecial.h:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::resetReachability):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::lastPhaseName):
        (JSC::B3::Procedure::byproducts):
        * b3/B3ReduceStrength.cpp:
        * b3/B3StackmapGenerationParams.cpp:
        (JSC::B3::StackmapGenerationParams::unavailableRegisters):
        (JSC::B3::StackmapGenerationParams::successorLabels):
        (JSC::B3::StackmapGenerationParams::fallsThroughToSuccessor):
        (JSC::B3::StackmapGenerationParams::proc):
        * b3/B3StackmapGenerationParams.h:
        (JSC::B3::StackmapGenerationParams::gpScratch):
        (JSC::B3::StackmapGenerationParams::fpScratch):
        * b3/B3SwitchValue.cpp:
        (JSC::B3::SwitchValue::~SwitchValue):
        (JSC::B3::SwitchValue::removeCase):
        (JSC::B3::SwitchValue::hasFallThrough):
        (JSC::B3::SwitchValue::setFallThrough):
        (JSC::B3::SwitchValue::appendCase):
        (JSC::B3::SwitchValue::dumpSuccessors):
        (JSC::B3::SwitchValue::dumpMeta):
        (JSC::B3::SwitchValue::cloneImpl):
        (JSC::B3::SwitchValue::SwitchValue):
        * b3/B3SwitchValue.h:
        (JSC::B3::SwitchValue::accepts):
        (JSC::B3::SwitchValue::caseValues):
        (JSC::B3::SwitchValue::cases):
        (JSC::B3::SwitchValue::fallThrough): Deleted.
        (JSC::B3::SwitchValue::size): Deleted.
        (JSC::B3::SwitchValue::at): Deleted.
        (JSC::B3::SwitchValue::operator[]): Deleted.
        (JSC::B3::SwitchValue::iterator::iterator): Deleted.
        (JSC::B3::SwitchValue::iterator::operator*): Deleted.
        (JSC::B3::SwitchValue::iterator::operator++): Deleted.
        (JSC::B3::SwitchValue::iterator::operator==): Deleted.
        (JSC::B3::SwitchValue::iterator::operator!=): Deleted.
        (JSC::B3::SwitchValue::begin): Deleted.
        (JSC::B3::SwitchValue::end): Deleted.
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::replaceWithPhi):
        (JSC::B3::Value::replaceWithJump):
        (JSC::B3::Value::replaceWithOops):
        (JSC::B3::Value::dump):
        (JSC::B3::Value::deepDump):
        (JSC::B3::Value::dumpSuccessors):
        (JSC::B3::Value::negConstant):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h:
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::addFastTmp):
        (JSC::B3::Air::Code::addDataSection):
        (JSC::B3::Air::Code::jsHash):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::isFastTmp):
        (JSC::B3::Air::Code::setLastPhaseName):
        * b3/air/AirCustom.h:
        (JSC::B3::Air::PatchCustom::shouldTryAliasingDef):
        (JSC::B3::Air::PatchCustom::isTerminal):
        (JSC::B3::Air::PatchCustom::hasNonArgNonControlEffects):
        (JSC::B3::Air::PatchCustom::generate):
        (JSC::B3::Air::CCallCustom::admitsStack):
        (JSC::B3::Air::CCallCustom::isTerminal):
        (JSC::B3::Air::CCallCustom::hasNonArgNonControlEffects):
        (JSC::B3::Air::ShuffleCustom::admitsStack):
        (JSC::B3::Air::ShuffleCustom::isTerminal):
        (JSC::B3::Air::ShuffleCustom::hasNonArgNonControlEffects):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * b3/air/AirGenerationContext.h:
        * b3/air/AirInst.h:
        (JSC::B3::Air::Inst::hasNonControlEffects):
        * b3/air/AirSimplifyCFG.cpp:
        (JSC::B3::Air::simplifyCFG):
        * b3/air/AirSpecial.cpp:
        (JSC::B3::Air::Special::shouldTryAliasingDef):
        (JSC::B3::Air::Special::isTerminal):
        (JSC::B3::Air::Special::hasNonArgNonControlEffects):
        * b3/air/AirSpecial.h:
        * b3/air/AirValidate.cpp:
        * b3/air/opcode_generator.rb:
        * b3/testb3.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::jump):
        (JSC::FTL::Output::branch):
        (JSC::FTL::Output::ret):
        (JSC::FTL::Output::unreachable):
        (JSC::FTL::Output::speculate):
        (JSC::FTL::Output::trap):
        (JSC::FTL::Output::anchor):
        (JSC::FTL::Output::decrementSuperSamplerCount):
        (JSC::FTL::Output::addIncomingToPhi):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::constIntPtr):
        (JSC::FTL::Output::callWithoutSideEffects):
        (JSC::FTL::Output::switchInstruction):
        (JSC::FTL::Output::phi):
        (JSC::FTL::Output::addIncomingToPhi):

2016-07-18  Anders Carlsson  <andersca@apple.com>

        WebKit nightly fails to build on macOS Sierra
        https://bugs.webkit.org/show_bug.cgi?id=159902
        rdar://problem/27365672

        Reviewed by Tim Horton.

        * icu/unicode/ucurr.h: Added.
        Add ucurr.h from ICU.

2016-07-18  Michael Saboff  <msaboff@apple.com>

        ASSERTION FAILED: : (year >= 1970 && yearday >= 0) || (year < 1970 && yearday < 0) -- WTF/wtf/DateMath.cpp
        https://bugs.webkit.org/show_bug.cgi?id=159883

        Reviewed by Filip Pizlo.

        New test.

        * tests/stress/regress-159883.js: Added.

2016-07-12  Filip Pizlo  <fpizlo@apple.com>

        MarkedBlocks should know that they can be used for more than JSCells
        https://bugs.webkit.org/show_bug.cgi?id=159643

        Reviewed by Geoffrey Garen.
        
        This teaches the Heap that a MarkedBlock may hold either JSCells, or Auxiliary, which is
        not a JSCell. It teaches the heap and all of the things that walk the heap to ignore
        non-JSCells whenever they are looking for global objects, JSObjects, and things to trace
        for debugging or profiling. The idea is that we will be able to allocate butterflies and
        typed array backing stores as Auxiliary in MarkedSpace rather than allocating those things
        in CopiedSpace. That's what bug 159658 is all about.
        
        This gives us a new type, called HeapCell, which is just meant to be a class distinct from
        JSCell or any type we would use for Auxiliary. For convenience, JSCell is a subclass of
        HeapCell. HeapCell has an enum called HeapCell::Kind, which is either HeapCell::JSCell or
        HeapCell::Auxiliary. MarkedSpace no longer speaks of JSCells directly except when dealing
        with destruction.
        
        This change required doing a lot of stuff to all of those functor callbacks, since they
        now take HeapCell* instead of JSCell* and they take an extra HeapCell::Kind argument to
        tell them if they are dealing with JSCells or Auxiliary. I figured that this would be as
        good a time as any to convert those functors to being lambda-compatible. This means that
        operator() must be const. In some cases, converting the operator() to be const would have
        taken more work than just turning the whole thing into a lambda. Whenever this was the
        case, I converted the code to use lambdas. I left a lot of functors alone. In cases where
        the functor would benefit from being a lambda, for example because it would get rid of
        const_casts or mutables, I put in a FIXME referencing bug 159644.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * debugger/Debugger.cpp:
        (JSC::Debugger::SetSteppingModeFunctor::SetSteppingModeFunctor):
        (JSC::Debugger::SetSteppingModeFunctor::operator()):
        (JSC::Debugger::ToggleBreakpointFunctor::ToggleBreakpointFunctor):
        (JSC::Debugger::ToggleBreakpointFunctor::operator()):
        (JSC::Debugger::ClearCodeBlockDebuggerRequestsFunctor::ClearCodeBlockDebuggerRequestsFunctor):
        (JSC::Debugger::ClearCodeBlockDebuggerRequestsFunctor::operator()):
        (JSC::Debugger::ClearDebuggerRequestsFunctor::ClearDebuggerRequestsFunctor):
        (JSC::Debugger::ClearDebuggerRequestsFunctor::operator()):
        * heap/CodeBlockSet.h:
        (JSC::CodeBlockSet::iterate):
        * heap/HandleSet.h:
        (JSC::HandleNode::next):
        (JSC::HandleSet::forEachStrongHandle):
        * heap/Heap.cpp:
        (JSC::GatherHeapSnapshotData::GatherHeapSnapshotData):
        (JSC::GatherHeapSnapshotData::operator()):
        (JSC::RemoveDeadHeapSnapshotNodes::RemoveDeadHeapSnapshotNodes):
        (JSC::RemoveDeadHeapSnapshotNodes::operator()):
        (JSC::Heap::protectedGlobalObjectCount):
        (JSC::Heap::globalObjectCount):
        (JSC::Heap::protectedObjectCount):
        (JSC::Heap::protectedObjectTypeCounts):
        (JSC::Heap::objectTypeCounts):
        (JSC::Heap::deleteAllCodeBlocks):
        (JSC::MarkedBlockSnapshotFunctor::MarkedBlockSnapshotFunctor):
        (JSC::MarkedBlockSnapshotFunctor::operator()):
        (JSC::Zombify::visit):
        (JSC::Zombify::operator()):
        (JSC::Heap::zombifyDeadObjects):
        (JSC::Heap::flushWriteBarrierBuffer):
        * heap/Heap.h:
        (JSC::Heap::handleSet):
        (JSC::Heap::handleStack):
        * heap/HeapCell.cpp: Added.
        (WTF::printInternal):
        * heap/HeapCell.h: Added.
        (JSC::HeapCell::HeapCell):
        (JSC::HeapCell::zap):
        (JSC::HeapCell::isZapped):
        * heap/HeapInlines.h:
        (JSC::Heap::deprecatedReportExtraMemory):
        (JSC::Heap::forEachCodeBlock):
        (JSC::Heap::forEachProtectedCell):
        (JSC::Heap::allocateWithDestructor):
        * heap/HeapStatistics.cpp:
        (JSC::StorageStatistics::visit):
        (JSC::StorageStatistics::operator()):
        * heap/HeapVerifier.cpp:
        (JSC::GatherLiveObjFunctor::visit):
        (JSC::GatherLiveObjFunctor::operator()):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateBlock):
        (JSC::MarkedAllocator::addBlock):
        (JSC::MarkedAllocator::reset):
        (JSC::MarkedAllocator::lastChanceToFinalize):
        (JSC::LastChanceToFinalize::operator()): Deleted.
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::takeLastActiveBlock):
        (JSC::MarkedAllocator::resumeAllocating):
        (JSC::MarkedAllocator::forEachBlock):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::destroy):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC::MarkedBlock::callDestructor):
        (JSC::MarkedBlock::specializedSweep):
        (JSC::SetNewlyAllocatedFunctor::SetNewlyAllocatedFunctor):
        (JSC::SetNewlyAllocatedFunctor::operator()):
        (JSC::MarkedBlock::stopAllocating):
        (JSC::MarkedBlock::didRetireBlock):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::CountFunctor::CountFunctor):
        (JSC::MarkedBlock::CountFunctor::count):
        (JSC::MarkedBlock::CountFunctor::returnValue):
        (JSC::MarkedBlock::needsDestruction):
        (JSC::MarkedBlock::cellKind):
        (JSC::MarkedBlock::size):
        (JSC::MarkedBlock::clearNewlyAllocated):
        (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
        (JSC::MarkedBlock::isLive):
        (JSC::MarkedBlock::isLiveCell):
        (JSC::MarkedBlock::forEachCell):
        (JSC::MarkedBlock::forEachLiveCell):
        (JSC::MarkedBlock::forEachDeadCell):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::~MarkedSpace):
        (JSC::MarkedSpace::lastChanceToFinalize):
        (JSC::MarkedSpace::sweep):
        (JSC::MarkedSpace::zombifySweep):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::visitWeakSets):
        (JSC::MarkedSpace::reapWeakSets):
        (JSC::MarkedSpace::forEachAllocator):
        (JSC::MarkedSpace::stopAllocating):
        (JSC::MarkedSpace::resumeAllocating):
        (JSC::MarkedSpace::isPagedOut):
        (JSC::MarkedSpace::shrink):
        (JSC::clearNewlyAllocatedInBlock):
        (JSC::MarkedSpace::clearNewlyAllocated):
        (JSC::MarkedSpace::clearMarks):
        (JSC::Free::Free): Deleted.
        (JSC::Free::operator()): Deleted.
        (JSC::FreeOrShrink::FreeOrShrink): Deleted.
        (JSC::FreeOrShrink::operator()): Deleted.
        (JSC::VisitWeakSet::VisitWeakSet): Deleted.
        (JSC::VisitWeakSet::operator()): Deleted.
        (JSC::ReapWeakSet::operator()): Deleted.
        (JSC::LastChanceToFinalize::operator()): Deleted.
        (JSC::StopAllocatingFunctor::operator()): Deleted.
        (JSC::ResumeAllocatingFunctor::operator()): Deleted.
        (JSC::ClearNewlyAllocated::operator()): Deleted.
        (JSC::VerifyNewlyAllocated::operator()): Deleted.
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::forEachLiveCell):
        (JSC::MarkedSpace::forEachDeadCell):
        (JSC::MarkedSpace::allocatorFor):
        (JSC::MarkedSpace::allocateWithDestructor):
        (JSC::MarkedSpace::forEachBlock):
        (JSC::MarkedSpace::didAddBlock):
        (JSC::MarkedSpace::objectCount):
        (JSC::MarkedSpace::size):
        (JSC::MarkedSpace::capacity):
        (JSC::ClearMarks::operator()): Deleted.
        (JSC::Sweep::operator()): Deleted.
        (JSC::ZombifySweep::operator()): Deleted.
        (JSC::MarkCount::operator()): Deleted.
        (JSC::Size::operator()): Deleted.
        * runtime/JSCell.h:
        (JSC::JSCell::zap): Deleted.
        (JSC::JSCell::isZapped): Deleted.
        * runtime/JSCellInlines.h:
        (JSC::allocateCell):
        (JSC::JSCell::isObject):
        (JSC::isZapped): Deleted.
        * runtime/JSGlobalObject.cpp:
        * tools/JSDollarVMPrototype.cpp:
        (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
        (JSC::CellAddressCheckFunctor::operator()):

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

        Repeatedly creating and destroying workers that enqueue DFG plans can outpace the DFG worklist, which then causes VM shutdown to stall, which then causes memory growth
        https://bugs.webkit.org/show_bug.cgi?id=159754

        Reviewed by Geoffrey Garen.
        
        If you create and destroy workers at a high rate and those workers enqueue some DFG plans
        that are still not compiled at the time that the worker is closed, then the closed workers
        end up stalling in VM::~VM waiting for the DFG worklist thread to finish those plans. Since
        we don't actually cancel the plans, it's easy to create a situation where the workers
        outpace the DFG worklist, especially if you create many workers at a time and each one
        finishes just after enqueueing those plans.
        
        The solution is to allow VM::~VM to remove plans from the DFG worklist that are related to
        that VM but aren't currently being worked on. That turns out to be an easy change.
        
        I have a test that repros this, but it's quite long-running. I call it workers/bomb.html. We
        may want to exclude it from test runs because of how long it takes.

        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::removeDeadPlans):
        (JSC::DFG::Worklist::removeNonCompilingPlansForVM):
        (JSC::DFG::Worklist::queueLength):
        (JSC::DFG::Worklist::runThread):
        * dfg/DFGWorklist.h:
        * runtime/VM.cpp:
        (JSC::VM::~VM):

2016-07-17  Filip Pizlo  <fpizlo@apple.com>

        Object.preventExtensions/seal/freeze makes code much slower
        https://bugs.webkit.org/show_bug.cgi?id=143247

        Reviewed by Michael Saboff.
        
        This has been a huge pet peeve of mine for a long time, but I was always afraid of fixing
        it because I thought that it would be hard. Well, it looks like it's not hard at all.
        
        The problem is that you cannot mutate a structure that participates in transition caching.
        You can only clone the structure and mutate that one. But if you do this, you have to make
        a hard choice:
        
        1) Clone the structure without caching the transition. This is what the code did before
           this change. It's the most obvious choice, but it introduces an uncacheable transition
           that leads to an explosion of structures, which then breaks all inline caches.
        
        2) Perform one of the existing cacheable transitions. Cacheable transitions can either add
           properties or they can do one of the NonPropertyTransitions, which until now have been
           restricted to just IndexingType transitions. So, only adding transitions or making
           certain prescribed changes to the indexing type count as cacheable transitions.
        
        This change decouples NonPropertyTransition from IndexingType and adds three new kinds of
        transitions: PreventExtensions, Seal, and Freeze. We have to give any cacheable transition
        a name that fully disambiguates this transition from any other, so that the transition can
        be cached. Since we're already giving them names in an enum, I figured that the most
        pragmatic way to implement them is to have Structure::nonPropertyTransition() case on the
        NonPropertyTransition and implement all of the mutations associated with that transition.
        The alternative would have been to allow callers of nonPropertyTransition() to supply
        something like a lambda that describes the mutation, but this seemed awkward since each
        set of mutations has to anyway be tied to one of the NonPropertyTransition members.
        
        This is an enormous speed-up on microbenchmarks that use Object.preventExtensions(),
        Object.seal(), or Object.freeze(). I don't know if "real" benchmarks use these features
        and I don't really care. This should be fast.

        * runtime/JSObject.cpp:
        (JSC::JSObject::notifyPresenceOfIndexedAccessors):
        (JSC::JSObject::createInitialUndecided):
        (JSC::JSObject::createInitialInt32):
        (JSC::JSObject::createInitialDouble):
        (JSC::JSObject::createInitialContiguous):
        (JSC::JSObject::convertUndecidedToInt32):
        (JSC::JSObject::convertUndecidedToDouble):
        (JSC::JSObject::convertUndecidedToContiguous):
        (JSC::JSObject::convertInt32ToDouble):
        (JSC::JSObject::convertInt32ToContiguous):
        (JSC::JSObject::convertDoubleToContiguous):
        (JSC::JSObject::switchToSlowPutArrayStorage):
        * runtime/Structure.cpp:
        (JSC::Structure::suggestedArrayStorageTransition):
        (JSC::Structure::addPropertyTransition):
        (JSC::Structure::toUncacheableDictionaryTransition):
        (JSC::Structure::sealTransition):
        (JSC::Structure::freezeTransition):
        (JSC::Structure::preventExtensionsTransition):
        (JSC::Structure::takePropertyTableOrCloneIfPinned):
        (JSC::Structure::nonPropertyTransition):
        (JSC::Structure::pin):
        (JSC::Structure::pinForCaching):
        (JSC::Structure::allocateRareData):
        * runtime/Structure.h:
        * runtime/StructureTransitionTable.h:
        (JSC::toAttributes):
        (JSC::changesIndexingType):
        (JSC::newIndexingType):
        (JSC::preventsExtensions):
        (JSC::setsDontDeleteOnAllProperties):
        (JSC::setsReadOnlyOnAllProperties):

2016-07-17  Filip Pizlo  <fpizlo@apple.com>

        RegisterSet should use a Bitmap instead of a BitVector so that it never allocates memory and is trivial to copy
        https://bugs.webkit.org/show_bug.cgi?id=159863

        Reviewed by Saam Barati.
        
        Switch RegisterSet set to Bitmap because Bitmap doesn't ever allocate memory and can be
        assigned by memcpy. This should be a performance improvement for compiler code that does a
        lot of things with RegisterSet. For example, it's one of the fundamental data structures in
        Air. The previous use of BitVector meant that almost every operation on RegisterSet would
        have a slow path call. On ARM64, it would mean memory allocation for any RegisterSet that
        used all available registers.
        
        This meant adding even more GPR/FPR reflection to the MacroAssembler API: we now have consts
        called numGPRs and numFPRs. This is necessary to statically size the Bitmap in RegisterSet.
        
        Here's the breakdown of sizes of RegisterSet on different CPUs:
        
        x86-32: 8 bits (GPRs) + 8 bits (FPRs) + 1 bit (is deleted) = 1x uint32_t.
        x86-64: 16 bits + 16 bits + 1 bit = 2x uint32_t.
        ARMv7: 16 bits + 16 bits + 1 bit = 2x uint32_t.
        ARM64: 32 bits + 32 bits + 1 bit = 3x uint32_t.

        * assembler/MacroAssemblerARM.h:
        * assembler/MacroAssemblerARM64.h:
        * assembler/MacroAssemblerARMv7.h:
        * assembler/MacroAssemblerX86.h:
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::scratchRegister):
        * assembler/MacroAssemblerX86_64.h:
        * jit/RegisterSet.h:
        (JSC::RegisterSet::set):
        (JSC::RegisterSet::get):
        (JSC::RegisterSet::setAll):
        (JSC::RegisterSet::merge):
        (JSC::RegisterSet::filter):
        (JSC::RegisterSet::exclude):
        (JSC::RegisterSet::numberOfSetRegisters):
        (JSC::RegisterSet::RegisterSet):
        (JSC::RegisterSet::isEmptyValue):
        (JSC::RegisterSet::isDeletedValue):
        (JSC::RegisterSet::operator==):
        (JSC::RegisterSet::operator!=):
        (JSC::RegisterSet::hash):
        (JSC::RegisterSet::forEach):
        (JSC::RegisterSet::setMany):

2016-07-15  Filip Pizlo  <fpizlo@apple.com>

        DFG and FTL should support op_call_eval
        https://bugs.webkit.org/show_bug.cgi?id=159786

        Reviewed by Saam Barati.
        
        This adds support for op_call_eval in DFG and FTL by brute force:
        
        - There is now a CallEval() node type, which compiles exactly the same way that we do in
          baseline.
        
        - We teach the DFG and bytecode liveness that the scope register and 'this' are read by
          CallEval()/op_call_eval.
        
        We can compile eval quite well, except that right now we cannot inline functions that use
        eval. It would be nice to do that, but the payoff is probably smaller. "Don't inline users
        of eval" may even be an OK inlining heuristic. Not inlining users of eval allows me to
        reuse the baseline implementation, which is really great. Otherwise, I'd have to get rid
        of things like the rogue reads of scope register and 'this'.
        
        The goal here is to produce speed-ups for code that has functions that do both eval and
        some computational stuff. Obviously, we're not producing any benefit for the eval itself.
        But now the other stuff in a function that uses eval will get to participate in
        optimization.
        
        This is a huge speed-up on microbenchmarks.

        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printCallOp):
        (JSC::CodeBlock::dumpBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::setLocal):
        (JSC::DFG::ByteCodeParser::setArgument):
        (JSC::DFG::ByteCodeParser::flush):
        (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/DFGGraph.h:
        (JSC::DFG::Graph::needsScopeRegister):
        (JSC::DFG::Graph::needsFlushedThis):
        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGMayExit.cpp:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * 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/DFGWatchpointCollectionPhase.cpp:
        (JSC::DFG::WatchpointCollectionPhase::handle):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
        (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::emitDumbVirtualCall):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitTypeOf):
        * jit/JITCall.cpp:
        (JSC::JIT::compileCallEvalSlowCase):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileCallEvalSlowCase):
        * jit/JITOperations.cpp:
        * tests/stress/exit-then-eval.js: Added.
        (foo):
        * tests/stress/force-exit-then-eval-dfg.js: Added.
        (foo):
        * tests/stress/force-exit-then-eval.js: Added.
        (foo):

2016-07-12  Filip Pizlo  <fpizlo@apple.com>

        DFG should really support jneq_ptr
        https://bugs.webkit.org/show_bug.cgi?id=159700

        Reviewed by Keith Miller.
        
        Prior to this change, DFG statically speculated that jneq_ptr would always fall through. This
        meant that programs that called o.apply() or o.call() where apply or call weren't the
        expected ones (i.e. the function.prototype.apply/call) would rage-recompile forever.
        
        This adds profiling to jneq_ptr. We now know if it always falls through or sometimes doesn't.
        If it sometimes doesn't, we now emit an actual control flow diamond. I decided to add a new
        NodeType for "equal pointer", since none of the existing ones really captured that. For
        example, there was no way to express "equal pointer" for strings or symbols. We don't use it
        for that right now, but we might, and if we did, then it would be hugely surprising that the
        DFG interpreted this as value equality. So, the DFG now has CompareEqPtr, which means exactly
        what jneq_ptr means by "equal pointer".
        
        This is an enormous speed-up on microbenchmarks. I would assume that it's a speed-up on some
        real things, too, but I don't know that for a fact.

        * bytecode/BytecodeList.json:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitJumpIfNotFunctionCall):
        (JSC::BytecodeGenerator::emitJumpIfNotFunctionApply):
        (JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
        * 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/DFGNode.h:
        (JSC::DFG::Node::hasCellOperand):
        * dfg/DFGNodeType.h:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileRecordRegExpCachedResult):
        (JSC::DFG::SpeculativeJIT::compileCompareEqPtr):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareEqPtr):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareLess):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEqConstant): Deleted.
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_jneq_ptr):
        (JSC::JIT::emit_op_eq):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_jneq_ptr):
        (JSC::JIT::emit_op_eq):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2016-07-12  Filip Pizlo  <fpizlo@apple.com>

        OSR entry into DFG has problems with lexical scoping
        https://bugs.webkit.org/show_bug.cgi?id=159687

        Reviewed by Saam Barati.
        
        What a fun bug! It turns out that uses of lexical scoping, like "let", may sometimes cause us
        to not be able to OSR enter into a loop from baseline to DFG. The bug is in a mitigation for
        a different bug, which in turn had a mitigation for yet another bug, so the story here is a
        long one.
        
        DFG OSR entry has long had a mitigation for the following bug: the DFG bytecode parser may
        choose to make us always OSR exit at some instruction if it thinks that it doesn't have
        enough profiling for that instruction. We will do this if some kinds of put_by_id only
        execute once, for example. This causes problems for loopy benchmarks like this:
        
            put_by_id(something crazy);
            for (var i = 0; i < bigNumber; ++i) simpleMath;
        
        In this case, the put_by_id will have only executed once, and since it did something crazy
        that one time, the bytecode parser will replace it with ForceOSRExit.
        
        This creates an OSR entry bug: DFG CFA will then prove that the loop is unreachable, and will
        tell OSR entry that it's impossible to enter into that loop.
        
        We mitigated this bug a long time ago by recording mustHandleValues for loops at which we
        want to enter. We inject these values into DFG CFA and we force CFA to recognize that the
        loop is reachable even if CFA wanted to prove that it wasn't.
        
        But this leads to another bug: we need to scrape the values from the stack inside
        operationOptimize() and then we need to reason about them in the compiler. Some of those
        values may be garbage, which would cause pandemonium inside the compiler. We also mitigated
        this bug, by only recording the "vars", since those are guaranteed to be reset by op_enter.
        
        And that's where the lexical scoping bug happens: "let" bound variables aren't part of the
        "vars". DFG will see that they are live, but mustHandleValues will not have anything for
        those variables, so CFA will prove that the values are Bottom. Then OSR entry will always
        fail because no value is ever a subset of Bottom.
        
        The first part of the fix is to ensure that mustHandleValues record all of the values on the
        stack (i.e. within m_numCalleeLocals, rather than just m_numVars). But this creates a second
        problem: we may record garbage. This patch includes a better fix for the garbage: before
        touching mustHandleValues we run the bytecode liveness analysis and clear any values that are
        not live. This ensures that we clear the garbage.
        
        This is an enormous speed-up on microbenchmarks that use lexical scoping and have some crazy
        put_by_id in the lead-up to the hot loop.

        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::CFAPhase::run):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        (JSC::DFG::Plan::checkLivenessAndVisitChildren):
        (JSC::DFG::Plan::cancel):
        (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
        * dfg/DFGPlan.h:
        (JSC::DFG::Plan::canTierUpAndOSREnter):
        * jit/JITOperations.cpp:

2016-07-18  Youenn Fablet  <youenn@apple.com>

        REGRESSION(r202975): --minimal build is broken
        https://bugs.webkit.org/show_bug.cgi?id=159765

        Reviewed by Chris Dumez.

        Covered partially by builtin generated test code.

        Updating generator to add a global compilation guard around the code that generates all global internal properties.
        Split the generate_methods function in two, one dedicated to the visit method and the second one dedicated to
        the initialize method.

        * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
        (BuiltinsInternalsWrapperImplementationGenerator.generate_section_for_object): Use splitted generation functions.
        (BuiltinsInternalsWrapperImplementationGenerator.generate_visit_method): Response to generate the visit method.
        (BuiltinsInternalsWrapperImplementationGenerator._generate_initialize_static_globals): Responsible to generate
        the code to initialize the internal globals. This code is put in a global compilation guard in case all
        internals are compiled out by specific builds.
        (BuiltinsInternalsWrapperImplementationGenerator):
        (BuiltinsInternalsWrapperImplementationGenerator.generate_initialize_method): Responsible to generate the
        initialize method.
        (BuiltinsInternalsWrapperImplementationGenerator.generate_methods): Deleted.
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: Copyright change.
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: Reflects partially the built-in
        generator change.

2016-07-18  Keith Miller  <keith_miller@apple.com>

        Fix bad assertions in genericTypedArrayViewPrivateFuncSubarrayCreate
        https://bugs.webkit.org/show_bug.cgi?id=159882
        <rdar://problem/27327111>

        Reviewed by Mark Lam.

        According the spec toInteger can return values we don't consider ints.
        Such as, -0 and +/-Infinity. This broke some assertions in
        genericTypedArrayViewPrivateFuncSubarrayCreate.

        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
        * tests/stress/typedarray-subarray.js:

2016-07-16  Filip Pizlo  <fpizlo@apple.com>

        DFG CSE is broken for MultiGetByOffset
        https://bugs.webkit.org/show_bug.cgi?id=159858

        Reviewed by Saam Barati.
        
        This disabled CSE for MultiGetByOffset. I opened bug 159859 for the long-term fix, which
        would teach CSE (and other passes also) how to decay a removed MultiGetByOffset to a
        CheckStructure. Since we currently just decay MultiGetByOffset to Check, we forget the
        structure checks. So, if we CSE a MultiGetByOffset that checks for one set of structures with
        a heap access on the same property and base that checks for different structures, then we
        will forget some structure checks that we had previously. It's unsound to forget checks in
        DFG IR.
        
        This bug mostly manifested as a high-volume crash at Unreachable in FTL, because we'd prove
        that the code after the MultiGetByOffset was unreachable due to the structure checks and then
        CSE would remove everything but the Unreachable.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize): Remove the def() for MultiGetByOffset to disable CSE for this node for now.
        * tests/stress/cse-multi-get-by-offset-remove-checks.js: Added. This used to fail with FTL enabled.
        (Cons1):
        (Cons2):
        (Cons3):
        (foo):
        (bar):

2016-07-17  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Enable test262 module tests
        https://bugs.webkit.org/show_bug.cgi?id=159854

        Reviewed by Saam Barati.

        This patch enables test262 module tests. Before this patch, the modules tests in test262 do not work fine.
        This patch fixes the following 2 things.

        1. Test harness

            Before this patch, there is only one global switch "-m" in jsc shell. So we cannot load the test262 test harness before evaluating the module tests.
            This patch adds a new option, "--module-file=". It is similar to "--strict-file=". When we specify the file with "--module-file=", it is evaluated as
            a module, while the other files are evaluated by following the JSC's default manner. This option allows us to load the test harness files into the
            global context before loading the module tests.

        2. Module's asynchronous errors

            Before this patch, the errors caused in the module evaluation are not handled as the same to the usual sync files. In synchronous execution, we have
            "--exception=" option to pass the expected exception to the JSC shell. But this option does not work in the module evaluation.
            This patch correctly handles this expected exception in the module evaluation promise's fulfill and reject handlers.

        And we fix the YAML file. Now the recorded :fail and :normal are the correct test results for the module tests.

        * jsc.cpp:
        (Script::Script):
        (checkUncaughtException):
        (runWithScripts):
        (printUsageStatement):
        (CommandLine::parseArguments):
        (dumpException): Deleted.
        * tests/test262.yaml:

2016-07-17  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Mask TrustedImm32 to 8bit in MacroAssembler for 8bit operations
        https://bugs.webkit.org/show_bug.cgi?id=159334

        Reviewed by Filip Pizlo.

        Previously, in 8bit operations (like add8, compare8, test8, branch8, branchTest8 etc.),
        we require that the given TrustedImm32 is in range of 8bit. While achieving this in
        the manual MacroAssembler calling is easy, in Air, we don't guarantee that the higher bit
        of the 8bit argument is cleared. So the current assertions are invalid.

        This patch relaxes the above restriction. By removing this assertion,
        8bit operations can take arbitrary 32bit imms. And only lower 8bit are effective when
        emitting the code in these methods.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::branchTest8):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::store8):
        (JSC::MacroAssemblerARM::branch8):
        (JSC::MacroAssemblerARM::branchTest8):
        (JSC::MacroAssemblerARM::compare8):
        (JSC::MacroAssemblerARM::test8):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::store8):
        (JSC::MacroAssemblerARM64::branch8):
        (JSC::MacroAssemblerARM64::branchTest8):
        (JSC::MacroAssemblerARM64::compare8):
        (JSC::MacroAssemblerARM64::test8):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::store8):
        (JSC::MacroAssemblerARMv7::branch8):
        (JSC::MacroAssemblerARMv7::branchTest8):
        (JSC::MacroAssemblerARMv7::compare8):
        (JSC::MacroAssemblerARMv7::test8):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::store8):
        (JSC::MacroAssemblerMIPS::branch8):
        (JSC::MacroAssemblerMIPS::compare8):
        (JSC::MacroAssemblerMIPS::branchTest8):
        (JSC::MacroAssemblerMIPS::test8):
        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::store8):
        (JSC::MacroAssemblerSH4::branchTest8):
        (JSC::MacroAssemblerSH4::branch8):
        (JSC::MacroAssemblerSH4::compare8):
        (JSC::MacroAssemblerSH4::test8):
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::store8):
        (JSC::MacroAssemblerX86::branch8):
        (JSC::MacroAssemblerX86::branchTest8):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::add8):
        (JSC::MacroAssemblerX86Common::store8):
        (JSC::MacroAssemblerX86Common::branch8):
        (JSC::MacroAssemblerX86Common::branchTest8):
        (JSC::MacroAssemblerX86Common::compare8):
        (JSC::MacroAssemblerX86Common::test8):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::store8):
        (JSC::MacroAssemblerX86_64::branch8):
        (JSC::MacroAssemblerX86_64::branchTest8):

2016-07-16  Chris Dumez  <cdumez@apple.com>

        Unreviewed, rolling out r203318.

        Regressed most JS Benchmarks on MacBook Air by ~2% (7% on
        SunSpider)

        Reverted changeset:

        "[JSC] Change some parameters based on a random search"
        https://bugs.webkit.org/show_bug.cgi?id=158514
        http://trac.webkit.org/changeset/203318

2016-07-15  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Convert the remaining createOutOfMemoryError()+throwException() into throwOutOfMemoryError()
        https://bugs.webkit.org/show_bug.cgi?id=159665

        Reviewed by Saam Barati.

        * API/JSTypedArray.cpp:
        (createTypedArray):
        * runtime/Error.cpp:
        (JSC::createOutOfMemoryError):
        * runtime/Error.h:
        * runtime/ExceptionHelpers.cpp:
        (JSC::throwOutOfMemoryError):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::constructArrayBuffer):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::arrayBufferProtoFuncSlice):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::create):
        (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):

2016-07-15  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Change some parameters based on a random search
        https://bugs.webkit.org/show_bug.cgi?id=158514

        Reviewed by Saam Barati.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::optimizationThresholdScalingFactor):
        * runtime/Options.h:

2016-07-15  Mark Lam  <mark.lam@apple.com>

        Assertion failures and crashes with missing TDZ checks for catch-node bindings.
        https://bugs.webkit.org/show_bug.cgi?id=158797

        Reviewed by Saam Barati.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitPushCatchScope):
        (JSC::BytecodeGenerator::emitPopCatchScope):
        * tests/stress/catch-clause-should-be-under-tdz1.js: Added.
        * tests/stress/catch-clause-should-be-under-tdz2.js: Added.
        * tests/stress/catch-clause-should-be-under-tdz3.js: Added.
        * tests/stress/catch-clause-should-be-under-tdz4.js: Added.
        * tests/stress/catch-clause-should-be-under-tdz5.js: Added.

2016-07-15  Geoffrey Garen  <ggaren@apple.com>

        Added a makeRef<T> helper
        https://bugs.webkit.org/show_bug.cgi?id=159835

        Reviewed by Andreas Kling.

        Anders told me to!

        * inspector/InjectedScriptHost.cpp:
        (Inspector::InjectedScriptHost::wrapper):

2016-07-15  Mark Lam  <mark.lam@apple.com>

        FunctionOverride's parseClause() needs to keep the CString instance in scope while its data is being used.
        https://bugs.webkit.org/show_bug.cgi?id=159828

        Reviewed by Saam Barati.

        Otherwise, we'll have a use after free.  This issue was caught when running an
        ASan debug build of testapi.

        * tools/FunctionOverrides.cpp:
        (JSC::parseClause):

2016-07-15  Keith Miller  <keith_miller@apple.com>

        %TypedArray%.prototype.indexOf is coercing non-integers or non-floats to numbers wrongly
        https://bugs.webkit.org/show_bug.cgi?id=159400

        Reviewed by Geoffrey Garen.

        This patch fixes coercion of non-numbers in indexOf/lastIndexOf.
        Additionally, this patch fixes an issue with includes where it
        would not check that the buffer remained non-neutered after
        calling the toInteger() function. Lastly, some extra release
        asserts have been added in some places to inform us of any issues
        in the future.

        Additionally, this patch changes bool toNativeFromDouble to
        Optional<Type> toNativeFromDoubleWithoutCoercion. This makes it a
        little clearer what the function does and also removes the return
        argument. The only behavior change is that the function no longer
        coerces non-numbers into numbers. That behavior was unused (maybe
        unintended), however.

        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValueWithoutCoercion):
        (JSC::JSGenericTypedArrayView::sort):
        (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue): Deleted.
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncCopyWithin):
        (JSC::genericTypedArrayViewProtoFuncIncludes):
        (JSC::genericTypedArrayViewProtoFuncIndexOf):
        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
        * runtime/ToNativeFromValue.h:
        (JSC::toNativeFromValueWithoutCoercion):
        (JSC::toNativeFromValue): Deleted.
        * runtime/TypedArrayAdaptors.h:
        (JSC::IntegralTypedArrayAdaptor::toNativeFromInt32WithoutCoercion):
        (JSC::IntegralTypedArrayAdaptor::toNativeFromUint32WithoutCoercion):
        (JSC::IntegralTypedArrayAdaptor::toNativeFromDoubleWithoutCoercion):
        (JSC::FloatTypedArrayAdaptor::toNativeFromInt32WithoutCoercion):
        (JSC::FloatTypedArrayAdaptor::toNativeFromDoubleWithoutCoercion):
        (JSC::Uint8ClampedAdaptor::toNativeFromInt32WithoutCoercion):
        (JSC::Uint8ClampedAdaptor::toNativeFromDoubleWithoutCoercion):
        (JSC::IntegralTypedArrayAdaptor::toNativeFromInt32): Deleted.
        (JSC::IntegralTypedArrayAdaptor::toNativeFromUint32): Deleted.
        (JSC::IntegralTypedArrayAdaptor::toNativeFromDouble): Deleted.
        (JSC::FloatTypedArrayAdaptor::toNativeFromInt32): Deleted.
        (JSC::FloatTypedArrayAdaptor::toNativeFromDouble): Deleted.
        (JSC::Uint8ClampedAdaptor::toNativeFromInt32): Deleted.
        (JSC::Uint8ClampedAdaptor::toNativeFromDouble): Deleted.
        * tests/stress/resources/typedarray-test-helper-functions.js:
        * tests/stress/typedarray-functions-with-neutered.js:
        (callWithArgs):
        * tests/stress/typedarray-includes.js: Added.
        * tests/stress/typedarray-indexOf.js:
        * tests/stress/typedarray-lastIndexOf.js:

2016-07-15  Csaba Osztrogonác  <ossy@webkit.org>

        Add new functions to ARMAssembler after r202214
        https://bugs.webkit.org/show_bug.cgi?id=159713

        Reviewed by Saam Barati.

        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::fillNops):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::patchableBranch32):
        (JSC::MacroAssemblerARM::internalCompare32):

2016-07-15  Mark Lam  <mark.lam@apple.com>

        Stack overflow error for deeply nested classes.
        https://bugs.webkit.org/show_bug.cgi?id=157086

        Reviewed by Geoffrey Garen.

        Changed the StructureStubClearingWatchpoint destructor to iteratively destruct
        its chain of next StructureStubClearingWatchpoints instead of recursively doing
        so.

        The added deep-StructureStubClearingWatchpoint-destructor-recursion.js test
        produces a crash before the fix is applied, but takes about 14 minutes to run.
        Hence, it is skipped.

        * bytecode/StructureStubClearingWatchpoint.cpp:
        (JSC::StructureStubClearingWatchpoint::~StructureStubClearingWatchpoint):
        * tests/stress/deep-StructureStubClearingWatchpoint-destructor-recursion.js: Added.

2016-07-15  Csaba Osztrogonác  <ossy@webkit.org>

        Fix expectations in test262.yaml
        https://bugs.webkit.org/show_bug.cgi?id=159810

        Reviewed by Keith Miller.

        * tests/test262.yaml:

2016-07-15  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Disable Inline Caching on ARMv7 traditional until proper fix
        https://bugs.webkit.org/show_bug.cgi?id=159759

        Reviewed by Saam Barati.

        * jit/Repatch.cpp:
        (JSC::forceICFailure):

2016-07-14  Keith Miller  <keith_miller@apple.com>

        Add Test262 test files and yaml

        Rubber Stamped by Benjamin Poulain.

        This patch adds all the test262 test files and the yaml that drives
        run-jsc-stress-tests.

        * tests/test262.yaml: Added. Yaml file to drive the test262 test suite with our driver.
        * tests/test262/LICENSE: Added. License for the test262 test suite.
        * tests/test262/harness/: Added. Harness directory for the test262 tests.
        * tests/test262/test/: Added. Directory with all the actual test files.

2016-07-14  Joseph Pecoraro  <pecoraro@apple.com>

        Return the correct value from Heap::externalMemorySize
        https://bugs.webkit.org/show_bug.cgi?id=159797
        <rdar://problem/27362446>

        Reviewed by Timothy Hatcher.

        * heap/Heap.h:
        (JSC::Heap::externalMemorySize):
        We should have been returning m_externalMemorySize which is a subset
        of m_extraMemorySize. In practice the difference can be small. A major
        difference in "extra memory size" may be from deprecated memory size
        and array buffer sizes.

2016-07-14  Saam Barati  <sbarati@apple.com>

        It should be a syntax error to have a 'use strict' directive inside a function that has a non-simple parameter list
        https://bugs.webkit.org/show_bug.cgi?id=159790
        <rdar://problem/27171636>

        Reviewed by Geoffrey Garen.

        Is is a syntax error for a function's parameter list to be non-simple
        and for the function to also contain a 'use strict' directive.

        See section 14.2.1 of the spec:
        https://tc39.github.io/ecma262/#sec-arrow-function-definitions-static-semantics-early-errors

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseSourceElements):
        (JSC::Parser<LexerType>::parseFormalParameters):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::strictMode):
        (JSC::Scope::isValidStrictMode):
        (JSC::Scope::shadowsArguments):
        (JSC::Scope::setHasNonSimpleParameterList):
        (JSC::Scope::hasNonSimpleParameterList):
        (JSC::Scope::copyCapturedVariablesToVector):

2016-07-14  Geoffrey Garen  <ggaren@apple.com>

        ASSERTION FAILED: : this != replacement()
        https://bugs.webkit.org/show_bug.cgi?id=159779

        Reviewed by Michael Saboff.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::jettison): If we jettison during GC, and our owner
        is dead, we choose not to replace ourselves. (See
        https://bugs.webkit.org/show_bug.cgi?id=159588.) So, it's possible to
        invalidate and still be our owner's CodeBlock. Relax our ASSERT to allow
        for this.

2016-07-14  Mark Lam  <mark.lam@apple.com>

        JSONObject Walker::walk must save array length before processing array elements.
        https://bugs.webkit.org/show_bug.cgi?id=153485

        Reviewed by Darin Adler and Michael Saboff.

        According to https://tc39.github.io/ecma262/#sec-internalizejsonproperty,
        JSON.parse() should cache the length of an array and use the cached length when
        iterating array elements (see section 24.3.1.1 2.b.iii).

        * runtime/JSONObject.cpp:
        (JSC::Walker::walk):
        * tests/stress/JSON-parse-should-cache-array-lengths.js: Added.
        (toString):
        (shouldBe):
        (test):
        (test2):

2016-07-14  Julien Brianceau  <jbriance@cisco.com>

        [mips] Handle properly unaligned halfword load
        https://bugs.webkit.org/show_bug.cgi?id=153226

        Reviewed by Michael Catanzaro.

        Waiting for the kernel to silently fix-up unaligned accesses is
        not efficient, so let's provide an implementation of load16Unaligned
        in mips macro assembler.

        Performance improvement seen with SunSpider's regexp-dna test.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::load16Unaligned):
        (JSC::MacroAssemblerMIPS::load32WithUnalignedHalfWords):

2016-07-14  Youenn Fablet  <youenn@apple.com>

        DOM value iterable interfaces should use Array prototype methods
        https://bugs.webkit.org/show_bug.cgi?id=159296

        Reviewed by Chris Dumez and Mark Lam.

        * JavaScriptCore.xcodeproj/project.pbxproj: Marking some header files as private so that they can be included in
        WebCore.
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation): copying iterable methods (entries, forEach, keys and values) to private slots.

2016-07-13  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the magic numbers for ARM traditional in InlineAccess.h
        https://bugs.webkit.org/show_bug.cgi?id=159708

        Reviewed by Saam Barati.

        * bytecode/InlineAccess.h:
        (JSC::InlineAccess::sizeForPropertyAccess):
        (JSC::InlineAccess::sizeForPropertyReplace):
        (JSC::InlineAccess::sizeForLengthAccess):

2016-07-13  Michael Saboff  <msaboff@apple.com>

        YARR uses mixture of int and unsigned values to index into subject string
        https://bugs.webkit.org/show_bug.cgi?id=159744

        Reviewed by Benjamin Poulain.

        In most cases, we refer to characters in subject strings using a negative index from the number of
        "checked" characters in a subject string.  The required length is compared against the actual length
        and then we use that required length as the checked amount.  For example, when matching the string of
        4 digits in the RegExp /abc \d{4}/, we know that need 8 characters in the subject string.  We refer
        to the digits part of the expression from an already checked index of 8 and use negative offsets of
        -4 through -1.  In many cases we used a signed int for the negative offsets.  There are other cases
        where we used unsigned values as the amount of negative offset to use when accessing subject characters.

        Changed all occurrances of character offsets to unsigned or Checked Arithmetic unsigned values.  Note
        that the pre-existing Checked class is used in other places to check for under/overflow with arithmetic
        operations.  Those unsigned offsets are always the number of characters before (negative) from the
        current checked character offset.  Also added some asserts for cases where arithmetic is not protected
        by other checks or with Checked<> wrapped values.

        In the case of the JIT, subject characters are accessed using base with scaled index and offset
        addressing.  The MacroAssembler provides this addressing using the BaseIndex struct.  The offset for
        this struct is a 32 bit signed quantity.  Since we only care about negative offsets, we really only
        have 31 bits.  Changed the generation of a BaseOffset address to handle the case when the offset and
        scaled combination will exceed the 31 bits of negative offset.  This is done by moving the base value
        into a temp register and biasing the temp base and offset to smaller values so that we can emit
        instructions that can reference characters without exceeding the 31 bits of negative offset.

        To abstract the character address generation, put the base with scaled index and offset into
        one function and used that function everywhere the YARR JIT wants to access subject characters.
        Also consilidated a few cases where we were generating inline what readCharacter() does.  Usually
        this was due to using a different index register.

        Added a new regression test.

        * tests/stress/regress-159744.js: Added regression test.
        (testRegExp):
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::recordParenthesesMatch):
        (JSC::Yarr::Interpreter::resetMatches):
        (JSC::Yarr::Interpreter::matchParenthesesOnceEnd):
        (JSC::Yarr::Interpreter::backtrackParenthesesOnceEnd):
        (JSC::Yarr::ByteCompiler::closeBodyAlternative):
        (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
        (JSC::Yarr::ByteCompiler::atomParenthesesOnceEnd):
        (JSC::Yarr::ByteCompiler::atomParenthesesTerminalEnd):
        (JSC::Yarr::ByteCompiler::emitDisjunction):
        * yarr/YarrInterpreter.h:
        (JSC::Yarr::ByteTerm::ByteTerm):
        (JSC::Yarr::ByteTerm::BOL):
        (JSC::Yarr::ByteTerm::UncheckInput):
        (JSC::Yarr::ByteTerm::EOL):
        (JSC::Yarr::ByteTerm::WordBoundary):
        (JSC::Yarr::ByteTerm::BackReference):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::notAtEndOfInput):
        (JSC::Yarr::YarrGenerator::negativeOffsetIndexedAddress):
        (JSC::Yarr::YarrGenerator::readCharacter):
        (JSC::Yarr::YarrGenerator::jumpIfCharNotEquals):
        (JSC::Yarr::YarrGenerator::storeToFrame):
        (JSC::Yarr::YarrGenerator::generateAssertionBOL):
        (JSC::Yarr::YarrGenerator::backtrackAssertionBOL):
        (JSC::Yarr::YarrGenerator::generateAssertionEOL):
        (JSC::Yarr::YarrGenerator::matchAssertionWordchar):
        (JSC::Yarr::YarrGenerator::generateAssertionWordBoundary):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterGreedy):
        (JSC::Yarr::YarrGenerator::backtrackPatternCharacterNonGreedy):
        (JSC::Yarr::YarrGenerator::generateCharacterClassOnce):
        (JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
        (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
        (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
        (JSC::Yarr::YarrGenerator::generate):
        (JSC::Yarr::YarrGenerator::backtrack):
        (JSC::Yarr::YarrGenerator::YarrGenerator):
        * yarr/YarrPattern.h:
        (JSC::Yarr::PatternTerm::PatternTerm):

2016-07-13  Keith Miller  <keith_miller@apple.com>

        Crashes with detached ArrayBuffers
        https://bugs.webkit.org/show_bug.cgi?id=157088
        <rdar://problem/27327362>

        Reviewed by Filip Pizlo.

        TypedArray.prototype.fill was incorrect because it should perform
        ToNumber coercion each time it tries to store the
        object. Currently, we only perform the coercion once at the
        beginning of the loop. If we find that we need to improve the
        performance of this function, we can add a faster C++ path back
        that only handles the primitive case.

        This patch also moves the isNeutered() checks from put and
        putByIndex into setIndex. This fixes an issue where setIndex might
        store to a no longer valid offset.

        * builtins/TypedArrayPrototype.js:
        (globalPrivate.typedArrayClampArgumentToStartOrEnd):
        (fill):
        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::setIndexQuickly):
        (JSC::JSGenericTypedArrayView::setIndex):
        (JSC::JSGenericTypedArrayView::setRangeToValue): Deleted.
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::put): Deleted.
        (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex): Deleted.
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncFill): Deleted.
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        (JSC::typedArrayViewProtoFuncFill): Deleted.
        * tests/stress/typedarray-fill.js:
        * tests/stress/typedarray-functions-with-neutered.js:
        (defaultForArg):
        (test2):
        (checkArgumentsForType): Deleted.
        (checkArguments): Deleted.

2016-07-13  Michael Saboff  <msaboff@apple.com>

        Some bad unicode regex escapes aren't flagged as errors
        https://bugs.webkit.org/show_bug.cgi?id=158080

        Reviewed by Saam Barati.

        If we have a partial unicode escape, eg /\u{1/u or /\u12|abc/u, we
        didn't check for the closing '}' and processed the unicode escape with
        the hex value provided.  

        Added a check that we properly terminated a \u{} unicode escape.
        If we fail that check and there isn't a prior error, we record that we
        have an invalid unicode escape.  The next existing line in the code will
        terminate parsing and bubble up the error.

        * yarr/YarrParser.h:
        (JSC::Yarr::Parser::parseEscape):

2016-07-13  Chris Dumez  <cdumez@apple.com>

        Unreviewed, rolling out r203199.

        Broke the build

        Reverted changeset:

        "Crashes with detached ArrayBuffers"
        https://bugs.webkit.org/show_bug.cgi?id=157088
        http://trac.webkit.org/changeset/203199

2016-07-13  Keith Miller  <keith_miller@apple.com>

        Crashes with detached ArrayBuffers
        https://bugs.webkit.org/show_bug.cgi?id=157088
        <rdar://problem/27327362>

        Reviewed by Filip Pizlo.

        TypedArray.prototype.fill was incorrect because it should perform
        ToNumber coercion each time it tries to store the
        object. Currently, we only perform the coercion once at the
        beginning of the loop. If we find that we need to improve the
        performance of this function, we can add a faster C++ path back
        that only handles the primitive case.

        This patch also moves the isNeutered() checks from put and
        putByIndex into setIndex. This fixes an issue where setIndex might
        store to a no longer valid offset.

        * builtins/TypedArrayPrototype.js:
        (globalPrivate.typedArrayClampArgumentToStartOrEnd):
        (fill):
        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::setIndexQuickly):
        (JSC::JSGenericTypedArrayView::setIndex):
        (JSC::JSGenericTypedArrayView::setRangeToValue): Deleted.
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::put): Deleted.
        (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex): Deleted.
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncFill): Deleted.
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        (JSC::typedArrayViewProtoFuncFill): Deleted.
        * tests/stress/typedarray-fill.js:
        * tests/stress/typedarray-functions-with-neutered.js:
        (defaultForArg):
        (test2):
        (checkArgumentsForType): Deleted.
        (checkArguments): Deleted.

2016-07-13  Enrica Casucci  <enrica@apple.com>

        Update supported platforms in xcconfig files to match the sdk names.
        https://bugs.webkit.org/show_bug.cgi?id=159728

        Reviewed by Tim Horton.

        * Configurations/Base.xcconfig:

2016-07-13  Csaba Osztrogonác  <ossy@webkit.org>

        CLoop buildfix after r203142
        https://bugs.webkit.org/show_bug.cgi?id=159706

        Unreviewed buildfix.

        * interpreter/CLoopStack.cpp:
        (JSC::CLoopStack::isSafeToRecurse):
        * interpreter/CLoopStack.h:
        * interpreter/CLoopStackInlines.h:
        (JSC::CLoopStack::isSafeToRecurse): Deleted.

2016-07-12  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Array.prototype.join() fails some conformance tests
        https://bugs.webkit.org/show_bug.cgi?id=159657

        Reviewed by Saam Barati.

        There were a couple of failures:
        -separator.toString() was called *before* we get the length
         and process ToLength() on it.
        -We were using toUInt32() on length instead of ToLength(),
         failing on big integers and various negative numbers.

        Additionally, I replaced the "fast" ArrayStorage path
        by a fully generic implementation that does not depends on StringJoiner.

        The reason is StringJoiner was doing poorly on sparse objects
        in certain cases.
        If you have a sparse object with a length > INT_MAX but very few
        indices defined, and you join on the empty string, it should be possible
        to join the array (albeit very slowly). With StringJoiner, we fail
        because we try to allocate > INT_MAX empty strings in a contiguous vector.

        * runtime/ArrayPrototype.cpp:
        (JSC::slowJoin):
        (JSC::canUseFastJoin):
        (JSC::fastJoin):
        (JSC::arrayProtoFuncJoin):
        (JSC::join): Deleted.
        * runtime/JSArray.h:
        (JSC::toLength):

2016-07-12  Mark Lam  <mark.lam@apple.com>

        Gardening: C Loop build fix after r203142.

        Not reviewed.

        * interpreter/CLoopStackInlines.h:
        (JSC::CLoopStack::isSafeToRecurse):

2016-07-12  Commit Queue  <commit-queue@webkit.org>

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

        This change caused an existing LayoutTest to time out on debug
        testers (Requested by ryanhaddad on #webkit).

        Reverted changeset:

        "[JSC] Array.prototype.join() fails some conformance tests"
        https://bugs.webkit.org/show_bug.cgi?id=159657
        http://trac.webkit.org/changeset/203131

2016-07-12  Mark Lam  <mark.lam@apple.com>

        We should use different stack limits for stack checks from JS and host code.
        https://bugs.webkit.org/show_bug.cgi?id=159442
        <rdar://problem/26889188>

        Reviewed by Geoffrey Garen.

        We have 2 stack reservedZoneSizes:
        1. Options::softReservedZoneSize()
        2. Options::reservedZoneSize()

        Respectively, there are used to define 2 stack limits based on these reserved
        zone sizes:
        1. VM::m_softStackLimit
        2. VM::m_stackLimit

        Options::reservedZoneSize() is the amount of the stack space that JSC guarantees
        to the VM and client host code for it's use.  Host code that has well known
        stack usage characteristics (i.e. doesn't call arbitrary code) may do stack
        checks against the VM::m_stackLimit limit (which is computed using
        Options::reservedZoneSize()).

        Options::softReservedZoneSize() is a more conservative amount of reserved stack
        space.  This is used to compute the VM::m_softStackLimit limit.  Any code that
        is difficult to have its stack usage characterized (i.e. may call arbitrary code)
        may need more stack space for its work.  Hence, these should do stack checks
        against the VM::m_softStackLimit limit.

        JS code and host code that may call into JS code falls into the category of code
        that may call arbitrary code.  Hence, they should do stack checks against the
        VM::m_softStackLimit limit.

        Accordingly, the VM now provides 2 recursion check functions:

        1. VM::isSafeToRecurseSoft() will do a stack check against VM::m_softStackLimit.
           In addition, for C Loop builds, VM::isSafeToRecurseSoft() will also
           check the CLoopStack against VM::m_cloopStackLimit.

        2. VM::isSafeToRecurse() will do a stack check against VM::m_stackLimit.

        Also added a promise-infinite-recursion-should-not-crash.js test.

        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitNodeInTailPosition):
        (JSC::BytecodeGenerator::emitNodeInConditionContext):
        * interpreter/CLoopStack.cpp:
        (JSC::CLoopStack::grow):
        * interpreter/CLoopStack.h:
        (JSC::CLoopStack::size):
        * interpreter/CLoopStackInlines.h:
        (JSC::CLoopStack::ensureCapacityFor):
        (JSC::CLoopStack::isSafeToRecurse):
        (JSC::CLoopStack::topOfFrameFor):
        * interpreter/CachedCall.h:
        (JSC::CachedCall::CachedCall):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * parser/Parser.cpp:
        * runtime/Options.h:
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        (JSC::ProxyObject::performPut):
        (JSC::performProxyCall):
        (JSC::performProxyConstruct):
        (JSC::ProxyObject::performDelete):
        (JSC::ProxyObject::performPreventExtensions):
        (JSC::ProxyObject::performIsExtensible):
        (JSC::ProxyObject::performDefineOwnProperty):
        (JSC::ProxyObject::performGetOwnPropertyNames):
        (JSC::ProxyObject::performSetPrototype):
        (JSC::ProxyObject::performGetPrototype):
        * runtime/RegExp.cpp:
        (JSC::RegExp::finishCreation):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/StringRecursionChecker.h:
        (JSC::StringRecursionChecker::performCheck):
        * runtime/VM.cpp:
        (JSC::VM::setStackPointerAtVMEntry):
        (JSC::VM::updateSoftReservedZoneSize):
        (JSC::preCommitStackMemory):
        (JSC::VM::updateStackLimits):
        (JSC::VM::updateStackLimit): Deleted.
        * runtime/VM.h:
        (JSC::VM::stackLimit):
        (JSC::VM::softStackLimit):
        (JSC::VM::addressOfSoftStackLimit):
        (JSC::VM::setCLoopStackLimit):
        (JSC::VM::isSafeToRecurse):
        (JSC::VM::lastStackTop):
        (JSC::VM::setException):
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        (JSC::VM::isSafeToRecurseSoft):
        (JSC::VM::shouldTriggerTermination):
        * tests/stress/promise-infinite-recursion-should-not-crash.js: Added.
        (testPromise):
        (promiseFunc):
        * yarr/YarrPattern.cpp:

2016-07-12  Per Arne Vollan  <pvollan@apple.com>

        [Win] Fix for build error when trying to version stamp dll.
        https://bugs.webkit.org/show_bug.cgi?id=159692

        Reviewed by Brent Fulgham.

        Use correct path to version stamp script.

        * CMakeLists.txt:

2016-07-12  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Array.prototype.join() fails some conformance tests
        https://bugs.webkit.org/show_bug.cgi?id=159657

        Reviewed by Saam Barati.

        There were a couple of failures:
        -separator.toString() was called *before* we get the length
         and process ToLength() on it.
        -We were using toUInt32() on length instead of ToLength(),
         failing on big integers and various negative numbers.

        Additionally, I replaced the "fast" ArrayStorage path
        by a fully generic implementation that does not depends on StringJoiner.

        The reason is StringJoiner was doing poorly on sparse objects
        in certain cases.
        If you have a sparse object with a length > INT_MAX but very few
        indices defined, and you join on the empty string, it should be possible
        to join the array (albeit very slowly). With StringJoiner, we fail
        because we try to allocate > INT_MAX empty strings in a contiguous vector.

        * runtime/ArrayPrototype.cpp:
        (JSC::slowJoin):
        (JSC::canUseFastJoin):
        (JSC::fastJoin):
        (JSC::arrayProtoFuncJoin):
        (JSC::join): Deleted.
        * runtime/JSArray.h:
        (JSC::toLength):

2016-07-12  Mark Lam  <mark.lam@apple.com>

        More stack limit and reserved zone renaming.
        https://bugs.webkit.org/show_bug.cgi?id=159690

        Rubber-stamped by Geoffrey Garen.

        We should rename the following:
            osStackLimitWithReserve => softStackLimit
            reservedZoneSize => softReservedZoneSize
            errorModeReservedZoneSize => reservedZoneSize

        * API/tests/PingPongStackOverflowTest.cpp:
        (testPingPongStackOverflow):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        * interpreter/CLoopStack.cpp:
        (JSC::CLoopStack::CLoopStack):
        (JSC::CLoopStack::grow):
        (JSC::CLoopStack::releaseExcessCapacity):
        (JSC::CLoopStack::addToCommittedByteCount):
        (JSC::CLoopStack::setSoftReservedZoneSize):
        (JSC::CLoopStack::setReservedZoneSize): Deleted.
        * interpreter/CLoopStack.h:
        (JSC::CLoopStack::size):
        * interpreter/CLoopStackInlines.h:
        (JSC::CLoopStack::shrink):
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ErrorHandlingScope.cpp:
        (JSC::ErrorHandlingScope::ErrorHandlingScope):
        (JSC::ErrorHandlingScope::~ErrorHandlingScope):
        * runtime/ErrorHandlingScope.h:
        * runtime/Options.h:
        * runtime/RegExp.cpp:
        (JSC::RegExp::finishCreation):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::setStackPointerAtVMEntry):
        (JSC::VM::updateSoftReservedZoneSize):
        (JSC::VM::updateStackLimit):
        (JSC::VM::updateReservedZoneSize): Deleted.
        * runtime/VM.h:
        (JSC::VM::stackPointerAtVMEntry):
        (JSC::VM::softReservedZoneSize):
        (JSC::VM::softStackLimit):
        (JSC::VM::addressOfSoftStackLimit):
        (JSC::VM::cloopStackLimit):
        (JSC::VM::setCLoopStackLimit):
        (JSC::VM::isSafeToRecurse):
        (JSC::VM::reservedZoneSize): Deleted.
        (JSC::VM::osStackLimitWithReserve): Deleted.
        (JSC::VM::addressOfOSStackLimitWithReserve): Deleted.
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::startFunction):

2016-07-12  Gyuyoung Kim  <gyuyoung.kim@webkit.org>

        Remove ENABLE_CSS3_TEXT_LINE_BREAK flag
        https://bugs.webkit.org/show_bug.cgi?id=159671

        Reviewed by Csaba Osztrogonác.

        ENABLE_CSS3_TEXT_LINE_BREAK feature was implemented without guards.
        https://bugs.webkit.org/show_bug.cgi?id=89235

        So this guard can be removed in build scripts.

        * Configurations/FeatureDefines.xcconfig:

2016-07-12  Per Arne Vollan  <pvollan@apple.com>

        [Win] DLLs are missing version information.
        https://bugs.webkit.org/show_bug.cgi?id=159349

        Reviewed by Brent Fulgham.

        Generate autoversion.h and run perl version stamp utility.

        * CMakeLists.txt:

2016-07-11  Caio Lima  <ticaiolima@gmail.com>

        ECMAScript 2016: %TypedArray%.prototype.includes implementation
        https://bugs.webkit.org/show_bug.cgi?id=159385

        Reviewed by Benjamin Poulain.

        This patch implements the ECMAScript 2016:
        %TypedArray%.prototype.includes
        following spec 22.2.3.14
        https://tc39.github.io/ecma262/2016/#sec-%typedarray%.prototype.includes

        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncIncludes):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewProtoFuncIncludes):
        (JSC::JSTypedArrayViewPrototype::finishCreation):

2016-07-11  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Array.from() and Array.of() try to build objects even if "this" is not a constructor
        https://bugs.webkit.org/show_bug.cgi?id=159604

        Reviewed by Yusuke Suzuki.

        The spec says IsConstructor(), we were just checking if "this"
        is any function.

        * builtins/ArrayConstructor.js:
        (of):
        (from):

2016-07-11  Keith Miller  <keith_miller@apple.com>

        defineProperty on a index of a TypedArray should throw if configurable
        https://bugs.webkit.org/show_bug.cgi?id=159653

        Reviewed by Saam Barati.

        When I fixed this before I misread the spec and thought it said we
        should throw if the descriptor said the proprety is not
        configurable. This is the opposite. We should throw if the
        descriptor says the property is configurable.

        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
        * tests/stress/typedarray-access-monomorphic-neutered.js:
        * tests/stress/typedarray-access-neutered.js:
        * tests/stress/typedarray-configure-index.js: Added.
        (assert):
        (assertThrows):
        (makeDescriptor):
        (test):

2016-07-11  Saam Barati  <sbarati@apple.com>

        some paths in Array.prototype.splice don't account for the array not having certain indexed properties
        https://bugs.webkit.org/show_bug.cgi?id=159641
        <rdar://problem/27171999>

        Reviewed by Filip Pizlo and Keith Miller.

        Array.prototype.splice was incorrectly putting properties on
        the result array even if the |this| array didn't have those
        properties. This is not the behavior of the spec. However, this
        could also cause a crash because we can construct a program where
        we would putByIndex on a typed array where the value we are
        putting is JSValue(). This is bad because the typed array will
        try to convert JSValue() into an integer.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSplice):
        * tests/stress/array-prototype-splice-making-typed-array.js: Added.
        (assert):
        (test):

2016-07-11  Mark Lam  <mark.lam@apple.com>

        Refactor JSStack to only be the stack data structure for the C Loop.
        https://bugs.webkit.org/show_bug.cgi?id=159545

        Reviewed by Geoffrey Garen.

        Changes made:
        1. Renamed JSStack to CLoopStack.
        2. Made all of CLoopStack code to conditional on #if !ENABLE(JIT) i.e. they will
           only be in effect for the C Loop build.
        3. Changed clients of JSStack to use new equivalent VM APIs:
            a. JSStack::ensureCapacityFor() => VM::ensureStackCapacityFor()
            b. JSStack::committedByteCount() => VM::committedStackByteCount()
        4. Made VM::updateReservedZoneSize() call CLoopStack::setReservedZoneSize()
           instead of calling it from all the clients of VM::updateReservedZoneSize().
        5. Removed all unnecessary references to JSStack.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MaxFrameExtentForSlowPathCall.h:
        * bytecode/BytecodeConventions.h:
        * dfg/DFGGraph.h:
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * ftl/FTLOSREntry.cpp:
        (JSC::FTL::prepareOSREntry):
        * heap/Heap.cpp:
        (JSC::Heap::finalizeUnconditionalFinalizers):
        (JSC::Heap::willStartIterating):
        (JSC::Heap::gatherJSStackRoots):
        (JSC::Heap::stack): Deleted.
        * heap/Heap.h:
        * interpreter/CLoopStack.cpp: Copied from Source/JavaScriptCore/interpreter/JSStack.cpp.
        (JSC::commitSize):
        (JSC::CLoopStack::CLoopStack):
        (JSC::CLoopStack::~CLoopStack):
        (JSC::CLoopStack::grow):
        (JSC::CLoopStack::gatherConservativeRoots):
        (JSC::CLoopStack::sanitizeStack):
        (JSC::CLoopStack::releaseExcessCapacity):
        (JSC::CLoopStack::addToCommittedByteCount):
        (JSC::CLoopStack::setReservedZoneSize):
        (JSC::CLoopStack::committedByteCount):
        (JSC::JSStack::JSStack): Deleted.
        (JSC::JSStack::~JSStack): Deleted.
        (JSC::JSStack::growSlowCase): Deleted.
        (JSC::JSStack::gatherConservativeRoots): Deleted.
        (JSC::JSStack::sanitizeStack): Deleted.
        (JSC::JSStack::releaseExcessCapacity): Deleted.
        (JSC::JSStack::addToCommittedByteCount): Deleted.
        (JSC::JSStack::setReservedZoneSize): Deleted.
        (JSC::JSStack::lowAddress): Deleted.
        (JSC::JSStack::highAddress): Deleted.
        (JSC::JSStack::committedByteCount): Deleted.
        * interpreter/CLoopStack.h: Copied from Source/JavaScriptCore/interpreter/JSStack.h.
        (JSC::CLoopStack::containsAddress):
        (JSC::CLoopStack::lowAddress):
        (JSC::CLoopStack::highAddress):
        (JSC::CLoopStack::reservationTop):
        (JSC::JSStack::containsAddress): Deleted.
        (JSC::JSStack::lowAddress): Deleted.
        (JSC::JSStack::highAddress): Deleted.
        (JSC::JSStack::reservationTop): Deleted.
        * interpreter/CLoopStackInlines.h: Copied from Source/JavaScriptCore/interpreter/JSStackInlines.h.
        (JSC::CLoopStack::ensureCapacityFor):
        (JSC::CLoopStack::topOfFrameFor):
        (JSC::CLoopStack::topOfStack):
        (JSC::CLoopStack::shrink):
        (JSC::CLoopStack::setCLoopStackLimit):
        (JSC::JSStack::ensureCapacityFor): Deleted.
        (JSC::JSStack::topOfFrameFor): Deleted.
        (JSC::JSStack::topOfStack): Deleted.
        (JSC::JSStack::shrink): Deleted.
        (JSC::JSStack::grow): Deleted.
        (JSC::JSStack::setCLoopStackLimit): Deleted.
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::unsafeCallSiteIndex):
        (JSC::CallFrame::currentVPC):
        (JSC::CallFrame::stack): Deleted.
        * interpreter/CallFrame.h:
        (JSC::ExecState::callerFrameAndPC):
        (JSC::ExecState::unsafeCallerFrameAndPC):
        * interpreter/Interpreter.cpp:
        (JSC::sizeOfVarargs):
        (JSC::sizeFrameForForwardArguments):
        (JSC::sizeFrameForVarargs):
        (JSC::Interpreter::Interpreter):
        * interpreter/Interpreter.h:
        (JSC::Interpreter::cloopStack):
        (JSC::Interpreter::getOpcode):
        (JSC::Interpreter::isCallBytecode):
        (JSC::Interpreter::stack): Deleted.
        * interpreter/JSStack.cpp: Removed.
        * interpreter/JSStack.h: Removed.
        * interpreter/JSStackInlines.h: Removed.
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::dump):
        * jit/JIT.h:
        * jit/JITOperations.cpp:
        * jit/JSInterfaceJIT.h:
        * jit/SpecializedThunkJIT.h:
        * jit/ThunkGenerators.cpp:
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::llint_stack_check_at_vm_entry):
        * llint/LLIntThunks.cpp:
        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoop::execute):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor):
        * runtime/ErrorHandlingScope.cpp:
        (JSC::ErrorHandlingScope::ErrorHandlingScope):
        (JSC::ErrorHandlingScope::~ErrorHandlingScope):
        * runtime/JSGlobalObject.h:
        * runtime/MemoryStatistics.cpp:
        (JSC::globalMemoryStatistics):
        * runtime/StackAlignment.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::updateReservedZoneSize):
        (JSC::sanitizeStackForVM):
        (JSC::VM::committedStackByteCount):
        * runtime/VM.h:
        (JSC::VM::reservedZoneSize):
        (JSC::VM::osStackLimitWithReserve):
        (JSC::VM::addressOfOSStackLimitWithReserve):
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        (JSC::VM::shouldTriggerTermination):

2016-07-11  Keith Miller  <keith_miller@apple.com>

        STP TypedArray.subarray 5x slowdown compared to 9.1
        https://bugs.webkit.org/show_bug.cgi?id=156404
        <rdar://problem/26493032>

        Reviewed by Geoffrey Garen.

        This patch moves the species constructor work for
        %TypedArray%.prototype.subarray to a js wrapper. By moving the
        species constructor work to JS we are able to completely optimize
        it out in DFG. The actual work of creating a TypedArray is still
        done in C++ since we are able to avoid calling into the
        constructor, which is expensive. This patch also changes the error
        message when a %TypedArray%.prototype function is passed a non-typed
        array this value. Finally, we used to check that the this value
        had not been detached, however, this behavior was incorrect.

        * builtins/BuiltinNames.h:
        * builtins/TypedArrayPrototype.js:
        (globalPrivate.typedArraySpeciesConstructor):
        (subarray):
        * runtime/ConstructData.cpp:
        (JSC::construct):
        * runtime/ConstructData.h:
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
        (JSC::genericTypedArrayViewProtoFuncSubarray): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewPrivateFuncLength):
        (JSC::typedArrayViewPrivateFuncSubarrayCreate):
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        (JSC::typedArrayViewProtoFuncSubarray): Deleted.
        * runtime/JSTypedArrayViewPrototype.h:

2016-07-11  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION(r202992): JSC varargs tests are broken
        https://bugs.webkit.org/show_bug.cgi?id=159616

        Reviewed by Csaba Osztrogonác.

        The substitution miss in r202992 causes varargs tests failures in GTK port.

        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):

2016-07-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Promise.{all,race} no longer use @@species
        https://bugs.webkit.org/show_bug.cgi?id=159615

        Reviewed by Keith Miller.

        As per the latest ES draft, Promise.{all,race} no longer use @@species.
        So, this patch drops FIXMEs.

        * builtins/PromiseConstructor.js:
        (all):
        (race):
        * tests/stress/ignore-promise-species.js: Added.
        (shouldBe):
        (DerivedPromise.prototype.get Symbol):
        (DerivedPromise):

2016-07-10  Commit Queue  <commit-queue@webkit.org>

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

        The JSC tests are breaking in elcapitan-debug-tests-jsc and
        elcapitan-release-tests-jsc (Requested by caiolima on
        #webkit).

        Reverted changeset:

        "ECMAScript 2016: %TypedArray%.prototype.includes
        implementation"
        https://bugs.webkit.org/show_bug.cgi?id=159385
        http://trac.webkit.org/changeset/203037

2016-07-10  Caio Lima  <ticaiolima@gmail.com>

        ECMAScript 2016: %TypedArray%.prototype.includes implementation
        https://bugs.webkit.org/show_bug.cgi?id=159385

        Reviewed by Benjamin Poulain.

        This patch implements the ECMAScript 2016:
        %TypedArray%.prototype.includes
        following spec 22.2.3.14
        https://tc39.github.io/ecma262/2016/#sec-%typedarray%.prototype.includes

        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncIncludes):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewProtoFuncIncludes):
        (JSC::JSTypedArrayViewPrototype::finishCreation):

2016-07-09  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(201900): validation failure for GetByOffset/PutByOffset in VALIDATE((node), node->child1().node() == node->child2().node() || node->child1()->result() == NodeResultStorage)
        https://bugs.webkit.org/show_bug.cgi?id=159603

        Reviewed by Keith Miller.
        
        This removes an incorrect validation rule and replaces it with a FIXME about how to make this
        aspect of IR easier to validate soundly.
        
        It's not valid to assert that two children of a node are the same. It should always be valid
        to take:
        
        Foo(@x, @x)
        
        and turn it into:
        
        a: ValueRep(@x)
        b: ValueRep(@x)
        Foo(@a, @b)
        
        or even something like:
        
        y: Identity(@y)
        Foo(@x, @y)
        
        That's because it should be possible to rewire any data flow edge something that produces an
        equivalent value.
        
        The validation rule that this patch removes meant that such rewirings were invalid on
        GetByOffset/PutByOffset. FixupPhase did such a rewiring sometimes.

        * dfg/DFGValidate.cpp:
        * tests/stress/get-by-offset-double.js: Added.

2016-07-09  Keith Miller  <keith_miller@apple.com>

        appendMemcpy might fail in concatAppendOne
        https://bugs.webkit.org/show_bug.cgi?id=159601
        <rdar://problem/27211300>

        Reviewed by Mark Lam.

        There are multiple reasons why we might fail appendMemcpy. One
        reason, which I suspect was the source of the crashes, is that one
        of the Array prototypes has an indexed property. This patch
        consolidates the two old cases by just creating an array then
        attempting to memcpy append. If that fails, we fall back to
        moveElements.

        * runtime/ArrayPrototype.cpp:
        (JSC::concatAppendOne):
        * tests/stress/concat-with-holesMustForwardToPrototype.js: Added.
        (arrayEq):

2016-07-09  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Fix the Template Raw Value of \ (escape) + LineTerminatorSequence
        https://bugs.webkit.org/show_bug.cgi?id=159595

        Reviewed by Yusuke Suzuki.

        The spec (https://tc39.github.io/ecma262/#sec-static-semantics-tv-and-trv)
        says:
        "The TRV of LineContinuation::\LineTerminatorSequence is the sequence
         consisting of the code unit value 0x005C followed by the code units
         of TRV of LineTerminatorSequence."
        
        We were not normalizing the LineTerminatorSequence in that case, but it should
        be as it is the TRV of LineTerminatorSequence.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::parseTemplateLiteral):
        * tests/stress/tagged-templates-raw-strings.js:

2016-07-08  Saam Barati  <sbarati@apple.com>

        We may add a ReadOnly property without setting the corresponding bit on Structure
        https://bugs.webkit.org/show_bug.cgi?id=159542
        <rdar://problem/27084591>

        Reviewed by Benjamin Poulain.

        The reason this usually is OK is due to happenstance. Often, instances that putDirectWithoutTransition
        also happen to have a static property table. Having a static property table causes the
        HasReadOnlyOrGetterSetterPropertiesExcludingProto on the structure to be set. However, 
        there are times where an object calls putDirectWithoutTransition, and it doesn't have a
        static property hash table. The fix is simple, putDirectWithTransition needs to set the
        HasReadOnlyOrGetterSetterPropertiesExcludingProto if it puts a ReadOnly property.

        * runtime/JSObject.h:
        (JSC::JSObject::putDirectWithoutTransition):
        * tests/stress/proper-property-store-with-prototype-property-that-is-not-writable.js: Added.
        (assert):

2016-07-08  Michael Saboff  <msaboff@apple.com>

        ASSERTION FAILED: Heap::isMarked(cell) in SlotVisitor::appendToMarkStack(JSC::JSCell *)
        https://bugs.webkit.org/show_bug.cgi?id=159588

        Reviewed by Geoffrey Garen.

        We were jettisoning a CodeBlock during GC that won't survive and its owning script
        won't survive either.  We can't install any code on the owning script as that involves
        a write barrier that will "pull" the script back into the remembered set.  Badness would
        ensue.  Added an early return in CodeBlock::jettison() when we are garbage collecting
        and the owning script isn't marked.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::jettison):

2016-07-08  Mark Lam  <mark.lam@apple.com>

        Move CallFrame header info from JSStack.h to CallFrame.h
        https://bugs.webkit.org/show_bug.cgi?id=159549

        Reviewed by Geoffrey Garen.

        CallFrame.h is a much better location for CallFrame header info.

        Replaced CallFrame::init() with ExecState::initGlobalExec() because normal
        CallFrames are setup by a different mechanism now.  Only the globalExec is still
        using it.  So, might as well change it to be specifically for the globalExec.

        Removed the use of JSStack::containsAddress() in ExecState::initGlobalExec()
        because it is not relevant to the globalExec.

        Also removed some unused code: JSStack::gatherConservativeRoots() and
        JSStack::sanitizeStack() is never called for JIT builds.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):
        * bytecode/VirtualRegister.h:
        (JSC::VirtualRegister::isValid):
        (JSC::VirtualRegister::isLocal):
        (JSC::VirtualRegister::isArgument):
        (JSC::VirtualRegister::isHeader):
        (JSC::VirtualRegister::isConstant):
        (JSC::VirtualRegister::toLocal):
        (JSC::VirtualRegister::toArgument):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitConstruct):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::CallArguments::thisRegister):
        (JSC::CallArguments::argumentRegister):
        (JSC::CallArguments::stackOffset):
        (JSC::CallArguments::argumentCountIncludingThis):
        (JSC::CallArguments::argumentsNode):
        (JSC::BytecodeGenerator::registerFor):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::emitHomeObjectForCallee):
        (JSC::emitGetSuperFunctionForConstruct):
        (JSC::CallArguments::CallArguments):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGArgumentsUtilities.cpp:
        (JSC::DFG::argumentsInvolveStackSlot):
        (JSC::DFG::emitCodeToGetArgumentsArrayLength):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::get):
        (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal):
        (JSC::DFG::ByteCodeParser::flush):
        (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
        (JSC::DFG::ByteCodeParser::getArgumentCount):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::handlePutById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::isLiveInBytecode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileEntry):
        (JSC::DFG::JITCompiler::compileSetupRegistersForEntry):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::emitStoreCallSiteIndex):
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExitCompiler.cpp:
        (JSC::DFG::OSRExitCompiler::emitRestoreArguments):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGOSRExitCompilerCommon.h:
        (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitGetLength):
        (JSC::DFG::SpeculativeJIT::emitGetCallee):
        (JSC::DFG::SpeculativeJIT::emitGetArgumentStart):
        (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
        * 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/DFGThunks.cpp:
        (JSC::DFG::osrEntryThunkGenerator):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetCallee):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetArgumentCountIncludingThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetScope):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue):
        (JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength):
        (JSC::FTL::DFG::LowerDFGToB3::getCurrentCallee):
        (JSC::FTL::DFG::LowerDFGToB3::getArgumentsStart):
        (JSC::FTL::DFG::LowerDFGToB3::callPreflight):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * ftl/FTLSlowPathCall.h:
        (JSC::FTL::callOperation):
        * interpreter/CallFrame.cpp:
        (JSC::ExecState::initGlobalExec):
        (JSC::CallFrame::callSiteBitsAreBytecodeOffset):
        (JSC::CallFrame::callSiteAsRawBits):
        (JSC::CallFrame::unsafeCallSiteAsRawBits):
        (JSC::CallFrame::callSiteIndex):
        (JSC::CallFrame::setCurrentVPC):
        (JSC::CallFrame::callSiteBitsAsBytecodeOffset):
        * interpreter/CallFrame.h:
        (JSC::CallSiteIndex::CallSiteIndex):
        (JSC::ExecState::calleeAsValue):
        (JSC::ExecState::callee):
        (JSC::ExecState::unsafeCallee):
        (JSC::ExecState::codeBlock):
        (JSC::ExecState::unsafeCodeBlock):
        (JSC::ExecState::scope):
        (JSC::ExecState::setCallerFrame):
        (JSC::ExecState::setScope):
        (JSC::ExecState::argumentCount):
        (JSC::ExecState::argumentCountIncludingThis):
        (JSC::ExecState::argumentOffset):
        (JSC::ExecState::argumentOffsetIncludingThis):
        (JSC::ExecState::offsetFor):
        (JSC::ExecState::noCaller):
        (JSC::ExecState::setArgumentCountIncludingThis):
        (JSC::ExecState::setCallee):
        (JSC::ExecState::setCodeBlock):
        (JSC::ExecState::setReturnPC):
        (JSC::ExecState::argIndexForRegister):
        (JSC::ExecState::callerFrameAndPC):
        (JSC::ExecState::unsafeCallerFrameAndPC):
        (JSC::ExecState::init): Deleted.
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::dumpRegisters):
        * interpreter/Interpreter.h:
        (JSC::calleeFrameForVarargs):
        * interpreter/JSStack.h:
        (JSC::JSStack::containsAddress):
        (JSC::JSStack::gatherConservativeRoots): Deleted.
        (JSC::JSStack::sanitizeStack): Deleted.
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::jitAssertArgumentCountSane):
        (JSC::AssemblyHelpers::emitRandomThunk):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::restoreReturnAddressBeforeReturn):
        (JSC::AssemblyHelpers::emitGetFromCallFrameHeaderPtr):
        (JSC::AssemblyHelpers::emitGetFromCallFrameHeader32):
        (JSC::AssemblyHelpers::emitGetFromCallFrameHeader64):
        (JSC::AssemblyHelpers::emitPutToCallFrameHeader):
        (JSC::AssemblyHelpers::emitPutToCallFrameHeaderBeforePrologue):
        (JSC::AssemblyHelpers::emitPutPayloadToCallFrameHeaderBeforePrologue):
        (JSC::AssemblyHelpers::emitPutTagToCallFrameHeaderBeforePrologue):
        (JSC::AssemblyHelpers::calleeFrameSlot):
        * jit/CCallHelpers.cpp:
        (JSC::CCallHelpers::logShadowChickenProloguePacket):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::prepareForTailCallSlow):
        * jit/CallFrameShuffler.cpp:
        (JSC::CallFrameShuffler::CallFrameShuffler):
        (JSC::CallFrameShuffler::dump):
        (JSC::CallFrameShuffler::extendFrameIfNeeded):
        (JSC::CallFrameShuffler::prepareForSlowPath):
        (JSC::CallFrameShuffler::prepareForTailCall):
        (JSC::CallFrameShuffler::prepareAny):
        * jit/CallFrameShuffler.h:
        (JSC::CallFrameShuffler::snapshot):
        (JSC::CallFrameShuffler::setCalleeJSValueRegs):
        (JSC::CallFrameShuffler::assumeCalleeIsCell):
        (JSC::CallFrameShuffler::numLocals):
        (JSC::CallFrameShuffler::getOld):
        (JSC::CallFrameShuffler::setOld):
        (JSC::CallFrameShuffler::firstOld):
        (JSC::CallFrameShuffler::lastOld):
        (JSC::CallFrameShuffler::isValidOld):
        (JSC::CallFrameShuffler::argCount):
        (JSC::CallFrameShuffler::getNew):
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCall):
        * jit/JITInlines.h:
        (JSC::JIT::getConstantOperand):
        (JSC::JIT::emitPutIntToCallFrameHeader):
        (JSC::JIT::updateTopCallFrame):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_get_scope):
        (JSC::JIT::emit_op_argument_count):
        (JSC::JIT::emit_op_get_rest_length):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileCTINativeCall):
        (JSC::JIT::emit_op_get_scope):
        * jit/JSInterfaceJIT.h:
        (JSC::JSInterfaceJIT::emitJumpIfNotType):
        (JSC::JSInterfaceJIT::emitGetFromCallFrameHeaderPtr):
        (JSC::JSInterfaceJIT::emitPutToCallFrameHeader):
        (JSC::JSInterfaceJIT::emitPutCellToCallFrameHeader):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetVarargsFrame):
        (JSC::emitSetupVarargsFrameFastCase):
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::SpecializedThunkJIT):
        * jit/ThunkGenerators.cpp:
        (JSC::nativeForGenerator):
        (JSC::arityFixupGenerator):
        (JSC::boundThisNoArgsFunctionCallGenerator):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::genericCall):
        (JSC::LLInt::varargsSetup):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        * runtime/StackAlignment.h:
        (JSC::roundArgumentCountToAlignFrame):
        (JSC::roundLocalRegisterCountForFramePointerOffset):
        (JSC::logStackAlignmentRegisters):
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::startFunction):
        (JSC::WASMFunctionCompiler::endFunction):
        (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
        (JSC::WASMFunctionCompiler::callAndUnboxResult):
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::updateTempStackHeightForCall):

2016-07-08  Chris Dumez  <cdumez@apple.com>

        Object.defineProperty() should maintain existing getter / setter if not overridden in the new descriptor
        https://bugs.webkit.org/show_bug.cgi?id=159576
        <rdar://problem/27242197>

        Reviewed by Mark Lam.

        Object.defineProperty() should maintain existing getter / setter if not
        overridden in the new descriptor. Previously, if the property is a had
        a custom getter / setter, and if the new descriptor only had a setter
        (or only a getter), JSC would clear the existing getter (or setter).
        This behavior did not match the EcmaScript specification or Firefox /
        Chrome. This patch fixes the issue.

        This fixes searching and search suggestions on www.iciba.com.

        * runtime/JSObject.cpp:
        (JSC::validateAndApplyPropertyDescriptor):

2016-07-08  Michael Saboff  <msaboff@apple.com>

        Dumping the object graph doesn't work with verbose GC logging
        https://bugs.webkit.org/show_bug.cgi?id=159569

        Reviewed by Mark Lam.

        The current object graph logging code tries to revisits the graph.  This doesn't work
        correctly and asking around it isn't used.  The only way to dump the true object graph
        is to log while we GC and that has obvious performance implications.
        Therefore I eliminated GCLogging::dumpObjectGraph() and related code.  

        * heap/GCLogging.cpp:
        (JSC::GCLogging::levelAsString):
        (JSC::LoggingFunctor::LoggingFunctor): Deleted.
        (JSC::LoggingFunctor::~LoggingFunctor): Deleted.
        (JSC::LoggingFunctor::operator()): Deleted.
        (JSC::LoggingFunctor::log): Deleted.
        (JSC::LoggingFunctor::reviveCells): Deleted.
        (JSC::LoggingFunctor::returnValue): Deleted.
        (JSC::GCLogging::dumpObjectGraph): Deleted.
        * heap/Heap.cpp:
        (JSC::Heap::didFinishCollection):

2016-07-08  Keith Miller  <keith_miller@apple.com>

        speculateTypedArrayIsNotNeutered has an inverted speculation
        https://bugs.webkit.org/show_bug.cgi?id=159571

        Reviewed by Mark Lam.

        For some confusing reason FTLLowerDFGToB3 takes the condition the
        speculation wants to be false. This issue caused
        typedarray-access-monomorphic-neutered.js to fail on the bots.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):

2016-07-08  Mark Lam  <mark.lam@apple.com>

        Rename jsCPUStackLimit to osStackLimitWithReserve and jsEmulatedStackLimit to cloopStackLimit.
        https://bugs.webkit.org/show_bug.cgi?id=159544

        Reviewed by Geoffrey Garen.

        This patch does the following refactoring:
        1. Rename jsCPUStackLimit to osStackLimitWithReserve.
        2. Rename jsEmulatedStackLimit to cloopStackLimit.
        2. Remove llintStackLimit (which previously is either an alias for
           jsCPUStackLimit or jsEmulatedStackLimit depending on whether we have a JIT or
           C Loop build).  Instead, we'll change the LLINT to conditionally use the
           osStackLimitWithReserve or cloopStackLimit.

        There are no semantic changes.

        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        * interpreter/JSStack.cpp:
        (JSC::JSStack::JSStack):
        (JSC::JSStack::growSlowCase):
        (JSC::JSStack::lowAddress):
        (JSC::JSStack::highAddress):
        * interpreter/JSStack.h:
        * interpreter/JSStackInlines.h:
        (JSC::JSStack::ensureCapacityFor):
        (JSC::JSStack::shrink):
        (JSC::JSStack::grow):
        (JSC::JSStack::setCLoopStackLimit):
        (JSC::JSStack::setJSEmulatedStackLimit): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/RegExp.cpp:
        (JSC::RegExp::finishCreation):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/VM.cpp:
        (JSC::VM::updateStackLimit):
        * runtime/VM.h:
        (JSC::VM::reservedZoneSize):
        (JSC::VM::osStackLimitWithReserve):
        (JSC::VM::addressOfOSStackLimitWithReserve):
        (JSC::VM::cloopStackLimit):
        (JSC::VM::setCLoopStackLimit):
        (JSC::VM::isSafeToRecurse):
        (JSC::VM::jsCPUStackLimit): Deleted.
        (JSC::VM::addressOfJSCPUStackLimit): Deleted.
        (JSC::VM::jsEmulatedStackLimit): Deleted.
        (JSC::VM::setJSEmulatedStackLimit): Deleted.
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::startFunction):

2016-07-08  Commit Queue  <commit-queue@webkit.org>

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

        Caused build failure (Requested by perarne on #webkit).

        Reverted changeset:

        "[Win] DLLs are missing version information."
        https://bugs.webkit.org/show_bug.cgi?id=159349
        http://trac.webkit.org/changeset/202799

2016-07-08  Youenn Fablet  <youenn@apple.com>

        Built-in generator should generate files with a default copyright
        https://bugs.webkit.org/show_bug.cgi?id=159561

        Reviewed by Alex Christensen.

        * Scripts/builtins/builtins_model.py:
        (BuiltinsCollection._parse_copyright_lines): Adding default copyright to the parsed copyrights.
        * Scripts/builtins/builtins_templates.py:
        (BuiltinsGeneratorTemplates): Adding a default copyright.
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result: Rebasing with added default copyright.
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result: Ditto.
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result: Ditto.
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: Ditto.


2016-07-08  Keith Miller  <keith_miller@apple.com>

        TypedArrays need more isNeutered checks.
        https://bugs.webkit.org/show_bug.cgi?id=159231

        Reviewed by Filip Pizlo.

        According to the ES6 spec if a user tries to get, set, or define a
        property on a neutered TypedArray we should throw an
        exception. Currently, if a user tries to get an out of bounds
        access on a TypedArray we will always OSR.  This makes handling
        the exception easy as all we need to do is make out of bounds gets
        in PolymorphicAccess go to the slow path, which will then throw
        the appropriate exception. For the case of set, we need ensure we
        don't OSR on each out of bounds put since, for some confusing
        reason, people do this.  Thus, for GetByVal in the DFG/FTL if the
        user accesses out of bounds we then need to check if the view has
        been neutered. If it is neutered then we will OSR.

        Additionally, this patch adds a bunch of isNeutered checks to
        various prototype functions for TypedArray, which are needed for
        correctness.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
        (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
        * dfg/DFGSpeculativeJIT.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
        (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * runtime/JSArrayBufferView.h:
        * runtime/JSCJSValue.h:
        (JSC::encodedJSUndefined):
        (JSC::encodedJSValue):
        * runtime/JSGenericTypedArrayView.h:
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::throwNeuteredTypedArrayTypeError):
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
        (JSC::JSGenericTypedArrayView<Adaptor>::put):
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
        (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
        (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
        (JSC::JSGenericTypedArrayView<Adaptor>::deletePropertyByIndex):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncCopyWithin):
        (JSC::genericTypedArrayViewProtoFuncFill):
        (JSC::genericTypedArrayViewProtoFuncIndexOf):
        (JSC::genericTypedArrayViewProtoFuncJoin):
        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
        (JSC::genericTypedArrayViewProtoFuncSlice):
        (JSC::genericTypedArrayViewProtoFuncSubarray):
        * tests/stress/fold-typed-array-properties.js:
        * tests/stress/typedarray-access-monomorphic-neutered.js: Added.
        (check):
        (test):
        (testFTL):
        * tests/stress/typedarray-access-neutered.js: Added.
        (check):
        (test):
        * tests/stress/typedarray-functions-with-neutered.js:
        (defaultForArg):
        (callWithArgs):
        (checkArgumentsForType):
        (checkArguments):
        * tests/stress/typedarray-view-string-properties-neutered.js: Added.
        (call):
        (test):

2016-07-08  Youenn Fablet  <youenn@apple.com>

        Generate WebCore builtin wrapper files
        https://bugs.webkit.org/show_bug.cgi?id=159461

        Reviewed by Brian Burg.

        Updating builtin generator to generate wrapper files used in WebCore (See WebCore change log).
        Rebasing builtins generator test results according generator changes by activating wrapper file generation for
        WebCore builtins tests.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/builtins/builtins.py: Adding new generators.
        * Scripts/builtins/builtins_generate_internals_wrapper_header.py: Added to generate WebCoreJSBuiltinInternals.h.
        * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py: Added to generate WebCoreJSBuiltinInternals.cpp.
        * Scripts/builtins/builtins_generate_wrapper_header.py: Added to generate WebCoreJSBuiltins.h.
        * Scripts/builtins/builtins_generate_wrapper_implementation.py: Added to generate WebCoreJSBuiltins.cpp.
        * Scripts/generate-js-builtins.py: Adding new option to activate generation of the wrapper files.
        (generate_bindings_for_builtins_files):
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:

2016-07-07  Joseph Pecoraro  <pecoraro@apple.com>

        padStart/padEnd with Infinity produces unexpected result
        https://bugs.webkit.org/show_bug.cgi?id=159543

        Reviewed by Benjamin Poulain.

        * builtins/GlobalOperations.js:
        (globalPrivate.toLength):
        Fix style.

        * builtins/StringPrototype.js:
        (padStart):
        (padEnd):
        After all observable operations, and after empty string has been handled,
        throw an out of memory error if the resulting string would be greater
        than the maximum string size.

        * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors-proxy.js:
        (shouldThrow): Deleted.
        * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js:
        (shouldThrow):
        (testMeta):
        * tests/es6/String.prototype_methods_String.prototype.padEnd.js:
        (shouldThrow):
        (TestToLength):
        (TestMemoryLimits):
        (TestMeta): Deleted.
        * tests/es6/String.prototype_methods_String.prototype.padStart.js:
        (shouldThrow):
        (TestToLength):
        (TestMemoryLimits):
        Replace incorrect shouldThrow(..., errorType) with explicit shouldThrow(..., errorMessage).
        The old shouldThrow would incorrectly succeed if the expected error type was just "Error".
        Now we explicitly check the error message.

2016-07-07  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] String.prototype[Symbol.iterator] needs a name
        https://bugs.webkit.org/show_bug.cgi?id=159541

        Reviewed by Yusuke Suzuki.

        A man needs a name.
        Spec: https://tc39.github.io/ecma262/#sec-string.prototype-@@iterator

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

2016-07-07  Michael Saboff  <msaboff@apple.com>

        REGRESSION(184445): Need to insert a StoreBarrier when we don't know child's epoch
        https://bugs.webkit.org/show_bug.cgi?id=159537

        Reviewed by Benjamin Poulain.

        We weren't checking the case of a child node with a null epoch.  The problem surfaces
        when the base node of a PutByVal variant has a non-null epoch, because it represents an
        allocation in the current function, while the child of the same node has an unknown epoch.
        Added a check that the child node is not null before comparing the epochs of the base and
        child nodes.

        The added test creates the problem circumstance by doing a full GC to place an array in
        remembered space, allocating a new object followed by an eden GC.  The new object is
        only referenced by the array and therefore won't be visited Without the store barrier.
        The test may crash or more likely get the wrong answer with the bug.

        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * tests/stress/regress-159537.js: Added test.
        (MyNumber):
        (MyNumber.prototype.plusOne):
        (bar):
        (foo):
        (test):

2016-07-07  Joseph Pecoraro  <pecoraro@apple.com>

        Unexpected "Out of memory" error for "x".repeat(-1)
        https://bugs.webkit.org/show_bug.cgi?id=159529

        Reviewed by Benjamin Poulain.

        * builtins/StringPrototype.js:
        (globalPrivate.repeatSlowPath):
        (repeat):
        Move the @toInteger and range checking to the always path,
        since the spec does say it should always happen. Also remove
        the duplication of the fast path here.

        * runtime/StringPrototype.cpp:
        (JSC::repeatCharacter):
        Remove unused function.

        (JSC::stringProtoFuncRepeatCharacter):
        ASSERT if given a negative number. This is a private function
        only used internally.

        * tests/stress/string-repeat-edge-cases.js:
        (shouldThrow):
        Update expected error message.

2016-07-07  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Array.prototype[Symbol.unscopables] should have the "includes" property
        https://bugs.webkit.org/show_bug.cgi?id=159504

        Reviewed by Keith Miller.

        The property "includes" was missing.
        Spec: https://tc39.github.io/ecma262/#sec-array.prototype-@@unscopables

        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        * tests/stress/unscopables.js:

2016-07-07  Saam Barati  <sbarati@apple.com>

        ToThis constant folding in DFG is incorrect when the structure indicates that toThis is overridden
        https://bugs.webkit.org/show_bug.cgi?id=159501
        <rdar://problem/27109354>

        Reviewed by Mark Lam.

        We *cannot* constant fold ToThis when the structure of an object
        indicates that toThis() is overridden. isToThisAnIdentity() inside
        AbstractInterpreterInlines accidentally wrote the opposite rule.
        The rule was written as we can constant fold ToThis only when
        toThis() is overridden. To fix the bug, we must write the rule
        as isToThisAnIdentity() can only be true as long as the structure
        set indicates that no structures override toThis().

        We could probably get more clever in the future and notice
        when we're dealing with a constant |this| values. For example,
        a ToThis might occur on a constant JSLexicalEnvironment. We could
        implement the rules of JSLexicalEnvironment's toThis() implementation
        inside AI/constant folding.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::isToThisAnIdentity):
        * tests/stress/to-this-on-constant-lexical-environment.js: Added.
        (foo.bar):
        (foo.inner):
        (foo):

2016-07-07  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Array.prototype.includes uses ToInt32 instead of ToInteger on the index argument
        https://bugs.webkit.org/show_bug.cgi?id=159505

        Reviewed by Mark Lam.

        The code was using (value)|0 which is effectively a ToInt32.
        This fails on large integers and +-Infinity.

        Spec: https://tc39.github.io/ecma262/#sec-array.prototype.includes

        * builtins/ArrayPrototype.js:
        (includes):

2016-07-07  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] String.prototype.normalize should have a length of zero
        https://bugs.webkit.org/show_bug.cgi?id=159506

        Reviewed by Yusuke Suzuki.

        Spec: https://tc39.github.io/ecma262/#sec-string.prototype.normalize
        The argument is optional, the length should be zero.

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

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

        [ARMv7] REGRESSION(r197655): ASSERTION FAILED: (cond == Zero) || (cond == NonZero)
        https://bugs.webkit.org/show_bug.cgi?id=159419

        Reviewed by Benjamin Poulain.

        Allow Signed and PositiveOrZero conditions too because tst instruction updates N and Z flags.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::branchTest32):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::branchTest32): Add assertions to avoid possible bugs in the future.

2016-07-06  Youenn Fablet  <youenn@apple.com>

        Builtin generator should use pragma once for header files
        https://bugs.webkit.org/show_bug.cgi?id=159462

        Reviewed by Alex Christensen.

        * Scripts/builtins/builtins_generate_combined_header.py:
        (BuiltinsCombinedHeaderGenerator.generate_output): 
        * Scripts/builtins/builtins_generate_separate_header.py:
        (BuiltinsSeparateHeaderGenerator.generate_output):
        * Scripts/builtins/builtins_templates.py:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:

2016-07-06  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Unify how we throw TypeError from C++
        https://bugs.webkit.org/show_bug.cgi?id=159500

        Reviewed by Saam Barati.

        Throwing a TypeError is an uncommon case. We should minimize the impact
        on the call sites.

        This patch does that by:
        -Replace the 2 calls createTypeError()->throwException() by throwTypeError().
        -Use ASCIILiteral when possible.
        -Add an overload of throwTypeError() taking ASCIILiteral directly
         (that way, the String creation and destruction is done by the callee).

        On x86_64, this reduces the __TEXT__ segment by 29kb.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * jit/JITOperations.cpp:
        * runtime/DatePrototype.cpp:
        (JSC::dateProtoFuncToJSON):
        * runtime/Error.cpp:
        (JSC::throwConstructorCannotBeCalledAsFunctionTypeError):
        (JSC::throwTypeError):
        * runtime/Error.h:
        (JSC::throwVMTypeError):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::arrayBufferProtoFuncSlice):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        (JSC::JSValue::toStringSlowCase):
        * runtime/JSCJSValueInlines.h:
        (JSC::toPreferredPrimitiveType):
        * runtime/JSDataViewPrototype.cpp:
        (JSC::getData):
        (JSC::setData):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewFromIterator):
        (JSC::constructGenericTypedArrayViewWithArguments):
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::speciesConstruct):
        (JSC::genericTypedArrayViewProtoFuncSet):
        (JSC::genericTypedArrayViewProtoFuncCopyWithin):
        (JSC::genericTypedArrayViewProtoFuncIndexOf):
        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
        (JSC::genericTypedArrayViewProtoFuncSubarray):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoGetter):
        (JSC::globalFuncProtoSetter):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::appendStringifiedValue):
        * runtime/JSObject.cpp:
        (JSC::JSObject::setPrototypeWithCycleCheck):
        (JSC::callToPrimitiveFunction):
        (JSC::JSObject::ordinaryToPrimitive):
        (JSC::JSObject::defaultHasInstance):
        (JSC::validateAndApplyPropertyDescriptor):
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::constructTypedArrayView):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewPrivateFuncLength):
        (JSC::typedArrayViewProtoFuncSet):
        (JSC::typedArrayViewProtoFuncCopyWithin):
        (JSC::typedArrayViewProtoFuncFill):
        (JSC::typedArrayViewProtoFuncLastIndexOf):
        (JSC::typedArrayViewProtoFuncIndexOf):
        (JSC::typedArrayViewProtoFuncJoin):
        (JSC::typedArrayViewProtoGetterFuncBuffer):
        (JSC::typedArrayViewProtoGetterFuncLength):
        (JSC::typedArrayViewProtoGetterFuncByteLength):
        (JSC::typedArrayViewProtoGetterFuncByteOffset):
        (JSC::typedArrayViewProtoFuncReverse):
        (JSC::typedArrayViewProtoFuncSubarray):
        (JSC::typedArrayViewProtoFuncSlice):
        * runtime/ObjectConstructor.cpp:
        (JSC::toPropertyDescriptor):
        (JSC::objectConstructorDefineProperty):
        (JSC::objectConstructorDefineProperties):
        (JSC::objectConstructorCreate):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncDefineGetter):
        (JSC::objectProtoFuncDefineSetter):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncCompile):
        * runtime/Symbol.cpp:
        (JSC::Symbol::toNumber):

2016-07-06  Saam Barati  <sbarati@apple.com>

        InlineAccess::sizeForLengthAccess() is wrong on some platforms because it should also consider "length" not being array length
        https://bugs.webkit.org/show_bug.cgi?id=159429

        Reviewed by Filip Pizlo.

        The calculation inside sizeForLengthAccess() was not taking into
        account that an access to a "length" property might not be an
        array length access. sizeForLengthAccess() should always have enough
        room for a regular self property accesses. This only changes how
        much of a nop sled we emit if array length access size is smaller
        than self access size. This matters on ARM64.

        * bytecode/InlineAccess.h:
        (JSC::InlineAccess::sizeForPropertyAccess):
        (JSC::InlineAccess::sizeForPropertyReplace):
        (JSC::InlineAccess::sizeForLengthAccess):

2016-07-06  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r198928 and r198985.
        https://bugs.webkit.org/show_bug.cgi?id=159478

        "It's breaking some websites" (Requested by saamyjoon on
        #webkit).

        Reverted changesets:

        "[ES6] Disallow var assignments in for-in loops"
        https://bugs.webkit.org/show_bug.cgi?id=155451
        http://trac.webkit.org/changeset/198928

        "Unreviewed, turn ES6 for-in loop test success"
        https://bugs.webkit.org/show_bug.cgi?id=155451
        http://trac.webkit.org/changeset/198985

2016-07-05  Mark Lam  <mark.lam@apple.com>

        Rename VM stack limit fields to better describe their purpose.
        https://bugs.webkit.org/show_bug.cgi?id=159451

        Reviewed by Keith Miller.

        This is in preparation for an upcoming patch that changes what stack limit values
        are used under various circumstances.  This patch aims to do some minimal work to
        rename the fields so that it will be easier to reason about the upcoming patch.
    
        In this patch, we make the following changes:

        1. Rename VM::m_stackLimit to VM::m_jsCPUStackLimit.

        2. VM::m_jsStackLimit used to have an overloaded meaning:
           a. For JIT builds, m_jsStackLimit is synonymous with m_stackLimit.
           b. For C Loop builds, m_jsStackLimit is a separate pointer that points to the
              emulated JS stack that the C Loop uses.

           In place of m_jsStackLimit, this patch introduces 2 new fields:
           VM::m_jsEmulatedStackLimit and VM::m_llintStackLimit.

           m_llintStackLimit is the limit that the LLInt assembly uses for its stack
           check.  m_llintStackLimit behaves like the old m_jsStackLimit in that:
           a. For JIT builds, m_llintStackLimit is synonymous with m_jsCPUStackLimit.
           b. For C Loop builds, m_llintStackLimit is synonymous with m_jsEmulatedStackLimit.

           m_jsEmulatedStackLimit is used for the emulated stack that the C Loop uses.

        3. Rename the following methods to match the above:
             VM::stackLimit() ==> VM::jsCPUStackLimit()
             VM::addressOfStackLimit() ==> VM::addressOfJSCPUStackLimit()
             VM::jsStackLimit() ==> VM::jsEmulatedStackLimit()
             VM::setJSStackLimit() ==> VM::setJSEmulatedStackLimit()
             JSStack::setStackLimit() ==> JSStack::setEmulatedStackLimit()

        4. With change (2) and (3), the limits will be used as follows:
           a. VM code doing stack recursion checks will only use m_jsCPUStackLimit.
           b. JIT code will only use m_jsCPUStackLimit.
           c. C Loop emulated stack code in JSStack will only use m_jsEmulatedStackLimit.
              Note: the part of JSStack that operates on a JIT build will use
                    m_jsCPUStackLimit as expected.
           d. LLINT assembly code will only use m_llintStackLimit.

        This patch only contains the above refactoring changes.  There is no behavior
        change.

        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        * interpreter/JSStack.cpp:
        (JSC::JSStack::JSStack):
        (JSC::JSStack::growSlowCase):
        (JSC::JSStack::lowAddress):
        (JSC::JSStack::highAddress):
        * interpreter/JSStack.h:
        * interpreter/JSStackInlines.h:
        (JSC::JSStack::ensureCapacityFor):
        (JSC::JSStack::shrink):
        (JSC::JSStack::grow):
        (JSC::JSStack::setJSEmulatedStackLimit):
        (JSC::JSStack::setStackLimit): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/RegExp.cpp:
        (JSC::RegExp::finishCreation):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::updateStackLimit):
        * runtime/VM.h:
        (JSC::VM::reservedZoneSize):
        (JSC::VM::jsCPUStackLimit):
        (JSC::VM::addressOfJSCPUStackLimit):
        (JSC::VM::jsEmulatedStackLimit):
        (JSC::VM::setJSEmulatedStackLimit):
        (JSC::VM::isSafeToRecurse):
        (JSC::VM::jsStackLimit): Deleted.
        (JSC::VM::setJSStackLimit): Deleted.
        (JSC::VM::stackLimit): Deleted.
        (JSC::VM::addressOfStackLimit): Deleted.
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::startFunction):

2016-07-05  Saam Barati  <sbarati@apple.com>

        StackVisitor::unwindToMachineCodeBlockFrame() may unwind past a VM entry frame when catching an exception and the frame has inlined tail calls
        https://bugs.webkit.org/show_bug.cgi?id=159448
        <rdar://problem/27084459>

        Reviewed by Mark Lam.

        Consider the following stack trace:
        (machine) foo -> VM entry frame -> (machine) bar -> (inlined tailcall) baz

        If an exception is thrown at 'baz', we will do exception unwinding,
        which will eventually call unwindToMachineCodeBlockFrame() which will call
        gotoNextFrame() on the 'baz' frame. The next logical frame for 'baz' is 'foo' because
        'bar' tail called 'baz' even though there is a machine frame for 'bar' on the stack.
        This is a bug. unwindToMachineCodeBlockFrame() should not care about the next
        logical frame, it just wants to move StackVisitor's state to the current machine
        frame. The bug here is that we would end up unwinding past the VM entry frame
        which can have all kinds of terrible consequences.

        This bug fixes unwindToMachineCodeBlockFrame() by having it not rely
        on gotoNextFrame() and instead using its own mechanism for setting
        the StackVisotor's state to the current machine frame.

        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
        * tests/stress/dont-unwind-past-vm-entry-frame.js: Added.
        (let.p.new.Proxy):
        (let.p.new.Proxy.apply):
        (bar):
        (let.good):
        (getItem):
        (start):

2016-07-05  Joseph Pecoraro  <pecoraro@apple.com>

        RELEASE_ASSERT(!thisObject) in ObjCCallbackFunctionImpl::call when calling JSExport ObjC Constructor without operator new
        https://bugs.webkit.org/show_bug.cgi?id=159446

        Reviewed by Mark Lam.

        Treat ObjC JSExport init constructors like ES6 Class Constructors
        and throw a TypeError when called without 'new'.

        * API/ObjCCallbackFunction.mm:
        (JSC::ObjCCallbackFunctionImpl::type):
        (JSC::objCCallbackFunctionCallAsFunction):
        When calling an init method as a function instead of construction
        throw a TypeError.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        Improve error message.

        * API/tests/testapi.mm:
        (testObjectiveCAPIMain):
        Test we get an exception when calling an ObjC constructor without 'new'.

2016-07-05  Mark Lam  <mark.lam@apple.com>

        Remove some unneeded #include "CachedCall.h".
        https://bugs.webkit.org/show_bug.cgi?id=159449

        Reviewed by Saam Barati.

        * runtime/ArrayPrototype.cpp:
        * runtime/JSArray.cpp:
        * runtime/MapPrototype.cpp:
        * runtime/SetPrototype.cpp:

2016-07-05  Geoffrey Garen  <ggaren@apple.com>

        Crash @ bankofamerica.com, University of Vienna
        https://bugs.webkit.org/show_bug.cgi?id=159439

        Reviewed by Saam Barati.

        * ftl/FTLLink.cpp:
        (JSC::FTL::link): Do check for stack overflow in the arity mismatch thunk
        because it can happen. Don't store a CallSiteIndex because we haven't
        stored a CodeBlock yet, and our stack frame is not fully constructed,
        so it would be an error for any client to try to load this value (and
        operationCallArityCheck does not load this value).

        * tests/stress/arity-check-ftl-throw.js: Added. New test case for stressing
        a stack overflow with arity mismatch. Sadly, after hours of fiddling, I
        can't seem to get this to fail in trunk. Still, it's good to have some
        more testing in this area.

2016-07-05  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] The prototype cycle checks throws the wrong error type
        https://bugs.webkit.org/show_bug.cgi?id=159393

        Reviewed by Geoffrey Garen.

        We were supposed to throw the TypeError:
        -https://tc39.github.io/ecma262/#sec-set-object.prototype.__proto__

        * runtime/JSObject.cpp:
        (JSC::JSObject::setPrototypeWithCycleCheck):

2016-07-05  Saam Barati  <sbarati@apple.com>

        our parsing for "use strict" is wrong when we first parse other directives that are not "use strict" but are located in a place where "use strict" would be valid
        https://bugs.webkit.org/show_bug.cgi?id=159376
        <rdar://problem/27108773>

        Reviewed by Benjamin Poulain.

        Our strict mode detection algorithm used to break if we ever saw a directive
        that is not "use strict" but is syntactically located in a location where our
        parser looks for "use strict". It broke as follows:

        If a function started with a non "use strict" string literal, we will allow
        "use strict" to be in any arbitrary statement inside the top level block in
        the function body. For example, this meant that if we parsed a sequence of string
        literals, followed by arbitrary statements, followed by "use strict", we would parse
        the function as if it's in strict mode. This is the wrong behavior with respect to
        the spec. This has consequences in other ways that break invariants of the language.
        For example, we used to allow functions that are lexically nested inside what we deemed
        a strict function to be non-strict. This used to fire an assertion if we ever skipped over
        that function using the source provider cache, but it worked just fine in release builds.

        This patch fixes this bug.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseSourceElements):
        (JSC::Parser<LexerType>::parseStatement):
        * tests/stress/ensure-proper-strict-mode-parsing.js: Added.
        (foo.bar):
        (foo):
        (bar.foo):
        (bar):
        (bar.call.undefined.this.throw.new.Error.string_appeared_here.baz):
        (baz.call.undefined.undefined.throw.new.Error.string_appeared_here.jaz):
        (jaz.call.undefined.this.throw.new.Error.string_appeared_here.vaz):

2016-07-05  Saam Barati  <sbarati@apple.com>

        reportAbandonedObjectGraph should report abandoned bytes based on capacity() so it works even if a GC has never happened
        https://bugs.webkit.org/show_bug.cgi?id=159222
        <rdar://problem/27001991>

        Reviewed by Geoffrey Garen.

        When reportAbandonedObjectGraph() was called before the first GC, it used to
        not indicate to the GC timers that we have memory that needs to be collected
        because the calculation was based on m_sizeAfterLastCollect (which was zero).
        This patch makes the calculation based on capacity() which is a valid number
        even before the first GC.

        * heap/Heap.cpp:
        (JSC::Heap::reportAbandonedObjectGraph):
        (JSC::Heap::protect):
        (JSC::Heap::didAbandon): Deleted.
        * heap/Heap.h:
        (JSC::Heap::jitStubRoutines):

2016-07-05  Csaba Osztrogonác  <ossy@webkit.org>

        Typo fix after r202214
        https://bugs.webkit.org/show_bug.cgi?id=159416

        Reviewed by Saam Barati.

        * bytecode/InlineAccess.h:

2016-07-03  Per Arne Vollan  <pvollan@apple.com>

        [Win] DLLs are missing version information.
        https://bugs.webkit.org/show_bug.cgi?id=159349

        Reviewed by Brent Fulgham.

        Run perl version stamp utility.
        
        * CMakeLists.txt:

2016-07-01  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] MacroAssemblerX86::branch8 should accept unsigned 8bit value
        https://bugs.webkit.org/show_bug.cgi?id=159334

        Reviewed by Benjamin Poulain.

        As described in branchTest8 functions, byte in TrustedImm32 is not well defined.
        So the assertion here should be a little permissive; accepting -128 to 255.

        This assertion is originally fired when executing misc-bugs-847389-jpeg2000 benchmark in Debug build.
        So this patch includes misc-bugs-847389-jpeg2000 benchmark.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::branchTest8):
        (JSC::MacroAssemblerX86Common::branch8):
        * b3/testb3.cpp:
        (JSC::B3::testBranch8WithLoad8ZIndex):
        (JSC::B3::run):

2016-07-03  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] __lookupGetter__ and __lookupSetter__ should not ignore exceptions
        https://bugs.webkit.org/show_bug.cgi?id=159390

        Reviewed by Mark Lam.

        See:
        -https://tc39.github.io/ecma262/#sec-object.prototype.__lookupGetter__
        -https://tc39.github.io/ecma262/#sec-object.prototype.__lookupSetter__

        They are both supposed to be regular [[GetOwnProperty]].

        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncLookupGetter):
        (JSC::objectProtoFuncLookupSetter):

2016-07-03  Saam Barati  <sbarati@apple.com>

        BytecodeGenerator::getVariablesUnderTDZ is too conservative
        https://bugs.webkit.org/show_bug.cgi?id=159387

        Reviewed by Filip Pizlo.

        We were too conservative in the following type of programs:
        ```
        {
            {
                let x;
                ...
            }
            let x;
        }
        ```
        We used to report "x" as under TDZ when calling getVariablesUnderTDZ at the
        "...", even though "x" is not under TDZ. This patch removes this conservatism
        and makes the algorithm precise.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::getVariablesUnderTDZ):
        * bytecompiler/BytecodeGenerator.h:

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

        FTL should refer to B3 types directly
        https://bugs.webkit.org/show_bug.cgi?id=159389

        Reviewed by Saam Barati.
        
        When we used LLVM, types were objects that were allocated by the LLVMContext. We had to
        remember pointers to them or else call through the C API every time we wanted the type. We
        stored the type pointers inside FTL::CommonValues.
        
        But in B3, types are just members of an enum. We don't have to remember pointers to them.
        
        This change replaces all prior uses of things like "m_out.int32" with just "Int32", and
        likewise for m_out.boolean, m_out.int64, m_out.intPtr, m_out.floatType, m_out.doubleType,
        and m_out.voidType.
        
        We still use FTL::CommonValues for common constants that we have pre-hoisted. Hopefully we
        will come up with a better story for those eventually, since that's still kinda ugly.

        * ftl/FTLCommonValues.cpp:
        (JSC::FTL::CommonValues::CommonValues):
        * ftl/FTLCommonValues.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::createPhiVariables):
        (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep):
        (JSC::FTL::DFG::LowerDFGToB3::compileBooleanToNumber):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::compileToThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToB3::compileStrCat):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithMinOrMax):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithPow):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByValWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByIdWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByValWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutAccessorById):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutGetterSetterById):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutAccessorByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayPop):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateScopedArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateClonedArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileCopyRest):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetRestLength):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileToNumber):
        (JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::compileToPrimitive):
        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileSwitch):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsString):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsObjectOrNull):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsRegExpObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsTypedArrayView):
        (JSC::FTL::DFG::LowerDFGToB3::compileTypeOf):
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):
        (JSC::FTL::DFG::LowerDFGToB3::compileOverridesHasInstance):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckTypeInfoFlags):
        (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
        (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOfCustom):
        (JSC::FTL::DFG::LowerDFGToB3::compileCountExecution):
        (JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):
        (JSC::FTL::DFG::LowerDFGToB3::compileHasGenericProperty):
        (JSC::FTL::DFG::LowerDFGToB3::compileHasStructureProperty):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumerableLength):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetPropertyEnumerator):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorStructurePname):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorGenericPname):
        (JSC::FTL::DFG::LowerDFGToB3::compileToIndexString):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckStructureImmediate):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::compileSetFunctionName):
        (JSC::FTL::DFG::LowerDFGToB3::numberOrNotCellToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::checkInferredType):
        (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
        (JSC::FTL::DFG::LowerDFGToB3::getById):
        (JSC::FTL::DFG::LowerDFGToB3::compare):
        (JSC::FTL::DFG::LowerDFGToB3::compileResolveScope):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetDynamicVar):
        (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject):
        (JSC::FTL::DFG::LowerDFGToB3::speculateTruthyObject):
        (JSC::FTL::DFG::LowerDFGToB3::nonSpeculativeCompare):
        (JSC::FTL::DFG::LowerDFGToB3::stringsEqual):
        (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::ensureShadowChickenPacket):
        (JSC::FTL::DFG::LowerDFGToB3::boolify):
        (JSC::FTL::DFG::LowerDFGToB3::equalNullOrUndefined):
        (JSC::FTL::DFG::LowerDFGToB3::contiguousPutByValOutOfBounds):
        (JSC::FTL::DFG::LowerDFGToB3::buildSwitch):
        (JSC::FTL::DFG::LowerDFGToB3::switchStringSlow):
        (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::strictInt52ToJSValue):
        (JSC::FTL::DFG::LowerDFGToB3::strictInt52ToInt52):
        (JSC::FTL::DFG::LowerDFGToB3::unboxInt32):
        (JSC::FTL::DFG::LowerDFGToB3::boxInt32):
        (JSC::FTL::DFG::LowerDFGToB3::isCellOrMisc):
        (JSC::FTL::DFG::LowerDFGToB3::unboxDouble):
        (JSC::FTL::DFG::LowerDFGToB3::boxDouble):
        (JSC::FTL::DFG::LowerDFGToB3::jsValueToStrictInt52):
        (JSC::FTL::DFG::LowerDFGToB3::doubleToStrictInt52):
        (JSC::FTL::DFG::LowerDFGToB3::convertDoubleToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::callCheck):
        (JSC::FTL::DFG::LowerDFGToB3::crash):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::bitCast):

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

        DFG LICM needs to go all-in on the idea that some loops can't be LICMed
        https://bugs.webkit.org/show_bug.cgi?id=159388

        Reviewed by Mark Lam.
        
        Some time ago I acknowledged that LICM required loops to meet certain requirements that
        may get broken by the time we do LICM, like that the terminal of the pre-header is ExitOK.
        It used to be that we just ignored that requirement and would hoist anyway, but since
        r189126 we've stopped hoisting out of loops that don't have ExitOK.  We also added tests
        for the case that the pre-header doesn't exist or is invalid.

        It turns out that this patch didn't go far enough: even though it made LICM avoid loops
        that had an invalid pre-header, the part that updated the AI state in nested loops still
        assumed that these loops had valid pre-headers.  We would crash in null dereference in
        that loop if a nested loop had an invalid pre-header.

        The fix is simple: don't update the AI state of nested loops that don't have pre-headers,
        since we won't try to hoist out of those loops anyway.

        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::attemptHoist):
        * tests/stress/licm-no-pre-header-nested.js: Added. This would always crash before this fix.
        (foo):
        * tests/stress/licm-pre-header-cannot-exit-nested.js: Added. This was a failed attempt at a test, but I figure it's good to have weird code anyway.
        (foo):
        (valueOf):

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

        Scopes that are not under TDZ should still push their variables onto the TDZ stack so that lifting TDZ doesn't bypass that scope
        https://bugs.webkit.org/show_bug.cgi?id=159332
        rdar://problem/27018958

        Reviewed by Saam Barati.
        
        This fixes an instacrash in this code:
        
            try{}catch(e){}print(e);let e;
        
        We lift TDZ for "e" in "catch (e){}", but since that scope doesn't push anything onto the
        TDZ stack, we lift TDZ from "let e".
        
        The problem is that we weren't tracking the set of variables that do not have TDZ. We need
        to track them to "block" the traversal that lifts TDZ. This change fixes this issue by
        using a map that tracks all known variables, and tells you if they are under TDZ or not.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::numParameters):
        * bytecode/CodeOrigin.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::Label::setLocation):
        (JSC::Variable::dump):
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::pushLexicalScopeInternal):
        (JSC::BytecodeGenerator::popLexicalScope):
        (JSC::BytecodeGenerator::popLexicalScopeInternal):
        (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
        (JSC::BytecodeGenerator::variable):
        (JSC::BytecodeGenerator::needsTDZCheck):
        (JSC::BytecodeGenerator::liftTDZCheckIfPossible):
        (JSC::BytecodeGenerator::pushTDZVariables):
        (JSC::BytecodeGenerator::getVariablesUnderTDZ):
        (JSC::BytecodeGenerator::endGenerator):
        (WTF::printInternal):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::Variable::isConst):
        (JSC::Variable::setIsReadOnly):
        * interpreter/CallFrame.h:
        (JSC::ExecState::topOfFrame):
        * tests/stress/lift-tdz-bypass-catch.js: Added.
        (foo):
        (catch):

2016-07-01  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] RegExp.compile is not returning the regexp when it succeed
        https://bugs.webkit.org/show_bug.cgi?id=159381

        Reviewed by Mark Lam.

        Spec:
        -https://tc39.github.io/ecma262/#sec-regexp.prototype.compile
        -https://tc39.github.io/ecma262/#sec-regexpinitialize

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

2016-07-01  Saam Barati  <sbarati@apple.com>

        fix "ASSERTION FAILED: currentOffset() >= currentLineStartOffset()"
        https://bugs.webkit.org/show_bug.cgi?id=158572
        <rdar://problem/26884092>

        Reviewed by Mark Lam.

        There is a bug in our lexer when we notice the pattern:
        ```<return|continue|break|...etc> // some comment here```
        Our code will say that the token for the comment is a semicolon.
        This is the correct semantics, however, it would give the semicolon
        a start offset of the comment, but it will give its line start offset
        the newline after the comment.  This breaks the invariant in the lexer/parser
        that the offset for the current line starting point must be less than or equal to
        than the start offset of any token on that line. This invariant was broken because
        the line start offset was greater than the token start offset. To maintain this
        invariant, we claim that the semicolon token is located where the comment starts,
        and that its line start offset is the line start offset for the line with the
        comment on it.  There are other solutions that maintain this invariant, but this
        solution provides the best error messages.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::lex):
        * parser/Parser.h:
        (JSC::Parser::internalSaveLexerState):
        * tests/stress/obscure-error-message-dont-crash.js: Added.
        (try.eval.or.catch):

2016-07-01  Benjamin Poulain  <bpoulain@apple.com>

        __defineGetter__/__defineSetter__ should throw exceptions
        https://bugs.webkit.org/show_bug.cgi?id=142934

        Reviewed by Mark Lam.

        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncDefineGetter):
        (JSC::objectProtoFuncDefineSetter):

2016-07-01  Jon Davis  <jond@apple.com>

        Moved Web Animations and Resource Timing feature entries to WebCore.
        https://bugs.webkit.org/show_bug.cgi?id=159356

        Reviewed by Timothy Hatcher.

        * features.json:

2016-07-01  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Date.toGMTString should be the Date.toUTCString function
        https://bugs.webkit.org/show_bug.cgi?id=159318

        Reviewed by Mark Lam.

        See https://tc39.github.io/ecma262/#sec-date.prototype.togmtstring

        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::finishCreation):
        (JSC::dateProtoFuncToGMTString): Deleted.

2016-07-01  Mark Lam  <mark.lam@apple.com>

        Update JSC_functionOverrides to handle the new SourceCode strings that have params.
        https://bugs.webkit.org/show_bug.cgi?id=159321

        Reviewed by Geoffrey Garen.

        And add tests so that this won't fail silently and bit rot anymore.

        * API/tests/FunctionOverridesTest.cpp: Added.
        (testFunctionOverrides):
        * API/tests/FunctionOverridesTest.h: Added.
        * API/tests/testapi-function-overrides.js: Added.
        * API/tests/testapi.c:
        (main):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::link):
        * shell/PlatformWin.cmake:
        * tools/FunctionOverrides.cpp:
        (JSC::FunctionOverrides::FunctionOverrides):
        (JSC::FunctionOverrides::reinstallOverrides):
        (JSC::initializeOverrideInfo):
        (JSC::FunctionOverrides::initializeOverrideFor):
        * tools/FunctionOverrides.h:
        (JSC::FunctionOverrides::clear):

2016-07-01  Caio Lima  <ticaiolima@gmail.com>

        ES6: Implement HasRestrictedGlobalProperty when checking for global lexical tier conflicts
        https://bugs.webkit.org/show_bug.cgi?id=148763

        Reviewed by Saam Barati

        I've implemented the ES6 spec 8.1.1.4.14
        (http://www.ecma-international.org/ecma-262/6.0/index.html#sec-hasrestrictedglobalproperty)
        that defines when a global property can be shadowed.

        Added some test cases into global-lexical-redeclare-variable.js

        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * tests/stress/global-lexical-redeclare-variable.js:
        (catch):
        * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/eighth.js: Added.
        * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/nineth.js: Added.
        * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/seventh.js: Added.
        * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/sixth.js:
        * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/tenth.js: Added.

2016-07-01  Youenn Fablet  <youennf@gmail.com>

        Add a runtime flag for DOM iterators
        https://bugs.webkit.org/show_bug.cgi?id=159300

        Reviewed by Alex Christensen.

        * runtime/CommonIdentifiers.h:

2016-06-30  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Wrong function name next to scope
        https://bugs.webkit.org/show_bug.cgi?id=158210
        <rdar://problem/26543093>

        Reviewed by Timothy Hatcher.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        Add DebuggerLocation. A helper for describing a unique location.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::setConstantRegisters):
        When compiled with debug info, add a SymbolTable rare data pointer
        back to the CodeBlock. This will be used later to get JSScope debug
        info if Web Inspector pauses.

        * runtime/SymbolTable.h:
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::cloneScopePart):
        (JSC::SymbolTable::prepareForTypeProfiling):
        (JSC::SymbolTable::uniqueIDForVariable):
        (JSC::SymbolTable::uniqueIDForOffset):
        (JSC::SymbolTable::globalTypeSetForOffset):
        (JSC::SymbolTable::globalTypeSetForVariable):
        Rename rareData and include a CodeBlock pointer.

        (JSC::SymbolTable::rareDataCodeBlock):
        (JSC::SymbolTable::setRareDataCodeBlock):
        Setter and getter for the rare data. It should only be set once.

        (JSC::SymbolTable::visitChildren):
        Visit the rare data code block if we have one.

        * runtime/JSSymbolTableObject.h:
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::deleteProperty):
        (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
        Give JSSymbolTable its own class info. JSWithScope was unexpectedly
        inheriting from JSSymbolTable since it did not have its own and
        was using JSScope's class info. Also do a bit of cleanup.

        * debugger/DebuggerLocation.cpp: Added.
        (JSC::DebuggerLocation::DebuggerLocation):
        * debugger/DebuggerLocation.h: Added.
        (JSC::DebuggerLocation::DebuggerLocation):
        Construction from a ScriptExecutable.

        * runtime/JSScope.cpp:
        (JSC::JSScope::symbolTable):
        * runtime/JSScope.h:
        * debugger/DebuggerScope.h:
        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::name):
        (JSC::DebuggerScope::location):
        Name and location for a scope. This uses:
        JSScope -> SymbolTable -> CodeBlock -> Executable

        * inspector/protocol/Debugger.json:
        * inspector/InjectedScriptSource.js:
        (InjectedScript.CallFrameProxy.prototype._wrapScopeChain):
        (InjectedScript.CallFrameProxy._createScopeJson):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::valueForScopeType):
        (Inspector::valueForScopeLocation):
        (Inspector::JSJavaScriptCallFrame::scopeDescriptions):
        (Inspector::JSJavaScriptCallFrame::scopeType): Deleted.
        * inspector/JSJavaScriptCallFrame.h:
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeType): Deleted.
        Simplify this code to build the objects we will send across the protocol
        to descript a Scope.

2016-06-30  Saam Barati  <sbarati@apple.com>

        missing exception checks in arrayProtoFuncReverse
        https://bugs.webkit.org/show_bug.cgi?id=159319
        <rdar://problem/27083696>

        Reviewed by Filip Pizlo.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncToString):
        (JSC::arrayProtoFuncReverse):

2016-06-30  Saam Barati  <sbarati@apple.com>

        get_by_id_with_this does not trigger a to_this in caller.
        https://bugs.webkit.org/show_bug.cgi?id=159226

        Reviewed by Keith Miller.

        This is a bug if the caller is in sloppy mode and the callee is in strict
        mode. This can't happen with ES6 classes because they're all in strict mode,
        but it can happen with method syntax on an object literal. The caller must
        to_this on |this| when it knows that it performs super property accesses.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * tests/stress/super-property-access-object-literal-to-this-2.js: Added.
        (assert):
        (test):
        (let.o1.get foo):
        (let.o2.a):
        (let.o2.aa):
        * tests/stress/super-property-access-object-literal-to-this.js: Added.
        (assert):
        (test):
        (let.o1.get foo):
        (let.o2.a):
        (let.o2.aa):
        (let.o2.b):
        (let.o2.bb):
        * tests/stress/super-property-access-to-this.js: Added.
        (assert):
        (test):
        (Base.prototype.get foo):
        (Base):
        (Child.prototype.a):
        (Child.prototype.b):
        (Child):

2016-06-30  Saam Barati  <sbarati@apple.com>

        We need to to_this when an inner arrow function uses 'this'
        https://bugs.webkit.org/show_bug.cgi?id=159290
        <rdar://problem/27058322>

        Reviewed by Geoffrey Garen.

        We put the |this| value into the closure object when there
        is an arrow function that uses |this|. However, an arrow function
        using |this| wasn't causing the creator of the closure that
        holds |this| to to_this its value before putting it in the
        closure. That's a huge bug because it means some arrow functions
        can capture the raw |this| value, which might be a JSLexicalEnvironment.
        This patch fixes this by adding an easy to check to see if any
        inner arrow functions use |this|, and if any do, it will to_this
        the |this| value.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * tests/stress/to-this-before-arrow-function-closes-over-this-that-starts-as-lexical-environment.js: Added.
        (assert):
        (obj):
        (foo.capture):
        (foo.wrapper.let.x.):
        (foo2.capture):
        (foo2.wrapper.let.x.):
        (foo2.wrapper.bar):

2016-06-29  Filip Pizlo  <fpizlo@apple.com>

        Generators violate bytecode liveness validation
        https://bugs.webkit.org/show_bug.cgi?id=159279

        Reviewed by Yusuke Suzuki.
        
        Fix a liveness bug found by Basic. The problem is that resume's intended liveness rule is:
        "live-in is just the token argument", but the liveness analysis thought that the rule was
        "live-in is live-out minus defs plus live-at-catch". Clearly these two rules are quite
        different. The way this sort of worked before is that we would define the defs of resume
        as being equal to our prediction of what the live-outs would be. We did this in the hope
        that we would subtract all live-outs. But, this misses the live-at-catch part. So, this
        change adds another hack to neutralize live-at-catch.
        
        This would make a lot more sense if we wrote a new liveness analysis that was just for
        generator conversion. It could reuse BytecodeUseDef but otherwise it would be a new thing.
        It would be easy to write crazy rules for save/resume in such an analysis, especially if
        that analysis rewrote the bytecode. We could then just have an op_yield that is a no-op.
        We would just record the live-outs of op_yield and use that for rewriting the code in terms
        of a switch statement.

        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::stepOverInstruction):
        (JSC::BytecodeLivenessAnalysis::dumpResults):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):

2016-06-30  Commit Queue  <commit-queue@webkit.org>

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

        The test for this change times out on mac-wk2 debug and caused
        an existing test to crash. (Requested by ryanhaddad on
        #webkit).

        Reverted changeset:

        "Web Inspector: Wrong function name next to scope"
        https://bugs.webkit.org/show_bug.cgi?id=158210
        http://trac.webkit.org/changeset/202659

2016-06-30  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Date.setYear() misses timeClip()
        https://bugs.webkit.org/show_bug.cgi?id=159289

        Reviewed by Geoffrey Garen.

        * runtime/DatePrototype.cpp:
        (JSC::dateProtoFuncSetYear):

2016-06-30  Joseph Pecoraro  <pecoraro@apple.com> and Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Implement isFinite / isNaN in JS and make DFG ToNumber accept non number values
        https://bugs.webkit.org/show_bug.cgi?id=154022

        Reviewed by Filip Pizlo.

        We aim at optimizing @toInteger operation.
        While it still has an unoptimized part[1], this patch should be a first step.

        We introduce the @toNumber builtin intrinsic operation.
        This converts the given value to the JS number by emitting op_to_number bytecode.
        Previously @toInteger called C++ @Number constructor for that purpose.

        And in DFG, op_to_number is converted to DFG ToNumber node.
        During DFG, we attempt to convert this to edge filtering and Identity, but if we fail,
        we just fall back to calling the C++ function.

        To utilize ToNumber in user-land side, we add a path attempting to convert Number constructor calls
        to ToNumber DFG nodes. This conversion is useful because `Number(value)` is used to convert a value to a number in JS.

        Before this patch, we emit simple edge filtering (NumberUse) instead of emitting DFG node like ToNumber for op_to_number.
        But emitting ToNumber is useful, because in the case of `Number(value)`, considering `value` may not be a number is reasonable.

        By leveraging @toNumber operation, we rewrite Number.{isFinite, isNaN}, global.{isFinite, isNaN} and @toInteger.

        ToNumber DFG node has a value profiling. This profiling is leveraged to determine the result number type of the ToNumber operation.
        This value profiling is provided from either NumberConstructor's call operation or op_to_number.

        The results (with the added performance tests) show that, while existing cases are performance neutral, the newly added cases gain the performance benefit.
        And ASMBench/n-body.c also shows stable ~2% progression.

        [1]: https://bugs.webkit.org/show_bug.cgi?id=153738

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinNames.h:
        * builtins/GlobalObject.js:
        (globalPrivate.isFinite):
        (globalPrivate.isNaN):
        (globalPrivate.toInteger): Deleted.
        (globalPrivate.toLength): Deleted.
        (globalPrivate.isDictionary): Deleted.
        (globalPrivate.speciesGetter): Deleted.
        (globalPrivate.speciesConstructor): Deleted.
        * builtins/GlobalOperations.js: Copied from Source/JavaScriptCore/builtins/GlobalObject.js.
        (globalPrivate.toInteger):
        (globalPrivate.toLength):
        (globalPrivate.isDictionary):
        (globalPrivate.speciesGetter):
        (globalPrivate.speciesConstructor):
        * builtins/NumberConstructor.js: Added.
        (isFinite):
        (isNaN):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finishCreation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitUnaryOp):
        (JSC::BytecodeGenerator::emitUnaryOpProfiled):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitToNumber):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_toNumber):
        (JSC::UnaryPlusNode::emitBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::parseBlock):
        We use `getPrediction()` to retrieve the heap prediction from the to_number bytecode.
        According to the benchmark results, choosing `getPredictionWithoutOSRExit()` causes performance regression (1.5%) in kraken stanford-crypto-aes.

        * 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):
        (JSC::DFG::FixupPhase::fixupToNumber):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        Always on the heap prediction.

        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        As of 64bit version, we carefully manage the register reuse. The largest difference between 32bit and 64bit is
        `branchIfNotNumber()` requires the temporary register. We should not use the result registers for that since
        it may be reuse the argument registers and it can break the argument registers before using them to call the operation.
        Currently, we allocate the additional temporary register for that scratch register.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        Reuse the argument register for the result if possible. And manually decrement the use count in the middle of the node.
        This is similar technique used in ToPrimitive. Typically, the child of ToNumber is only used by this ToNumber node since
        we would like to perform the type conversion onto this child node here. So this careful register reuse effectively removes
        the spills to call the operation. The example of the actually emitted code is the following.

        76:<!2:loc11>     ToNumber(Untyped:@68, JS|MustGen|UseAsOther, DoubleimpurenanTopEmpty, R:World, W:Heap, Exits, ClobbersExit, bc#48)  predicting DoubleimpurenanTopEmpty
            0x7f986d5fe693: test %rax, %r14
            0x7f986d5fe696: jz 0x7f986d5fe6a1
            0x7f986d5fe69c: jmp 0x7f986d5fe6d1
            0x7f986d5fe6a1: mov %rax, %rsi
            0x7f986d5fe6a4: mov %rbp, %rdi
            0x7f986d5fe6a7: mov $0x2, 0x24(%rbp)
            0x7f986d5fe6ae: mov $0x7f98711ea5f0, %r11
            0x7f986d5fe6b8: call *%r11
            0x7f986d5fe6bb: mov $0x7f982d3f72d0, %r11
            0x7f986d5fe6c5: mov (%r11), %r11
            0x7f986d5fe6c8: test %r11, %r11
            0x7f986d5fe6cb: jnz 0x7f986d5fe88c

        It effectively removes the unnecessary spill to call the operation!

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileToNumber):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfNumber):
        (JSC::AssemblyHelpers::branchIfNotNumber):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_to_number):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_to_number):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/Nodes.h:
        (JSC::UnaryOpNode::opcodeID):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncIsNaN): Deleted.
        (JSC::globalFuncIsFinite): Deleted.
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/MathCommon.h:
        (JSC::maxSafeInteger):
        (JSC::minSafeInteger):
        * runtime/NumberConstructor.cpp:
        (JSC::NumberConstructor::finishCreation):
        (JSC::numberConstructorFuncIsFinite): Deleted.
        (JSC::numberConstructorFuncIsNaN): Deleted.
        * runtime/NumberConstructor.h:
        * tests/stress/Number-isNaN-basics.js: Added.
        (numberIsNaNOnInteger):
        (testNumberIsNaNOnIntegers):
        (verifyNumberIsNaNOnIntegerWithOtherTypes):
        (numberIsNaNOnDouble):
        (testNumberIsNaNOnDoubles):
        (verifyNumberIsNaNOnDoublesWithOtherTypes):
        (numberIsNaNNoArguments):
        (numberIsNaNTooManyArguments):
        (testNumberIsNaNOnConstants):
        (numberIsNaNStructTransition):
        (Number.isNaN):
        * tests/stress/global-is-finite.js: Added.
        (shouldBe):
        * tests/stress/global-is-nan.js: Added.
        (shouldBe):
        * tests/stress/global-isNaN-basics.js: Added.
        (isNaNOnInteger):
        (testIsNaNOnIntegers):
        (verifyIsNaNOnIntegerWithOtherTypes):
        (isNaNOnDouble):
        (testIsNaNOnDoubles):
        (verifyIsNaNOnDoublesWithOtherTypes):
        (verifyIsNaNOnCoercedTypes):
        (isNaNNoArguments):
        (isNaNTooManyArguments):
        (testIsNaNOnConstants):
        (isNaNTypeCoercionSideEffects):
        (i.value.isNaNTypeCoercionSideEffects.valueOf):
        (isNaNStructTransition):
        (isNaN):
        * tests/stress/number-is-finite.js: Added.
        (shouldBe):
        (test2):
        (test3):
        * tests/stress/number-is-nan.js: Added.
        (shouldBe):
        (test2):
        (test3):
        * tests/stress/to-number-basics.js: Added.
        (shouldBe):
        * tests/stress/to-number-convert-identity-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        (valueOf):
        * tests/stress/to-number-int52.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-convert-to-identity-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        (valueOf):
        * tests/stress/to-number-intrinsic-int52.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-object-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-value-profiling.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-object-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-object.js: Added.
        (shouldBe):
        (test12):
        (object1.valueOf):
        (test2):
        (test22):
        (object2.valueOf):
        (test3):
        (test32):
        (object3.valueOf):
        * tests/stress/to-number-value-profiling.js: Added.
        (shouldBe):
        (object.valueOf):

2016-06-29  Benjamin Poulain  <benjamin@webkit.org>

        Fix the debug build after r202667

        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        The putDirect was missing the Accessor flag for the GetterSetter.

2016-06-29  Michael Saboff  <msaboff@apple.com>

        REGRESSION(200114): Netflix app does not see ChromeCast
        https://bugs.webkit.org/show_bug.cgi?id=159287

        Reviewed by Benjamin Poulain.

        Change set 200114 changed the behavior of how we check for whether or not we
        wrap Objective C init methods in JavaScript constructors.  The prior method
        checked the version of JavaScriptCore that was linked with the application.
        If the application was not directly linked with JavaScriptCore the prior
        method indicated that we shouldn't create constructors.  The new method uses
        the SDK the application was compiled with.  Using the new method, an
        application compiled with iOS SDK 8.0 or greater would create constructors
        and not export init methods to JavaScript.  The problem is that an existing
        application that hasn't been recompiled will get a different answer using
        the new method.  We need to come up with a method that works in a compatible
        way with existing programs, but provides a newly compiled program with the
        "is built with SDK N or greater" check.
        
        Added back the prior check of the version of JavaScriptCore the program was
        directly linked against.  However we only use this check if we directly linked
        with JavaScriptCore.  Otherwise we fall through to check against the SDK the
        program was built with.  Changed the iOS SDK version we check
        against to be the new version of iOS, iOS 10.

        This provides compatible behavior for existing programs.  It may be the case
        that some of those programs may require changes when they are rebuilt with the
        iOS 10 SDK or later.

        * API/JSWrapperMap.mm:
        (supportsInitMethodConstructors):

2016-06-29  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Minor TypedArray fixes
        https://bugs.webkit.org/show_bug.cgi?id=159286

        Reviewed by Keith Miller.

        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
        See https://tc39.github.io/ecma262/#sec-%typedarray%

        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewPrivateFuncLength):
        See https://tc39.github.io/ecma262/#sec-get-%typedarray%.prototype.length

        (JSC::typedArrayViewProtoGetterFuncToStringTag):
        Yep, that's odd.
        See https://tc39.github.io/ecma262/#sec-get-%typedarray%.prototype-@@tostringtag

        (JSC::JSTypedArrayViewPrototype::finishCreation):
        See the last paragraph of https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects

2016-06-29  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: API View of Native DOM APIs looks poor (TypeErrors for native getters)
        https://bugs.webkit.org/show_bug.cgi?id=158334
        <rdar://problem/26615366>

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype._getProperties):
        (InjectedScript.prototype._propertyDescriptors):
        Do not create fake value property descriptors for native accessors
        unless requested. This means, getProperties for a native prototype
        should return  accessors for native accessors just like it does
        for normal non-native accessors (getters/setters).

        (InjectedScript.prototype.getProperties):
        Do not produce fake value accessors for native accessors.

        (InjectedScript.prototype.getDisplayableProperties):
        (InjectedScript.RemoteObject.prototype._generatePreview):
        Do produce fake value accessors for native accessors.

2016-06-29  Saam barati  <sbarati@apple.com>

        JSGlobalLexicalEnvironment needs a toThis implementation
        https://bugs.webkit.org/show_bug.cgi?id=159285

        Reviewed by Mark Lam.

        This was a huge oversight of my original implementation. It gave users
        of the language direct access to the JSGlobalLexicalEnvironment object.

        * runtime/JSGlobalLexicalEnvironment.cpp:
        (JSC::JSGlobalLexicalEnvironment::isConstVariable):
        (JSC::JSGlobalLexicalEnvironment::toThis):
        * runtime/JSGlobalLexicalEnvironment.h:
        (JSC::JSGlobalLexicalEnvironment::isEmpty):
        * tests/stress/global-lexical-environment-to-this.js: Added.
        (assert):
        (let.f):
        (let.fStrict):

2016-06-29  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Wrong function name next to scope
        https://bugs.webkit.org/show_bug.cgi?id=158210
        <rdar://problem/26543093>

        Reviewed by Brian Burg.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        Add DebuggerLocation. A helper for describing a unique location.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::setConstantRegisters):
        When compiled with debug info, add a SymbolTable rare data pointer
        back to the CodeBlock. This will be used later to get JSScope debug
        info if Web Inspector pauses.

        * runtime/SymbolTable.h:
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::cloneScopePart):
        (JSC::SymbolTable::prepareForTypeProfiling):
        (JSC::SymbolTable::uniqueIDForVariable):
        (JSC::SymbolTable::uniqueIDForOffset):
        (JSC::SymbolTable::globalTypeSetForOffset):
        (JSC::SymbolTable::globalTypeSetForVariable):
        Rename rareData and include a CodeBlock pointer.

        (JSC::SymbolTable::rareDataCodeBlock):
        (JSC::SymbolTable::setRareDataCodeBlock):
        Setter and getter for the rare data. It should only be set once.

        (JSC::SymbolTable::visitChildren):
        Visit the rare data code block if we have one.

        * debugger/DebuggerLocation.cpp: Added.
        (JSC::DebuggerLocation::DebuggerLocation):
        * debugger/DebuggerLocation.h: Added.
        (JSC::DebuggerLocation::DebuggerLocation):
        Construction from a ScriptExecutable.

        * runtime/JSScope.cpp:
        (JSC::JSScope::symbolTable):
        * runtime/JSScope.h:
        * debugger/DebuggerScope.h:
        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::name):
        (JSC::DebuggerScope::location):
        Name and location for a scope. This uses:
        JSScope -> SymbolTable -> CodeBlock -> Executable

        * inspector/protocol/Debugger.json:
        * inspector/InjectedScriptSource.js:
        (InjectedScript.CallFrameProxy.prototype._wrapScopeChain):
        (InjectedScript.CallFrameProxy._createScopeJson):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::valueForScopeType):
        (Inspector::valueForScopeLocation):
        (Inspector::JSJavaScriptCallFrame::scopeDescriptions):
        (Inspector::JSJavaScriptCallFrame::scopeType): Deleted.
        * inspector/JSJavaScriptCallFrame.h:
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeType): Deleted.
        Simplify this code to build the objects we will send across the protocol
        to descript a Scope.

2016-06-29  Saam barati  <sbarati@apple.com>

        We don't emit TDZ checks for call_eval
        https://bugs.webkit.org/show_bug.cgi?id=159277
        <rdar://problem/27018801>

        Reviewed by Benjamin Poulain.

        This is a problem if you're trying to call a TDZ variable
        that is named 'eval'.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::EvalFunctionCallNode::emitBytecode):
        * tests/stress/variable-named-eval-under-tdz.js: Added.
        (shouldThrowTDZ):
        (test):
        (test.foo):
        (throw.new.Error):

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

        Add support for collecting cumulative LLINT stats via a JSC_llintStatsFile option.
        https://bugs.webkit.org/show_bug.cgi?id=159274

        Reviewed by Keith Miller.

        * jsc.cpp:
        (main):
        * llint/LLIntData.cpp:
        (JSC::LLInt::initialize):
        (JSC::LLInt::Data::finalizeStats):
        (JSC::LLInt::compareStats):
        (JSC::LLInt::Data::dumpStats):
        (JSC::LLInt::Data::ensureStats):
        (JSC::LLInt::Data::loadStats):
        (JSC::LLInt::Data::resetStats):
        (JSC::LLInt::Data::saveStats):
        * llint/LLIntData.h:
        (JSC::LLInt::Data::opcodeStats):
        * runtime/Options.cpp:
        (JSC::Options::isAvailable):
        (JSC::recomputeDependentOptions):
        (JSC::Options::initialize):
        * runtime/Options.h:

2016-06-29  Saam barati  <sbarati@apple.com>

        Destructuring variable declaration is missing a validation of the syntax of a sub production when there is a rhs
        https://bugs.webkit.org/show_bug.cgi?id=159267

        Reviewed by Mark Lam.

        We were parsing something without checking if it had a syntax error.
        This is wrong for many reasons, but it could actually cause a crash
        in a debug build if you parsed particular programs.

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

2016-06-29  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Show Shadow Root type in DOM Tree
        https://bugs.webkit.org/show_bug.cgi?id=159236
        <rdar://problem/27068521>

        Reviewed by Timothy Hatcher.

        * inspector/protocol/DOM.json:
        Include optional shadowRootType property for DOMNodes.

2016-06-29  Commit Queue  <commit-queue@webkit.org>

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

        patch is broken on arm (Requested by keith_miller on #webkit).

        Reverted changeset:

        "LLInt should support other types of prototype GetById
        caching."
        https://bugs.webkit.org/show_bug.cgi?id=158083
        http://trac.webkit.org/changeset/202627

2016-06-29  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Fix small issues of TypedArray prototype
        https://bugs.webkit.org/show_bug.cgi?id=159248

        Reviewed by Saam Barati.

        First, TypedArray's toString and Array's toString
        should be the same function.
        I moved the function to GlobalObject and each array type
        gets it as needed.

        Then TypedArray length was supposed to be configurable.
        I removed the "DontDelete" flag accordingly.

        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::arrayProtoToStringFunction):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):

2016-06-29  Caio Lima  <ticaiolima@gmail.com>

        LLInt should support other types of prototype GetById caching.
        https://bugs.webkit.org/show_bug.cgi?id=158083

        Recently, we started supporting prototype load caching for get_by_id
        in the LLInt. This patch is expading the caching strategy to enable
        cache the prototype accessor and custom acessors.

        Similarly to the get_by_id_proto_load bytecode, we are adding new
        bytecodes called get_by_id_proto_accessor that uses the calculated
        offset of a object to call a getter function and get_by_id_proto_custom
        that stores the pointer to the custom function and call them directly
        from LowLevelInterpreter.

        Reviewed by Keith Miller

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdOp):
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setupGetByIdPrototypeCache):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2016-06-28  Commit Queue  <commit-queue@webkit.org>

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

        Caused all WKTR tests to fail on GuardMalloc and Production
        only for unknown reasons, investigating offline. (Requested by
        brrian on #webkit).

        Reverted changeset:

        "RunLoop::Timer should use constructor templates instead of
        class templates"
        https://bugs.webkit.org/show_bug.cgi?id=159153
        http://trac.webkit.org/changeset/202580

2016-06-28  Keith Miller  <keith_miller@apple.com>

        We should not crash there is a finally inside a for-in loop
        https://bugs.webkit.org/show_bug.cgi?id=159243
        <rdar://problem/27018910>

        Reviewed by Benjamin Poulain.

        Previously we would swap the m_forInContext with an empty vector
        then attempt to shrink the size of m_forInContext by the amount
        we expected. This meant that if there was more than one ForInContext
        on the stack and we wanted to pop exactly one off we would crash.
        This patch makes ForInContexts RefCounted so they can be duplicated
        into other vectors. It also has ForInContexts copy the entire stack
        rather than do the swap that we did before. This makes ForInContexts
        work the same as the other contexts.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitComplexPopScopes):
        (JSC::BytecodeGenerator::pushIndexedForInScope):
        (JSC::BytecodeGenerator::pushStructureForInScope):
        * bytecompiler/BytecodeGenerator.h:
        * tests/stress/finally-for-in.js: Added.
        (repeat):
        (createSimple):

2016-06-28  Saam Barati  <sbarati@apple.com>

        Assertion failure or crash when accessing let-variable in TDZ with eval with a function in it that returns let variable
        https://bugs.webkit.org/show_bug.cgi?id=158796
        <rdar://problem/26984659>

        Reviewed by Michael Saboff.

        There was a bug where some functions inside of an eval were
        omitting a necessary TDZ check. This obviously leads to bad
        things because a variable under TDZ is the null pointer.
        The eval's bytecode was generated with the correct TDZ set, but 
        it created all its functions before pushing that TDZ set onto
        the stack. That's a mistake. Those functions need to be created with
        that TDZ set. The solution is simple, the TDZ set that the eval
        is created with needs to be pushed onto the TDZ stack before
        the eval creates any functions.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * tests/stress/variable-under-tdz-eval-tricky.js: Added.
        (assert):
        (throw.new.Error):
        (assert.try.underTDZ):

2016-06-28  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r200946): Improper backtracking from last alternative in sticky patterns
        https://bugs.webkit.org/show_bug.cgi?id=159233

        Reviewed by Mark Lam.

        Jump to fail exit code when the last alternative of a sticky pattern fails.

        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::backtrack):

2016-06-28  Saam Barati  <sbarati@apple.com>

        some Watchpoints' ::fireInternal method will call operations that might GC where the GC will cause the watchpoint itself to destruct
        https://bugs.webkit.org/show_bug.cgi?id=159198
        <rdar://problem/26302360>

        Reviewed by Filip Pizlo.

        Firing a watchpoint may cause a GC to happen. This GC could destroy various
        Watchpoints themselves while they're in the process of firing. It's not safe
        for most Watchpoints to be destructed while they're in the middle of firing.
        This GC could also destroy the WatchpointSet itself, and it's not in a safe
        state to be destroyed. WatchpointSet::fireAllWatchpoints now defers gc for a
        while. This prevents a GC from destructing any Watchpoints while they're
        in the process of firing. This bug was being hit by the stress GC bots
        because we would destruct a particular Watchpoint while it was firing,
        and then we would access its field after it had already been destroyed.
        This was causing all kinds of weird symptoms. Also, this was easier to
        catch when running with guard malloc because the first access after
        destruction would lead to a crash.

        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecode/VariableWriteFireDetail.cpp:
        (JSC::VariableWriteFireDetail::dump):
        (JSC::VariableWriteFireDetail::touch):
        * bytecode/VariableWriteFireDetail.h:
        * bytecode/Watchpoint.cpp:
        (JSC::WatchpointSet::add):
        (JSC::WatchpointSet::fireAllSlow):
        (JSC::WatchpointSet::fireAllWatchpoints):
        (JSC::InlineWatchpointSet::add):
        (JSC::InlineWatchpointSet::fireAll):
        (JSC::InlineWatchpointSet::inflateSlow):
        * bytecode/Watchpoint.h:
        (JSC::WatchpointSet::startWatching):
        (JSC::WatchpointSet::fireAll):
        (JSC::WatchpointSet::touch):
        (JSC::WatchpointSet::invalidate):
        (JSC::WatchpointSet::isBeingWatched):
        (JSC::WatchpointSet::offsetOfState):
        (JSC::WatchpointSet::addressOfSetIsNotEmpty):
        (JSC::InlineWatchpointSet::startWatching):
        (JSC::InlineWatchpointSet::fireAll):
        (JSC::InlineWatchpointSet::invalidate):
        (JSC::InlineWatchpointSet::touch):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * dfg/DFGOperations.cpp:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * jit/JITOperations.cpp:
        * jsc.cpp:
        (WTF::Masquerader::create):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/ArrayBufferNeuteringWatchpoint.cpp:
        (JSC::ArrayBufferNeuteringWatchpoint::fireAll):
        * runtime/FunctionRareData.cpp:
        (JSC::FunctionRareData::clear):
        * runtime/InferredType.cpp:
        (JSC::InferredType::willStoreValueSlow):
        (JSC::InferredType::makeTopSlow):
        (JSC::InferredType::set):
        (JSC::InferredType::removeStructure):
        (JSC::InferredType::InferredStructureWatchpoint::fireInternal):
        * runtime/InferredValue.cpp:
        (JSC::InferredValue::notifyWriteSlow):
        (JSC::InferredValue::ValueCleanup::finalizeUnconditionally):
        * runtime/InferredValue.h:
        (JSC::InferredValue::notifyWrite):
        (JSC::InferredValue::invalidate):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::haveABadTime):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTablePutTouchWatchpointSet):
        (JSC::symbolTablePutInvalidateWatchpointSet):
        * runtime/Structure.cpp:
        (JSC::Structure::didCachePropertyReplacement):
        (JSC::Structure::startWatchingInternalProperties):
        (JSC::DeferredStructureTransitionWatchpointFire::~DeferredStructureTransitionWatchpointFire):
        (JSC::DeferredStructureTransitionWatchpointFire::add):
        (JSC::Structure::didTransitionFromThisStructure):
        (JSC::Structure::prototypeForLookup):
        * runtime/StructureInlines.h:
        (JSC::Structure::didReplaceProperty):
        (JSC::Structure::propertyReplacementWatchpointSet):
        * runtime/SymbolTable.h:
        (JSC::SymbolTableEntry::isDontEnum):
        (JSC::SymbolTableEntry::disableWatching):
        * runtime/VM.cpp:
        (JSC::VM::addImpureProperty):
        (JSC::enableProfilerWithRespectToCount):

2016-06-28  Filip Pizlo  <fpizlo@apple.com>

        JSRopeString should use release asserts, not debug asserts, about substring bounds
        https://bugs.webkit.org/show_bug.cgi?id=159227

        Reviewed by Saam Barati.
        
        According to my experiments this change costs nothing.  That's not surprising since the
        most common way to construct a rope these days is inlined into the JIT, which does its own
        safety checks.  This makes us crash sooner rather than corrupting memory.

        * runtime/JSString.h:

2016-06-28  Brian Burg  <bburg@apple.com>

        RunLoop::Timer should use constructor templates instead of class templates
        https://bugs.webkit.org/show_bug.cgi?id=159153

        Reviewed by Alex Christensen.

        Remove the RunLoop::Timer class template argument, and pass its constructor
        a reference to `this` instead of a pointer to `this`.

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):

2016-06-28  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: selectElement.options shows unexpected entries in console (named indexes beyond collection length)
        https://bugs.webkit.org/show_bug.cgi?id=159192

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype.arrayIndexPropertyNames):
        Start with an empty array because we just push valid indexes.

        (InjectedScript.prototype._propertyDescriptors):
        Avoid the >100 length requirement, and always treat the
        array-like objects the same. The frontend currently
        doesn't show named indexes for arrays anyways, so they
        would have been unused.

2016-06-28  Per Arne Vollan  <pvollan@apple.com>

        [Win] Skip failing INTL test.
        https://bugs.webkit.org/show_bug.cgi?id=159141

        Reviewed by Brent Fulgham.

        INTL is not enabled on Windows.

        * tests/stress/intl-constructors-with-proxy.js:
        (shouldBe):

2016-06-28  Joonghun Park  <jh718.park@samsung.com>

        [JSC] Fix build break since r202502 - 2
        https://bugs.webkit.org/show_bug.cgi?id=159194

        Reviewed by Gyuyoung Kim.

        Fix about the error message below.
        error: control reaches end of non-void function [-Werror=return-type]

        * b3/B3TypeMap.h: add #pragma GCC diagnostic ignored "-Wreturn-type".

2016-06-28  Joonghun Park  <jh718.park@samsung.com>

        [JSC] Fix build break since r202502
        https://bugs.webkit.org/show_bug.cgi?id=159194

        Reviewed by Alex Christensen.

        Fix about the error message below.
        error: control reaches end of non-void function [-Werror=return-type]

        * b3/B3TypeMap.h:
        (JSC::B3::TypeMap::at): add missing ASSERT_NOT_REACHED().

2016-06-27  Keith Miller  <keith_miller@apple.com>

        Fix bad assert in StructureRareData::setObjectToStringValue
        https://bugs.webkit.org/show_bug.cgi?id=159171
        <rdar://problem/26987355>

        Reviewed by Mark Lam.

        We should not have expected the generateConditionsForPrototypePropertyHit would succeed.
        There are many reasons it might fail including that there is a proxy somewhere on the
        prototype chain of the object.

        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::setObjectToStringValue):
        * tests/stress/object-toString-with-proxy.js: Added.
        (get target):

2016-06-27  Filip Pizlo  <fpizlo@apple.com>

        Crashing at an unreachable code trap in FTL should give more information
        https://bugs.webkit.org/show_bug.cgi?id=159177

        Reviewed by Saam Barati.
        
        This stuffs information into registers so that we have some chance of seeing what happened
        by looking at the register dumps.

        * assembler/AbortReason.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::ftlUnreachable):
        (JSC::FTL::DFG::LowerDFGToB3::compileBlock):
        (JSC::FTL::DFG::LowerDFGToB3::crash):

2016-06-27  Filip Pizlo  <fpizlo@apple.com>

        Clean up resetting reachability in B3/Air
        https://bugs.webkit.org/show_bug.cgi?id=159170

        Reviewed by Geoffrey Garen.
        
        When I fixed bug 159165, I took the brute force approach. I still used the
        B3::resetReachability() method, and changed the callback to record the set of deleted values
        instead of deleting them eagerly. But this means tracking the set of deleted values, even
        though resetReachability() already internally tracks the set of deleted blocks. You can find
        out if a value is deleted by asking if its owning block was deleted.
        
        So, this change refactors B3::resetReachability() into a new helper called
        B3::recomputePredecessors(). This new helper skips the block deletion step, and lets the
        client delete blocks. This lets Air delete blocks the same way that it did before, and it
        lets B3 use the isBlockDead() method (which is a glorified proxy for
        block->predecessors().isEmpty()) to track which values are deleted. This allows B3 to turn
        Upsilons that point to dead Phis into Nops before deleting the blocks.
        
        This shouldn't affect performance or anything real. It just makes the code cleaner.

        * b3/B3BasicBlockUtils.h:
        (JSC::B3::updatePredecessorsAfter):
        (JSC::B3::recomputePredecessors):
        (JSC::B3::isBlockDead):
        (JSC::B3::resetReachability): Deleted.
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::resetReachability):
        (JSC::B3::Procedure::invalidateCFG):
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::resetReachability):
        (JSC::B3::Air::Code::dump):

2016-06-27  Brian Burg  <bburg@apple.com>

        Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
        https://bugs.webkit.org/show_bug.cgi?id=159075
        <rdar://problem/26094341>

        Reviewed by Filip Pizlo.

        This change caused JSC stress tests to all hit an assertion in RunLoop.
        We should use RunLoop::current() to create the RunLoop::Timer since JSC-only
        clients like testapi and jsc don't ever call initializeMainRunLoop().

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):

2016-06-27  Filip Pizlo  <fpizlo@apple.com>

        B3::Procedure::resetReachability() can create dangling references from Upsilons to Phis
        https://bugs.webkit.org/show_bug.cgi?id=159165

        Reviewed by Mark Lam.
        
        You can delete an unreachable block that has a Phi but some prior block may still have an
        Upsilon pointing to that Phi. This can happen if the Upsilon precedes a Check that always
        exits or it can happen if we remove some successor of a block and this block had an Upsilon
        for one of the removed successors. These things are valid IR even if they are not canonical.
        Our policy for not-canonical-but-valid IR is that the compiler should still emit valid code
        in the end.
        
        The solution is to have Procedure::resetReachability() turn those Upsilons into Nops.

        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::resetReachability): Fix the bug.
        * b3/B3Validate.h:
        * b3/testb3.cpp:
        (JSC::B3::testResetReachabilityDanglingReference): Add a test. This always crashes prior to this change.
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::killUnreachableBlocks): Add a FIXME about a possible similar bug.

2016-06-27  Keith Miller  <keith_miller@apple.com>

        Add comment to Module feature in features.json
        https://bugs.webkit.org/show_bug.cgi?id=159159

        Reviewed by Saam Barati.

        * features.json:

2016-06-27  Keith Miller  <keith_miller@apple.com>

        Update features.json for ES6 completed features.
        https://bugs.webkit.org/show_bug.cgi?id=159152

        Reviewed by Mark Lam.

        * features.json:

2016-06-25  Filip Pizlo  <fpizlo@apple.com>

        B3 should not use Nops when deleting unreachable code
        https://bugs.webkit.org/show_bug.cgi?id=159120
        rdar://problem/26500743

        Reviewed by Michael Saboff.
        
        Prior to this change, transformations that obviated the need for some value could choose
        from these ways to kill it:
        
        - replaceWithIdentity() if we're replacing with another value.
        - replaceWithNop() if the type is Void or if we know that we'll fix any users of this
          value.
        - deleteValue() if the code is unreachable.
        
        The bug here is that reduceStrength() was being clever about how to get rid of a value.
        reduceStrength() may find a Check that must always exit. The goal is to remove any code
        dominated by the Check. But it would be awkward to eagerly delete all of the blocks
        dominated by this one. So this code took a much simpler approach: it would
        replaceWithNop() for all of the values in this block after the Check and it would replace
        the terminal with Oops.
        
        But this corrupts the IR in a subtle way: some of those values may have been non-Void but
        now they are Nops so they are Void. reduceStrength() will not yet realize that the blocks
        dominated by the one with the Check are unreachable, so it will run all sorts of
        optimizations on those blocks. This could have probably manifested as many different kinds
        of badness, but the way I found out about this issue was through a crash in
        IntRange::top(Type) when inlined into ReduceStrength::rangeFor(). We'd die in a switch
        statement over a child's type.
        
        We could fix this by making rangeFor() tolerate Void. But I think that this would be
        dangerous. There could easily be other places in reduceStrength() that assume that value's
        children are non-Void. So, this change fixes the Check optimization and adds mechanisms to
        prevent other optimizations from breaking the children-are-not-Void rule.
        
        This introduces two high-level changes:
        
        - It's no longer legal to replaceWithNop() if the value is not Void. This change alone
          would cause reduceStrength() to instacrash in its Check optimization. Almost all other
          uses of replaceWithNop() were already following this rule, so they were fine. One other
          place was using replaceWithNop() on non-Void values after arranging for them to no
          longer have any parents. That was changed to call replaceWithNopIgnoringType(), which
          doesn't have any type assertions.
        
        - For reduceStrength() there is a new Value::replaceWithBottom() method that works with
          Void or non-Void and behaves like you would want replaceWithNop() to behave: if you know
          that the code is unreachable then it produces something that is guaranteed to be deleted
          by later optimizations, and if it's not unreachable, then it's guaranteed to be compiled
          to something harmless and cheap. This means replacing the value with an identity that
          points to a bottom constant (the 0 for whatever type we have), or just replacing it with
          Nop if it's Void.
        
        This also adds a test case for the reason why we do this: we may have two blocks, where
        the first block unconditionally exits while dominating the second block. The second block
        references values in the part of the first block that is unreachable. In trunk, this test
        would assert in ReduceStrength::rangeFor() because the CheckAdd in the second block would
        reference a Nop in the first block.
        
        This fixes a high volume crash in ReduceStrength::rangeFor(). This crash was very
        confusing. Even though we were crashing at a RELEASE_ASSERT_NOT_REACHED() in a switch
        statement in IntRange::top(Type), clang was merging that trap with the trap it used for
        Vector OOB. The top of the stack in crash dumps looked like:
        
            JSC::B3::(anonymous namespace)::ReduceStrength::rangeFor(JSC::B3::Value*, unsigned int) + 4477 (Vector.h:655)
        
        Where Vector.h:655 is:
        
            OverflowHandler::overflowed();

        But this crash was not at Vector.h:655. It was at B3ReduceStrength.cpp:121. The two lines
        are both traps, so they got merged despite differences in debug info. This bug would have
        been so much easier to fix if I had the right line number.

        * b3/B3BottomProvider.h: Added. This is a utility for creating bottom values.
        (JSC::B3::BottomProvider::BottomProvider):
        (JSC::B3::BottomProvider::operator()):
        * b3/B3InsertionSet.cpp: Optimized adding bottom values a bit. We will no longer create pointless duplicates.
        (JSC::B3::InsertionSet::insertBottom):
        (JSC::B3::InsertionSet::execute):
        (JSC::B3::InsertionSet::bottomForType):
        * b3/B3InsertionSet.h:
        * b3/B3MoveConstants.cpp: Use replaceWithNopIgnoringType() because we *know* that we can replaceWithNop even for non-Void.
        * b3/B3Procedure.h:
        * b3/B3ReduceStrength.cpp: Use replaceWithBottom().
        * b3/B3ReduceStrength.h:
        * b3/B3TypeMap.h: I figured if I wrote type-casing code like this once then I'd never want to write it again.
        * b3/B3Value.cpp:
        (JSC::B3::Value::replaceWithIdentity):
        (JSC::B3::Value::replaceWithNop):
        (JSC::B3::Value::replaceWithNopIgnoringType):
        * b3/B3Value.h:
        * b3/B3ValueInlines.h:
        (JSC::B3::Value::replaceWithBottom): This is the new method of killing unreachable code.
        (JSC::B3::Value::as):
        * b3/testb3.cpp: Add new tests!
        (JSC::B3::testLateRegister):
        (JSC::B3::testReduceStrengthCheckBottomUseInAnotherBlock):
        (JSC::B3::zero):
        (JSC::B3::run):

2016-06-27  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION: Web Inspector: Text search broken in resources with <CR>
        https://bugs.webkit.org/show_bug.cgi?id=159110
        <rdar://problem/27008485>

        Reviewed by Brian Burg.

        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::lineEndings):
        The frontend moved to only treated newlines as line endings in
        the TextEditor. The backend however was looking for many
        different types of line endings (\r\n, \r, \n). This caused
        the line endings to ultimately differ between the frontend
        and the backend, so the frontend couldn't find the lines that
        the backend was claiming search results were on. Change the
        backend to only look for \n line endings.

2016-06-27  Brian Burg  <bburg@apple.com>

        Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
        https://bugs.webkit.org/show_bug.cgi?id=159075
        <rdar://problem/26094341>

        Reviewed by Timothy Hatcher.

        Move the asynchronous work to a task class that can be cancelled when the
        heap agent is reset, disabled or destroyed.

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
        (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection):
        (Inspector::SendGarbageCollectionEventsTask::reset):
        (Inspector::SendGarbageCollectionEventsTask::timerFired):
        Added. This holds onto GarbageCollectionData that needs to be sent asynchronously.
        It uses the RunLoop variant of Timer and can queue multiple collections to be sent.
        The data vector is guarded with a lock so that garbageCollected() can safely add
        collection data from a non-main thread while the main thread sends out events.

        (Inspector::InspectorHeapAgent::InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::disable):
        Reset the task when disabling or tearing down the agent so the timer doesn't fire after destruction.

        (Inspector::InspectorHeapAgent::didGarbageCollect):
        Add the collection data to the task, which will dispatch an event for it asynchronously.

        * inspector/agents/InspectorHeapAgent.h:

2016-06-27  Michael Saboff  <msaboff@apple.com>

        ES6 Change: Unify handling of RegExp CharacterClassEscapes \w and \W and Word Asserts \b and \B
        https://bugs.webkit.org/show_bug.cgi?id=158505

        Reviewed by Geoffrey Garen.

        This change makes it so that the CharacterClassEscape \w matches the inverse of
        \W and vice versa for unicode, ignore case RegExp's.

        Before this change, both /\w/ui and /\W/ui RegExp's would match the characters
        k, K, s, S, \u017f (Latin Small Letter Long S) and \u212a (Kelvin Sign).
        This was due to how the ES6 standard defined matching of character classes
        specifically that the abstract operation "Canonicalize()" is called for the
        character to be matched AND for the characters in the character class we are
        matching against.  This change is to make \W always be the inverse of \w.
        It is still the case that the characters that match against \w changes
        depending on a regular expression's flags.

        The only real changes occur for regular expressions with both the unicode and
        ignore case flags set.  Updated the character class generator to make 
        nonwordUnicodeIgnoreCaseChar not include k, K, s, S, \u017f and \u212a.
        Changed BytecodePattern.wordcharCharacterClass to use the correct
        word character class for the flags.  Simplfied character class set up in
        in the pattern to use m_pattern.wordUnicodeIgnoreCaseCharCharacterClass and
        invert as appropriate when unicode and ignore case are both set.

        * create_regex_tables:
        * yarr/YarrInterpreter.h:
        (JSC::Yarr::BytecodePattern::BytecodePattern):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass):

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

        DFGByteCodeParsing does not handle calling the Object constructor with no arguments correctly
        https://bugs.webkit.org/show_bug.cgi?id=159117
        <rdar://problem/26996781>

        Reviewed by Saam Barati.

        DFGByteCodeParsing always assumed there would be an argument to the Object constructor.
        This is clearly not always the case and we should be able to handle it.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        * tests/stress/indirect-call-object-constructor-with-no-arguments.js: Added.
        (let.foo.Object.test):

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

        B3 should die sooner if a Value has the wrong number of children
        https://bugs.webkit.org/show_bug.cgi?id=159108

        Reviewed by Mark Lam.
        
        I've been looking at a bug (rdar://problem/26500743) that's about a Vector OOB crash in
        ReduceStrength::rangeFor(). The only Vector accesses are to Value::m_children, and all of
        the accesses in rangeFor() are for child(0) or child(1) of binary arithmetic opcodes.
        Clearly those should never go out-of-bounds.
        
        Maybe we have horrible memory corruption. Or maybe some path creates a Value with the
        wrong number of children, and that path is not tested by any of our tests. This patch adds
        release assertions that will catch the latter.
        
        I've tested this a lot. It's not a regression on our benchmarks.

        * b3/B3Opcode.h:
        * b3/B3Value.cpp:
        (JSC::B3::Value::dumpMeta):
        (JSC::B3::Value::typeFor):
        (JSC::B3::Value::badOpcode):
        (JSC::B3::Value::checkOpcode): Deleted.
        * b3/B3Value.h:

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

        [JSC] Error prototypes are called on remote scripts.
        https://bugs.webkit.org/show_bug.cgi?id=52192

        Reviewed by Keith Miller.

        Added a sanitizedToString() to the Error instance object so that it can be used
        to get an error string without invoking getters and proxies.

        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::finishCreation):
        (JSC::ErrorInstance::sanitizedToString):
        * runtime/ErrorInstance.h:
        (JSC::ErrorInstance::createStructure):
        (JSC::ErrorInstance::runtimeTypeForCause):
        (JSC::ErrorInstance::clearRuntimeTypeForCause):

2016-06-24  Commit Queue  <commit-queue@webkit.org>

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

        Introduced memory corruption crashes (Requested by ap on
        #webkit).

        Reverted changeset:

        "Web Inspector: CRASH in backend at
        Inspector::HeapFrontendDispatcher::garbageCollected + 552 when
        closing frontend/inspected page"
        https://bugs.webkit.org/show_bug.cgi?id=159075
        http://trac.webkit.org/changeset/202443

2016-06-24  Brian Burg  <bburg@apple.com>

        Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
        https://bugs.webkit.org/show_bug.cgi?id=159075
        <rdar://problem/26094341>

        Reviewed by Joseph Pecoraro.

        Move the asynchronous work to a task class that can be cancelled when the
        heap agent is reset, disabled or destroyed.

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
        (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection):
        (Inspector::SendGarbageCollectionEventsTask::reset):
        (Inspector::SendGarbageCollectionEventsTask::timerFired):
        Added. This holds onto GarbageCollection objects that need to be sent asynchronously.
        It uses the RunLoop variant of Timer and can queue multiple pending objects to be sent.

        (Inspector::InspectorHeapAgent::InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::disable):
        Reset the task when disabling or tearing down the agent so the timer doesn't fire after destruction.

        (Inspector::InspectorHeapAgent::didGarbageCollect):
        Send the object to the task to be dispatched asynchronously.

        * inspector/agents/InspectorHeapAgent.h:

2016-06-24  Commit Queue  <commit-queue@webkit.org>

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

        Broke many JSC tests (Requested by ap on #webkit).

        Reverted changeset:

        "[JSC] Implement isFinite / isNaN in JS and make DFG ToNumber
        accept non number values"
        https://bugs.webkit.org/show_bug.cgi?id=154022
        http://trac.webkit.org/changeset/202413

2016-06-23  Benjamin Poulain  <bpoulain@apple.com>

        OOM Assertion failure in Array.prototype.toString
        https://bugs.webkit.org/show_bug.cgi?id=158793

        Reviewed by Saam Barati.

        JSString::create() taking a StringImpl was using a signed integer
        for the length of the string.
        The problem is StringImpl uses an unsigned integer. When a large string
        was passed to JSString, the signed integer would be negative and crash
        JSString.

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

2016-06-23  Joseph Pecoraro  <pecoraro@apple.com> and Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Implement isFinite / isNaN in JS and make DFG ToNumber accept non number values
        https://bugs.webkit.org/show_bug.cgi?id=154022

        Reviewed by Filip Pizlo.

        We aim at optimizing @toInteger operation.
        While it still has an unoptimized part[1], this patch should be a first step.

        We introduce the @toNumber builtin intrinsic operation.
        This converts the given value to the JS number by emitting op_to_number bytecode.
        Previously @toInteger called C++ @Number constructor for that purpose.

        And in DFG, op_to_number is converted to DFG ToNumber node.
        During DFG, we attempt to convert this to edge filtering and Identity, but if we fail,
        we just fall back to calling the C++ function.

        To utilize ToNumber in user-land side, we add a path attempting to convert Number constructor calls
        to ToNumber DFG nodes. This conversion is useful because `Number(value)` is used to convert a value to a number in JS.

        Before this patch, we emit simple edge filtering (NumberUse) instead of emitting DFG node like ToNumber for op_to_number.
        But emitting ToNumber is useful, because in the case of `Number(value)`, considering `value` may not be a number is reasonable.

        By leveraging @toNumber operation, we rewrite Number.{isFinite, isNaN}, global.{isFinite, isNaN} and @toInteger.

        ToNumber DFG node has a value profiling. This profiling is leveraged to determine the result number type of the ToNumber operation.
        This value profiling is provided from either NumberConstructor's call operation or op_to_number.

        The results (with the added performance tests) show that, while existing cases are performance neutral, the newly added cases gain the performance benefit.
        And ASMBench/n-body.c also shows stable ~2% progression.

        [1]: https://bugs.webkit.org/show_bug.cgi?id=153738

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinNames.h:
        * builtins/GlobalObject.js:
        (globalPrivate.isFinite):
        (globalPrivate.isNaN):
        (globalPrivate.toInteger): Deleted.
        (globalPrivate.toLength): Deleted.
        (globalPrivate.isDictionary): Deleted.
        (globalPrivate.speciesGetter): Deleted.
        (globalPrivate.speciesConstructor): Deleted.
        * builtins/GlobalOperations.js: Copied from Source/JavaScriptCore/builtins/GlobalObject.js.
        (globalPrivate.toInteger):
        (globalPrivate.toLength):
        (globalPrivate.isDictionary):
        (globalPrivate.speciesGetter):
        (globalPrivate.speciesConstructor):
        * builtins/NumberConstructor.js: Added.
        (isFinite):
        (isNaN):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finishCreation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitUnaryOp):
        (JSC::BytecodeGenerator::emitUnaryOpProfiled):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitToNumber):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_toNumber):
        (JSC::UnaryPlusNode::emitBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::parseBlock):
        We use `getPrediction()` to retrieve the heap prediction from the to_number bytecode.
        According to the benchmark results, choosing `getPredictionWithoutOSRExit()` causes performance regression (1.5%) in kraken stanford-crypto-aes.

        * 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):
        (JSC::DFG::FixupPhase::fixupToNumber):
        ToNumber tells its predicted type by its heap prediction. So the fixup phase need to consider about it.
        If the heap prediction is Int32, we should attempt to convert the child value to Int32.
        Without this, misc-bugs-847389-jpeg2000 in assorted tests poses 53% regression.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        Alway rely on the heap prediction.

        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        As of 64bit version, we carefully manage the register reuse. The largest difference between 32bit and 64bit is
        `branchIfNotNumber()` requires the temporary register. We should not use the result registers for that since
        it may be reuse the argument registers and it can break the argument registers before using them to call the operation.
        Currently, we allocate the additional temporary register for that scratch register.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        Reuse the argument register for the result if possible. And manually decrement the use count in the middle of the node.
        This is similar technique used in ToPrimitive. Typically, the child of ToNumber is only used by this ToNumber node since
        we would like to perform the type conversion onto this child node here. So this careful register reuse effectively removes
        the spills to call the operation. The example of the actually emitted code is the following.

        76:<!2:loc11>     ToNumber(Untyped:@68, JS|MustGen|UseAsOther, DoubleimpurenanTopEmpty, R:World, W:Heap, Exits, ClobbersExit, bc#48)  predicting DoubleimpurenanTopEmpty
            0x7f986d5fe693: test %rax, %r14
            0x7f986d5fe696: jz 0x7f986d5fe6a1
            0x7f986d5fe69c: jmp 0x7f986d5fe6d1
            0x7f986d5fe6a1: mov %rax, %rsi
            0x7f986d5fe6a4: mov %rbp, %rdi
            0x7f986d5fe6a7: mov $0x2, 0x24(%rbp)
            0x7f986d5fe6ae: mov $0x7f98711ea5f0, %r11
            0x7f986d5fe6b8: call *%r11
            0x7f986d5fe6bb: mov $0x7f982d3f72d0, %r11
            0x7f986d5fe6c5: mov (%r11), %r11
            0x7f986d5fe6c8: test %r11, %r11
            0x7f986d5fe6cb: jnz 0x7f986d5fe88c

        It effectively removes the unnecessary spill to call the operation!

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileToNumber):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfNumber):
        (JSC::AssemblyHelpers::branchIfNotNumber):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_to_number):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_to_number):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/Nodes.h:
        (JSC::UnaryOpNode::opcodeID):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncIsNaN): Deleted.
        (JSC::globalFuncIsFinite): Deleted.
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/MathCommon.h:
        (JSC::maxSafeInteger):
        (JSC::minSafeInteger):
        * runtime/NumberConstructor.cpp:
        (JSC::NumberConstructor::finishCreation):
        (JSC::numberConstructorFuncIsFinite): Deleted.
        (JSC::numberConstructorFuncIsNaN): Deleted.
        * runtime/NumberConstructor.h:
        * tests/stress/Number-isNaN-basics.js: Added.
        (numberIsNaNOnInteger):
        (testNumberIsNaNOnIntegers):
        (verifyNumberIsNaNOnIntegerWithOtherTypes):
        (numberIsNaNOnDouble):
        (testNumberIsNaNOnDoubles):
        (verifyNumberIsNaNOnDoublesWithOtherTypes):
        (numberIsNaNNoArguments):
        (numberIsNaNTooManyArguments):
        (testNumberIsNaNOnConstants):
        (numberIsNaNStructTransition):
        (Number.isNaN):
        * tests/stress/global-is-finite.js: Added.
        (shouldBe):
        * tests/stress/global-is-nan.js: Added.
        (shouldBe):
        * tests/stress/global-isNaN-basics.js: Added.
        (isNaNOnInteger):
        (testIsNaNOnIntegers):
        (verifyIsNaNOnIntegerWithOtherTypes):
        (isNaNOnDouble):
        (testIsNaNOnDoubles):
        (verifyIsNaNOnDoublesWithOtherTypes):
        (verifyIsNaNOnCoercedTypes):
        (isNaNNoArguments):
        (isNaNTooManyArguments):
        (testIsNaNOnConstants):
        (isNaNTypeCoercionSideEffects):
        (i.value.isNaNTypeCoercionSideEffects.valueOf):
        (isNaNStructTransition):
        (isNaN):
        * tests/stress/number-is-finite.js: Added.
        (shouldBe):
        (test2):
        (test3):
        * tests/stress/number-is-nan.js: Added.
        (shouldBe):
        (test2):
        (test3):
        * tests/stress/to-number-basics.js: Added.
        (shouldBe):
        * tests/stress/to-number-convert-identity-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        (valueOf):
        * tests/stress/to-number-int52.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-convert-to-identity-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        (valueOf):
        * tests/stress/to-number-intrinsic-int52.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-object-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-value-profiling.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-object-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-object.js: Added.
        (shouldBe):
        (test12):
        (object1.valueOf):
        (test2):
        (test22):
        (object2.valueOf):
        (test3):
        (test32):
        (object3.valueOf):
        * tests/stress/to-number-value-profiling.js: Added.
        (shouldBe):
        (object.valueOf):

2016-06-23  Saam Barati  <sbarati@apple.com>

        DFGSpeculativeJIT's m_slowPathLambdas should restore the current node field and DFG OSR entry functions should use DeferGCForAWhile instead of DeferGC
        https://bugs.webkit.org/show_bug.cgi?id=159064
        <rdar://problem/26599119>

        Reviewed by Filip Pizlo.

        The DFG has a list of m_slowPathLambdas that are code generators it emits
        amongst its slow paths. These lambdas, however, did not update the m_currentNode field.
        This caused us to use whatever Node happened to be used as the currentNode at the time
        we call the slowPathLambda. This means the wrong CallSiteIndex was stored into the call
        frame when we made a call. This may lead to a crash if the CallSiteIndex corresponds to
        the wrong CodeOrigin. For example, the wrong CodeOrigin could have an InlineCallFrame with
        a calleeRecovery that will not be in sync with the current stack state. Trying
        to recover that callee will often lead to a crash. The solution is to update
        m_currentNode to the DFG::Node* it corresponds to when emitting these slowPathLambdas.

        I found this bug because we were inside this bad state when calling an operation
        that happened to have a DeferGC. When this DeferGC actually GCed, it would
        take a StackTrace, which would lead to a crash because we were updating
        ShadowChicken with vm.topCallFrame. It just so happened that the CallSiteIndex
        in the call frame in this program corresponded to an InlineCallFrame with a calleeRecover.
        However, this CallSiteIndex didn't correspond to the actual state of execution
        of the program. I'm adding new options to make reproducing DeferGC related
        bugs easier by making DeferGC force a GC according to some probability. To
        always have DeferGC force a GC, you can set that probability to 1.

        There is a second bug that I discovered after solving the above bug. We were
        using DeferGC instead of DeferGCForAWhile in the OSR entry related functions
        in the DFG. This would cause us to take a stack trace when the call frame was
        in an inconsistent state. For example, the operation would call FTL::prepareOSREntry,
        which would replace the DFG CodeBlock in the call frame with the FTL CodeBlock.
        However, we wouldn't update the CallSiteIndex to correspond to an FTL CallSiteIndex.
        This would lead to a crash when taking a stack trace. The solution is to prevent
        stack traces from being taken when the program is in this state by using
        DeferGCForAWhie instead of DeferGC.

        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
        (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
        * dfg/DFGSpeculativeJIT.h:
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::collectIfNecessaryOrDefer):
        (JSC::Heap::collectAccordingToDeferGCProbability):
        (JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
        (JSC::Heap::markListSet):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        (JSC::Options::initialize):
        * runtime/Options.h:
        * tests/stress/slow-path-generator-updating-current-node-dfg.js: Added.
        (foo):
        (bar):

2016-06-23  Filip Pizlo  <fpizlo@apple.com>

        Failing baseline JIT compilation of a code block and then trying to compile it from OSR from DFG/FTL will corrupt the CodeBlock
        https://bugs.webkit.org/show_bug.cgi?id=158806

        Reviewed by Saam Barati.
        
        If we try to compile a CodeBlock that we already tried compiling in the past then we need
        to clean up the data structures that were partly filled in by the failed compile. That
        causes some races, since the DFG may be trying to parse those data structures while we are
        clearing them. This patch introduces such a clean-up (CodeBlock::resetJITData()) and fixes
        the races.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::getStubInfoMap):
        (JSC::CodeBlock::getCallLinkInfoMap):
        (JSC::CodeBlock::getByValInfoMap):
        (JSC::CodeBlock::getCallLinkInfoForBytecodeIndex):
        (JSC::CodeBlock::resetJITData):
        (JSC::CodeBlock::visitOSRExitTargets):
        (JSC::CodeBlock::setSteppingMode):
        (JSC::CodeBlock::addRareCaseProfile):
        (JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
        (JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
        (JSC::CodeBlock::resultProfileForBytecodeOffset):
        (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
        (JSC::CodeBlock::couldTakeSpecialFastCase):
        (JSC::CodeBlock::ensureResultProfile):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::getFromAllValueProfiles):
        (JSC::CodeBlock::numberOfRareCaseProfiles):
        (JSC::CodeBlock::numberOfResultProfiles):
        (JSC::CodeBlock::numberOfArrayProfiles):
        (JSC::CodeBlock::arrayProfiles):
        (JSC::CodeBlock::addRareCaseProfile): Deleted.
        (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset): Deleted.
        (JSC::CodeBlock::couldTakeSpecialFastCase): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::makeSafe):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        * jit/JIT.cpp:
        (JSC::JIT::link):
        * jit/JITWorklist.cpp:
        (JSC::JITWorklist::compileNow):

2016-06-23  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Memory Timeline sometimes shows impossible value for bmalloc size (underflowed)
        https://bugs.webkit.org/show_bug.cgi?id=158110
        <rdar://problem/26498584>

        Reviewed by Andreas Kling.

        * heap/Heap.cpp:
        (JSC::Heap::willStartCollection):
        (JSC::Heap::didFinishCollection):
        * heap/Heap.h:
        (JSC::Heap::externalMemorySize):
        * heap/HeapInlines.h:
        (JSC::Heap::reportExternalMemoryVisited):
        Keep count of external memory we visit.

        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::reportExternalMemoryVisited):
        Report external memory visited like we do extra memory, since
        it will be some subset of extra memory that is external.

2016-06-23  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Snapshots should be cleared at some point
        https://bugs.webkit.org/show_bug.cgi?id=157907
        <rdar://problem/26373610>

        Reviewed by Timothy Hatcher.

        * heap/HeapSnapshotBuilder.h:
        * heap/HeapSnapshotBuilder.cpp:
        (JSC::HeapSnapshotBuilder::resetNextAvailableObjectIdentifier):
        Provide a way to reset the object identifier counter.

        * inspector/agents/InspectorHeapAgent.h:
        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::clearHeapSnapshots):
        Make clearHeapSnapshots protected, so it can be called from a
        a PageHeapAgent on page navigations.

2016-06-22  Saam barati  <sbarati@apple.com>

        TypeProfiler and TypeProfilerLog don't play nicely with the concurrent JIT
        https://bugs.webkit.org/show_bug.cgi?id=159037
        <rdar://problem/26935349>

        Reviewed by Benjamin Poulain.

        The primary focus of this patch is to make the concurrent
        baseline JIT work with the type profiler. We were clearing
        the type profiler log on the background baseline compiler
        thread which lead to bad things happening. This patch fixes
        this by processing the log before we launch the compile on
        a background thread.

        Secondly, I audited the type profiler code inside the DFG,
        and found that we were doing some racy things. I haven't
        seen any crashes because of these things, but it is possible
        that they exist. We were grabbing a RefPtr to a TypeSet,
        even though TypeSet was RefCounted and not ThreadSafeRefCounted.
        This patch makes TypeSet ThreadSafeRefCounted. We were
        also copying a StructureSet while the execution thread could
        be augmenting the StructureSet. This patch puts changes to 
        TypeSet's StructureSet behind a ConcurrentJITLock.

        I've also added two more large running tests that run with the
        type profiler enabled. These are here just to catch any major bugs
        in the type profiler implementation.

        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        (JSC::JIT::privateCompile):
        (JSC::JIT::privateCompileExceptionHandlers):
        (JSC::JIT::doMainThreadPreparationBeforeCompile):
        (JSC::JIT::frameRegisterCountFor):
        * jit/JIT.h:
        (JSC::JIT::compile):
        * jit/JITWorklist.cpp:
        (JSC::JITWorklist::Plan::Plan):
        (JSC::JITWorklist::Plan::compileInThread):
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::addTypeInformation):
        (JSC::TypeSet::invalidateCache):
        * runtime/TypeSet.h:
        (JSC::TypeSet::create):
        (JSC::TypeSet::isEmpty):
        (JSC::TypeSet::seenTypes):
        (JSC::TypeSet::structureSet):
        * tests/typeProfiler/deltablue-for-of.js: Added.
        * tests/typeProfiler/getter-richards.js: Added.

2016-06-22  Keith Miller  <keith_miller@apple.com>

        We should have a DFG intrinsic that checks if a value is a TypedArrayView
        https://bugs.webkit.org/show_bug.cgi?id=159048

        Reviewed by Saam Barati.

        This patch adds a new DFG Intrinsic that checks if a value is a TypedArrayView.
        The intrinsic, IsTypedArrayView, works in the same way that the other Is<insert-type>
        DFG nodes work. Additionally, a new builtin function isTypedArrayView has been added.
        These changes are needed to fix regressions in %TypedArray%.prototype.subarray.

        * builtins/BuiltinNames.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * 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:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileIsTypedArrayView):
        * 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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsTypedArrayView):
        (JSC::FTL::DFG::LowerDFGToB3::isTypedArrayView):
        * runtime/Intrinsic.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewPrivateFuncIsTypedArrayView):
        * runtime/JSTypedArrayViewPrototype.h:
        * tests/stress/istypedarrayview-intrinsic.js: Added.
        (makeFn):
        (typedArrays.forEach):
        (let.test):
        (test):

2016-06-21  Anders Carlsson  <andersca@apple.com>

        Fix build.

        * Configurations/FeatureDefines.xcconfig:

2016-06-21  Geoffrey Garen  <ggaren@apple.com>

        Options::useImmortalObjects is not safe for conservative GC
        https://bugs.webkit.org/show_bug.cgi?id=158999

        Reviewed by Geoffrey Garen.

        useImmortalObjects set the mark bit to keep an object from being
        reallocated. This had the negative side-effect of convincing the
        conservative marker that the object was a valid and live cell, which
        would cause us to visit garbage.

        * heap/Heap.cpp:
        (JSC::Heap::didFinishCollection):
        (JSC::Heap::resumeCompilerThreads):
        (JSC::Heap::setFullActivityCallback):
        (JSC::Heap::markDeadObjects): Deleted.
        * heap/Heap.h: Don't set the mark bit on a dead object. That's a bug in
        a conservative GC.

        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::retire): New helper.

        (JSC::MarkedAllocator::reset): Automatically retire old blocks when
        we're doing the immortal objects thing. This has the effect of
        preserving memory for debugging because we never recycle a previously
        allocated block.

2016-06-21  Anders Carlsson  <andersca@apple.com>

        Begin moving the Apple Pay code to the open source repository
        https://bugs.webkit.org/show_bug.cgi?id=158998

        Reviewed by Tim Horton.

        * Configurations/FeatureDefines.xcconfig:
        Add ENABLE_APPLE_PAY.

2016-06-21  Saam Barati  <sbarati@apple.com>

        CodeBlock::shrinkToFit is racy
        https://bugs.webkit.org/show_bug.cgi?id=158994
        <rdar://problem/26920212>

        Reviewed by Filip Pizlo.

        To see why this is racy, consider the following scenario:
        - CodeBlock A is link()ing its baseline compile.
        - CodeBlock B is inlining A, and asks A for a result profile in DFGBytecodeParser.
        - The race occurs when the link() step of the baseline compile calls shrinkToFit
          on its m_resultProfiles field without grabbing a lock. This leads to a bad
          time because the DFG compile will be reading from that vector as it's getting
          changed by the baseline link() method.

        This race has always existed, though the move to a concurrent baseline
        JIT has made it more likely to occur. The solution is to have CodeBlock::shrinkToFit
        grab its lock before shrinking the vector.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::shrinkToFit):

2016-06-21  David Kilzer  <ddkilzer@apple.com>

        Migrate testair & testb3 settings from Xcode project to ToolExecutable.xcconfig
        <https://webkit.org/b/158989>

        Reviewed by Andy Estes.

        * Configurations/ToolExecutable.xcconfig:
        (CODE_SIGN_ENTITLEMENTS_ios_testair): Add from Xcode project.
        * JavaScriptCore.xcodeproj/project.pbxproj:
        (CODE_SIGN_ENTITLEMENTS_ios_testair): Move to
        ToolExecutable.xcconfig.
        (PRODUCT_NAME): Remove.  This variable is already set for both
        testair and testb3 since those build configurations use
        ToolExecutable.xcconfig as a base.

2016-06-21  Saam Barati  <sbarati@apple.com>

        LLInt doesn't throw stack exception overflow from parent frame
        https://bugs.webkit.org/show_bug.cgi?id=158962
        <rdar://problem/26902188>

        Reviewed by Filip Pizlo.

        All JIT tiers will throw stack overflow exceptions from the parent frame.
        The LLInt, on the other hand, did not use to. I've changed the LLInt to be
        consistent with the JITs. The reason I found this bug is because we had a
        test that would give different results depending on if the function was compiled
        in the baseline or the LLInt. Since Filip recently landed the concurrent baseline
        JIT patch, this otherwise deterministic test became dependent on it being compiled
        in the LLInt or one of the JIT tiers. I've added a new test that is deterministic
        because it runs the test with --useJIT=false.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * tests/stress/llint-stack-overflow-location.js: Added.
        (stackTraceDescription):
        (foo):
        (catch):

2016-06-21  David Kilzer  <ddkilzer@apple.com>

        CODE_SIGN_ENTITLEMENTS should be applied to iOS Simulator builds
        <https://webkit.org/b/158990>
        <rdar://problem/26906273>

        Reviewed by Dan Bernstein.

        * Configurations/JSC.xcconfig:
        (CODE_SIGN_ENTITLEMENTS): Change [sdk=iphoneos*] to
        [sdk=iphone*] to apply setting to iOS Simulator as well.
        * Configurations/ToolExecutable.xcconfig:
        (CODE_SIGN_ENTITLEMENTS): Ditto.

2016-06-21  Keith Miller  <keith_miller@apple.com>

        It should be easy to add a private global helper function for builtins
        https://bugs.webkit.org/show_bug.cgi?id=158893

        Reviewed by Mark Lam.

        This patch does two things. First it moves all the builtin names
        out of CommonIdentifiers and into BuiltinNames. This means that
        adding a new function to the Builtins does not require rebuilding
        all of JavaScriptCore. This patch also adds a new decorator to our
        builtins @privateGlobal that will automatically put the function
        on the global object. The name of the property will be the same as
        the private name of the function.

        This patch, also, removes the JSArrayIterator.h/.cpp files
        as they no longer appear to be used in any real way. Finally,
        the builtins tests have been rebaselined. It appears this has
        not been done for a while so the expected files contain other
        changes.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/builtins/builtins_generate_combined_header.py:
        (BuiltinsCombinedHeaderGenerator.generate_output):
        (generate_section_for_code_name_macro):
        (generate_section_for_global_private_code_name_macro):
        * Scripts/builtins/builtins_model.py:
        (BuiltinFunction.__init__):
        (BuiltinFunction.fromString):
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
        * builtins/ArrayIteratorPrototype.js:
        * builtins/ArrayPrototype.js:
        * builtins/BuiltinNames.h:
        * builtins/GeneratorPrototype.js:
        * builtins/GlobalObject.js:
        * builtins/PromiseOperations.js:
        * builtins/RegExpPrototype.js:
        * builtins/StringPrototype.js:
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::expectedFunctionForIdentifier):
        (JSC::BytecodeGenerator::emitGetTemplateObject):
        (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitGeneratorStateChange):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::emitHomeObjectForCallee):
        (JSC::emitPutHomeObject):
        (JSC::FunctionNode::emitBytecode):
        * dfg/DFGOperations.cpp:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        (Inspector::JSInjectedScriptHost::getInternalProperties): Deleted.
        * parser/Lexer.cpp:
        (JSC::Lexer<LChar>::parseIdentifier):
        (JSC::Lexer<UChar>::parseIdentifier):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::createGeneratorParameters):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        * runtime/ArrayIteratorPrototype.cpp:
        * runtime/ArrayIteratorPrototype.h:
        * runtime/ArrayPrototype.cpp:
        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::CommonIdentifiers): Deleted.
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/IntlDateTimeFormat.cpp:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
        * runtime/IntlObjectInlines.h:
        (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
        * runtime/JSArrayIterator.cpp: Removed.
        (JSC::JSArrayIterator::finishCreation): Deleted.
        (JSC::JSArrayIterator::kind): Deleted.
        (JSC::JSArrayIterator::iteratedValue): Deleted.
        * runtime/JSArrayIterator.h: Removed.
        (JSC::JSArrayIterator::createStructure): Deleted.
        (JSC::JSArrayIterator::create): Deleted.
        (JSC::JSArrayIterator::JSArrayIterator): Deleted.
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSInternalPromise.cpp:
        * runtime/JSInternalPromiseDeferred.cpp:
        (JSC::JSInternalPromiseDeferred::create):
        * runtime/JSPromise.cpp:
        (JSC::JSPromise::finishCreation):
        (JSC::JSPromise::result):
        * runtime/JSPromiseDeferred.cpp:
        (JSC::JSPromiseDeferred::create):
        * runtime/JSStringIterator.cpp:
        (JSC::JSStringIterator::finishCreation):
        (JSC::JSStringIterator::iteratedValue):
        (JSC::JSStringIterator::clone):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        * runtime/ReflectObject.cpp:
        (JSC::ReflectObject::finishCreation):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        * runtime/TypedArrayInlines.h:

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

        [JSC] Use bytecode intrinsic to expose Module's loading status to builtin JS
        https://bugs.webkit.org/show_bug.cgi?id=158871

        Reviewed by Sam Weinig.

        Now JSC has bytecode intrinsic system. Use it instead of exposing status values through the loader's properties.

        * builtins/ModuleLoaderObject.js:
        (newRegistryEntry):
        (fulfillFetch):
        (fulfillTranslate):
        (commitInstantiated):
        (requestFetch):
        (requestTranslate):
        (requestInstantiate):
        (requestResolveDependencies.):
        (requestResolveDependencies):
        (requestLink):
        (link):
        (provide):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * runtime/ModuleLoaderObject.cpp:
        (JSC::ModuleLoaderObject::finishCreation): Deleted.

2016-06-20  Commit Queue  <commit-queue@webkit.org>

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

        breaks builds on the simulator (Requested by keith_mi_ on
        #webkit).

        Reverted changeset:

        "It should be easy to add a private global helper function for
        builtins"
        https://bugs.webkit.org/show_bug.cgi?id=158893
        http://trac.webkit.org/changeset/202248

2016-06-20  Keith Miller  <keith_miller@apple.com>

        It should be easy to add a private global helper function for builtins
        https://bugs.webkit.org/show_bug.cgi?id=158893

        Reviewed by Mark Lam.

        This patch does two things. First it moves all the builtin names
        out of CommonIdentifiers and into BuiltinNames. This means that
        adding a new function to the Builtins does not require rebuilding
        all of JavaScriptCore. This patch also adds a new decorator to our
        builtins @privateGlobal that will automatically put the function
        on the global object. The name of the property will be the same as
        the private name of the function.

        This patch, also, removes the JSArrayIterator.h/.cpp files
        as they no longer appear to be used in any real way. Finally,
        the builtins tests have been rebaselined. It appears this has
        not been done for a while so the expected files contain other
        changes.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/builtins/builtins_generate_combined_header.py:
        (BuiltinsCombinedHeaderGenerator.generate_output):
        (generate_section_for_code_name_macro):
        (generate_section_for_global_private_code_name_macro):
        * Scripts/builtins/builtins_model.py:
        (BuiltinFunction.__init__):
        (BuiltinFunction.fromString):
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
        * builtins/ArrayIteratorPrototype.js:
        * builtins/ArrayPrototype.js:
        * builtins/BuiltinNames.h:
        * builtins/GeneratorPrototype.js:
        * builtins/GlobalObject.js:
        * builtins/PromiseOperations.js:
        * builtins/RegExpPrototype.js:
        * builtins/StringPrototype.js:
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::expectedFunctionForIdentifier):
        (JSC::BytecodeGenerator::emitGetTemplateObject):
        (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitGeneratorStateChange):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::emitHomeObjectForCallee):
        (JSC::emitPutHomeObject):
        (JSC::FunctionNode::emitBytecode):
        * dfg/DFGOperations.cpp:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        (Inspector::JSInjectedScriptHost::getInternalProperties): Deleted.
        * parser/Lexer.cpp:
        (JSC::Lexer<LChar>::parseIdentifier):
        (JSC::Lexer<UChar>::parseIdentifier):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::createGeneratorParameters):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        * runtime/ArrayIteratorPrototype.cpp:
        * runtime/ArrayIteratorPrototype.h:
        * runtime/ArrayPrototype.cpp:
        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::CommonIdentifiers): Deleted.
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/IntlDateTimeFormat.cpp:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
        * runtime/IntlObjectInlines.h:
        (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
        * runtime/JSArrayIterator.cpp: Removed.
        (JSC::JSArrayIterator::finishCreation): Deleted.
        (JSC::JSArrayIterator::kind): Deleted.
        (JSC::JSArrayIterator::iteratedValue): Deleted.
        * runtime/JSArrayIterator.h: Removed.
        (JSC::JSArrayIterator::createStructure): Deleted.
        (JSC::JSArrayIterator::create): Deleted.
        (JSC::JSArrayIterator::JSArrayIterator): Deleted.
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSInternalPromise.cpp:
        * runtime/JSInternalPromiseDeferred.cpp:
        (JSC::JSInternalPromiseDeferred::create):
        * runtime/JSPromise.cpp:
        (JSC::JSPromise::finishCreation):
        (JSC::JSPromise::result):
        * runtime/JSPromiseDeferred.cpp:
        (JSC::JSPromiseDeferred::create):
        * runtime/JSStringIterator.cpp:
        (JSC::JSStringIterator::finishCreation):
        (JSC::JSStringIterator::iteratedValue):
        (JSC::JSStringIterator::clone):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        * runtime/ReflectObject.cpp:
        (JSC::ReflectObject::finishCreation):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        * runtime/TypedArrayInlines.h:

2016-06-20  Filip Pizlo  <fpizlo@apple.com>

        LLInt64 Float64 get_by_val doesn't purify NaN
        https://bugs.webkit.org/show_bug.cgi?id=158956

        Reviewed by Michael Saboff.

        * llint/LowLevelInterpreter64.asm: Fix the bug.
        * tests/stress/float64-array-nan-inlined.js: Make this test also run in LLInt-only mode to catch this bug.

2016-06-20  Keith Rollin  <krollin@apple.com>

        Remove RefPtr::release() and change calls sites to use WTFMove()
        https://bugs.webkit.org/show_bug.cgi?id=158369

        Reviewed by Chris Dumez.

        RefPtr::release() releases its managed pointer awkwardly. It's more
        direct and clearer to use WTFMove to transfer ownership of the managed
        pointer.

        As part of this cleanup, also change a lot of explicit data types to
        'auto'.

        * API/JSObjectRef.cpp:
        (JSClassCreate):
        * API/JSScriptRef.cpp:
        * API/JSValueRef.cpp:
        (JSValueToStringCopy):
        * bytecompiler/StaticPropertyAnalyzer.h:
        (JSC::StaticPropertyAnalyzer::newObject):
        (JSC::StaticPropertyAnalyzer::mov):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::invalidate):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * inspector/InspectorValues.cpp:
        (Inspector::InspectorValue::parseJSON):
        * inspector/agents/InspectorAgent.cpp:
        (Inspector::InspectorAgent::activateExtraDomain):
        (Inspector::InspectorAgent::activateExtraDomains):
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::receivedSetupMessage):
        * jit/Repatch.cpp:
        (JSC::linkPolymorphicCall):
        * runtime/GenericTypedArrayViewInlines.h:
        (JSC::GenericTypedArrayView<Adaptor>::create):
        (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::constructArrayBuffer):
        * runtime/PropertyNameArray.h:
        (JSC::PropertyNameArray::releaseData):
        * runtime/Structure.cpp:
        (JSC::Structure::toStructureShape):
        * runtime/TypeSet.cpp:
        (JSC::StructureShape::merge):
        * tools/FunctionOverrides.cpp:
        (JSC::initializeOverrideInfo):

2016-06-20  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: console.profile should use the new Sampling Profiler
        https://bugs.webkit.org/show_bug.cgi?id=153499
        <rdar://problem/24352431>

        Reviewed by Timothy Hatcher.

        Currently console.profile/profileEnd behave slightly differently
        between JSContext and Web inspection. Unifying will be part of:
        <https://webkit.org/b/158753> Generalize the concept of Instruments on the backend

        Both JSContext and Web inspection keep track of active
        profiles started and stopped via console.profile/profileEnd.

        JSContext inspection sends its programmatic start/stop
        via the ScriptProfiler domain.

        Web inspection sends its programmatic start/stop
        via the Timeline domain, and also will start/stop backend
        list of Instruments.

        The functional differences between these is that for JSContext
        inspection, console.profile only starts/stops the ScriptProfiler
        domain, and does not auto-start other instruments. This isn't really
        a problem right now given the instruments available for JSContext
        inspection; but it will be nice to unify as we add more instruments.
        Also, JSContext inspection won't have "Profile (name)" records in
        its Events view, since those are currently generated only by the
        Web's Timeline domain.

        * inspector/protocol/ScriptProfiler.json:
        * inspector/protocol/Timeline.json:
        Events to inform the frontend of programmatic start/stop.

        * debugger/Debugger.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::breakpointsActive):
        (Inspector::InspectorDebuggerAgent::isPaused):
        * inspector/agents/InspectorDebuggerAgent.h:
        Expose breakpoints active state, since programmatic recording
        will temporarily disabled breakpoints if needed.

        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
        (Inspector::JSGlobalObjectConsoleClient::profile):
        (Inspector::JSGlobalObjectConsoleClient::profileEnd):
        (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
        (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
        * inspector/JSGlobalObjectConsoleClient.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted):
        (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped):
        * inspector/agents/InspectorScriptProfilerAgent.h:
        JSContext implementation of console.profile/profileEnd.

2016-06-19  Saam Barati  <sbarati@apple.com>

        We should be able to generate more types of ICs inline
        https://bugs.webkit.org/show_bug.cgi?id=158719
        <rdar://problem/26825641>

        Reviewed by Filip Pizlo.

        This patch changes how we emit code for *byId ICs inline.
        We no longer keep data labels to patch structure checks, etc.
        Instead, we just regenerate the entire IC into a designated
        region of code that the Baseline/DFG/FTL JIT will emit inline.
        This makes it much simpler to patch inline ICs. All that's
        needed to patch an inline IC is to memcpy the code from
        a macro assembler inline using LinkBuffer. This architecture
        will be easy to extend into other forms of ICs, such as one
        for add, in the future.

        To support this change, I've reworked the fields inside
        StructureStubInfo. It now has one field that is the CodeLocationLabel 
        of the start of the inline IC. Then it has a few ints that track deltas
        to other locations in the IC such as the slow path start, slow path call, the
        ICs 'done' location. We used to perform math on these ints in a bunch of different
        places. I've consolidated that math into methods inside StructureStubInfo.

        To generate inline ICs, I've implemented a new class called InlineAccess.
        InlineAccess is stateless: it just has a bunch of static methods for
        generating code into the inline region specified by StructureStubInfo.
        Repatch will now decide when it wants to generate such an inline
        IC, and it will ask InlineAccess to do so.

        I've implemented three types of inline ICs to begin with (extending
        this in the future should be easy):
        - Self property loads (both inline and out of line offsets).
        - Self property replace (both inline and out of line offsets).
        - Array length on specific array types.
        (An easy extension would be to implement JSString length.)

        To know how much inline space to reserve, I've implemented a
        method that stubs out the various inline cache shapes and 
        dumps their size. This is used to determine how much space
        to save inline. When InlineAccess ends up generating more
        code than can fit inline, we will fall back to generating
        code with PolymorphicAccess instead.

        To make generating code into already allocated executable memory
        efficient, I've made AssemblerData have 128 bytes of inline storage.
        This saves us a malloc when splatting code into the inline region.

        This patch also tidies up LinkBuffer's API for generating
        into already allocated executable memory. Now, when generating
        code that has less size than the already allocated space, LinkBuffer
        will fill the extra space with nops. Also, if branch compaction shrinks
        the code, LinkBuffer will add a nop sled at the end of the shrunken
        code to take up the entire allocated size.

        This looks like it could be a 1% octane progression.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::nop):
        (JSC::ARM64Assembler::fillNops):
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::nopw):
        (JSC::ARMv7Assembler::nopPseudo16):
        (JSC::ARMv7Assembler::nopPseudo32):
        (JSC::ARMv7Assembler::fillNops):
        (JSC::ARMv7Assembler::dmbSY):
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::addLinkTask):
        (JSC::AbstractMacroAssembler::emitNops):
        (JSC::AbstractMacroAssembler::AbstractMacroAssembler):
        * assembler/AssemblerBuffer.h:
        (JSC::AssemblerData::AssemblerData):
        (JSC::AssemblerData::operator=):
        (JSC::AssemblerData::~AssemblerData):
        (JSC::AssemblerData::buffer):
        (JSC::AssemblerData::grow):
        (JSC::AssemblerData::isInlineBuffer):
        (JSC::AssemblerBuffer::AssemblerBuffer):
        (JSC::AssemblerBuffer::ensureSpace):
        (JSC::AssemblerBuffer::codeSize):
        (JSC::AssemblerBuffer::setCodeSize):
        (JSC::AssemblerBuffer::label):
        (JSC::AssemblerBuffer::debugOffset):
        (JSC::AssemblerBuffer::releaseAssemblerData):
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::copyCompactAndLinkCode):
        (JSC::LinkBuffer::linkCode):
        (JSC::LinkBuffer::allocate):
        (JSC::LinkBuffer::performFinalization):
        (JSC::LinkBuffer::shrink): Deleted.
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::LinkBuffer):
        (JSC::LinkBuffer::debugAddress):
        (JSC::LinkBuffer::size):
        (JSC::LinkBuffer::wasAlreadyDisassembled):
        (JSC::LinkBuffer::didAlreadyDisassemble):
        (JSC::LinkBuffer::applyOffset):
        (JSC::LinkBuffer::code):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::patchableBranch32):
        (JSC::MacroAssemblerARM64::patchableBranch64):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::patchableBranch32):
        (JSC::MacroAssemblerARMv7::patchableBranchPtrWithPatch):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::nop):
        (JSC::X86Assembler::fillNops):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdCacheStatus):
        * bytecode/InlineAccess.cpp: Added.
        (JSC::InlineAccess::dumpCacheSizesAndCrash):
        (JSC::linkCodeInline):
        (JSC::InlineAccess::generateSelfPropertyAccess):
        (JSC::getScratchRegister):
        (JSC::hasFreeRegister):
        (JSC::InlineAccess::canGenerateSelfPropertyReplace):
        (JSC::InlineAccess::generateSelfPropertyReplace):
        (JSC::InlineAccess::isCacheableArrayLength):
        (JSC::InlineAccess::generateArrayLength):
        (JSC::InlineAccess::rewireStubAsJump):
        * bytecode/InlineAccess.h: Added.
        (JSC::InlineAccess::sizeForPropertyAccess):
        (JSC::InlineAccess::sizeForPropertyReplace):
        (JSC::InlineAccess::sizeForLengthAccess):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::initGetByIdSelf):
        (JSC::StructureStubInfo::initArrayLength):
        (JSC::StructureStubInfo::initPutByIdReplace):
        (JSC::StructureStubInfo::deref):
        (JSC::StructureStubInfo::aboutToDie):
        (JSC::StructureStubInfo::propagateTransitions):
        (JSC::StructureStubInfo::containsPC):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::considerCaching):
        (JSC::StructureStubInfo::slowPathCallLocation):
        (JSC::StructureStubInfo::doneLocation):
        (JSC::StructureStubInfo::slowPathStartLocation):
        (JSC::StructureStubInfo::patchableJumpForIn):
        (JSC::StructureStubInfo::valueRegs):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):
        (JSC::FTL::DFG::LowerDFGToB3::getById):
        * jit/JITInlineCacheGenerator.cpp:
        (JSC::JITByIdGenerator::finalize):
        (JSC::JITByIdGenerator::generateFastCommon):
        (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
        (JSC::JITGetByIdGenerator::generateFastPath):
        (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
        (JSC::JITPutByIdGenerator::generateFastPath):
        (JSC::JITPutByIdGenerator::slowPathFunction):
        (JSC::JITByIdGenerator::generateFastPathChecks): Deleted.
        * jit/JITInlineCacheGenerator.h:
        (JSC::JITByIdGenerator::reportSlowPathCall):
        (JSC::JITByIdGenerator::slowPathBegin):
        (JSC::JITByIdGenerator::slowPathJump):
        (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emit_op_try_get_by_id):
        (JSC::JIT::emit_op_get_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emit_op_try_get_by_id):
        (JSC::JIT::emit_op_get_by_id):
        * jit/Repatch.cpp:
        (JSC::repatchCall):
        (JSC::tryCacheGetByID):
        (JSC::repatchGetByID):
        (JSC::appropriateGenericPutByIdFunction):
        (JSC::tryCachePutByID):
        (JSC::repatchPutByID):
        (JSC::tryRepatchIn):
        (JSC::repatchIn):
        (JSC::linkSlowFor):
        (JSC::resetGetByID):
        (JSC::resetPutByID):
        (JSC::resetIn):
        (JSC::repatchByIdSelfAccess): Deleted.
        (JSC::resetGetByIDCheckAndLoad): Deleted.
        (JSC::resetPutByIDCheckAndLoad): Deleted.
        (JSC::replaceWithJump): Deleted.

2016-06-19  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(concurrent baseline JIT): Kraken/ai-astar runs 20% slower
        https://bugs.webkit.org/show_bug.cgi?id=158906

        Reviewed by Benjamin Poulain.
        
        The concurrent baseline JIT was a 2-3% progression on JSBench, possibly a 1% progression
        on PLT3, but a 2-5% regression on Kraken. This patch fixes the Kraken regression without
        affecting the other tests.
        
        The problem is that Kraken/ai-astar's initialization code had a ginormous piece of init
        code that took about 16ms to compile in baseline. There's no good way to avoid letting it
        tier-up into baseline since it has a compute loop. The time it takes to run this code is
        never measured. The concurrent baseline JIT caused us to schedule the compilation of this
        huge code rather than doing it eagerly. This meant that after initialization was done and
        we started actually running real stuff, all of the real stuff's compiles would be convoyed
        behind this super-expensive baseline compile. Note that DFG and FTL compiles convoy behind
        baseline compiles, since you can't schedule a DFG compile for a code block until that code
        block is in baseline.
        
        This uses the simplest fix: if we are thinking about scheduling some compile and the
        thread is busy, do the compile on the main thread instead. This doesn't completely
        eliminate the ai-astar regression (we still have a 4% regression on that test) but it now
        results in concurrent baseline JIT being an overall progression on Kraken as a whole (1%
        on my machine). This is because concurrent baseline appears to help on other tests.

        In the future, we could fix this even better by allowing the JITWorklist to spawn more
        threads or by being smarter about baseline compilation. I think it's nasty that if a giant
        piece of initialization code ends in a compute loop, we compile all of the code instead of
        just the loop. It's also gross that a constant-like object creation expression will result
        in so much code. It would result in less code if we allowed ourselves to do a bit more
        static reasoning about object literals.
        
        But for now, I think that this is a great way to recover the Kraken regression while still
        keeping the other progressions from concurrent baseline.

        * jit/JITWorklist.cpp:
        (JSC::JITWorklist::Plan::Plan):
        (JSC::JITWorklist::Plan::compileInThread):
        (JSC::JITWorklist::Plan::finalize):
        (JSC::JITWorklist::Plan::codeBlock):
        (JSC::JITWorklist::Plan::isFinishedCompiling):
        (JSC::JITWorklist::Plan::compileNow):
        (JSC::JITWorklist::JITWorklist):
        (JSC::JITWorklist::compileLater):
        (JSC::JITWorklist::compileNow):
        (JSC::JITWorklist::runThread):
        (JSC::JITWorklist::Plan::isFinalized): Deleted.
        * jit/JITWorklist.h:

2016-06-17  Commit Queue  <commit-queue@webkit.org>

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

        The new test is very unstable, timing out frequently
        (Requested by ap on #webkit).

        Reverted changeset:

        "Web Inspector: console.profile should use the new Sampling
        Profiler"
        https://bugs.webkit.org/show_bug.cgi?id=153499
        http://trac.webkit.org/changeset/202152

2016-06-14  Filip Pizlo  <fpizlo@apple.com>

        Baseline JIT should be concurrent
        https://bugs.webkit.org/show_bug.cgi?id=158755

        Reviewed by Geoffrey Garen.
        
        This makes the baseline JIT concurrent. We want it to be concurrent because it takes up
        about 1% of PLT3 and 10% of JSBench (though the JSBench number might be down from recent
        optimizations).
        
        The idea is really simple: I separated the compile and link phases of JIT::privateCompile(),
        and arranged to call the compile phase from another thread. This doesn't reuse the old
        DFG::Worklist code, because that code does things we don't need (like compilation plan
        cancellation to allow GC to interleave with compilations) and is structured in a way that
        would have required more changes to the baseline JIT. Also, I think that code uses the wrong
        API, and as a result, clients of that API have a bad time. For example, it's never clear who
        has the responsibility of setting the JIT thresholds and the DFG::Worklist goes to great
        lengths to try to help its client set those things correctly, but since it doesn't set them
        directly, the client then has to have additional complex logic to combine what it learned
        from the Worklist and what it knows to set the thresholds. This patch takes a simpler
        approach: the JITWorklist takes complete control over scheduling compilations. It's like a
        combination of DFG::Worklist and operationOptimize().
        
        Because the baseline JIT runs quickly, we can take some shortcuts. The JITWorklist requires
        that all of its plans complete before a GC begins. This ensures that we don't have to worry
        about interactions between the concurrent baseline JIT and the GC.
        
        I needed to do a bunch of minor changes to the JIT to handle the races that emerged. For
        example, I needed to do things to opcodes that read profiling both in the main path code
        generator and the slow path one. One trick I used was to create a copy of the instruction
        stream and provide that for anyone interested in the original value of the profiles. Most
        code still uses the CodeBlock's instruction stream because it may emit JIT code that points
        at the stream.
        
        This also fixes a LLInt bug in prototype caching. This bug was revealed by this change
        because more of our LayoutTests now run in LLInt.
        
        This looks like it might be a ~1% Octane speed-up (on command line) and a ~0.7% PLT3
        speed-up. This also looks like a ~2% JSBench speed-up.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * debugger/Debugger.cpp:
        (JSC::Debugger::setSteppingMode):
        (JSC::Debugger::toggleBreakpoint):
        (JSC::Debugger::clearBreakpoints):
        (JSC::Debugger::clearDebuggerRequests):
        * dfg/DFGOSRExitPreparation.cpp:
        (JSC::DFG::prepareCodeOriginForOSRExit):
        * heap/Heap.cpp:
        (JSC::Heap::didFinishIterating):
        (JSC::Heap::completeAllJITPlans):
        (JSC::Heap::deleteAllCodeBlocks):
        (JSC::Heap::collectImpl):
        (JSC::Heap::completeAllDFGPlans): Deleted.
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::forEachCodeBlock):
        * jit/JIT.cpp:
        (JSC::JIT::emitNotifyWrite):
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        (JSC::JIT::compileWithoutLinking):
        (JSC::JIT::link):
        (JSC::JIT::privateCompile):
        (JSC::JIT::privateCompileExceptionHandlers):
        * jit/JIT.h:
        (JSC::JIT::compile):
        (JSC::JIT::getSlowCase):
        (JSC::JIT::linkSlowCase):
        (JSC::JIT::linkDummySlowCase):
        * jit/JITInlines.h:
        (JSC::JIT::emitTagBool):
        (JSC::JIT::originalInstruction):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitSlow_op_put_to_scope):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitSlow_op_put_by_val):
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emitSlow_op_resolve_scope):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitSlow_op_put_to_scope):
        * jit/JITWorklist.cpp: Added.
        (JSC::JITWorklist::Plan::Plan):
        (JSC::JITWorklist::Plan::compileInThread):
        (JSC::JITWorklist::Plan::finalize):
        (JSC::JITWorklist::Plan::codeBlock):
        (JSC::JITWorklist::Plan::vm):
        (JSC::JITWorklist::Plan::isFinishedCompiling):
        (JSC::JITWorklist::Plan::isFinalized):
        (JSC::JITWorklist::JITWorklist):
        (JSC::JITWorklist::~JITWorklist):
        (JSC::JITWorklist::completeAllForVM):
        (JSC::JITWorklist::poll):
        (JSC::JITWorklist::compileLater):
        (JSC::JITWorklist::compileNow):
        (JSC::JITWorklist::runThread):
        (JSC::JITWorklist::finalizePlans):
        (JSC::JITWorklist::instance):
        * jit/JITWorklist.h: Added.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
        (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
        * runtime/VM.cpp:
        (JSC::VM::~VM):

2016-06-16  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: console.profile should use the new Sampling Profiler
        https://bugs.webkit.org/show_bug.cgi?id=153499
        <rdar://problem/24352431>

        Reviewed by Timothy Hatcher.

        Currently console.profile/profileEnd behave slightly differently
        between JSContext and Web inspection. Unifying will be part of:
        <https://webkit.org/b/158753> Generalize the concept of Instruments on the backend

        Both JSContext and Web inspection keep track of active
        profiles started and stopped via console.profile/profileEnd.

        JSContext inspection sends its programmatic start/stop
        via the ScriptProfiler domain.

        Web inspection sends its programmatic start/stop
        via the Timeline domain, and also will start/stop backend
        list of Instruments.

        The functional differences between these is that for JSContext
        inspection, console.profile only starts/stops the ScriptProfiler
        domain, and does not auto-start other instruments. This isn't really
        a problem right now given the instruments available for JSContext
        inspection; but it will be nice to unify as we add more instruments.
        Also, JSContext inspection won't have "Profile (name)" records in
        its Events view, since those are currently generated only by the
        Web's Timeline domain.

        * inspector/protocol/ScriptProfiler.json:
        * inspector/protocol/Timeline.json:
        Events to inform the frontend of programmatic start/stop.

        * debugger/Debugger.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::breakpointsActive):
        (Inspector::InspectorDebuggerAgent::isPaused):
        * inspector/agents/InspectorDebuggerAgent.h:
        Expose breakpoints active state, since programmatic recording
        will temporarily disabled breakpoints if needed.

        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
        (Inspector::JSGlobalObjectConsoleClient::profile):
        (Inspector::JSGlobalObjectConsoleClient::profileEnd):
        (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
        (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
        * inspector/JSGlobalObjectConsoleClient.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted):
        (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped):
        * inspector/agents/InspectorScriptProfilerAgent.h:
        JSContext implementation of console.profile/profileEnd.

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

        Kraken/stanford-crypto-pbkdf2.js sometimes crashes with an OSR assertion in FTL
        https://bugs.webkit.org/show_bug.cgi?id=158850

        Reviewed by Keith Miller.
        
        Bytecode liveness was incorrectly claiming that all tail-deleted locals are live! That's
        crazy! We never noticed this because extending OSR liveness is usually not a showstopper and
        until recently we didn't have a lot of tail-call test cases to play with. Well, we do now,
        thanks to the increasing reliance on tail calls in our builtins.

        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::localsLiveInBytecode): Fix the bug and add some optional tracing. Also restructure the code so that we don't break to return true, since that's counterintuitive.
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::buildExitArguments): Make this assertion print more useful information.

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

        Add collecting of LLINT slow path stats.
        https://bugs.webkit.org/show_bug.cgi?id=158829

        Reviewed by Keith Miller.

        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::dumpStats):
        * llint/LLIntData.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2016-06-15  Keith Miller  <keith_miller@apple.com>

        Add support for Symbol.isConcatSpreadable (round 2)
        https://bugs.webkit.org/show_bug.cgi?id=158769

        Reviewed by Mark Lam.

        This patch adds support for Symbol.isConcatSpreadable. In order to
        do so, it was necessary to move the Array.prototype.concat function
        to JS. A number of different optimizations were needed to make
        such the move to a builtin performant. First, this patch adds a
        new Bytecode intrinsic, isJSArray, that checks if the value is a
        JSArray object. Specifically, isJSArray checks that the array
        object is a normal instance of JSArray and not a RuntimeArray or
        Array.prototype. isJSArray can also be converted into a constant
        by the DFG if we are able to prove that the incomming value is
        already a JSArray.

        In order to further improve the perfomance we also now cover more
        indexing types in our fast path memcpy code. Before we would only
        memcpy Arrays if they had the same indexing type and did not have
        Array storage or were undecided. Now the memcpy code covers the
        following additional three cases:

        1) One array is undecided and the other does not have array storage

        2) One array is Int32 and the other is contiguous (we map this
        into a contiguous array).

        3) The this value is an array and first argument is a non-array
        that does not have Symbol.isConcatSpreadable set.

        This patch also adds a new fast path for concat with more than one
        array argument by using memcpy to append values onto the result
        array. This works roughly the same as the two array fast path
        using the same methodology to decide if we can memcpy the other
        butterfly into the result butterfly.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ArrayPrototype.js:
        (concatSlowPath):
        (concat):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitIsJSArray):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_isJSArray):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (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/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::compileIsJSArray):
        (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
        * dfg/DFGSpeculativeJIT.h:
        (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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::isArray):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_jsarray):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_jsarray):
        * jit/JITOperations.h:
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ArrayConstructor.h:
        (JSC::isArrayConstructor):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::speciesWatchpointsValid):
        (JSC::speciesConstructArray):
        (JSC::moveElements):
        (JSC::concatAppendOne):
        (JSC::arrayProtoFuncConcat): Deleted.
        * runtime/ArrayPrototype.h:
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/IndexingType.h:
        (JSC::indexingTypeForValue):
        * runtime/JSArray.cpp:
        (JSC::JSArray::appendMemcpy):
        (JSC::JSArray::fastConcatWith): Deleted.
        * runtime/JSArray.h:
        (JSC::JSArray::createStructure):
        (JSC::isJSArray):
        (JSC::JSArray::fastConcatType): Deleted.
        * runtime/JSArrayInlines.h: Added.
        (JSC::JSArray::mergeIndexingTypeForCopying):
        (JSC::JSArray::canFastCopy):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSObject.cpp:
        (JSC::JSObject::convertUndecidedForValue):
        * runtime/JSType.h:
        * runtime/ObjectConstructor.h:
        (JSC::constructObject):
        * tests/es6.yaml:
        * tests/stress/array-concat-spread-object.js: Added.
        (arrayEq):
        * tests/stress/array-concat-spread-proxy-exception-check.js: Added.
        (arrayEq):
        * tests/stress/array-concat-spread-proxy.js: Added.
        (arrayEq):
        * tests/stress/array-concat-with-slow-indexingtypes.js: Added.
        (arrayEq):
        * tests/stress/array-species-config-array-constructor.js:

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

        Assertion failure when returning incomplete property descriptor from proxy trap.
        https://bugs.webkit.org/show_bug.cgi?id=157078

        Reviewed by Saam Barati.

        If the proxy returns a descriptor that expects a value but does not specify one,
        we should use undefined for the value.

        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        * tests/stress/proxy-returning-incomplete-property-descriptor.js: Added.
        (truthiness):
        (compare):
        (shouldBe):
        (test):
        (get test):

2016-06-15  Keith Miller  <keith_miller@apple.com>

        Unreviewed, fix typo in test and move tests to the correct files.

        * tests/stress/multi-get-by-offset-proto-or-unset.js:
        * tests/stress/multi-get-by-offset-proto-self-or-unset.js:

2016-06-15  Keith Miller  <keith_miller@apple.com>

        DFGByteCodeParser should be able to infer the value of unset properties in MultiGetByOffset
        https://bugs.webkit.org/show_bug.cgi?id=158802

        Reviewed by Filip Pizlo.

        This patch adds support for unset properties in MultiGetByOffset. Since MultiGetByOffset
        already supports constant values this patch just adds a constant case where the fetched
        value is undefined. Fortunately (or unfortunately) we don't support object allocation
        sinking for constant cases of MultiGetByOffset, which means we don't need to adjust any
        in that phase.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::planLoad):
        (JSC::DFG::ByteCodeParser::handleGetById):
        * dfg/DFGMultiGetByOffsetData.h:
        * tests/stress/multi-get-by-offset-proto-or-unset.js: Added.
        (foo):
        * tests/stress/multi-get-by-offset-proto-self-or-unset.js: Added.
        (foo):
        * tests/stress/multi-get-by-offset-self-or-unset.js: Added.
        (foo):

2016-06-15  Chris Dumez  <cdumez@apple.com>

        Unreviewed GCC build fix after r202098.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::thresholdForJIT):

2016-06-14  Geoffrey Garen  <ggaren@apple.com>

        compilation policy should adapt to past behavior
        https://bugs.webkit.org/show_bug.cgi?id=158759

        Reviewed by Saam Barati.

        This looks like a ~9% speedup on JSBench.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::~CodeBlock): Record when a CodeBlock dies without ever
        making it to DFG.

        (JSC::CodeBlock::thresholdForJIT): CodeBlocks that make it to DFG should
        compile sooner; CodeBlocks that don't should compile later. The goal is
        to use past behavior, in addition to execution counts, to determine
        whether compilation is profitable.

        (JSC::CodeBlock::jitAfterWarmUp):
        (JSC::CodeBlock::jitSoon): Apply the thresholdForJIT rule.

        * bytecode/CodeBlock.h: Moved some code into the .cpp file so I could
        change stuff without recompiling.
        (JSC::CodeBlock::jitAfterWarmUp): Deleted.
        (JSC::CodeBlock::jitSoon): Deleted.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::didOptimize):
        (JSC::UnlinkedCodeBlock::setDidOptimize): Added a piece of data to track
        whether we made it to DFG.

        * jit/JITOperations.cpp: Record when we make it to DFG.

2016-06-15  Konstantin Tokarev  <annulen@yandex.ru>

        Only Mac port needs ObjC API for JSC.
        https://bugs.webkit.org/show_bug.cgi?id=158780

        Reviewed by Philippe Normand.

        * API/JSBase.h: Removed !defined(BUILDING_GTK__)

2016-06-15  Keith Miller  <keith_miller@apple.com>

        DFGByteCodeParser should be able to infer a property is unset from the Baseline inline cache.
        https://bugs.webkit.org/show_bug.cgi?id=158774

        Reviewed by Filip Pizlo.

        This patch allows the DFGByteCodeParser to speculatively convert a property access into a
        constant if that access was always a miss in the Baseline inline cache. This patch does
        not add support for MultiGetByOffset and unset properties. That functionality will come
        a future patch.

        * bytecode/ComplexGetStatus.cpp:
        (JSC::ComplexGetStatus::computeFor):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        * bytecode/GetByIdVariant.h:
        (JSC::GetByIdVariant::isPropertyUnset):
        * bytecode/PutByIdVariant.h:
        (JSC::PutByIdVariant::isPropertyUnset):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::load):
        (JSC::DFG::ByteCodeParser::handleGetById):
        * tests/stress/undefined-access-then-self-change.js: Added.
        (foo):

2016-06-15  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Move calling convention flags to WTF
        https://bugs.webkit.org/show_bug.cgi?id=158661

        Reviewed by Keith Miller.

        Due to some calling convention flags and JIT_OPERATION flags, MathCommon.h includes MacroAssemblerCodeRef and JITOperations.h.
        But MacroAssembler and JIT part should not be necessary for the MathCommon component.
        As with other calling convention flags like JSC_HOST_CALL, these flags should be in WTF.

        * assembler/MacroAssemblerCodeRef.h:
        * jit/JITOperations.h:
        Add wtf/Platform.h inclusion driven by the Windows port build failure.

        * runtime/MathCommon.h:

2016-06-15  Romain Bellessort  <romain.bellessort@crf.canon.fr>

        Enabling Shadow DOM for all platforms
        https://bugs.webkit.org/show_bug.cgi?id=158738

        Reviewed by Ryosuke Niwa.

        Removed Shadow DOM from options (enabled by default)

        * Configurations/FeatureDefines.xcconfig:

2016-06-14  Caio Lima  <ticaiolima@gmail.com>

        The parser doesn't properly parse "super" when default parameter is an
        arrow function.
        https://bugs.webkit.org/show_bug.cgi?id=157872.

        Reviewed by Saam Barati.

        The "super" member or "super()" could not be used when default parameter is an
        arrow function, resuling in sytax error. It happened because the
        "closestOrdinaryFunctionScope" was not being initialized properly
        before "parseFunctionParameters" step and the condition
        "functionSuperBinding == SuperBinding::NotNeeded" or
        "functionConstructorKind != ConstructorKind::Derived" on
        "Parser<LexerType>::parseMemberExpression" step were being true
        resulting in SyntaxError.

        * parser/Parser.cpp: 
        (JSC::Parser<LexerType>::parseFunctionInfo): setting
        "functionScope->setExpectedSuperBinding(expectedSuperBinding)" and
        "functionScope->setConstructorKind(constructorKind)" before
        "parseFunctionParameters" step.

2016-06-14  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Rename Timeline.setAutoCaptureInstruments to Timeline.setInstruments
        https://bugs.webkit.org/show_bug.cgi?id=158762

        Reviewed by Timothy Hatcher.

        Rename the protocol methods since the backend may use the instruments
        for purposes other then auto-capture, such as programmatic capture
        via console.profile.

        * inspector/protocol/Timeline.json:

2016-06-14  David Kilzer  <ddkilzer@apple.com>

        Document the native format of JSChar type
        <http://webkit.org/b/156137>

        Reviewed by Darin Adler.

        * API/JSStringRef.h:
        (typedef JSChar): Update documentation.

2016-06-14  Keith Miller  <keith_miller@apple.com>

        The Array species constructor watchpoints should be created the first time they are needed rather than on creation
        https://bugs.webkit.org/show_bug.cgi?id=158754

        Reviewed by Benjamin Poulain.

        We use adaptive watchpoints for some Array prototype functions to
        ensure that the user has not overridden the value of the
        Array.prototype.constructor or Array[Symbol.species]. This patch
        changes when the Array species constructor watchpoints are
        initialized. Before, those watchpoints would be created when the
        global object is initialized. This had the advantage that it did
        not require validating the constructor and Symbol.species
        properties. On the other hand, it also meant that if the user were
        to reconfigure properties Array.prototype, which would cause the
        structure of the property to become an uncachable dictionary,
        prior to running code that the watchpoints would be
        invalidated. It turns out that JSBench amazon, for instance, does
        reconfigure some of Array.prototype's properties. This patch
        initializes the watchpoints the first time they are needed. Since
        we only initialize once we also flatten the structure of Array and
        Array.prototype.

        * runtime/ArrayPrototype.cpp:
        (JSC::speciesConstructArray):
        (JSC::ArrayPrototype::attemptToInitializeSpeciesWatchpoint):
        (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
        (JSC::ArrayPrototype::setConstructor): Deleted.
        * runtime/ArrayPrototype.h:
        (JSC::ArrayPrototype::speciesWatchpointStatus):
        (JSC::ArrayPrototype::didChangeConstructorOrSpeciesProperties): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::speciesGetterSetter):
        (JSC::JSGlobalObject::arrayConstructor):
        * tests/stress/array-symbol-species-lazy-watchpoints.js: Added.
        (test):
        (arrayEq):
        (A):

2016-06-14  Keith Miller  <keith_miller@apple.com>

        REGRESSION(202002-202014): 845 32-bit JSC Stress Test failures
        https://bugs.webkit.org/show_bug.cgi?id=158737

        Reviewed by Filip Pizlo.

        When the this child and arguments child for the varargs nodes was switched I missed one
        case in the 32-bit build.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):

2016-06-13  Gavin & Ellie Barraclough  <barraclough@apple.com>

        setUpStaticFunctionSlot does not handle Builtin|Accessor properties
        https://bugs.webkit.org/show_bug.cgi?id=158637

        Reviewed by Geoff Garen.

        setUpStaticFunctionSlot contains a duplicate copy of the body of the function reifyStaticProperty
        - however it is missing handling for Accessor type under Builtin functions.
        Fix the bug by de-duplicating - setUpStaticFunctionSlot should just call reifyStaticProperty.

        * runtime/Lookup.cpp:
        (JSC::setUpStaticFunctionSlot):
            - should just call reifyStaticProperty.
        * runtime/Lookup.h:
        (JSC::lookupPut):
        (JSC::reifyStaticProperty):
            - changed reifyStaticProperty to take PropertyName.

2016-06-13  Gavin & Ellie Barraclough  <barraclough@apple.com>

        JSBoundSlotBaseFunction no longer binds slot base
        https://bugs.webkit.org/show_bug.cgi?id=157978

        Reviewed by Geoff Garen.

        This class is basically currently named after a bug. We should never have
        been binding function to slot bases - this was not ever correct behavior.
        This was fixed earlier in the year, but there is still some cruft including
        the class name to clean up.

            - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction
            - removed m_boundSlotBase - don't retain the original slot base
              (we were not really using it anyway).
            - ASSERT customGetterSetter->getter/setter are non-null, rather than checking.
            - Store the PropertyName such that we can pass this to the getter
              (we're currently reperforming the String->Identifier conversion every time).
            - Removed JSFunction::lookUpOrCreateNativeExecutable - this is just overhead,
              and not used consistently.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSBoundSlotBaseFunction.cpp: Removed.
        * runtime/JSBoundSlotBaseFunction.h: Removed.
            - JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction
        * runtime/JSCustomGetterSetterFunction.cpp: Copied from Source/JavaScriptCore/runtime/JSBoundSlotBaseFunction.cpp.
        (JSC::JSCustomGetterSetterFunction::customGetterSetterFunctionCall):
            - made a static function on JSCustomGetterSetterFunction such that accessor
              to member properties could be made private. Call variant of callCustomSetter
              that does not require slotBase, ASSERT getter/setter present, pass stored
              PropertyName to getter.
        (JSC::JSCustomGetterSetterFunction::JSCustomGetterSetterFunction):
            - renamed, store propertyName.
        (JSC::JSCustomGetterSetterFunction::create):
            - use same function name to Executable as is being passed to Function::finishCreation.
        (JSC::JSCustomGetterSetterFunction::visitChildren):
        (JSC::JSCustomGetterSetterFunction::finishCreation):
            - removed m_boundSlotBase.
        * runtime/JSCustomGetterSetterFunction.h: Copied from Source/JavaScriptCore/runtime/JSBoundSlotBaseFunction.h.
        (JSC::JSCustomGetterSetterFunction::customGetterSetter):
        (JSC::JSCustomGetterSetterFunction::isSetter):
            - made private.
        (JSC::JSCustomGetterSetterFunction::propertyName):
            - new accessor.
        (JSC::JSBoundSlotBaseFunction::boundSlotBase): Deleted.
            - removed.
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::create):
        (JSC::JSFunction::lookUpOrCreateNativeExecutable): Deleted.
            - removed lookUpOrCreateNativeExecutable. This inconsistently used wrapper was providing no value, only bloat.
        * runtime/JSFunction.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
            - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::customGetterSetterFunctionStructure):
        (JSC::JSGlobalObject::boundSlotBaseFunctionStructure): Deleted.
            - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc.
        * runtime/JSNativeStdFunction.cpp:
        (JSC::JSNativeStdFunction::create):
            - removed lookUpOrCreateNativeExecutable.
        * runtime/JSObject.cpp:
        (JSC::getCustomGetterSetterFunctionForGetterSetter):
        (JSC::JSObject::getOwnPropertyDescriptor):
        (JSC::getBoundSlotBaseFunctionForGetterSetter): Deleted.
            - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc.
        * runtime/VM.h:
            - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc.

2016-06-13  Saam Barati  <sbarati@apple.com>

        The sampling profiler should further protect itself against certain forms of sampling bias that arise due to the sampling interval being in sync with some other system process
        https://bugs.webkit.org/show_bug.cgi?id=158678

        Reviewed by Benjamin Poulain.

        I first became aware of this problem when I read this paper:
        http://plv.colorado.edu/papers/mytkowicz-pldi10.pdf

        To provide background for this change, I'll quote a paragraph
        from section 6.2:
        "One statically sound method for collecting random samples is to collect a
        sample at every t + r milliseconds, where t is the desired sampling interval
        and r is a random number between −t and t. One might think that sampling every
        t seconds is enough (i.e., drop the r component) but it is not: specifically,
        if a profiler samples every t seconds, the sampling rate would be synchronized
        with any program or system activity that occurs at regular time intervals [17].
        For example, if the thread scheduler switches between threads every 10ms and our
        sampling interval was also 10ms, then we may always take samples immediately after
        a thread switch. Because performance is often different immediately after a thread
        switch than at other points (e.g., due to cache and TLB warm-up effects) we would
        get biased data. The random component, r, guards against such situations."

        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::timerLoop):

2016-06-13  Oliver Hunt  <oliver@apple.com>

        DFG Validation fails when performing a concatenation with only a single entry
        https://bugs.webkit.org/show_bug.cgi?id=158699

        Reviewed by Saam Barati.

        Fairly simple short circuiting of a single replacement template string
        without any padding to be planted as a simple to string rather than
        op_strcat.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::TemplateLiteralNode::emitBytecode):
        * tests/stress/template-literal.js:
        (testSingleNode):

2016-06-13  Filip Pizlo  <fpizlo@apple.com>

        FTL::Output methods should be out-of-line whenever possible
        https://bugs.webkit.org/show_bug.cgi?id=158704

        Reviewed by Benjamin Poulain.
        
        These methods turn into a non-trivial amount of code because of the template-based B3 API.
        Inlining them didn't achieve any performance advantages for the FTL, but it did make the
        code larger. This outlines most methods in FTL::Output. It makes FTL::LowerDFGToB3 smaller
        and it doesn't change performance.

        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::appendTo):
        (JSC::FTL::Output::framePointer):
        (JSC::FTL::Output::lockedStackSlot):
        (JSC::FTL::Output::constBool):
        (JSC::FTL::Output::constInt32):
        (JSC::FTL::Output::constInt64):
        (JSC::FTL::Output::constDouble):
        (JSC::FTL::Output::phi):
        (JSC::FTL::Output::add):
        (JSC::FTL::Output::sub):
        (JSC::FTL::Output::mul):
        (JSC::FTL::Output::div):
        (JSC::FTL::Output::chillDiv):
        (JSC::FTL::Output::mod):
        (JSC::FTL::Output::chillMod):
        (JSC::FTL::Output::neg):
        (JSC::FTL::Output::doubleAdd):
        (JSC::FTL::Output::doubleSub):
        (JSC::FTL::Output::doubleMul):
        (JSC::FTL::Output::doubleDiv):
        (JSC::FTL::Output::doubleMod):
        (JSC::FTL::Output::bitAnd):
        (JSC::FTL::Output::bitOr):
        (JSC::FTL::Output::bitXor):
        (JSC::FTL::Output::shl):
        (JSC::FTL::Output::aShr):
        (JSC::FTL::Output::lShr):
        (JSC::FTL::Output::bitNot):
        (JSC::FTL::Output::logicalNot):
        (JSC::FTL::Output::ctlz32):
        (JSC::FTL::Output::doubleAbs):
        (JSC::FTL::Output::doubleCeil):
        (JSC::FTL::Output::doubleFloor):
        (JSC::FTL::Output::doubleTrunc):
        (JSC::FTL::Output::doubleSin):
        (JSC::FTL::Output::doubleCos):
        (JSC::FTL::Output::doublePow):
        (JSC::FTL::Output::doublePowi):
        (JSC::FTL::Output::doubleSqrt):
        (JSC::FTL::Output::doubleLog):
        (JSC::FTL::Output::hasSensibleDoubleToInt):
        (JSC::FTL::Output::doubleToUInt):
        (JSC::FTL::Output::signExt32To64):
        (JSC::FTL::Output::zeroExt):
        (JSC::FTL::Output::intToDouble):
        (JSC::FTL::Output::unsignedToDouble):
        (JSC::FTL::Output::castToInt32):
        (JSC::FTL::Output::doubleToFloat):
        (JSC::FTL::Output::floatToDouble):
        (JSC::FTL::Output::load):
        (JSC::FTL::Output::load8SignExt32):
        (JSC::FTL::Output::baseIndex):
        (JSC::FTL::Output::equal):
        (JSC::FTL::Output::notEqual):
        (JSC::FTL::Output::above):
        (JSC::FTL::Output::aboveOrEqual):
        (JSC::FTL::Output::below):
        (JSC::FTL::Output::belowOrEqual):
        (JSC::FTL::Output::greaterThan):
        (JSC::FTL::Output::greaterThanOrEqual):
        (JSC::FTL::Output::lessThan):
        (JSC::FTL::Output::lessThanOrEqual):
        (JSC::FTL::Output::doubleEqual):
        (JSC::FTL::Output::doubleEqualOrUnordered):
        (JSC::FTL::Output::doubleNotEqualOrUnordered):
        (JSC::FTL::Output::doubleLessThan):
        (JSC::FTL::Output::doubleLessThanOrEqual):
        (JSC::FTL::Output::doubleGreaterThan):
        (JSC::FTL::Output::doubleGreaterThanOrEqual):
        (JSC::FTL::Output::doubleNotEqualAndOrdered):
        (JSC::FTL::Output::doubleLessThanOrUnordered):
        (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered):
        (JSC::FTL::Output::doubleGreaterThanOrUnordered):
        (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered):
        (JSC::FTL::Output::isZero32):
        (JSC::FTL::Output::notZero32):
        (JSC::FTL::Output::isZero64):
        (JSC::FTL::Output::notZero64):
        (JSC::FTL::Output::select):
        (JSC::FTL::Output::jump):
        (JSC::FTL::Output::branch):
        (JSC::FTL::Output::check):
        (JSC::FTL::Output::ret):
        (JSC::FTL::Output::unreachable):
        (JSC::FTL::Output::speculate):
        (JSC::FTL::Output::speculateAdd):
        (JSC::FTL::Output::speculateSub):
        (JSC::FTL::Output::speculateMul):
        (JSC::FTL::Output::patchpoint):
        (JSC::FTL::Output::trap):
        (JSC::FTL::Output::anchor):
        (JSC::FTL::Output::bitCast):
        (JSC::FTL::Output::fround):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::setOrigin):
        (JSC::FTL::Output::origin):
        (JSC::FTL::Output::constIntPtr):
        (JSC::FTL::Output::doubleNeg):
        (JSC::FTL::Output::zeroExtPtr):
        (JSC::FTL::Output::load32NonNegative):
        (JSC::FTL::Output::isNull):
        (JSC::FTL::Output::notNull):
        (JSC::FTL::Output::testIsZeroPtr):
        (JSC::FTL::Output::testNonZeroPtr):
        (JSC::FTL::Output::call):
        (JSC::FTL::Output::operation):
        (JSC::FTL::Output::branch):
        (JSC::FTL::Output::switchInstruction):
        (JSC::FTL::Output::addIncomingToPhi):
        (JSC::FTL::Output::framePointer): Deleted.
        (JSC::FTL::Output::constBool): Deleted.
        (JSC::FTL::Output::constInt32): Deleted.
        (JSC::FTL::Output::constInt64): Deleted.
        (JSC::FTL::Output::constDouble): Deleted.
        (JSC::FTL::Output::phi): Deleted.
        (JSC::FTL::Output::add): Deleted.
        (JSC::FTL::Output::sub): Deleted.
        (JSC::FTL::Output::mul): Deleted.
        (JSC::FTL::Output::div): Deleted.
        (JSC::FTL::Output::chillDiv): Deleted.
        (JSC::FTL::Output::mod): Deleted.
        (JSC::FTL::Output::chillMod): Deleted.
        (JSC::FTL::Output::doubleAdd): Deleted.
        (JSC::FTL::Output::doubleSub): Deleted.
        (JSC::FTL::Output::doubleMul): Deleted.
        (JSC::FTL::Output::doubleDiv): Deleted.
        (JSC::FTL::Output::doubleMod): Deleted.
        (JSC::FTL::Output::bitAnd): Deleted.
        (JSC::FTL::Output::bitOr): Deleted.
        (JSC::FTL::Output::bitXor): Deleted.
        (JSC::FTL::Output::shl): Deleted.
        (JSC::FTL::Output::aShr): Deleted.
        (JSC::FTL::Output::lShr): Deleted.
        (JSC::FTL::Output::ctlz32): Deleted.
        (JSC::FTL::Output::addWithOverflow32): Deleted.
        (JSC::FTL::Output::subWithOverflow32): Deleted.
        (JSC::FTL::Output::mulWithOverflow32): Deleted.
        (JSC::FTL::Output::addWithOverflow64): Deleted.
        (JSC::FTL::Output::subWithOverflow64): Deleted.
        (JSC::FTL::Output::mulWithOverflow64): Deleted.
        (JSC::FTL::Output::doubleAbs): Deleted.
        (JSC::FTL::Output::doubleCeil): Deleted.
        (JSC::FTL::Output::doubleFloor): Deleted.
        (JSC::FTL::Output::doubleSin): Deleted.
        (JSC::FTL::Output::doubleCos): Deleted.
        (JSC::FTL::Output::doublePow): Deleted.
        (JSC::FTL::Output::doubleSqrt): Deleted.
        (JSC::FTL::Output::doubleLog): Deleted.
        (JSC::FTL::Output::signExt32To64): Deleted.
        (JSC::FTL::Output::zeroExt): Deleted.
        (JSC::FTL::Output::intToDouble): Deleted.
        (JSC::FTL::Output::castToInt32): Deleted.
        (JSC::FTL::Output::doubleToFloat): Deleted.
        (JSC::FTL::Output::floatToDouble): Deleted.
        (JSC::FTL::Output::equal): Deleted.
        (JSC::FTL::Output::notEqual): Deleted.
        (JSC::FTL::Output::above): Deleted.
        (JSC::FTL::Output::aboveOrEqual): Deleted.
        (JSC::FTL::Output::below): Deleted.
        (JSC::FTL::Output::belowOrEqual): Deleted.
        (JSC::FTL::Output::greaterThan): Deleted.
        (JSC::FTL::Output::greaterThanOrEqual): Deleted.
        (JSC::FTL::Output::lessThan): Deleted.
        (JSC::FTL::Output::lessThanOrEqual): Deleted.
        (JSC::FTL::Output::doubleEqual): Deleted.
        (JSC::FTL::Output::doubleEqualOrUnordered): Deleted.
        (JSC::FTL::Output::doubleNotEqualOrUnordered): Deleted.
        (JSC::FTL::Output::doubleLessThan): Deleted.
        (JSC::FTL::Output::doubleLessThanOrEqual): Deleted.
        (JSC::FTL::Output::doubleGreaterThan): Deleted.
        (JSC::FTL::Output::doubleGreaterThanOrEqual): Deleted.
        (JSC::FTL::Output::doubleNotEqualAndOrdered): Deleted.
        (JSC::FTL::Output::doubleLessThanOrUnordered): Deleted.
        (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered): Deleted.
        (JSC::FTL::Output::doubleGreaterThanOrUnordered): Deleted.
        (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered): Deleted.
        (JSC::FTL::Output::isZero32): Deleted.
        (JSC::FTL::Output::notZero32): Deleted.
        (JSC::FTL::Output::isZero64): Deleted.
        (JSC::FTL::Output::notZero64): Deleted.
        (JSC::FTL::Output::select): Deleted.
        (JSC::FTL::Output::extractValue): Deleted.
        (JSC::FTL::Output::jump): Deleted.
        (JSC::FTL::Output::ret): Deleted.
        (JSC::FTL::Output::unreachable): Deleted.
        (JSC::FTL::Output::speculate): Deleted.
        (JSC::FTL::Output::speculateAdd): Deleted.
        (JSC::FTL::Output::speculateSub): Deleted.
        (JSC::FTL::Output::speculateMul): Deleted.
        (JSC::FTL::Output::patchpoint): Deleted.
        (JSC::FTL::Output::trap): Deleted.
        (JSC::FTL::Output::anchor): Deleted.
        (JSC::FTL::Output::bitCast): Deleted.
        (JSC::FTL::Output::fround): Deleted.

2016-06-13  Keith Miller  <keith_miller@apple.com>

        Unreviewed, Cloop build fix.

        * bytecode/BytecodeList.json:

2016-06-12  Keith Miller  <keith_miller@apple.com>

        Add new builtin opcode tailCallForwardArguments
        https://bugs.webkit.org/show_bug.cgi?id=158666

        Reviewed by Filip Pizlo.

        We should support the ability to have a builtin forward its
        arguments to a helper without allocating an arguments object. This
        patch adds a new bytecode intrinsic @tailCallForwardArguments that
        takes two values. The first is the target of the call and the
        second is the new this value. This opcode will tail call to the
        passed function without triggering an allocation of an arguments
        object for the caller function.

        In the LLInt and Baseline this function acts the same way a normal
        tail call does.  The bytecode will allocate a new stack frame
        copying all the arguments of the caller function into the new
        frame, along with the new this. Then when the actual call happens
        the new frame is copied over the caller frame. While this is not
        necessary, it allows the target function to have more arguments
        than the caller function via arity fixup.

        Once we get to the DFG we reuse existing DFG Nodes for forwarding
        arguments, although there were some minor changes. This patch
        swaps the meaning of the second and third children for each DFG
        varargs node, exchanging the argmuments and this child,
        respectively. It also makes the arguments child for each varargs
        node, as well as the ForwardVarargs node optional. If the optional
        child is missing, then forwarding node assumes that the arguments
        for the node's inlineCallFrame should be used instead. Finally,
        when inlining the target of an inlined
        op_tail_call_forward_arguments we make sure the arguments of the
        forwarding function are marked as non-unboxable since this would
        normally be done by the caller's create arguments object node,
        which does not exist in this case.

        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::callTypeFor):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finishCreation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
        (JSC::BytecodeGenerator::emitCallVarargs):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_tailCallForwardArguments):
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasArgumentsChild):
        (JSC::DFG::Node::argumentsChild):
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileForwardVarargs):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGVarargsForwardingPhase.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
        * interpreter/Interpreter.cpp:
        (JSC::sizeFrameForForwardArguments):
        (JSC::setupForwardArgumentsFrame):
        (JSC::setupForwardArgumentsFrameAndSetThis):
        * interpreter/Interpreter.h:
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::emit_op_tail_call_forward_arguments):
        (JSC::JIT::emitSlow_op_tail_call_forward_arguments):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::emitSlow_op_tail_call_forward_arguments):
        (JSC::JIT::emit_op_tail_call_forward_arguments):
        (JSC::JIT::compileSetupVarargsFrame):
        (JSC::JIT::compileOpCall):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::varargsSetup):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * tests/stress/tailCallForwardArguments.js: Added.
        (putFuncToPrivateName.createBuiltin):
        (putFuncToPrivateName):
        (createTailCallForwardingFuncWith):
        (baz):
        (baz2):
        (baz3):
        (let.bodyText):
        (baz4):
        (baz5):
        (arrayEq):

2016-06-13  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, follow up patch for r201964
        https://bugs.webkit.org/show_bug.cgi?id=158619

        Fix typo in the comment.

        * runtime/MathCommon.h:
        (JSC::toInt32):

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

        Add a mechanism for collecting LLINT stats.
        https://bugs.webkit.org/show_bug.cgi?id=158668

        Reviewed by Filip Pizlo.

        This patch will add a mechanism for collecting the stats on LLINT opcode
        execution counts.  The changes made to enable this are:

        1. Refactored how Options availability work so that we can add a new category:
           Configurable (in addition to the pre-existing Normal and Restricted
           availability).
               Normal options - always available.
               Restricted options - only available on debug builds.
               Configurable options - depends on #define flag options.

           This change is necessary so that:
           a. we won't have to rebuild the world when we want to enable that #define flag
              to make that Configurable option available.
           b. when the #define flag is disabled, the option will be invisible to the user.

           With this, we add our first configurable option, JSC_reportLLIntStats, which
           is dependent on the ENABLE_LLINT_STATS flag.  See next.

        2. Added the ENABLE_LLINT_STATS flag in LLIntCommon.h.  To enable LLINT stats
           collection, we'll need to set this flag to a non-zero value, and rebuilding
           the project.  By design, this will only require a minimal set of files to
           be rebuilt.

           ENABLE_LLINT_STATS is 0 (i.e. disabled) by default.

        3. Added a slow path callback to the LLINT's traceExecution() macro, to call
           _llint_count_opcode(), which in turns counts the opcode.  This callback will
           only be built into the LLINT if ENABLE_LLINT_STATS is non-zero.

        4. Added s_opcodeStatsArray to LLInt::Data.  This is where the stats are
           recorded and stored.

        5. Added calls to LLInt::Data::dumpStats() in jsc.cpp and DumpRenderTree.mm
           to dump the LLINT stats if enabled.  If enabled, the LLINT stats will be
           sorted and dumped (via dataLog) before the programs terminate.

        * interpreter/Interpreter.h:
        * jsc.cpp:
        (main):
        * llint/LLIntCommon.h:
        * llint/LLIntData.cpp:
        (JSC::LLInt::initialize):
        (JSC::LLInt::Data::dumpStats):
        * llint/LLIntData.h:
        (JSC::LLInt::Data::opcodeStats):
        * llint/LLIntOfflineAsmConfig.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::llint_crash):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * runtime/Options.cpp:
        (JSC::parse):
        (JSC::Options::isAvailable):
        (JSC::overrideOptionWithHeuristic):
        (JSC::scaleJITPolicy):
        (JSC::Options::initialize):
        (JSC::Options::setOptionWithoutAlias):
        (JSC::Options::dumpAllOptions):
        (JSC::Options::dumpOption):
        * runtime/Options.h:
        (JSC::Option::Option):
        (JSC::Option::operator!=):
        (JSC::Option::id):

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

        Minimize the amount of memcpy done for allocating Error stacks.
        https://bugs.webkit.org/show_bug.cgi?id=158664

        Reviewed by Darin Adler.

        Currently, Vector<StackFrame> are being copied around multiple times in the
        process of creating Error stacks.

        This patch avoids this unnecessary copying by:
        1. Sizing the StackFrame vector correctly to begin with, and skipping
           undesirable top frames before filling in the vector.
        2. Using perfect forwarding or passing by reference to pass the vector data around
           instead of copying the vectors.
        3. Changing the Exception object to take a Vector<StackFrame> instead of a
           RefCountedArray<StackFrame>.

        This patch has passed the JSC and layout tests.  Benchmarks show that perf is
        neutral.

        * API/tests/testapi.mm:
        (testObjectiveCAPI):
        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::createScriptCallStackFromException):
        * interpreter/Interpreter.cpp:
        (JSC::GetStackTraceFunctor::GetStackTraceFunctor):
        (JSC::GetStackTraceFunctor::operator()):
        (JSC::Interpreter::getStackTrace):
        (JSC::Interpreter::stackTraceAsString):
        (JSC::findExceptionHandler):
        * interpreter/Interpreter.h:
        * runtime/Error.cpp:
        (JSC::addErrorInfoAndGetBytecodeOffset):
        * runtime/Exception.cpp:
        (JSC::Exception::finishCreation):
        * runtime/Exception.h:
        (JSC::Exception::valueOffset):
        (JSC::Exception::value):
        (JSC::Exception::stack):
        (JSC::Exception::didNotifyInspectorOfThrow):
        (JSC::Exception::setDidNotifyInspectorOfThrow):

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

        Tests that overflows the stack should not be run with the sampling profiler.
        https://bugs.webkit.org/show_bug.cgi?id=158663

        Reviewed by Saam Barati.

        The sampling profiler will be sampling the whole stack, and the amount of memory
        churn will make this tests time out, especially with debug builds.  Hence,
        let's not run the test with the sampling profiler configuration.

        * tests/stress/mutual-tail-call-no-stack-overflow.js:
        (shouldThrow):

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

        Unreviewed, attempt to fix r201964 failure on Apple ports
        https://bugs.webkit.org/show_bug.cgi?id=158619

        Reviewed by Mark Lam.

        Add Private attributes to MathCommon.h.

        * JavaScriptCore.xcodeproj/project.pbxproj:

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

        [JSC] Inline JSC::toInt32 to improve kraken
        https://bugs.webkit.org/show_bug.cgi?id=158619

        Reviewed by Mark Lam.

        Several kraken benchmarks show that JSC::toInt32 is frequently called.
        For example, stanford-crypto-pbkdf2 reports that the hottest runtime function is JSC::toInt32.

        The data is below (taken by Linux perf tools).
        5.50%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZN3JSC7toInt32Ed
        3.96%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZN3JSC20arrayProtoFuncConcatEPNS_9ExecStateE
        2.48%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZN3JSC19arrayProtoFuncSliceEPNS_9ExecStateE
        1.69%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZNK3JSC9Structure27holesMustForwardToPrototypeERNS_2VME

        This is because of CommonSlowPaths' bit operations's JSValue::toInt32.
        Due to the slow path, in `value | 0`, `value` may be a double number value. In that case, JSC::toInt32 is called.

        While JSC::toIn32 is hot, the function itself is very small. It's worth inlining.

        This change offers the following kraken improvements.

                                                         baseline                  patched
        Kraken:
           audio-beat-detection                       47.492+-1.701             46.657+-1.232           might be 1.0179x faster
           stanford-crypto-aes                        43.669+-0.210      ^      42.862+-0.115         ^ definitely 1.0188x faster
           stanford-crypto-ccm                        45.213+-1.424             44.490+-1.290           might be 1.0162x faster
           stanford-crypto-pbkdf2                    107.665+-0.581      ^     106.229+-0.807         ^ definitely 1.0135x faster

        This patch only focused on the call to toInt32 from the runtime functions.
        So JSC::toInt32 calls from the baseline / DFG remain.
        We ensure that JIT code uses operationToInt32 instead of JSC::toInt32 since JSC::toInt32 is now marked as ALWAYS_INLINE.
        Linux perf profiler also finds that this `operationToInt32` is frequently called in the above benchmarks.
        It may be good to introduce asm emit for that instead of calling JSC::toInt32 operation in the separated patch.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
        * runtime/JSCJSValue.cpp:
        (JSC::toInt32): Deleted.
        * runtime/JSCJSValueInlines.h:
        * runtime/MathCommon.cpp:
        (JSC::operationToInt32):
        * runtime/MathCommon.h:
        (JSC::toInt32):

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

        The backend should be happy to compile Unreachable even if AI didn't prove it to be unreachable
        https://bugs.webkit.org/show_bug.cgi?id=158631

        Reviewed by Keith Miller.
        
        We've been slowly making the DFG Unreachable opcode behave like a grown-up. When we first
        added it, it was a hack for Throw, and we could always rely on AI proving that Unreachable
        was not reachable. But then we started using Unreachable as a proper Unreachable opcode,
        like Oops in B3 for example, which has a more nuanced meaning: you use it whenever you
        emit code that *you* know will not return, and you need some way of terminating the basic
        block. The DFG is not a proof-carrying compiler, and it never will be. So, when you have
        proved that something is not reachable, you should be able to use Unreachable even if
        there is no guarantee that the compiler will later be able to replicate your proof. This
        means that the backend may find itself compiling Unreachable because AI did not prove that
        it was unreachable.
        
        Prior to this change, we would crash compiling Unreachable because we would rely on AI
        preventing us from reaching Unreachable in the backend. But that's silly! We don't want
        users of Unreachable to have to also convince AI that their Unreachable is really
        Unreachable.
        
        This fixes crashes on real websites. I couldn't work out how to turn them into a reduced
        test.

        * assembler/AbortReason.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
        (JSC::DFG::SpeculativeJIT::unreachable):
        (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutDynamicVar):
        (JSC::FTL::DFG::LowerDFGToB3::compileUnreachable):
        (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject):

2016-06-09  Alex Christensen  <achristensen@webkit.org>

        Clean up JavaScriptCore.vcxproj directory after switching to CMake.

        * JavaScriptCore.vcxproj/LLInt: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.pl: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.pl: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.props: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props: Removed.
        * JavaScriptCore.vcxproj/jsc: Removed.
        * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp: Removed.
        * JavaScriptCore.vcxproj/jsc/DLLLauncherWinCairo.props: Removed.
        * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Removed.
        * JavaScriptCore.vcxproj/jsc/jsc.vcxproj.filters: Removed.
        * JavaScriptCore.vcxproj/jsc/jscCommon.props: Removed.
        * JavaScriptCore.vcxproj/jsc/jscDebug.props: Removed.
        * JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj: Removed.
        * JavaScriptCore.vcxproj/jsc/jscLauncherPostBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/jsc/jscLauncherPreBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/jsc/jscLauncherPreLink.cmd: Removed.
        * JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/jsc/jscPreBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/jsc/jscPreLink.cmd: Removed.
        * JavaScriptCore.vcxproj/jsc/jscProduction.props: Removed.
        * JavaScriptCore.vcxproj/jsc/jscRelease.props: Removed.
        * JavaScriptCore.vcxproj/testRegExp: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.filters: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpDebug.props: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncher.vcxproj: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPostBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreLink.cmd: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpPostBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpPreBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpPreLink.cmd: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpProduction.props: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpRelease.props: Removed.
        * JavaScriptCore.vcxproj/testapi: Removed.
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Removed.
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiCommon.props: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiDebug.props: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiDebugCFLite.props: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiLauncherPostBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiLauncherPreBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiLauncherPreLink.cmd: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiPostBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiPreBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiPreLink.cmd: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiProduction.props: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiRelease.props: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiReleaseCFLite.props: Removed.
        * shell/DLLLauncherMain.cpp: Copied from JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp.
        * shell/PlatformWin.cmake:

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

        Rare failure in stress/v8-deltablue-strict.js.ftl-eager
        https://bugs.webkit.org/show_bug.cgi?id=158591

        Reviewed by Saam Barati.
        
        This is a simple and sensible fix to an amazing compiler bug that previously only
        manifested rarely in the v8-deltablue-strict test. It required on average 1000 runs while
        the system was under load for the bug to manifest. Fortunately, the bug is 100% repro with
        concurrent JIT disabled in the new "constant-fold-multi-get-by-offset-to-get-by-offset-on-
        prototype-and-sink-allocation.js" test.
        
        The problem here is that we were allowing ourselves to be super sloppy with the meaning of
        the two children of GetByOffset, and to a lesser extent, PutByOffset. The first two
        children of these nodes have these meanings:
        
        child1: the storage from which to load (or to which to store)
        child2: the logical object base
        
        Normally, child1 == child2, but child1 may point to a node that vends the storage pointer
        in case we are using multiple indirections to get to the property. That's fairly common.
        
        Where this gets nutty is that we don't validate the behavior of child1. Previously, the
        DFG::Validate phase would accept code that had child1 point to one object and child2 point
        to another object. That's bad because then, analyses will assume that we're loading from
        one object while we are actually loading from another. One of the fixes is to make
        Validate smarter about this, so that future problems with this get caught sooner.
        
        The actual bug was in ConstantFoldingPhase. When we first wrote ConstantFoldingPhase's
        logic for converting GetByIds and MultiGetByOffsets to GetByOffset, we assumed that this
        was only for non-prototype loads. This was becuase the logic was originally written based
        on a static GetByIdStatus analysis, which does not handle prototypes. So, as a shortcut,
        we would convert the GetById (or MultiGetByOffset) to a GetByOffset by doing this
        shuffling of children:
        
        child1 got the storage pointer, which might be a new GetButterfly node that we created.
        child2 got the old value of child1.
        
        The bug was introduced when I later made it possible for a monomorphic prototype
        MultiGetByOffset to be converted to a GetByOffset. Then this algorithm would mean that:
        
        child1 got either a pointer to the prototype or a storage pointer derived from the
            prototype.
        child2 got the old value of child1, which was a pointer to the base object (i.e. not the
            prototype).
        
        This happens super rarely because most prototype loads that we can statically reason about
        also happen to load constants, so we don't convert to GetByOffset at all. You need the
        strange combination of a MultiGetByOffset (not GetById or GetByOffset) on some prototypes
        and some static reasoning about the base so that we can convert it to a GetByOffset, but
        not enough static reasoning that we can convert it to a constant.
        
        Even if the bad thing happened, then this is not enough for it to cause symptons. If we
        did nothing else - like none of the other optimizations succeeded - then this would
        be OK because the backend will emit code based on child1, which is right. But disaster
        strikes when the code otherwise looks sane enough for ObjectAllocationSinkingPhase to kick
        in. This phase operates on child2, as any good phase should: child1 is only interesting
        for knowing *how* to load, not *what* we are loading. The phase is right to ignore child1.

        So the phase would assume that we are loading the prototype property ("f" in the new test
        or "addToGraph" in deltablue) from the sunken base object allocation in the inlined
        constructor. The base object has no such property, but the phase conservatively assumes
        that it does indeed have such a property. That's just how the phase does things: it is
        very abstract and general, so it assumes that the set of properties on an allocation is
        the set of properties that accesses to the allocation speak of. Clearly, this GetByOffset
        was speaking of the property as being on the allocation. When sinking completed, it would
        convert the GetByOffset to the sunken (a.k.a. promoted) property. But nobody stored to
        this property on the allocation, so we'd get the bottom value, which is 1927. Why 1927? I
        don't remember anymore, but apparently I chose it. It helped here - when I started seeing
        that value come up, it took a quick grep to realize that this was the object allocation
        sinking phase's bottom value.
        
        The real fix to the bug is to make Node::convertToGetByOffset() take an explicit new base
        since its clients will use it to potentially create a load on a different object than the
        base of the original operation, as in the relatively new
        MultiGetByOffset(prototype)->GetByOffset optimization. As far as I know, the PutByOffset
        code did not have the same bug because we don't have any optimizations that turn a PutById
        or MultiPutByOffset into a PutByOffset on anything but the base object. But the logical
        bug is definitely there: there's code in ConstantFoldingPhase that claims to be able to
        convert any node to a PutByOffset on any base, but it actually silently reuses the
        original node's child1 as the logical base (i.e. child2). This patch makes all of this
        stuff explicit. You can't make this mistake anymore.

        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
        (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToGetStack):
        (JSC::DFG::Node::convertToGetByOffset):
        (JSC::DFG::Node::convertToMultiGetByOffset):
        (JSC::DFG::Node::convertToPutByOffset):
        * dfg/DFGValidate.cpp:
        * tests/stress/constant-fold-multi-get-by-offset-to-get-by-offset-on-prototype-and-sink-allocation.js: Added.
        (ThingA):
        (ThingB):
        (foo):
        (bar):
        * tests/stress/sink-to-impossible-multi-get-by-offset-on-prototypes.js: Added.
        (ThingA):
        (ThingB):
        (ThingC):
        (bar):
        (foo):

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

        Make some methods const.
        https://bugs.webkit.org/show_bug.cgi?id=158594

        Reviewed by Benjamin Poulain.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::columnNumberForBytecodeOffset):
        (JSC::CodeBlock::expressionRangeForBytecodeOffset):
        * bytecode/CodeBlock.h:
        * bytecode/ExpressionRangeInfo.h:
        (JSC::ExpressionRangeInfo::encodeFatColumnMode):
        (JSC::ExpressionRangeInfo::decodeFatLineMode):
        (JSC::ExpressionRangeInfo::decodeFatColumnMode):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset):
        (JSC::UnlinkedCodeBlock::getLineAndColumn):
        (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::createRareDataIfNecessary):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::isOpcode):
        (JSC::StackFrame::computeLineAndColumn):
        (JSC::StackFrame::toString):
        * interpreter/Interpreter.h:
        (JSC::StackFrame::isNative):

2016-06-09  Michael Saboff  <msaboff@apple.com>

        ES6: Reusing function name as a parameter name shouldn't throw Syntax Error
        https://bugs.webkit.org/show_bug.cgi?id=158575

        Reviewed by Benjamin Poulain.

        The check for a parameter with a duplicate name doesn't take into account the
        type of the prior variable.  Added a check that the duplicate is also a
        parameter.

        See the relevant spec section at:
        http://www.ecma-international.org/ecma-262/6.0/#sec-function-definitions-static-semantics-early-errors

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

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

        Unreviewed, rolling out r201836, r201845, and r201848.

        Looks like a 1-2% PLT regression on iOS

        Reverted changesets:

        "[JSC] Change some parameters based on a random search"
        https://bugs.webkit.org/show_bug.cgi?id=158514
        http://trac.webkit.org/changeset/201836

        "Tempory fix for the debug bots"
        http://trac.webkit.org/changeset/201845

        "Change thresholdForOptimizeSoon to match
        thresholdForOptimizeAfterWarmUp"
        http://trac.webkit.org/changeset/201848

2016-06-09  Commit Queue  <commit-queue@webkit.org>

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

        breaks build without ENABLE_WEB_ANIMATION (Requested by
        mcatanzaro on #webkit).

        Reverted changeset:

        "[web-animations] Add Animatable, AnimationEffect,
        KeyframeEffect and Animation interface"
        https://bugs.webkit.org/show_bug.cgi?id=156096
        http://trac.webkit.org/changeset/201810

2016-06-08  Gavin & Ellie Barraclough  <barraclough@apple.com>

        JSObject::reifyAllStaticProperties cleanup
        https://bugs.webkit.org/show_bug.cgi?id=158543

        Reviewed by Mark Lam.

        - JSObject & Structure contain fields labeled 'staticFunctionsReified', however reification now
          affects all properties, not just functions. Rename to 'staticPropertiesReified'.
        - reifyAllStaticProperties relies on a 'hasStaticProperties' method on ClassInfo that walks the
          ClassInfo inheritance chain looking for static property tables. We can now more efficiently
          get this information from TypeInfo.
        - reifyAllStaticProperties triggers a 'toUncacheableDictionaryTransition'; this is overzealous,
          cacheable dictionary is sufficient - this is what we do in the case of DOM prototype property
          reification (see 'reifyStaticProperties' in Lookup.h). (Changing this with an eye on switching
          DOM prototype property reification to use JSObject:: reifyAllStaticProperties, rather than
          having its own special purpose code path.)

        * runtime/ClassInfo.h:
        (JSC::ClassInfo::hasStaticProperties): Deleted.
            - deprecated by TypeInfo::hasStaticPropertyTable.
        * runtime/JSObject.cpp:
        (JSC::JSObject::putInlineSlow):
        (JSC::JSObject::deleteProperty):
        (JSC::JSObject::getOwnNonIndexPropertyNames):
            - staticFunctionsReified -> staticPropertiesReified
        (JSC::JSObject::reifyAllStaticProperties):
            - hasStaticProperties -> TypeInfo::hasStaticPropertyTable
            - toUncacheableDictionaryTransition -> toCacheableDictionaryTransition
            - staticFunctionsReified -> staticPropertiesReified
        * runtime/JSObject.h:
        (JSC::JSObject::staticPropertiesReified):
        (JSC::JSObject::staticFunctionsReified): Deleted.
        * runtime/Lookup.cpp:
        (JSC::setUpStaticFunctionSlot):
        * runtime/Lookup.h:
        (JSC::getStaticPropertySlotFromTable):
        (JSC::replaceStaticPropertySlot):
        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        * runtime/Structure.h:
            - staticFunctionsReified -> staticPropertiesReified

2016-06-08  Benjamin Poulain  <bpoulain@apple.com>

        Change thresholdForOptimizeSoon to match thresholdForOptimizeAfterWarmUp

        Unreviewed.

        This adds back the assertion removed in r201845.
        Making those threshold equal is completely perf neutral
        (on Haswell rMBP with 20 runs).

        * runtime/Options.cpp:
        (JSC::Options::initialize):
        * runtime/Options.h:

2016-06-08  Benjamin Poulain  <bpoulain@apple.com>

        Tempory fix for the debug bots

        Unreviewed.

        * runtime/Options.cpp:
        (JSC::Options::initialize):
        Weaken an assertion while I test values for thresholdForOptimizeSoon.

2016-06-08  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Change some parameters based on a random search
        https://bugs.webkit.org/show_bug.cgi?id=158514

        Reviewed by Filip Pizlo.

        Over the weekend, I left an iMac running the JSC benchmarks
        while changing a bunch of parameters.

        The parameters were changed randomly, with a random deviation
        from the original value.
        To converge toward good values, the range was subject
        to exponential annealing over time.

        The values in this patch is the best outcome my iMac could
        find over the weekend. It is about 1% better on the Haswell
        machines I tested.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::optimizationThresholdScalingFactor):
        * runtime/Options.h:

2016-06-08  Gavin Barraclough  <barraclough@apple.com>

        Remove removeDirect
        https://bugs.webkit.org/show_bug.cgi?id=158516

        Reviewed by Ryosuke Niwa.

        removeDirect is typically used as a subroutine of deleteProperty, but is also available to
        call directly. Having this functionality factored out to a separate routine is a bad idea
        on a couple of fronts:

        - for the main use within deleteProperty there is redundancy (presence of the property
          was being checked twice) and inconsistency (the two functions returned different results
          in the case of a nonexistent property; the result from removeDirect was never observed).

        - all uses of removeDirect are in practical terms incorrect. removeDirect had the
          advantage of ignoring the configurable (DontDelete) attributes, but this is achievable
          using the DeletePropertyMode setting - and the disadvantage of failing delete static
          table properties. Last uses were one that was removed in bug #158295 (where failure to
          delete static properties was a problem), and as addressed in this patch removeDirect is
          being used to implement runtime enabled features. This only works because we currently
          force reification of all properties on the DOM prototype objects, so in effect there are
          no static properties. In order to make the code robust such that runtime enabled
          features would still work even if we were not reifying static properties (a change we
          may want to make) we should be calling deleteProperty in this case too.

        * runtime/JSObject.cpp:
        (JSC::JSObject::deleteProperty):
            - incorporated removeDirect functionality, added comments & ASSERT.
        (JSC::JSObject::removeDirect): Deleted.
            - removed.
        * runtime/JSObject.h:
            - removed removeDirect.

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

        Simplify Interpreter::StackFrame.
        https://bugs.webkit.org/show_bug.cgi?id=158498

        Reviewed by Saam Barati.

        Previously, Interpreter::StackFrame (which is used to capture info for
        Error.stack) eagerly extracts info out of CodeBlock and duplicates the work that
        CodeBlock does to compute line and column numbers (amongst other things).

        This patch does away with the eager extraction and only stashes the CodeBlock
        pointer in the Interpreter::StackFrame.  Instead, Interpreter::StackFrame will
        provide methods for computing the desired values on request later.

        One difference in implementation: the old StackFrame offers a sourceURL and a
        friendlySourceURL().  The only difference between the 2 is that for native
        functions, sourceURL returns an empty string, and friendlySourceURL() returns
        "[native code]".  This is how it affects the clients of StackFrame:

            - In the old code, the Error object's addErrorInfoAndGetBytecodeOffset() and
              the inspector's createScriptCallStackFromException() would check if
              sourceURL is empty.  If so, they will use this as an indicator to use
              alternate source info in the Error object e.g. url and line numbers from
              the parser that produced a SyntaxError.

            - In the new implementation, StackFrame only has a sourceURL() function that
              behaves like the old friendlySourceURL().  The client code which were
              relying on sourceURL being empty, will now explicitly check if the
              StackFrame is for native code using a new isNative() query in addition to
              the sourceURL being empty.  This achieve functional parity with the old
              behavior.

        Also fix Error.cpp's addErrorInfoAndGetBytecodeOffset() to take a bytecodeOffset
        pointer instead of a reference.  The bytecodeOffset arg is supposed to be
        optional, but was implemented in a unclear way.  This change clarifies it.

        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::createScriptCallStackFromException):
        * interpreter/Interpreter.cpp:
        (JSC::StackFrame::sourceID):
        (JSC::StackFrame::sourceURL):
        (JSC::StackFrame::functionName):
        (JSC::eval):
        (JSC::Interpreter::isOpcode):
        (JSC::StackFrame::computeLineAndColumn):
        (JSC::StackFrame::toString):
        (JSC::GetStackTraceFunctor::operator()):
        (JSC::StackFrame::friendlySourceURL): Deleted.
        (JSC::StackFrame::friendlyFunctionName): Deleted.
        (JSC::getStackFrameCodeType): Deleted.
        (JSC::StackFrame::expressionInfo): Deleted.
        * interpreter/Interpreter.h:
        (JSC::StackFrame::isNative):
        * runtime/Error.cpp:
        (JSC::addErrorInfoAndGetBytecodeOffset):
        (JSC::addErrorInfo):
        * runtime/Error.h:
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::finishCreation):

2016-06-08  Keith Miller  <keith_miller@apple.com>

        We should be able to lookup symbols by identifier in builtins
        https://bugs.webkit.org/show_bug.cgi?id=158530

        Reviewed by Mark Lam.

        This patch allows us to lookup the value of a symbol property on a
        object by identifier in builtins. Before, it was only possible to
        do so if we were directly emitting the bytecodes, such as in a
        for-of loop looking for Symbol.iterator. As we tier up we convert
        the builtin's get_by_val symbol lookups into get_by_id
        lookups. However, there is still a significant performance
        difference between get_by_id and get_by_val in the LLInt, where
        this transformation does not take place.

        In order to make this work we hijack BuiltinNames'
        m_publicToPrivateMap so that it points the @<symbol>Symbol to the
        appropriate vm symbol. This way when we lex the identifier it will
        become the appropriate symbol's identifier.  Currently, if the
        symbol is used to name a property in an object literal we will not
        keep a cache of the Symbol objects we have already seen. We could
        add a map for symbols but since we can only load symbols by
        identifier in builtins its likely not worth it. Additionally, even
        in builtins it is extremely rare to use Symbols in object
        literals.

        * builtins/ArrayConstructor.js:
        (from):
        * builtins/ArrayPrototype.js:
        (filter):
        (map):
        * builtins/BuiltinNames.h:
        (JSC::BuiltinNames::BuiltinNames):
        * builtins/BuiltinUtils.h:
        * builtins/GlobalObject.js:
        (speciesConstructor):
        * builtins/StringPrototype.js:
        (match):
        (intrinsic.StringPrototypeReplaceIntrinsic.replace):
        (search):
        (split):
        * builtins/TypedArrayConstructor.js:
        (from):
        * builtins/TypedArrayPrototype.js:
        (map):
        (filter):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): Deleted.
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitLoad):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):

2016-06-08  Rawinder Singh  <rawinder.singh-webkit@cisra.canon.com.au>

        [web-animations] Add Animatable, AnimationEffect, KeyframeEffect and Animation interface
        https://bugs.webkit.org/show_bug.cgi?id=156096

        Reviewed by Dean Jackson.

        Adds:
        - Animatable interface and implementation of getAnimations in Element
        - Interface and implementation for Document getAnimations method.
        - AnimationEffect interface and class stub.
        - KeyframeEffect interface and constructor implementation.
        - 'Animation' interface, constructor and query methods for effect and timeline.
        - Remove runtime condition on Web animation interfaces (compile time flag is specified).

        * runtime/CommonIdentifiers.h:

2016-06-08  Chris Dumez  <cdumez@apple.com>

        self.hasOwnProperty() does not work inside Web workers
        https://bugs.webkit.org/show_bug.cgi?id=158446
        <rdar://problem/26638397>

        Reviewed by Geoffrey Garen.

        Add a factory function to JSProxy to create a JSProxy without a target.
        Also make the setTarget() method public so that the target can now be
        set after creation. This is needed so that we can create a proxy for
        JSWorkerGlobalScope, then create the JSWorkerGlobalScope object,
        passing it the proxy and finally set the target on the proxy.

        * runtime/JSProxy.h:
        (JSC::JSProxy::create):

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

        Add result validation to JSAir
        https://bugs.webkit.org/show_bug.cgi?id=158493

        Reviewed by Saam Barati.
        
        Add a ::jsHash() method to some things, to compute a hash code that is suitable for
        comparing a C++ Code to a JSAir Code. This is different from existing hashing functionality
        because it errs on the side of easy reproducibility from JS rather than speed.

        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::isCompatibleType):
        (JSC::B3::Air::Arg::jsHash):
        (JSC::B3::Air::Arg::dump):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::asDoubleCondition):
        (JSC::B3::Air::Arg::isInvertible):
        (JSC::B3::Air::Arg::isUnsignedCond):
        (JSC::B3::Air::Arg::Arg):
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::addFastTmp):
        (JSC::B3::Air::Code::jsHash):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::lastPhaseName):
        * b3/air/AirDumpAsJS.cpp:
        (JSC::B3::Air::dumpAsJS):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        * b3/air/AirInst.cpp:
        (JSC::B3::Air::Inst::hasArgEffects):
        (JSC::B3::Air::Inst::jsHash):
        (JSC::B3::Air::Inst::dump):
        * b3/air/AirInst.h:
        * b3/air/AirStackSlot.cpp:
        (JSC::B3::Air::StackSlot::setOffsetFromFP):
        (JSC::B3::Air::StackSlot::jsHash):
        (JSC::B3::Air::StackSlot::dump):
        * b3/air/AirStackSlot.h:
        * b3/air/opcode_generator.rb:

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

        Need an exception check after constructEmptyArray().
        https://bugs.webkit.org/show_bug.cgi?id=158411

        Reviewed by Saam Barati.

        Added an exception check after each call to constructEmptyArray().

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        (Inspector::JSInjectedScriptHost::weakMapEntries):
        (Inspector::JSInjectedScriptHost::weakSetEntries):
        (Inspector::JSInjectedScriptHost::iteratorEntries):
        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::functionsOnStack):
        * profiler/ProfilerBytecodeSequence.cpp:
        (JSC::Profiler::BytecodeSequence::addSequenceProperties):
        * profiler/ProfilerCompilation.cpp:
        (JSC::Profiler::Compilation::toJS):
        * profiler/ProfilerDatabase.cpp:
        (JSC::Profiler::Database::toJS):
        * profiler/ProfilerOSRExitSite.cpp:
        (JSC::Profiler::OSRExitSite::toJS):
        * profiler/ProfilerOriginStack.cpp:
        (JSC::Profiler::OriginStack::toJS):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncConcat):
        (JSC::arrayProtoFuncSlice):
        (JSC::arrayProtoFuncSplice):
        * runtime/LiteralParser.cpp:
        (JSC::LiteralParser<CharType>::parse):
        * runtime/ModuleLoaderObject.cpp:
        (JSC::moduleLoaderObjectRequestedModules):
        * runtime/ObjectConstructor.cpp:
        (JSC::ownPropertyKeys):
        * runtime/RegExpObject.cpp:
        (JSC::collectMatches):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncSplitFast):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncSplitFast):
        * runtime/TemplateRegistry.cpp:
        (JSC::TemplateRegistry::getTemplateObject):

        * tests/stress/regress-158411.js: Added.

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

        Implement Air::allocateStack() in ES6 to see how much of a bad idea that is
        https://bugs.webkit.org/show_bug.cgi?id=158318

        Reviewed by Saam Barati.
        
        Most of these changes are to support dumpAsJS(). But I also found some duplicate and dead
        code while rewriting it to JS.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/AirAllocateStack.cpp:
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isSomeImm):
        (JSC::B3::Air::Arg::isAddr):
        (JSC::B3::Air::Arg::tmpIndex):
        (JSC::B3::Air::Arg::isValidImmForm):
        (JSC::B3::Air::Arg::withOffset): Deleted. This was dead code.
        * b3/air/AirArgInlines.h: It turns out that Inst has a ForEach thing that duplicated some of the logic of ArgThingHelper, so I just made ArgThingHelper more powerful.
        (JSC::B3::Air::ArgThingHelper<Arg>::forEach):
        (JSC::B3::Air::ArgThingHelper<Reg>::is):
        (JSC::B3::Air::ArgThingHelper<Reg>::as):
        (JSC::B3::Air::ArgThingHelper<Reg>::forEachFast):
        (JSC::B3::Air::ArgThingHelper<Reg>::forEach):
        (JSC::B3::Air::Arg::is):
        * b3/air/AirDumpAsJS.cpp: Added.
        (JSC::B3::Air::dumpAsJS):
        * b3/air/AirDumpAsJS.h: Added.
        * b3/air/AirFixObviousSpills.cpp:
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::forEach):
        (JSC::B3::Air::Inst::extraClobberedRegs):
        (JSC::B3::Air::ForEach<Tmp>::forEach): Deleted. This was doing what ArgThingHelper would have done but not as well.
        (JSC::B3::Air::ForEach<Arg>::forEach): Deleted.
        (JSC::B3::Air::ForEach<Reg>::forEach): Deleted.
        * b3/air/AirLogRegisterPressure.cpp:
        * b3/air/AirReportUsedRegisters.cpp:
        * b3/air/AirSpillEverything.cpp:
        * b3/air/opcode_generator.rb: Make this dump opcode.js, which is like what it dumps for C++.
        * jit/Reg.cpp:
        (JSC::Reg::debugName):
        (JSC::Reg::dump):
        * jit/Reg.h:
        (JSC::Reg::hash):
        * jsc.cpp: Fix jsc so that it reports the filename and line number of parser errors.
        (dumpException):
        * parser/ParserError.h: Make it easier to debug this code.
        (WTF::printInternal):
        * runtime/Options.h:

2016-06-07  Keith Rollin  <krollin@apple.com>

        Remove all uses of PassRefPtr in WTF
        https://bugs.webkit.org/show_bug.cgi?id=157596
        <rdar://problem/26234391>

        Reviewed by Chris Dumez.

        Update calls to interfaces that no longer take or return PassRefPtrs.

        * runtime/JSString.cpp:
        (JSC::JSRopeString::resolveRope):
        * runtime/JSString.h:
        (JSC::JSString::JSString):
        (JSC::jsSubstring):
        * runtime/PrivateName.h:
        (JSC::PrivateName::PrivateName):
        * runtime/SmallStrings.cpp:
        (JSC::SmallStringsStorage::SmallStringsStorage):
        * runtime/StringConstructor.cpp:
        (JSC::stringFromCharCodeSlowCase):
        * runtime/StringPrototype.cpp:
        (JSC::jsSpliceSubstrings):
        (JSC::jsSpliceSubstringsWithSeparators):
        (JSC::replaceUsingStringSearch):
        (JSC::repeatCharacter):
        (JSC::stringProtoFuncFontsize):
        (JSC::stringProtoFuncLink):
        (JSC::normalize):

2016-06-07  Saam barati  <sbarati@apple.com>

        InvalidationPointInjectionPhase creates bogus InvalidationPoints that may even be inserted when it's not OK to exit
        https://bugs.webkit.org/show_bug.cgi?id=158499
        <rdar://problem/26647473>

        Reviewed by Mark Lam and Benjamin Poulain.

        InvalidationPointInjectionPhase forgot to clear m_originThatHadFire 
        before analyzing the current block it's analyzing. This meant that
        the phase allowed a residual m_originThatHadFire that was set from the
        previous block to effect a completely unrelated block. This is usually
        harmless, but sometimes we would insert an InvalidationPoint at a point
        in the graph when exiting is invalid. This would cause a crash.

        * dfg/DFGInvalidationPointInjectionPhase.cpp:
        (JSC::DFG::InvalidationPointInjectionPhase::run):
        * tests/stress/dont-crash-on-bad-invalidation-point.js: Added.
        (dontCrash):

2016-06-07  Saam Barati  <sbarati@apple.com>

        operationProcessTypeProfilerLogDFG doesn't update topCallFrame
        https://bugs.webkit.org/show_bug.cgi?id=158428
        <rdar://problem/26571493>

        Reviewed by Mark Lam.

        * dfg/DFGOperations.cpp:

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

        calculatedDisplayName() and friends actually need a VM& and not a ExecState/CallFrame.
        https://bugs.webkit.org/show_bug.cgi?id=158488

        Reviewed by Geoffrey Garen.

        calculatedDisplayName() (and some of its friends) actually just need a VM&.
        Their work has nothing to do with an ExecState at all.  This patch will make that
        clear by changing these functions to take a VM& arg instead of an ExecState* or
        CallFrame*.

        Also removed the JS_EXPORT_PRIVATE attribute from Interpreter::StackFrame::toString().
        The JS_EXPORT_PRIVATE attribute was a holdover from the days when WebInspector
        was entirely in WebCore.  It is no longer needed.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::functionName):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::functionDetails):
        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::createScriptCallStackFromException):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::friendlyFunctionName):
        * interpreter/Interpreter.cpp:
        (JSC::StackFrame::friendlySourceURL):
        (JSC::StackFrame::friendlyFunctionName):
        (JSC::StackFrame::expressionInfo):
        (JSC::StackFrame::toString):
        (JSC::Interpreter::stackTraceAsString):
        * interpreter/Interpreter.h:
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::functionName):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::name):
        (JSC::InternalFunction::displayName):
        (JSC::InternalFunction::getCallData):
        (JSC::InternalFunction::calculatedDisplayName):
        * runtime/InternalFunction.h:
        (JSC::InternalFunction::createStructure):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::name):
        (JSC::JSFunction::displayName):
        (JSC::JSFunction::calculatedDisplayName):
        (JSC::JSFunction::getConstructData):
        (JSC::getCalculatedDisplayName):
        * runtime/JSFunction.h:
        (JSC::JSFunction::executable):
        * runtime/JSObject.cpp:
        (JSC::JSObject::calculatedClassName):

2016-06-07  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Do not allocate unnecessary UTF-8 string for encodeXXX functions
        https://bugs.webkit.org/show_bug.cgi?id=158416

        Reviewed by Darin Adler and Geoffrey Garen.

        Previously, encodeXXX functions first allocate new UTF-8 string, and generate (& allocate) the results from this UTF-8 string.
        It is costly since this UTF-8 string is always wasted. In this patch, we generate the results without this UTF-8 string.
        We precisely implement ECMA262's Encode abstract operation[1].

        This optimized encodeXXX functions provide great improvement in kraken stanford-crypto-sha256-iterative since it frequently calls
        these functions. We can see 6 - 7% improvements.

                                                      baseline                  patched

        stanford-crypto-sha256-iterative           37.952+-0.155      ^      35.484+-0.265         ^ definitely 1.0695x faster


        [1]: https://tc39.github.io/ecma262/#sec-encode

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::toSafeView):
        Use this helper function to retrieve JSString::SafeView.

        (JSC::makeCharacterBitmap):
        (JSC::encode):
        In encode, we reserve N length buffer at first. This is important when the length of the given string is long enough,
        preventing frequent unnecessary buffer reallocations. This reserving contributes to 1% kraken stanford-crypto-sha256-iterative progression.

        (JSC::decode):
        Previously, Bitmap accidentally includes \0. And instead of removing this \0, we checked character != 0.
        This patch fixes it for the Bitmap not to include \0.

        (JSC::globalFuncParseInt):
        (JSC::globalFuncEscape):
        (JSC::globalFuncUnescape):
        * tests/stress/encode-decode-ascii.js: Added.
        (shouldBe):
        * tests/stress/encode-decode-unicode.js: Added.
        (shouldBe):
        (isLowSurrogate):
        (isHighSurrogate):
        (isSurrogate):
        * tests/stress/encode-decode-uri-component-surrogates.js: Added.
        (shouldBe):
        (toHighSurrogate):
        (toLowSurrogate):
        * tests/stress/encode-decode-uri-surrogates.js: Added.
        (shouldBe):
        (toHighSurrogate):
        (toLowSurrogate):
        * tests/stress/encode-decode-zero.js: Added.
        (shouldBe):
        * tests/stress/escape-unescape-surrogates.js: Added.
        (shouldBe):
        (toHighSurrogate):
        (toLowSurrogate):

2016-06-07  Ting-Wei Lan  <lantw44@gmail.com>

        [GTK] Include locale.h before using LC_ALL
        https://bugs.webkit.org/show_bug.cgi?id=158470

        Reviewed by Darin Adler.

        * jsc.cpp:

2016-06-07  Joseph Pecoraro  <pecoraro@apple.com>

        Unskip generator related stress tests
        https://bugs.webkit.org/show_bug.cgi?id=158461

        Reviewed by Darin Adler.

        * tests/stress/generator-methods.js:
        * tests/stress/generator-syntax.js:
        * tests/stress/yield-and-line-terminator.js:
        * tests/stress/yield-label-generator.js:
        * tests/stress/yield-named-accessors-generator.js:
        * tests/stress/yield-named-variable-generator.js:
        * tests/stress/yield-out-of-generator.js:

2016-06-06  Joseph Pecoraro  <pecoraro@apple.com>

        Fix typo in test name trailing-comma-in-function-paramters.js
        https://bugs.webkit.org/show_bug.cgi?id=158462

        Reviewed by Mark Lam.

        * tests/stress/trailing-comma-in-function-parameters.js: Renamed from Source/JavaScriptCore/tests/stress/trailing-comma-in-function-paramters.js.

2016-06-06  Andreas Kling  <akling@apple.com>

        REGRESSION(r197595): 2% JSBench regression on iPhone 5.
        <https://webkit.org/b/158459>

        Unreviewed rollout.

        * runtime/VM.cpp:
        (JSC::VM::deleteAllRegExpCode): Deleted.
        * runtime/VM.h:

2016-06-06  Michael Saboff  <msaboff@apple.com>

        octal and binary parsing is wrong for some programs
        https://bugs.webkit.org/show_bug.cgi?id=158437

        Reviewed by Saam Barati.

        When there is an error parsing an binary or octal literal, we need to clear the returnValue
        of any residual value.  This is because the processing of returnValue happens before the
        syntax check for the extra character.  Without clearing returnValue, we end trying to
        categorize the value as an INTEGER or DOUBLE token.  If the value happens to be an
        impure NaN, we ASSERT.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::parseBinary):
        (JSC::Lexer<T>::parseOctal):
        * tests/stress/regress-158437.js: New test.

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

        32-bit JSC stress test failing: stress/recursive-try-catch.js.ftl-no-cjit-validate-sampling-profiler
        https://bugs.webkit.org/show_bug.cgi?id=158362

        Reviewed by Michael Saboff.

        The test does infinite recursion until it overflows the stack.  That means the
        sampling profiler will have to capture excessively large samples, which in turn
        makes it run very slowly.  This is what causes the test time out.

        The fix is to not run the test with the sampling profiler.

        * tests/stress/recursive-try-catch.js:

2016-06-06  Andreas Kling  <akling@apple.com>

        Don't reportAbandonedObjectGraph() after throwing out linked code or RegExps.
        <https://webkit.org/b/158444>

        Unreviewed.

        This is a speculative change for iOS performance bots. The calls to reportAbandonedObjectGraph
        were basically redundant, since mainframe navigation will cause GC acceleration anyway via
        ScriptController.

        This appears successful at recovering the ~0.7% regression I could reproduce locally on newer
        hardware but it's a bit too noisy to say for sure.

        * runtime/VM.cpp:
        (JSC::VM::deleteAllLinkedCode):
        (JSC::VM::deleteAllRegExpCode):

2016-06-06  Skachkov Oleksandr  <gskachkov@gmail.com>
        [ESNext] Trailing commas in function parameters.
        https://bugs.webkit.org/show_bug.cgi?id=158020

        Reviewed by Keith Miller.

        ESNext allow to add trailing commas in function parameters and function arguments.
        Link to spec - https://jeffmo.github.io/es-trailing-function-commas 
        Example of using - (function (a, b,) { return a + b; })(1,2,);

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFormalParameters):
        (JSC::Parser<LexerType>::parseArguments):
        * tests/stress/trailing-comma-in-function-paramters.js: Added.

2016-06-05  Gavin & Ellie Barraclough  <barraclough@apple.com>

        Deprecate remaining uses of Lookup getStatic*, use HasStaticPropertyTable instead.
        https://bugs.webkit.org/show_bug.cgi?id=158178

        Reviewed by Darin Adler.

        As of bug #158059 most JSC static table property access no longer requires getOwnPropertySlot to be
        overridden. Port remaining calls to the getStatic* functions in Lookup.h over to the new mechanism.

        Deprecate getStatic* functions in Lookup.h

        * runtime/Lookup.h:
        (JSC::getStaticPropertySlot): Deleted.
        (JSC::getStaticFunctionSlot): Deleted.
        (JSC::getStaticValueSlot): Deleted.
            - No longer required. Static table access now via JSObject.

2016-06-06  Guillaume Emont  <guijemont@igalia.com>

        [jsc][mips] Implement absDouble()
        https://bugs.webkit.org/show_bug.cgi?id=158206

        Reviewed by Mark Lam.

        Implement absDouble() for MIPS. This is needed because Math.pow() uses
        it since r200208.

        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::absd):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::absDouble):

2016-06-03  Oliver Hunt  <oliver@apple.com>

        RegExp unicode parsing reads an extra character before failing
        https://bugs.webkit.org/show_bug.cgi?id=158376

        Reviewed by Saam Barati.

        This was a probably harmless bug, but keeps triggering assertions
        for me locally. Essentially we'd see a parse error, set the error
        type, but then carry on parsing. In debug builds this asserts, in
        release builds you are pretty safe unless you're exceptionally
        unlucky with where the error occurs.

        * yarr/YarrParser.h:
        (JSC::Yarr::Parser::parseEscape):

2016-06-06  Guillaume Emont  <guijemont@igalia.com>

        [jsc][mips] fix JIT::emit_op_log_shadow_chicken_prologue/_tail
        https://bugs.webkit.org/show_bug.cgi?id=158209

        Reviewed by Mark Lam.

        On MIPS, changes GPRInfo::nonArgGPR0 to be regT4 instead of regT0,
        since the code of JIT::emit_op_log_shadow_chicken_prologue/_tail()
        expects nonArgGPR0 to be a different register from regT0 and regT2.

        * jit/GPRInfo.h:

2016-06-06  Chris Dumez  <cdumez@apple.com>

        Crash under JSObject::getOwnPropertyDescriptor()
        https://bugs.webkit.org/show_bug.cgi?id=158382
        <rdar://problem/26605004>

        Reviewed by Mark Lam.

        * runtime/JSObject.h:
        (JSC::JSObject::putDirectInternal):
        We were crashing under getOwnPropertyDescriptor() because the
        CustomAccessor was not properly reset on window.statusbar when
        setting it to false (which is allowed because the property is
        marked as [Replaceable] in the IDL). We now property reset the
        CustomAccessor flag in putDirectInternal() when needed. This
        fixes the crash.

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

        [EFL] Move efl include paths to JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES
        https://bugs.webkit.org/show_bug.cgi?id=158418

        Reviewed by Csaba Osztrogonác.

        In Source/JavaScriptCore/PlatformEfl.cmake, we don't use JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES
        for efl include paths.

        * PlatformEfl.cmake:
        * tests/stress/encode-decode-ascii.js: Added.
        (shouldBe):
        * tests/stress/encode-decode-unicode.js: Added.
        (shouldBe):
        (isLowSurrogate):
        (isHighSurrogate):
        (isSurrogate):
        * tests/stress/encode-decode-uri-component-surrogates.js: Added.
        (shouldBe):
        (toHighSurrogate):
        (toLowSurrogate):
        * tests/stress/encode-decode-uri-surrogates.js: Added.
        (shouldBe):
        (toHighSurrogate):
        (toLowSurrogate):
        * tests/stress/encode-decode-zero.js: Added.
        (shouldBe):
        * tests/stress/escape-unescape-surrogates.js: Added.
        (shouldBe):
        (toHighSurrogate):
        (toLowSurrogate):

2016-06-05  Yusuke Suzuki  <utatane.tea@gmail.com>

        Change ProxyObject.[[Get]] not to use custom accessor
        https://bugs.webkit.org/show_bug.cgi?id=157080

        Reviewed by Darin Adler.

        This patch focuses on introducing the second part of the followings.
        But to do so, first and third parts are necessary.

        1. Insert missing exception checks for getPropertySlot.

            While getPropertySlot can perform user-observable behavior if the slot is not VMInquiry,
            several places miss exeption checks. For example, ProxyObject's hasProperty already can
            throw any errors. Looking through the code, we found several missing error checks after
            hasProperty, but this will be fixed in the separated patch[1].

        2. Do not use custom accessor to implement ProxyObject's [[Get]].

            The caller already allows getOwnPropertySlot to throw an exception if the type
            is not VMInquiry. So instead of using custom accessor, we simply implement it
            directly in the ProxyObject's method.

        3. Strip slotBase from custom accessor.

            The custom accessor should not be bound to the specific slot base[2], since it
            is just an accessor. There is an alternative design: makeing this custom accessor
            to custom value accessor and accept both the slot base and the receiver instead
            of allowing throwing an error from getOwnPropertySlot. But we take the first design
            that allows getPropertySlot to throw an error, since hasProperty (that does not call
            getValue of the custom getters) can already throw any errors.

            To query the property with the non-user-observable way, we already provided the way for that:
            use VMInquiry and isTaintedByProxy() instead.

        Tests just ensure that the current semantics works correctly after this patch.
        And this patch is performance neutral.

        Later, we will attempt to rename "thisValue" to "receiver"[3].

        [1]: https://bugs.webkit.org/show_bug.cgi?id=158398
        [2]: https://bugs.webkit.org/show_bug.cgi?id=157978
        [3]: https://bugs.webkit.org/show_bug.cgi?id=158397

        * API/JSCallbackObject.h:
        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::staticFunctionGetter):
        (JSC::JSCallbackObject<Parent>::callbackGetter):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):
        * dfg/DFGOperations.cpp:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * jit/JITOperations.cpp:
        * jsc.cpp:
        (WTF::ImpureGetter::getOwnPropertySlot):
        (WTF::CustomGetter::customGetter):
        (WTF::RuntimeArray::lengthGetter):
        (GlobalObject::finishCreation):
        (GlobalObject::moduleLoaderFetch):
        (functionGetGetterSetter):
        (functionRun):
        (functionLoad):
        (functionLoadString):
        (functionReadFile):
        (functionCheckSyntax):
        (functionLoadWebAssembly):
        (functionLoadModule):
        (functionCreateBuiltin):
        (functionCheckModuleSyntax):
        (dumpException):
        (runWithScripts):
        (runInteractive):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSBoundSlotBaseFunction.cpp:
        (JSC::boundSlotBaseFunctionCall):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::getPropertySlot):
        * runtime/JSCellInlines.h:
        (JSC::ExecState::vm):
        This change is super important for performance. We add several `exec->hadException()` calls into the super hot path, like JSC::operationGetByIdOptimize.
        Without this change, we call ExecState::vm() and it is not inlined. This causes 1 - 2% performance regression in Octane PDFJS.

        * runtime/JSFunction.cpp:
        (JSC::JSFunction::argumentsGetter):
        (JSC::JSFunction::callerGetter):
        * runtime/JSFunction.h:
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewWithArguments):
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::callbackGetter):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Holder::appendNextProperty):
        Here's UNLIKELY is important for Kraken's json-stringify-tinderbox. Without it, we can observe 0.5% regression.

        (JSC::Walker::walk):
        * runtime/JSObject.h:
        (JSC::JSObject::getPropertySlot):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString):
        * runtime/PropertySlot.cpp:
        (JSC::PropertySlot::customGetter):
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::thisValue):
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performGet):
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        * runtime/ProxyObject.h:
        * runtime/RegExpConstructor.cpp:
        (JSC::regExpConstructorDollar):
        (JSC::regExpConstructorInput):
        (JSC::regExpConstructorMultiline):
        (JSC::regExpConstructorLastMatch):
        (JSC::regExpConstructorLastParen):
        (JSC::regExpConstructorLeftContext):
        (JSC::regExpConstructorRightContext):
        * tests/stress/get-from-scope-dynamic-onto-proxy.js: Added.
        (shouldBe):
        (shouldThrow.handler.has):
        (handler.has):
        (try.handler.has):
        * tests/stress/operation-in-throw-error.js: Added.
        (testCase.handler.has):
        (testCase):
        * tests/stress/proxy-and-json-stringify.js: Added.
        (shouldThrow):
        * tests/stress/proxy-and-typed-array.js: Added.
        * tests/stress/proxy-json-path.js: Added.
        * tests/stress/proxy-with-statement.js: Added.

2016-06-03  Gavin & Ellie Barraclough  <barraclough@apple.com>

        Deprecate remaining uses of Lookup getStatic*, use HasStaticPropertyTable instead.
        https://bugs.webkit.org/show_bug.cgi?id=158178

        Reviewed by Darin Adler.

        As of bug #158059 most JSC static table property access no longer requires getOwnPropertySlot to be
        overridden. Port remaining calls to the getStatic* functions in Lookup.h over to the new mechanism.

        Part 1: Switch JSGlobalObject & JSDOMWindow to use HasStaticPropertyTable.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::getOwnPropertySlot):
            - Override is still required for symbol table,
              but regular property access is now via Base::getOwnPropertySlot.
        * runtime/JSGlobalObject.h:
            - add HasStaticPropertyTable to structureFlags.

2016-06-03  Benjamin Poulain  <bpoulain@apple.com>

        Eager FTL failure for strict comparison of NaN with number check
        https://bugs.webkit.org/show_bug.cgi?id=158368

        Reviewed by Darin Adler.

        DoupleRep with a RealNumberUse starts by handling double
        then falls back to Int32 if the unboxed double is NaN.

        Before handling integers, the code is checking if the input
        is indeed an int32. The problem was that this check failed
        to account for NaN as an original input of the DoubleRep.

        The call to isNotInt32() filter the doubles checks because
        that was handled by the previous block.
        The problem is the previous block handles any double except NaN.
        If the original input was NaN, the masking by "~SpecFullDouble"
        filter that possibility and isNotInt32() fails to test that case.

        This patch fixes the issue by changing the filter to SpecDoubleReal.
        The type SpecDoubleReal does not include the NaN types.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep):
        * tests/stress/double-rep-real-number-use-on-nan.js: Added.
        To ensure the isNotInt32() does not test anything, we want
        proven numbers as input. The (+value) are there to enforce
        a ToNumber() which in turn give us a proven Number type.

2016-06-03  Benjamin Poulain  <bpoulain@apple.com>

        JSON.stringify replacer function calls with numeric array indices
        https://bugs.webkit.org/show_bug.cgi?id=158262
        rdar://problem/26613876

        Reviewed by Saam Barati.

        The spec of SerializeJSONArray is pretty clear that the index
        should be transformed into a string before calling SerializeJSONProperty.
        See http://www.ecma-international.org/ecma-262/6.0/#sec-serializejsonarray

        * runtime/JSONObject.cpp:
        (JSC::PropertyNameForFunctionCall::value):

2016-06-03  Saam barati  <sbarati@apple.com>

        Proxy.ownKeys should no longer throw an exception when duplicate keys are returned and the target is non-extensible
        https://bugs.webkit.org/show_bug.cgi?id=158350
        <rdar://problem/26626211>

        Reviewed by Michael Saboff.

        The spec was recently changes in Proxy [[OwnPropertyKeys]]
        to allow for duplicate property names under certain circumstances.
        This patch fixes our implementation to match the spec.
        See: https://github.com/tc39/ecma262/pull/594

        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performGetOwnPropertyNames):
        * tests/stress/proxy-own-keys.js:
        (i.catch):
        (ownKeys):
        (assert):

2016-06-03  Saam barati  <sbarati@apple.com>

        Some shadow chicken code is wrong when run on a big endian CPU
        https://bugs.webkit.org/show_bug.cgi?id=158361

        Reviewed by Mark Lam.

        This code was wrong on a big endian CPU, and it was
        also an anti-pattern in the file. The code was harmless
        on a little endian CPU, but it's better to remove it.

        * llint/LowLevelInterpreter64.asm:

2016-06-03  Keith Miller  <keith_miller@apple.com>

        Add argument_count bytecode for concat
        https://bugs.webkit.org/show_bug.cgi?id=158358

        Reviewed by Geoffrey Garen.

        This patch adds a new argument count bytecode. Normally, we would
        just make sure that the argument.length bytecode was fast enough
        that we shouldn't need such an bytecode.  However, for the case of
        Array.prototype.concat the overhead of the arguments object
        allocation in the LLInt was too high and caused regressions.

        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_argumentCount):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getArgumentCount):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_argument_count):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * tests/stress/argument-count-bytecode.js: Added.
        (inlineCount):
        (inlineCount1):
        (inlineCount2):
        (inlineCountVarArgs):
        (assert):

2016-06-03  Geoffrey Garen  <ggaren@apple.com>

        Clients of PolymorphicAccess::addCases shouldn't have to malloc
        https://bugs.webkit.org/show_bug.cgi?id=158357

        Reviewed by Keith Miller.

        We only ever have 1 or 2 cases, so we can use inline Vector capacity.

        This shows up a little in the JSBench profile.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::addCases):
        (JSC::PolymorphicAccess::addCase):
        * bytecode/PolymorphicAccess.h:
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::addAccessCase):

2016-06-03  Benjamin Poulain  <bpoulain@apple.com>

        Fix some more INFINITI->INFINITY typos

        Unreviewed.

        The tests were not covering the edge cases they were supposed to test.

        * tests/stress/math-ceil-basics.js:
        (testMathCeilOnConstants):
        * tests/stress/math-clz32-basics.js:
        (testMathClz32OnDoubles):
        (testMathClz32OnConstants):
        * tests/stress/math-floor-basics.js:
        (testMathFloorOnConstants):
        * tests/stress/math-round-basics.js:
        (testMathRoundOnConstants):
        * tests/stress/math-trunc-basics.js:
        (testMathTruncOnConstants):

2016-06-02  Gavin & Ellie Barraclough  <barraclough@apple.com>

        JSGlobalObject::addFunction should call deleteProperty rather than removeDirect
        https://bugs.webkit.org/show_bug.cgi?id=158295

        Reviewed by Saam Barati.

        When a function in declared in program code, this replaces any previosly existing
        property from the global object. JSGlobalObject::addFunction is currently calling
        removeDirect rather than deleteProperty to remove the existing property. This fails
        to remove any properties from static tables.

        We currently get away with this because (a) JSObject & JSGlobalObject don't currently
        have any properties in static tables, and (b) the current quirky property precedence
        means that the symbol table properties end up taking precedence over JSDOMWindow's
        static table, so window object properties end up being shadowed.

        As a part of bug #158178 the precedence of static tables will change, requiring this
        to be fixed.

        The deleteProperty function does what we want (has the ability to remove properties,
        including those from the static tables). Normally deleteProperty will not remove
        properties that are non-configurable (DontDelete) - we need to do so. The function
        does already support this, through a flag on VM named 'isInDefineOwnProperty', which
        causes configurability to be ignored. Generalize this mechanism for use outside of
        defineOwnProperty, renaming & moving DefineOwnPropertyScope helper class out to VM.

        * runtime/JSFunction.cpp:
        (JSC::JSFunction::deleteProperty):
            - isInDefineOwnProperty -> deletePropertyMode.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::addFunction):
            - removeDirect -> deleteProperty.
        * runtime/JSObject.cpp:
        (JSC::JSObject::deleteProperty):
            - isInDefineOwnProperty -> deletePropertyMode.
        (JSC::JSObject::defineOwnNonIndexProperty):
            - DefineOwnPropertyScope -> VM::DeletePropertyModeScope.
        (JSC::DefineOwnPropertyScope::DefineOwnPropertyScope): Deleted.
        (JSC::DefineOwnPropertyScope::~DefineOwnPropertyScope): Deleted.
            - DefineOwnPropertyScope -> VM::DeletePropertyModeScope.
        * runtime/VM.cpp:
        (JSC::VM::VM):
            - removed m_inDefineOwnProperty.
        * runtime/VM.h:
        (JSC::VM::deletePropertyMode):
            - isInDefineOwnProperty -> deletePropertyMode.
        (JSC::VM::DeletePropertyModeScope::DeletePropertyModeScope):
        (JSC::VM::DeletePropertyModeScope::~DeletePropertyModeScope):
            - DefineOwnPropertyScope -> VM::DeletePropertyModeScope.
        (JSC::VM::setInDefineOwnProperty): Deleted.
            - Replaced with deletePropertyMode, can now only be set via VM::DeletePropertyModeScope.
        (JSC::VM::isInDefineOwnProperty): Deleted.
            - isInDefineOwnProperty -> deletePropertyMode.

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

        ARMv7 vstm and vldm instructions can only operate on a maximum of 16 registers.
        https://bugs.webkit.org/show_bug.cgi?id=158349

        Reviewed by Filip Pizlo.

        According to the ARM Assembler Reference, the vstm and vldm instructions can only
        operate on a maximum of 16 registers.  See
        http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0002a/ch01s03s02.html
        and http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0002a/ch01s03s02.html.

        The ARMv7 probe code was wrongly using these instructions to store and load all
        32 'd' registers.  This is now fixed.

        * assembler/MacroAssemblerARMv7.cpp:

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

        Gardening: CLOOP build fix (needs a #include).

        Not reviewed.

        * interpreter/StackVisitor.h:

2016-06-03  Andreas Kling  <akling@apple.com>

        Eliminate two large sources of temporary StringImpl objects.
        <https://webkit.org/b/158336>

        Reviewed by Anders Carlsson.

        We were jumping through some inefficient hoops when creating Identifiers due to the
        convenience of our String(const char*) constructor.

        This patch avoids just over 1 million temporary StringImpl objects on the PLUM benchmark.

        * runtime/JSObject.h:
        (JSC::makeIdentifier): Add an overload for string literals so we can stop creating a temporary
        String just for passing to Identifier::fromString().

        * runtime/Lookup.h:
        (JSC::reifyStaticProperties): Use the Identifier::fromString() that takes an LChar* and a length
        instead of creating a temporary String.

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

        Clean up how StackVisitor dumps its frames.
        https://bugs.webkit.org/show_bug.cgi?id=158316

        Reviewed by Keith Miller.

        1. Updated to do dumping to a PrintStream.
        2. Added support for printing a prefix for each frame.
           This is currently used by JSDollarVMPrototype to print frame numbers.
        3. Fix the incrementing of the frame index in StackVisitor.
           It was initialized but never incremented before when iterating the frames.

        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::gotoNextFrame):
        (JSC::StackVisitor::Frame::codeType):
        (JSC::StackVisitor::Frame::functionName):
        (JSC::StackVisitor::Frame::sourceURL):
        (JSC::StackVisitor::Frame::toString):
        (JSC::StackVisitor::Frame::createArguments):
        (JSC::StackVisitor::Frame::computeLineAndColumn):
        (JSC::StackVisitor::Frame::retrieveExpressionInfo):
        (JSC::StackVisitor::Frame::setToEnd):
        (JSC::StackVisitor::Frame::dump):
        (JSC::StackVisitor::Indent::dump):
        (JSC::printIndents): Deleted.
        (JSC::log): Deleted.
        (JSC::logF): Deleted.
        (JSC::StackVisitor::Frame::print): Deleted.
        * interpreter/StackVisitor.h:
        (JSC::StackVisitor::Indent::Indent):
        (JSC::StackVisitor::Indent::operator++):
        (JSC::StackVisitor::Indent::operator--):
        (JSC::StackVisitor::Frame::isJSFrame):
        (JSC::StackVisitor::Frame::isInlinedFrame):
        (JSC::StackVisitor::Frame::vmEntryFrame):
        (JSC::StackVisitor::Frame::callFrame):
        (JSC::StackVisitor::Frame::Frame):
        (JSC::StackVisitor::Frame::~Frame):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::PrintFrameFunctor::operator()):

2016-06-02  Saam Barati  <sbarati@apple.com>

        global lexical environment variables are not accessible through functions created using the function constructor
        https://bugs.webkit.org/show_bug.cgi?id=158319

        Reviewed by Filip Pizlo.

        When creating a function using the Function constructor, we were
        using the global object instead of the global lexical environment
        as the function's scope. We should be using the global lexical environment.

        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * tests/stress/function-constructor-reading-from-global-lexical-environment.js: Added.
        (assert):
        (test):
        (ClassTDZ):

2016-06-02  Oliver Hunt  <oliver@apple.com>

        JS parser incorrectly handles invalid utf8 in error messages.
        https://bugs.webkit.org/show_bug.cgi?id=158128

        Reviewed by Saam Barati.

        The bug here was caused by us using PrintStream's toString method
        to produce the error message for a parse error, even though toString
        may produce a null string in the event of invalid utf8 that causes
        the error in first case. So when we try to create an error message
        containing the invalid character code, we set m_errorMessage to the
        null string, as that signals "no error" we don't stop parsing, and
        everything goes down hill from there.

        Now we use the new toStringWithLatin1Fallback so that we can always
        produce an error message, even if it contains invalid unicode. We
        also add an additional fallback so that we can guarantee an error
        message is set even if we're given a null string. There's a debug
        mode assertion to prevent anyone accidentally attempting to clear
        the message via setErrorMessage.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::logError):
        * parser/Parser.h:
        (JSC::Parser::setErrorMessage):

2016-06-02  Saam Barati  <sbarati@apple.com>

        Teach bytecode liveness about the debugger
        https://bugs.webkit.org/show_bug.cgi?id=158288

        Reviewed by Filip Pizlo.

        There was a bug where we wouldn't always keep the scope register
        on the stack when the debugger is enabled. The debugger always assumes
        it can read from the scope. The bug happened in OSR exit from the FTL.
        The FTL uses bytecode liveness for OSR exit. Bytecode liveness proved
        that the scope register was dead, so the FTL OSR exit wrote `undefined`
        into the scope's stack slot when OSR exiting to the baseline.

        To fix this, I taught bytecode liveness' computeUsesForBytecodeOffset() that the
        scope is used by every instruction except op_enter. This causes the
        scope to be live-in at every instruction except op_enter.

        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::blockContainsBytecodeOffset):
        (JSC::addAlwaysLiveLocals):
        (JSC::findBasicBlockForBytecodeOffset):
        (JSC::stepOverInstruction):
        (JSC::computeLocalLivenessForBytecodeOffset):
        (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * tests/stress/shadow-chicken-reading-from-scope-after-ftl-osr-exit-bytecode-liveness.js: Added.
        (foo):
        (catch):

2016-06-02  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r200694): %ThrowTypeError% is not unique
        https://bugs.webkit.org/show_bug.cgi?id=158231

        Reviewed by Joseph Pecoraro.

        The ES6 standard in section 9.2.7.1 states that %ThrowTypeError% is unique.  This
        change reverts the handling of TypeError before r200694 and then rolls in
        throwTypeErrorGetterSetter() with the renamed throwTypeErrorArgumentsCalleeAndCallerGetterSetter().

        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::getOwnPropertySlot):
        (JSC::ClonedArguments::materializeSpecials):
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::finishCreation):
        (JSC::JSBoundFunction::visitChildren):
        * runtime/JSFunction.cpp:
        (JSC::getThrowTypeErrorGetterSetter):
        (JSC::JSFunction::callerGetter):
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::regExpProtoSymbolReplaceFunction):
        (JSC::JSGlobalObject::regExpProtoGlobalGetter):
        (JSC::JSGlobalObject::regExpProtoUnicodeGetter):
        (JSC::JSGlobalObject::throwTypeErrorArgumentsCalleeAndCallerGetterSetter):
        (JSC::JSGlobalObject::moduleLoader):
        (JSC::JSGlobalObject::throwTypeErrorGetterSetter): Deleted.
        (JSC::JSGlobalObject::throwTypeErrorCalleeAndCallerGetterSetter): Deleted.
        (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInStrictModeGetterSetter): Deleted.
        (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInClassContextGetterSetter): Deleted.
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncThrowTypeError):
        (JSC::globalFuncThrowTypeErrorArgumentsCalleeAndCaller):
        (JSC::globalFuncThrowTypeErrorCalleeAndCaller): Deleted.
        (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInStrictMode): Deleted.
        (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInClassContext): Deleted.
        * runtime/JSGlobalObjectFunctions.h:
        * tests/stress/reflect-set.js:

2016-06-02  Michael Saboff  <msaboff@apple.com>

        [iOS]: Some JSC stress tests fail running out of executable memory when the LLInt is disabled
        https://bugs.webkit.org/show_bug.cgi?id=158317

        Reviewed by Saam Barati.

        Updated these test to not run the "no-llint" variant when running on ARM machines.

        * tests/stress/arrowfunction-lexical-bind-superproperty.js: Skip no-llint for ARM
        (testCase):
        * tests/stress/proxy-revoke.js: Skipp no-lint for ARM and ARM64
        (assert):

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

        Unreviewed, reland r201532. The associated regressions have been fixed
        by r201584.

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

        Use "= delete" for Locker(int) 

        Rubber stamped by Saam Barati.

        * runtime/ConcurrentJITLock.h:
        (JSC::ConcurrentJITLocker::ConcurrentJITLocker):

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

        ObjectPropertyCondition should have a isStillValidAssumingImpurePropertyWatchpoint function
        https://bugs.webkit.org/show_bug.cgi?id=158308

        Reviewed by Filip Pizlo.

        Recently, structureEnsuresValidityAssumingImpurePropertyWatchpoint was converted to check
        what should be isStillValidAssumingImpurePropertyWatchpoint. This patch fixes the API so
        it should work as expected. This patch also changes generateConditions in
        ObjectPropertyConditionSet to use isStillValidAssumingImpurePropertyWatchpoint.

        * bytecode/ObjectPropertyCondition.cpp:
        (JSC::ObjectPropertyCondition::structureEnsuresValidityAssumingImpurePropertyWatchpoint):
        (JSC::ObjectPropertyCondition::isStillValidAssumingImpurePropertyWatchpoint):
        * bytecode/ObjectPropertyCondition.h:
        * bytecode/ObjectPropertyConditionSet.cpp:

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

        Make it harder to accidentally pass an integer to a locker.

        Rubber stamped by Keith Miller.

        * runtime/ConcurrentJITLock.h:
        (JSC::ConcurrentJITLocker::ConcurrentJITLocker):

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

        Make it easier to use NoLockingNecessary
        https://bugs.webkit.org/show_bug.cgi?id=158306

        Reviewed by Keith Miller.
        
        Adapt to the new NoLockingNecessary API. More details in the WTF ChangeLog.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::instantiateLexicalVariables):
        (JSC::BytecodeGenerator::emitPrefillStackTDZVariables):
        (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
        (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
        (JSC::BytecodeGenerator::popLexicalScopeInternal):
        (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
        (JSC::BytecodeGenerator::variable):
        (JSC::BytecodeGenerator::createVariable):
        (JSC::BytecodeGenerator::emitResolveScope):
        (JSC::BytecodeGenerator::emitPushFunctionNameScope):
        * runtime/ConcurrentJITLock.h:
        (JSC::ConcurrentJITLockerBase::ConcurrentJITLockerBase):
        (JSC::ConcurrentJITLocker::ConcurrentJITLocker):

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

        Structure::previousID() races with Structure::allocateRareData()
        https://bugs.webkit.org/show_bug.cgi?id=158280

        Reviewed by Mark Lam.
        
        The problem is that previousID() would test hasRareData() and then either load the
        previous Structure from the rare data, or load it directly. allocateRareData() would set
        the hasRareData() bit separately from moving the Structure pointer into the rare data. So
        we'd have a race that would cause previousID() to sometimes return the rarae data instead
        of the previous Structure.

        The fix is to get rid of the hasRareData bit. We can use the structureID of the
        previousOrRareData cell to determine if it's the previousID or the RareData. This fixes the
        race and it's probably not any slower.

        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        (JSC::Structure::allocateRareData):
        * runtime/Structure.h:

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

        Runaway WebContent process CPU & memory @ foxnews.com
        https://bugs.webkit.org/show_bug.cgi?id=158290

        Reviewed by Mark Lam.

        Clear the thrown value at the end of the catch block so that the stack scanner won't
        find the value during GC.

        Added a new stress test.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::TryNode::emitBytecode):
        * tests/stress/recursive-try-catch.js: Added.
        (logError):
        (tryCallingBadFunction):
        (recurse):
        (test):

2016-06-01  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Some setters for components of Date do not timeClip() their result
        https://bugs.webkit.org/show_bug.cgi?id=158278
        rdar://problem/25131426

        Reviewed by Geoffrey Garen.

        Many of the setters where not doing timeClip() on the computed UTC
        time since Epoch.

        See http://www.ecma-international.org/ecma-262/6.0/#sec-date.prototype.setdate
        and the following sections for the definition.

        * runtime/DatePrototype.cpp:
        (JSC::setNewValueFromTimeArgs):
        (JSC::setNewValueFromDateArgs):

2016-06-01  Keith Miller  <keith_miller@apple.com>

        canOptimizeStringObjectAccess should use ObjectPropertyConditions rather than structure watchpoints
        https://bugs.webkit.org/show_bug.cgi?id=158291

        Reviewed by Benjamin Poulain.

        The old StringObject primitive access code used structure watchpoints. This meant that
        if you set a watchpoint on String.prototype prior to tiering up to the DFG then added
        a new property to String.prototype then we would never use StringObject optimizations.
        This made property caching in the LLInt bad because it meant we would watchpoint
        String.prototype very early in the program, which hurt date-format-xpab.js since that
        benchmark relies on the StringObject optimizations.

        This patch also extends ObjectPropertyConditionSet to be able to handle a slotBase
        equivalence condition. Since that makes the code for generating the DFG watchpoints
        significantly cleaner.

        * bytecode/ObjectPropertyCondition.cpp:
        (JSC::ObjectPropertyCondition::structureEnsuresValidityAssumingImpurePropertyWatchpoint):
        * bytecode/ObjectPropertyConditionSet.cpp:
        (JSC::ObjectPropertyConditionSet::hasOneSlotBaseCondition):
        (JSC::ObjectPropertyConditionSet::slotBaseCondition):
        (JSC::generateConditionsForPrototypeEquivalenceConcurrently):
        * bytecode/ObjectPropertyConditionSet.h:
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::isStringPrototypeMethodSane):
        (JSC::DFG::Graph::canOptimizeStringObjectAccess):
        * dfg/DFGGraph.h:

2016-06-01  Geoffrey Garen  <ggaren@apple.com>

        Unreviewed, rolling in r201436.
        https://bugs.webkit.org/show_bug.cgi?id=158143

        r201562 should haved fixed the Dromaeo DOM core regression.

        Restored changeset:

        "REGRESSION: JSBench spends a lot of time transitioning
        to/from dictionary"
        https://bugs.webkit.org/show_bug.cgi?id=158045
        http://trac.webkit.org/changeset/201436


2016-06-01  Commit Queue  <commit-queue@webkit.org>

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

        Caused 23% regression on JetStream's crypto-md5 (Requested by
        rniwa on #webkit).

        Reverted changeset:

        "[ESNext] Support trailing commas in function param lists"
        https://bugs.webkit.org/show_bug.cgi?id=158020
        http://trac.webkit.org/changeset/201488

2016-05-31  Geoffrey Garen  <ggaren@apple.com>

        Dictionary property access should be fast
        https://bugs.webkit.org/show_bug.cgi?id=158250

        Reviewed by Keith Miller.

        We have some remnant code that unnecessarily takes a slow path for
        dictionaries. This caused the Dromaeo regression in r201436. Let's fix
        that.

        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID): Attempt to flatten a dictionary if necessary, but
        not too much. This is our idiom in other places.

        (JSC::tryCachePutByID): See tryCacheGetByID.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setupGetByIdPrototypeCache): See tryCacheGetByID.

        * runtime/JSObject.cpp:
        (JSC::JSObject::fillGetterPropertySlot):
        * runtime/JSObject.h:
        (JSC::JSObject::fillCustomGetterPropertySlot): The rules for caching a
        getter are the same as the rules for caching anything else: We're
        allowed to cache even in dictionaries, as long as they're cacheable
        dictionaries. Any transition that would change to/from getter/setter
        or change other attributes requires a structure transition.

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

        [JSC] Drop "replace" from JSC_COMMON_PRIVATE_IDENTIFIERS_EACH_WELL_KNOWN_SYMBOL_NOT_IMPLEMENTED_YET
        https://bugs.webkit.org/show_bug.cgi?id=158223

        Reviewed by Darin Adler.

        This list maintains "not implemented yet" well-known symbols.
        `Symbol.replace` is already implemented.

        * runtime/CommonIdentifiers.h:

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

        Unreviewed, roll out r201481, r201523: 0.3% regression in Octane code-load
        https://bugs.webkit.org/show_bug.cgi?id=158249

        * API/JSScriptRef.cpp:
        (parseScript):
        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/AsyncFunctionPrototype.js: Removed.
        (asyncFunctionResume): Deleted.
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutable):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset): Deleted.
        (JSC::computeDefsForBytecodeOffset): Deleted.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::dumpBytecode): Deleted.
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::isArrowFunction):
        (JSC::UnlinkedCodeBlock::isOrdinaryArrowFunction): Deleted.
        (JSC::UnlinkedCodeBlock::isAsyncArrowFunction): Deleted.
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
        (JSC::BytecodeGenerator::emitNewMethodDefinition):
        (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon): Deleted.
        (JSC::BytecodeGenerator::emitNewFunction): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::makeFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionNode::emitBytecode): Deleted.
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::parse):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass): Deleted.
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitNewFuncCommon): Deleted.
        (JSC::JIT::emit_op_new_async_func): Deleted.
        (JSC::JIT::emitNewFuncExprCommon): Deleted.
        (JSC::JIT::emit_op_new_async_func_exp): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jsc.cpp:
        (runInteractive):
        (printUsageStatement): Deleted.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createAsyncFunctionBody): Deleted.
        * parser/Keywords.table:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::isArrowFunctionParameters):
        (JSC::Parser<LexerType>::parseStatementListItem):
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseImportClauseItem):
        (JSC::Parser<LexerType>::parseImportDeclaration):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):
        (JSC::Parser<LexerType>::parseArrowFunctionExpression):
        (JSC::Parser<LexerType>::printUnexpectedTokenText):
        (JSC::Parser<LexerType>::parseAsyncFunctionSourceElements): Deleted.
        (JSC::Parser<LexerType>::parseVariableDeclarationList): Deleted.
        (JSC::Parser<LexerType>::parseDestructuringPattern): Deleted.
        (JSC::Parser<LexerType>::parseFunctionDeclarationStatement): Deleted.
        (JSC::Parser<LexerType>::parseFormalParameters): Deleted.
        (JSC::stringForFunctionMode): Deleted.
        (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration): Deleted.
        (JSC::Parser<LexerType>::parseExpressionOrLabelStatement): Deleted.
        (JSC::Parser<LexerType>::parseAwaitExpression): Deleted.
        (JSC::Parser<LexerType>::parseAsyncFunctionExpression): Deleted.
        (JSC::Parser<LexerType>::parseUnaryExpression): Deleted.
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Parser::ExpressionErrorClassifier::propagateExpressionErrorClass):
        (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope):
        (JSC::Parser::pushScope):
        (JSC::Parser::popScopeInternal):
        (JSC::Parser::matchSpecIdentifier):
        (JSC::parse):
        (JSC::Scope::setSourceParseMode): Deleted.
        (JSC::Scope::isAsyncFunction): Deleted.
        (JSC::Scope::isAsyncFunctionBoundary): Deleted.
        (JSC::Scope::isModule): Deleted.
        (JSC::Scope::setIsFunction): Deleted.
        (JSC::Scope::setIsAsyncArrowFunction): Deleted.
        (JSC::Scope::setIsAsyncFunction): Deleted.
        (JSC::Scope::setIsAsyncFunctionBody): Deleted.
        (JSC::Scope::setIsAsyncArrowFunctionBody): Deleted.
        (JSC::Parser::ExpressionErrorClassifier::forceClassifyExpressionError): Deleted.
        (JSC::Parser::ExpressionErrorClassifier::indicatesPossibleAsyncArrowFunction): Deleted.
        (JSC::Parser::forceClassifyExpressionError): Deleted.
        (JSC::Parser::declarationTypeToVariableKind): Deleted.
        (JSC::Parser::upperScope): Deleted.
        (JSC::Parser::isDisallowedIdentifierAwait): Deleted.
        (JSC::Parser::disallowedIdentifierAwaitReason): Deleted.
        * parser/ParserModes.h:
        (JSC::isFunctionParseMode):
        (JSC::isModuleParseMode):
        (JSC::isProgramParseMode):
        (JSC::SourceParseModeSet::SourceParseModeSet): Deleted.
        (JSC::SourceParseModeSet::contains): Deleted.
        (JSC::SourceParseModeSet::mergeSourceParseModes): Deleted.
        (JSC::isAsyncFunctionParseMode): Deleted.
        (JSC::isAsyncArrowFunctionParseMode): Deleted.
        (JSC::isAsyncFunctionWrapperParseMode): Deleted.
        (JSC::isAsyncFunctionBodyParseMode): Deleted.
        (JSC::constructAbilityForParseMode): Deleted.
        * parser/ParserTokens.h:
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::operator==):
        (JSC::SourceCodeKey::runtimeFlags): Deleted.
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createAsyncFunctionBody): Deleted.
        * runtime/AsyncFunctionConstructor.cpp: Removed.
        (JSC::AsyncFunctionConstructor::AsyncFunctionConstructor): Deleted.
        (JSC::AsyncFunctionConstructor::finishCreation): Deleted.
        (JSC::callAsyncFunctionConstructor): Deleted.
        (JSC::constructAsyncFunctionConstructor): Deleted.
        (JSC::AsyncFunctionConstructor::getCallData): Deleted.
        (JSC::AsyncFunctionConstructor::getConstructData): Deleted.
        * runtime/AsyncFunctionConstructor.h: Removed.
        (JSC::AsyncFunctionConstructor::create): Deleted.
        (JSC::AsyncFunctionConstructor::createStructure): Deleted.
        * runtime/AsyncFunctionPrototype.cpp: Removed.
        (JSC::AsyncFunctionPrototype::AsyncFunctionPrototype): Deleted.
        (JSC::AsyncFunctionPrototype::finishCreation): Deleted.
        * runtime/AsyncFunctionPrototype.h: Removed.
        (JSC::AsyncFunctionPrototype::create): Deleted.
        (JSC::AsyncFunctionPrototype::createStructure): Deleted.
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        * runtime/CommonIdentifiers.h:
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        (JSC::checkModuleSyntax):
        * runtime/Completion.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ProgramExecutable::checkSyntax):
        * runtime/Executable.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionConstructor.h:
        * runtime/JSAsyncFunction.cpp: Removed.
        (JSC::JSAsyncFunction::JSAsyncFunction): Deleted.
        (JSC::JSAsyncFunction::createImpl): Deleted.
        (JSC::JSAsyncFunction::create): Deleted.
        (JSC::JSAsyncFunction::createWithInvalidatedReallocationWatchpoint): Deleted.
        * runtime/JSAsyncFunction.h: Removed.
        (JSC::JSAsyncFunction::allocationSize): Deleted.
        (JSC::JSAsyncFunction::createStructure): Deleted.
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertySlot):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock):
        (JSC::JSGlobalObject::createModuleProgramCodeBlock):
        (JSC::JSGlobalObject::init): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::asyncFunctionPrototype): Deleted.
        (JSC::JSGlobalObject::asyncFunctionStructure): Deleted.
        * runtime/ModuleLoaderObject.cpp:
        (JSC::moduleLoaderObjectParseModule):
        * runtime/RuntimeFlags.h:
        (JSC::RuntimeFlags::operator==): Deleted.
        (JSC::RuntimeFlags::operator!=): Deleted.
        * tests/stress/async-await-basic.js: Removed.
        (shouldBe): Deleted.
        (shouldBeAsync): Deleted.
        (shouldThrow): Deleted.
        (shouldThrowAsync): Deleted.
        (shouldThrowSyntaxError): Deleted.
        (let.AsyncFunction.async): Deleted.
        (async.asyncFunctionForProto): Deleted.
        (Object.getPrototypeOf.async): Deleted.
        (Object.getPrototypeOf.async.method): Deleted.
        (async): Deleted.
        (async.method): Deleted.
        (async.asyncNonConstructorDecl): Deleted.
        (shouldThrow.new.async): Deleted.
        (shouldThrow.new.async.nonConstructor): Deleted.
        (async.asyncDecl): Deleted.
        (async.f): Deleted.
        (MyError): Deleted.
        (async.asyncDeclThrower): Deleted.
        (shouldThrowAsync.async): Deleted.
        (resolveLater): Deleted.
        (rejectLater): Deleted.
        (async.resumeAfterNormal): Deleted.
        (O.async.resumeAfterNormal): Deleted.
        (resumeAfterNormalArrow.async): Deleted.
        (async.resumeAfterThrow): Deleted.
        (O.async.resumeAfterThrow): Deleted.
        (resumeAfterThrowArrow.async): Deleted.
        (catch): Deleted.
        * tests/stress/async-await-module-reserved-word.js: Removed.
        (shouldThrow): Deleted.
        (SyntaxError.Canstring_appeared_hereawait.checkModuleSyntaxError.String.raw.await): Deleted.
        (checkModuleSyntaxError.String.raw.await): Deleted.
        (checkModuleSyntaxError.String.raw.async.await): Deleted.
        (SyntaxError.Cannot.declare.named): Deleted.
        * tests/stress/async-await-mozilla.js: Removed.
        (shouldBe): Deleted.
        (shouldBeAsync): Deleted.
        (shouldThrow): Deleted.
        (shouldThrowAsync): Deleted.
        (assert): Deleted.
        (shouldThrowSyntaxError): Deleted.
        (mozSemantics.async.empty): Deleted.
        (mozSemantics.async.simpleReturn): Deleted.
        (mozSemantics.async.simpleAwait): Deleted.
        (mozSemantics.async.simpleAwaitAsync): Deleted.
        (mozSemantics.async.returnOtherAsync): Deleted.
        (mozSemantics.async.simpleThrower): Deleted.
        (mozSemantics.async.delegatedThrower): Deleted.
        (mozSemantics.async.tryCatch): Deleted.
        (mozSemantics.async.tryCatchThrow): Deleted.
        (mozSemantics.async.wellFinally): Deleted.
        (mozSemantics.async.finallyMayFail): Deleted.
        (mozSemantics.async.embedded.async.inner): Deleted.
        (mozSemantics.async.embedded): Deleted.
        (mozSemantics.async.fib): Deleted.
        (mozSemantics.async.isOdd.async.isEven): Deleted.
        (mozSemantics.async.isOdd): Deleted.
        (mozSemantics.hardcoreFib.async.fib2): Deleted.
        (mozSemantics.namedAsyncExpr.async.simple): Deleted.
        (mozSemantics.async.executionOrder.async.first): Deleted.
        (mozSemantics.async.executionOrder.async.second): Deleted.
        (mozSemantics.async.executionOrder.async.third): Deleted.
        (mozSemantics.async.executionOrder): Deleted.
        (mozSemantics.async.miscellaneous): Deleted.
        (mozSemantics.thrower): Deleted.
        (mozSemantics.async.defaultArgs): Deleted.
        (mozSemantics.shouldThrow): Deleted.
        (mozSemantics): Deleted.
        (mozMethods.X): Deleted.
        (mozMethods.X.prototype.async.getValue): Deleted.
        (mozMethods.X.prototype.setValue): Deleted.
        (mozMethods.X.prototype.async.increment): Deleted.
        (mozMethods.X.prototype.async.getBaseClassName): Deleted.
        (mozMethods.X.async.getStaticValue): Deleted.
        (mozMethods.Y.prototype.async.getBaseClassName): Deleted.
        (mozMethods.Y): Deleted.
        (mozFunctionNameInferrence.async.test): Deleted.
        (mozSyntaxErrors): Deleted.
        * tests/stress/async-await-reserved-word.js: Removed.
        (assert): Deleted.
        (shouldThrowSyntaxError): Deleted.
        (AsyncFunction.async): Deleted.
        * tests/stress/async_arrow_functions_lexical_arguments_binding.js: Removed.
        (shouldBe): Deleted.
        (shouldBeAsync): Deleted.
        (shouldThrowAsync): Deleted.
        (noArgumentsArrow2.async): Deleted.
        * tests/stress/async_arrow_functions_lexical_new.target_binding.js: Removed.
        (shouldBe): Deleted.
        (shouldBeAsync): Deleted.
        (shouldThrowAsync): Deleted.
        (C1): Deleted.
        (C2): Deleted.
        (shouldThrowAsync.async): Deleted.
        * tests/stress/async_arrow_functions_lexical_super_binding.js: Removed.
        (shouldBe): Deleted.
        (shouldBeAsync): Deleted.
        (BaseClass.prototype.baseClassValue): Deleted.
        (BaseClass.prototype.get property): Deleted.
        (BaseClass): Deleted.
        (ChildClass.prototype.asyncSuperProp): Deleted.
        (ChildClass.prototype.asyncSuperProp2): Deleted.
        (ChildClass): Deleted.
        (ChildClass2): Deleted.
        * tests/stress/async_arrow_functions_lexical_this_binding.js: Removed.
        (shouldBe): Deleted.
        (shouldBeAsync): Deleted.
        (d.y): Deleted.

2016-05-31  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r201363 and r201456.
        https://bugs.webkit.org/show_bug.cgi?id=158240

        "40% regression on date-format-xparb" (Requested by
        keith_miller on #webkit).

        Reverted changesets:

        "LLInt should be able to cache prototype loads for values in
        GetById"
        https://bugs.webkit.org/show_bug.cgi?id=158032
        http://trac.webkit.org/changeset/201363

        "get_by_id should support caching unset properties in the
        LLInt"
        https://bugs.webkit.org/show_bug.cgi?id=158136
        http://trac.webkit.org/changeset/201456

2016-05-31  Commit Queue  <commit-queue@webkit.org>

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

        "It was not a speedup on anything" (Requested by saamyjoon on
        #webkit).

        Reverted changeset:

        "We can cache lookups to JSScope::abstractResolve inside
        CodeBlock::finishCreation"
        https://bugs.webkit.org/show_bug.cgi?id=158036
        http://trac.webkit.org/changeset/201359

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

        [JSC] Recover parser performance regression by async support
        https://bugs.webkit.org/show_bug.cgi?id=158228

        Reviewed by Saam Barati.

        This patch recovers parser performance regression caused in r201481.

        Compared to the version that reverts r201481, still ~1% regression remains.
        But compared to ToT, this patch significantly improves the code-load performance.

        In Linux x64 JSCOnly port, with GCC 5.3.1.

        reverted v.s. patched.
                                 reverted                  patched

        closure              0.61805+-0.00376    ?     0.62280+-0.00525       ?
        jquery               8.03778+-0.02114          8.03453+-0.04646

        <geometric>          2.22883+-0.00836    ?     2.23688+-0.00995       ? might be 1.0036x slower

        ToT v.s. patched.
                                 baseline                  patched

        closure              0.65490+-0.00351    ^     0.62473+-0.00363       ^ definitely 1.0483x faster
        jquery               8.25373+-0.06256    ^     8.04701+-0.03455       ^ definitely 1.0257x faster

        <geometric>          2.32488+-0.00921    ^     2.24210+-0.00592       ^ definitely 1.0369x faster

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        Extend SourceParseMode.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::isArrowFunctionParameters):
        Do not call `matchSpecIdentifier()` as much as we can. This greatly improves the performance.

        (JSC::Parser<LexerType>::parseStatementListItem):
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        Do not touch `currentScope()->isGenerator()` even if it is unnecessary in parseFunctionInfo.
        And accidental `syntaxChecker => context` changes are fixed.

        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
        (JSC::Parser<LexerType>::parseImportClauseItem):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        Do not use matchSpecIdentifier() in the hot paths.

        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):
        (JSC::Parser<LexerType>::parseUnaryExpression):
        (JSC::Parser<LexerType>::printUnexpectedTokenText): Deleted.
        * parser/Parser.h:
        (JSC::isIdentifierOrKeyword):
        AWAIT shoud be one of the keywords. This AWAIT check is unnecessary.

        (JSC::Parser::upperScope):
        (JSC::Parser::matchSpecIdentifier):
        Touching currentScope() and its member causes significant performance degradation.
        We carefully remove the above access in the hot paths.

        (JSC::Parser::isDisallowedIdentifierAwait):
        * parser/ParserModes.h:
        (JSC::SourceParseModeSet::SourceParseModeSet):
        (JSC::SourceParseModeSet::contains):
        (JSC::SourceParseModeSet::mergeSourceParseModes):
        (JSC::isFunctionParseMode):
        (JSC::isAsyncFunctionParseMode):
        (JSC::isAsyncArrowFunctionParseMode):
        (JSC::isAsyncFunctionWrapperParseMode):
        (JSC::isAsyncFunctionBodyParseMode):
        (JSC::isModuleParseMode):
        (JSC::isProgramParseMode):
        (JSC::constructAbilityForParseMode):
        The parser frequently checks SourceParseMode. And variety of SourceParseMode becomes many.
        So using switch onto SourceParseMode degrades the performance. Instead, we use bit tests to guard against
        many SourceParseModes. We expect that this will be efficiently compiled into test & jmp.

        * parser/ParserTokens.h:
        Change AWAIT to one of the keywords, as the same to YIELD / LET.

2016-05-31  Saam Barati  <sbarati@apple.com>

        Web Inspector: capturing with Allocations timeline causes GC to take 100x longer and cause frame drops
        https://bugs.webkit.org/show_bug.cgi?id=158054
        <rdar://problem/25280762>

        Reviewed by Joseph Pecoraro.

        HeapSnapshot::sweepCell was taking a long time on 
        http://bl.ocks.org/syntagmatic/6c149c08fc9cde682635
        because it has to do a binary search to find if
        an item is or is not in the list. 90% of the binary searches
        would not find anything. This resulted in a lot of wasted time.

        This patch adds a TinyBloomFilter member variable to HeapSnapshot.
        We use this filter to try to bypass doing a binary search when the
        filter tells us that a particular JSCell is definitely not in our
        list. This is a 2x speedup on the steady state GC of the above
        website.

        * heap/HeapSnapshot.cpp:
        (JSC::HeapSnapshot::appendNode):
        (JSC::HeapSnapshot::sweepCell):
        (JSC::HeapSnapshot::shrinkToFit):
        (JSC::HeapSnapshot::nodeForCell):
        * heap/HeapSnapshot.h:

2016-05-29  Saam barati  <sbarati@apple.com>

        Stack overflow crashes with deep or cyclic proxy prototype chains
        https://bugs.webkit.org/show_bug.cgi?id=157087

        Reviewed by Filip Pizlo and Mark Lam.

        Because a Proxy can call back into the JS runtime in arbitrary
        ways, we may have effectively cyclic prototype chains and property lookups
        by using a Proxy. We may also have arbitrarily long Proxy chains
        where we call into a C frame for each link in the Proxy chain.
        This means that every Proxy hook must be aware that it can stack overflow.
        Before, only certain hooks were aware of this fact. That was a bug,
        all hooks must assume they can stack overflow.

        Also, because we may have effectively cyclic prototype chains, we
        compile ProxyObject.cpp with -fno-optimize-sibling-calls. This prevents
        tail call optimization from happening on any of the calls from
        ProxyObject.cpp. We do this because we rely on the machine stack
        growing for throwing a stack overflow error. It's better for developers
        to be able to see a stack overflow error than to have their program
        infinite loop because the compiler performed TCO.

        This patch also fixes a couple call sites of various methods
        where we didn't check for an exception.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * interpreter/Interpreter.cpp:
        (JSC::sizeOfVarargs):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::createSubclassStructure):
        * runtime/JSArray.h:
        (JSC::getLength):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString):
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        (JSC::ProxyObject::performPut):
        (JSC::performProxyCall):
        (JSC::performProxyConstruct):
        (JSC::ProxyObject::performDelete):
        (JSC::ProxyObject::performPreventExtensions):
        (JSC::ProxyObject::performIsExtensible):
        (JSC::ProxyObject::performDefineOwnProperty):
        (JSC::ProxyObject::performGetOwnPropertyNames):
        (JSC::ProxyObject::getOwnPropertyNames):
        (JSC::ProxyObject::getPropertyNames):
        (JSC::ProxyObject::getOwnNonIndexPropertyNames):
        (JSC::ProxyObject::performSetPrototype):
        (JSC::ProxyObject::performGetPrototype):
        * runtime/ProxyObject.h:
        (JSC::ProxyObject::create):
        * tests/stress/proxy-stack-overflow-exceptions.js: Added.
        (shouldThrowStackOverflow):
        (const.emptyFunction):
        (makeLongProxyChain):
        (shouldThrowStackOverflow.longProxyChain):
        (shouldThrowStackOverflow.effecivelyCyclicProxyProtoChain1):
        (shouldThrowStackOverflow.effecivelyCyclicProxyProtoChain2):
        (shouldThrowStackOverflow.effecivelyCyclicProxyProtoChain3):
        (shouldThrowStackOverflow.longProxyChainBind):
        (shouldThrowStackOverflow.longProxyChainPropertyAccess):
        (shouldThrowStackOverflow.longProxyChainReflectConstruct):
        (shouldThrowStackOverflow.longProxyChainReflectSet):
        (shouldThrowStackOverflow.longProxyChainReflectOwnKeys):
        (shouldThrowStackOverflow.longProxyChainGetPrototypeOf):
        (shouldThrowStackOverflow.longProxyChainSetPrototypeOf):
        (shouldThrowStackOverflow.longProxyChainGetOwnPropertyDescriptor):
        (shouldThrowStackOverflow.longProxyChainDefineProperty):
        (shouldThrowStackOverflow.longProxyChainIsExtensible):
        (shouldThrowStackOverflow.longProxyChainPreventExtensions):
        (shouldThrowStackOverflow.longProxyChainDeleteProperty):
        (shouldThrowStackOverflow.longProxyChainWithScope):
        (shouldThrowStackOverflow.longProxyChainWithScope2):
        (shouldThrowStackOverflow.longProxyChainWithScope3):
        (shouldThrowStackOverflow.longProxyChainArrayPrototypePush):
        (shouldThrowStackOverflow.longProxyChainWithScope4):
        (shouldThrowStackOverflow.longProxyChainCall):
        (shouldThrowStackOverflow.longProxyChainConstruct):
        (shouldThrowStackOverflow.longProxyChainHas):

2016-05-28  Andreas Kling  <akling@apple.com>

        JSGlobalLexicalEnvironment leaks SegmentedVector due to lack of destructor.
        <https://webkit.org/b/158186>

        Reviewed by Saam Barati.

        Give JSGlobalLexicalEnvironment a destroy() and set up a finalizer for it
        like we do with JSGlobalObject. (This is needed because they don't inherit
        from JSDestructibleObjects and thus can't use JSCell::needsDestruction to
        ask for allocation in destructor space.)

        This stops us from leaking all the SegmentedVector backing stores.

        * runtime/JSGlobalLexicalEnvironment.cpp:
        (JSC::JSGlobalLexicalEnvironment::destroy):
        * runtime/JSGlobalLexicalEnvironment.h:
        (JSC::JSGlobalLexicalEnvironment::create):

2016-05-28  Skachkov Oleksandr  <gskachkov@gmail.com>
        [ESNext] Trailing commas in function parameters.
        https://bugs.webkit.org/show_bug.cgi?id=158020

        Reviewed by Keith Miller.

        ESNext allow to add trailing commas in function parameters and function arguments.
        Link to spec - https://jeffmo.github.io/es-trailing-function-commas 
        Example of using - (function (a, b,) { return a + b; })(1,2,);

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFormalParameters):
        (JSC::Parser<LexerType>::parseArguments):
        * tests/stress/trailing-comma-in-function-paramters.js: Added.

2016-05-28  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] op_new_arrow_func_exp is no longer necessary
        https://bugs.webkit.org/show_bug.cgi?id=158180

        Reviewed by Saam Barati.

        This patch removes op_new_arrow_func_exp bytecode since
        what op_new_arrow_func_exp is doing is completely the same to op_new_func_exp.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset): Deleted.
        (JSC::computeDefsForBytecodeOffset): Deleted.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass): Deleted.
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitNewFuncExprCommon):
        (JSC::JIT::emit_op_new_arrow_func_exp): Deleted.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:

2016-05-27  Caitlin Potter  <caitp@igalia.com>

        [JSC] implement async functions proposal
        https://bugs.webkit.org/show_bug.cgi?id=156147

        Reviewed by Yusuke Suzuki.

        Adds support for `async` functions, proposed in https://tc39.github.io/ecmascript-asyncawait/.

        On the front-end side, "await" becomes a contextual keyword when used within an async function,
        which triggers parsing an AwaitExpression. "await" becomes an illegal identifier name within
        these contexts. The bytecode generated from an "await" expression is identical to that generated
        in a "yield" expression in a Generator, as AsyncFunction reuses generator's state machine mechanism.

        There are numerous syntactic forms for language features, including a variation on ArrowFunctions,
        requiring the keyword `async` to precede ArrowFormalParameters, and similarly, MethodDefinitions,
        which are ordinary MethodDefinitions preceded by the keyword `async`.

        An async function desugars to the following:

        ```
        async function asyncFn() {
        }

        becomes:

        function asyncFn() {
            let generator = {
                @generatorNext: function(@generator, @generatorState, @generatorValue, @generatorResumeMode) {
                  // generator state machine stuff here
                },
                @generatorState: 0,
                @generatorThis: this,
                @generatorFrame: null
            };
            return @asyncFunctionResume(generator, undefined, GeneratorResumeMode::NormalMode);
        }
        ```

        `@asyncFunctionResume()` is similar to `@generatorResume`, with the exception that it will wrap the
        result of invoking `@generatorNext()` in a Promise, and will avoid allocating an iterator result
        object.

        If the generator has yielded (an AwaitExpression has occurred), resumption will occur automatically
        once the await-expression operand is finished, via Promise chaining.

        * API/JSScriptRef.cpp:
        (parseScript):
        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/AsyncFunctionPrototype.js: Added.
        (asyncFunctionResume):
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutable):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finishCreation):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::isArrowFunction):
        (JSC::UnlinkedCodeBlock::isOrdinaryArrowFunction):
        (JSC::UnlinkedCodeBlock::isAsyncArrowFunction):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
        (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
        (JSC::BytecodeGenerator::emitNewMethodDefinition):
        (JSC::BytecodeGenerator::emitNewFunction):
        (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::makeFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionNode::emitBytecode):
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::parse):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitNewFuncCommon):
        (JSC::JIT::emit_op_new_async_func):
        (JSC::JIT::emitNewFuncExprCommon):
        (JSC::JIT::emit_op_new_async_func_exp):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jsc.cpp:
        (runInteractive):
        (printUsageStatement):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createAsyncFunctionBody):
        * parser/Keywords.table:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::isArrowFunctionParameters):
        (JSC::Parser<LexerType>::parseAsyncFunctionSourceElements):
        (JSC::Parser<LexerType>::parseStatementListItem):
        (JSC::Parser<LexerType>::parseVariableDeclarationList):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
        (JSC::Parser<LexerType>::parseFormalParameters):
        (JSC::stringForFunctionMode):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
        (JSC::Parser<LexerType>::parseImportClauseItem):
        (JSC::Parser<LexerType>::parseImportDeclaration):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseAwaitExpression):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parseAsyncFunctionExpression):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):
        (JSC::Parser<LexerType>::parseArrowFunctionExpression):
        (JSC::Parser<LexerType>::parseUnaryExpression):
        (JSC::Parser<LexerType>::printUnexpectedTokenText):
        * parser/Parser.h:
        (JSC::isIdentifierOrKeyword):
        (JSC::Scope::Scope):
        (JSC::Scope::setSourceParseMode):
        (JSC::Scope::isAsyncFunction):
        (JSC::Scope::isAsyncFunctionBoundary):
        (JSC::Scope::isModule):
        (JSC::Scope::setIsFunction):
        (JSC::Scope::setIsAsyncArrowFunction):
        (JSC::Scope::setIsAsyncFunction):
        (JSC::Scope::setIsAsyncFunctionBody):
        (JSC::Scope::setIsAsyncArrowFunctionBody):
        (JSC::Parser::ExpressionErrorClassifier::forceClassifyExpressionError):
        (JSC::Parser::ExpressionErrorClassifier::propagateExpressionErrorClass):
        (JSC::Parser::ExpressionErrorClassifier::indicatesPossibleAsyncArrowFunction):
        (JSC::Parser::forceClassifyExpressionError):
        (JSC::Parser::declarationTypeToVariableKind):
        (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope):
        (JSC::Parser::pushScope):
        (JSC::Parser::popScopeInternal):
        (JSC::Parser::matchSpecIdentifier):
        (JSC::Parser::isDisallowedIdentifierAwait):
        (JSC::Parser::disallowedIdentifierAwaitReason):
        (JSC::parse):
        * parser/ParserModes.h:
        (JSC::isFunctionParseMode):
        (JSC::isAsyncFunctionParseMode):
        (JSC::isAsyncArrowFunctionParseMode):
        (JSC::isAsyncFunctionWrapperParseMode):
        (JSC::isAsyncFunctionBodyParseMode):
        (JSC::isModuleParseMode):
        (JSC::isProgramParseMode):
        (JSC::constructAbilityForParseMode):
        * parser/ParserTokens.h:
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::runtimeFlags):
        (JSC::SourceCodeKey::operator==):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createAsyncFunctionBody):
        * runtime/AsyncFunctionConstructor.cpp: Added.
        (JSC::AsyncFunctionConstructor::AsyncFunctionConstructor):
        (JSC::AsyncFunctionConstructor::finishCreation):
        (JSC::callAsyncFunctionConstructor):
        (JSC::constructAsyncFunctionConstructor):
        (JSC::AsyncFunctionConstructor::getCallData):
        (JSC::AsyncFunctionConstructor::getConstructData):
        * runtime/AsyncFunctionConstructor.h: Added.
        (JSC::AsyncFunctionConstructor::create):
        (JSC::AsyncFunctionConstructor::createStructure):
        * runtime/AsyncFunctionPrototype.cpp: Added.
        (JSC::AsyncFunctionPrototype::AsyncFunctionPrototype):
        (JSC::AsyncFunctionPrototype::finishCreation):
        * runtime/AsyncFunctionPrototype.h: Added.
        (JSC::AsyncFunctionPrototype::create):
        (JSC::AsyncFunctionPrototype::createStructure):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        * runtime/CommonIdentifiers.h:
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        (JSC::checkModuleSyntax):
        * runtime/Completion.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ProgramExecutable::checkSyntax):
        * runtime/Executable.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionConstructor.h:
        * runtime/JSAsyncFunction.cpp: Added.
        (JSC::JSAsyncFunction::JSAsyncFunction):
        (JSC::JSAsyncFunction::createImpl):
        (JSC::JSAsyncFunction::create):
        (JSC::JSAsyncFunction::createWithInvalidatedReallocationWatchpoint):
        * runtime/JSAsyncFunction.h: Added.
        (JSC::JSAsyncFunction::allocationSize):
        (JSC::JSAsyncFunction::createStructure):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertySlot):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock):
        (JSC::JSGlobalObject::createModuleProgramCodeBlock):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::asyncFunctionPrototype):
        (JSC::JSGlobalObject::asyncFunctionStructure):
        * runtime/ModuleLoaderObject.cpp:
        (JSC::moduleLoaderObjectParseModule):
        * runtime/RuntimeFlags.h:
        (JSC::RuntimeFlags::operator==):
        (JSC::RuntimeFlags::operator!=):
        * tests/stress/async-await-basic.js: Added.
        (shouldBe):
        (shouldBeAsync):
        (shouldThrow):
        (shouldThrowAsync):
        (let.AsyncFunction.async):
        (async.asyncFunctionForProto):
        (Object.getPrototypeOf.async):
        (Object.getPrototypeOf.async.method):
        (async):
        (async.method):
        (async.asyncNonConstructorDecl):
        (shouldThrow.new.async):
        (shouldThrow.new.async.nonConstructor):
        (async.asyncDecl):
        (async.f):
        (MyError):
        (async.asyncDeclThrower):
        (shouldThrowAsync.async):
        (resolveLater):
        (rejectLater):
        (async.resumeAfterNormal):
        (O.async.resumeAfterNormal):
        (resumeAfterNormalArrow.async):
        (async.resumeAfterThrow):
        (O.async.resumeAfterThrow):
        (resumeAfterThrowArrow.async):
        (catch):
        * tests/stress/async-await-module-reserved-word.js: Added.
        (shouldThrow):
        (SyntaxError.Canstring_appeared_hereawait.checkModuleSyntaxError.String.raw.await):
        (checkModuleSyntaxError.String.raw.await):
        (checkModuleSyntaxError.String.raw.async.await):
        (SyntaxError.Cannot.declare.named):
        * tests/stress/async-await-mozilla.js: Added.
        (shouldBe):
        (shouldBeAsync):
        (shouldThrow):
        (shouldThrowAsync):
        (assert):
        (shouldThrowSyntaxError):
        (mozSemantics.async.empty):
        (mozSemantics.async.simpleReturn):
        (mozSemantics.async.simpleAwait):
        (mozSemantics.async.simpleAwaitAsync):
        (mozSemantics.async.returnOtherAsync):
        (mozSemantics.async.simpleThrower):
        (mozSemantics.async.delegatedThrower):
        (mozSemantics.async.tryCatch):
        (mozSemantics.async.tryCatchThrow):
        (mozSemantics.async.wellFinally):
        (mozSemantics.async.finallyMayFail):
        (mozSemantics.async.embedded.async.inner):
        (mozSemantics.async.embedded):
        (mozSemantics.async.fib):
        (mozSemantics.async.isOdd.async.isEven):
        (mozSemantics.async.isOdd):
        (mozSemantics.hardcoreFib.async.fib2):
        (mozSemantics.namedAsyncExpr.async.simple):
        (mozSemantics.async.executionOrder.async.first):
        (mozSemantics.async.executionOrder.async.second):
        (mozSemantics.async.executionOrder.async.third):
        (mozSemantics.async.executionOrder):
        (mozSemantics.async.miscellaneous):
        (mozSemantics.thrower):
        (mozSemantics.async.defaultArgs):
        (mozSemantics.shouldThrow):
        (mozSemantics):
        (mozMethods.X):
        (mozMethods.X.prototype.async.getValue):
        (mozMethods.X.prototype.setValue):
        (mozMethods.X.prototype.async.increment):
        (mozMethods.X.prototype.async.getBaseClassName):
        (mozMethods.X.async.getStaticValue):
        (mozMethods.Y.prototype.async.getBaseClassName):
        (mozMethods.Y):
        (mozFunctionNameInferrence.async.test):
        (mozSyntaxErrors):
        * tests/stress/async-await-reserved-word.js: Added.
        (assert):
        (shouldThrowSyntaxError):
        (AsyncFunction.async):
        * tests/stress/async_arrow_functions_lexical_arguments_binding.js: Added.
        (shouldBe):
        (shouldBeAsync):
        (shouldThrowAsync):
        (noArgumentsArrow2.async):
        * tests/stress/async_arrow_functions_lexical_new.target_binding.js: Added.
        (shouldBe):
        (shouldBeAsync):
        (shouldThrowAsync):
        (C1):
        (C2):
        (shouldThrowAsync.async):
        * tests/stress/async_arrow_functions_lexical_super_binding.js: Added.
        (shouldBe):
        (shouldBeAsync):
        (BaseClass.prototype.baseClassValue):
        (BaseClass):
        (ChildClass.prototype.asyncSuperProp):
        (ChildClass.prototype.asyncSuperProp2):
        (ChildClass):
        * tests/stress/async_arrow_functions_lexical_this_binding.js: Added.
        (shouldBe):
        (shouldBeAsync):
        (d.y):

2016-05-27  Saam barati  <sbarati@apple.com>

        DebuggerCallFrame crashes when updated with the globalExec because neither ShadowChicken's algorithm nor StackVisitor's algorithm reasons about the globalExec
        https://bugs.webkit.org/show_bug.cgi?id=158104

        Reviewed by Filip Pizlo.

        I think globalExec is a special enough case that it should be handled
        at the layers above ShadowChicken and StackVisitor. Those APIs should
        deal with real stack frames on the machine stack, not a heap constructed frame.

        This patch makes DebuggerCallFrame::create aware that it may be
        created with the globalObject->globalExec() by having it construct
        a single DebuggerCallFrame that wraps the globalExec.

        This fixes a crasher because we will construct a DebuggerCallFrame
        with the globalExec when the Inspector is set to pause on all uncaught
        exceptions and the JS program has a syntax error. Because the program
        hasn't begun execution, there is no machine JS stack frame yet. So
        DebuggerCallFrame is created with globalExec, which will cause it
        to hit an assertion that dictates that the stack have size greater
        than zero.

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

2016-05-27  Filip Pizlo  <fpizlo@apple.com>

        DFG::LazyJSValue::tryGetStringImpl() crashes for empty values
        https://bugs.webkit.org/show_bug.cgi?id=158170

        Reviewed by Michael Saboff.

        The problem here is that jsDynamicCast<>() is evil! It avoids checking for the empty
        value, presumably because this makes it soooper fast. In DFG IR, empty values can appear
        anywhere because of TDZ.
        
        This patch doesn't change jsDynamicCast<>(), but it hardens our wrappers for it in the DFG
        and it has the affected code use one of those wrappers.
        
        * dfg/DFGFrozenValue.h:
        (JSC::DFG::FrozenValue::dynamicCast): Harden this.
        (JSC::DFG::FrozenValue::cast):
        * dfg/DFGLazyJSValue.cpp:
        (JSC::DFG::LazyJSValue::tryGetStringImpl): Use the hardened wrapper.
        * tests/stress/strcat-emtpy.js: Added. This used to crash every time.
        (foo):
        (i.catch):

2016-05-27  Filip Pizlo  <fpizlo@apple.com>

        regExpProtoFuncSplitFast should OOM before it swaps
        https://bugs.webkit.org/show_bug.cgi?id=158157

        Reviewed by Mark Lam.
        
        This is a huge speed-up on some jsfunfuzz test cases because it makes us realize much
        sooner that running a regexp split will result in swapping. It uses the same basic
        approach as http://trac.webkit.org/changeset/201451: if the result array crosses a certain
        size threshold, we proceed with a dry run to see how big the array will get before
        allocating anything else. This way, bogus uses of split that would have OOMed only after
        killing the user's machine will now OOM before killing the user's machine.
        
        This is an enormous speed-up on some jsfunfuzz tests: they go from running for a long
        time to running instantly.

        * runtime/RegExpPrototype.cpp:
        (JSC::advanceStringIndex):
        (JSC::genericSplit):
        (JSC::regExpProtoFuncSplitFast):
        * runtime/StringObject.h:
        (JSC::jsStringWithReuse):
        (JSC::jsSubstring):
        * tests/stress/big-split-captures.js: Added.
        * tests/stress/big-split.js: Added.

2016-05-27  Saam barati  <sbarati@apple.com>

        ShadowChicken/DebuggerCallFrame don't properly handle when the entry stack frame is a tail deleted frame
        https://bugs.webkit.org/show_bug.cgi?id=158131

        Reviewed by Yusuke Suzuki.

        There were bugs both in DebuggerCallFrame and ShadowChicken when the entry stack
        frame(s) are tail deleted.

        DebuggerCallFrame had an assertion saying that the entry frame shouldn't be
        tail deleted. This is clearly wrong. The following program proves that this assertion
        was misguided:
        ```
        "use strict";
        setTimeout(function foo() { return bar(); }, 0);
        ```

        ShadowChicken had a very subtle bug when creating the shadow stack when 
        the entry frames of the stack were tail deleted. Because it places frames into its shadow
        stack by walking the machine frame and looking up entries in the log,
        the machine frame doesn't have any notion of those tail deleted frames
        at the entry of execution. ShadowChicken would never find those frames
        because it would look for tail deleted frames *before* consulting the
        current machine frame. This is wrong because if the entry frames
        are tail deleted, then there is no machine frame for them because there
        is no machine frame before them! Therefore, we must search for tail deleted
        frames *after* consulting a machine frame. This is sound because we will always
        have at least one machine frame on the stack (when we are using StackVisitor on a valid ExecState).
        So when we consult the machine frame that is the entry frame on the machine stack,
        we will search for tail deleted frames that come before it in the shadow stack.
        This will allow us to find those tail deleted frames that are the entry frames
        for the shadow stack.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::create):
        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::Packet::dump):
        (JSC::ShadowChicken::update):
        (JSC::ShadowChicken::dump):

2016-05-27  Chris Dumez  <cdumez@apple.com>

        WorkQueue::dispatch() / RunLoop::dispatch() should not copy captured lambda variables
        https://bugs.webkit.org/show_bug.cgi?id=158111

        Reviewed by Darin Adler.

        WorkQueue::dispatch() / RunLoop::dispatch() should not copy captured lambda variables.
        These are often used cross-thread and copying the captured lambda variables can be
        dangerous (e.g. we do not want to copy a String after calling isolatedCopy() upon
        capture).

        * runtime/Watchdog.cpp:
        (JSC::Watchdog::startTimer):
        (JSC::Watchdog::Watchdog): Deleted.
        (JSC::Watchdog::setTimeLimit): Deleted.
        * runtime/Watchdog.h:

2016-05-27  Konstantin Tokarev  <annulen@yandex.ru>

        Removed unused headers from ExecutableAllocatorFixedVMPool.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=158159

        Reviewed by Darin Adler.

        * jit/ExecutableAllocatorFixedVMPool.cpp:

2016-05-27  Keith Miller  <keith_miller@apple.com>

        get_by_id should support caching unset properties in the LLInt
        https://bugs.webkit.org/show_bug.cgi?id=158136

        Reviewed by Benjamin Poulain.

        Recently, we started supporting prototype load caching for get_by_id
        in the LLInt. This patch extends that to caching unset properties.
        While it is uncommon in general for a program to see a single structure
        without a given property, the Array.prototype.concat function needs to
        lookup the Symbol.isConcatSpreadable property. For any existing code
        That property will never be set as it did not exist prior to ES6.

        Similarly to the get_by_id_proto_load bytecode, this patch adds a new
        bytecode, get_by_id_unset that checks the structureID of the base and
        assigns undefined to the result.

        There are no new tests here since we already have many tests that
        incidentally cover this change.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdOp):
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setupGetByIdPrototypeCache):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

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

        Bogus uses of regexp matching should realize that they will OOM before they start swapping
        https://bugs.webkit.org/show_bug.cgi?id=158142

        Reviewed by Michael Saboff.
        
        Refactored the RegExpObject::matchGlobal() code so that there is less duplication. Took
        advantage of this to make the code more resilient in case of absurd situations: if the
        result array gets large, it proceeds with a dry run to detect how many matches there will
        be. This allows it to OOM before it starts swapping.
        
        This also improves the overall performance of the code by using lightweight substrings and
        skipping the whole intermediate argument array.
        
        This makes some jsfunfuzz tests run a lot faster and use a lot less memory.
        
        * builtins/RegExpPrototype.js:
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/MatchResult.cpp: Added.
        (JSC::MatchResult::dump):
        * runtime/MatchResult.h:
        (JSC::MatchResult::empty):
        (MatchResult::empty): Deleted.
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::match):
        (JSC::collectMatches):
        (JSC::RegExpObject::matchGlobal):
        * runtime/StringObject.h:
        (JSC::jsStringWithReuse):
        (JSC::jsSubstring):
        * tests/stress/big-match.js: Added. Make sure that this optimization doesn't break big matches.

2016-05-26  Gavin & Ellie Barraclough  <barraclough@apple.com>

        Static table property lookup should not require getOwnPropertySlot override.
        https://bugs.webkit.org/show_bug.cgi?id=158059

        Reviewed by Darin Adler.

        Currently JSObject does not handle property lookup of entries in the static
        table. Each subclass with static properties mut override getOwnPropertySlot,
        and explicitly call the lookup functions. This has the following drawbacks:

        - Performance: for any class with static properties, property acces becomes
          virtual (via method table).
        - Poor encapsulation: implementation detail of static property access is
          spread throughout & cross projects, rather than being contained in JSObject.
        - Code size: this results in a great many additional functions.
        - Inconsistency: static table presence has to be be taken into account in many
          other operations, e.g. presence of read-only properties for put.
        - Memory: in order to avoid the virtual lookup, DOM prototypes eagerly reify
          all properties. This is likely suboptimal.

        Instead, JSObject::getPropertySlot / JSObject::getOwnPropertySlot should be
        able to handle static properties.

        This is actually a fairly small & simple change.

        The common pattern is for subclasses of JObject to override getOwnPropertySlot
        to first defer to JSObject for property storage lookup, and only if this fails
        consult the static table. They just want the static tables to be consulted after
        regular property storgae lookup. So just add a fast flag in TypeInfo for JSObject
        to check, and where it is set, do so. Then it's just a question of switching
        classes over to start setting this flag, and drop the override.

        The new mechanism does change static table lookup order from oldest-ancestor
        first to most-derived first. The new ordering makes more sense (means derived
        class static tables can now override entries from parents), and shoudn't affect
        any existing code (since overriding didn't previously work, there likely aren't
        shadowing properties in more derived types).

        This patch changes all classes in JavaScriptCore over to using the new mechanism,
        except JSGlobalObject. I'll move classes in WebCore over as a separate patch
        (this is also why I've not moved JSGlobalObject in this patch - doing so would
        move JSDOMWindow, and I'd rather handle that separately).

        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::hasStaticPropertyTable):
            - Add HasStaticPropertyTable flag.
        * runtime/Lookup.cpp:
        (JSC::setUpStaticFunctionSlot):
            - Change setUpStaticFunctionSlot to take a VM&.
        * runtime/Lookup.h:
        (JSC::getStaticPropertySlotFromTable):
            - Added helper function to perform static lookup alone.
        (JSC::getStaticPropertySlot):
        (JSC::getStaticFunctionSlot):
            - setUpStaticFunctionSlot changed to take a VM&.
        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnStaticPropertySlot):
            - Added, walks ClassInfo chain looking for static properties.
        * runtime/JSObject.h:
        (JSC::JSObject::getOwnNonIndexPropertySlot):
            - getOwnNonIndexPropertySlot is used internally by getPropertySlot
              & getOwnPropertySlot. If property is not present in storage array
              then check the static table.
        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        (JSC::constructArrayWithSizeQuirk):
        (JSC::ArrayConstructor::getOwnPropertySlot): Deleted.
        * runtime/ArrayConstructor.h:
        (JSC::ArrayConstructor::create):
        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation):
        (JSC::ArrayIteratorPrototype::getOwnPropertySlot): Deleted.
        * runtime/ArrayIteratorPrototype.h:
        (JSC::ArrayIteratorPrototype::create):
        (JSC::ArrayIteratorPrototype::ArrayIteratorPrototype):
        * runtime/BooleanPrototype.cpp:
        (JSC::BooleanPrototype::finishCreation):
        (JSC::booleanProtoFuncToString):
        (JSC::BooleanPrototype::getOwnPropertySlot): Deleted.
        * runtime/BooleanPrototype.h:
        (JSC::BooleanPrototype::create):
        * runtime/DateConstructor.cpp:
        (JSC::DateConstructor::finishCreation):
        (JSC::millisecondsFromComponents):
        (JSC::DateConstructor::getOwnPropertySlot): Deleted.
        * runtime/DateConstructor.h:
        (JSC::DateConstructor::create):
        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::finishCreation):
        (JSC::dateProtoFuncToString):
        (JSC::DatePrototype::getOwnPropertySlot): Deleted.
        * runtime/DatePrototype.h:
        (JSC::DatePrototype::create):
        * runtime/ErrorPrototype.cpp:
        (JSC::ErrorPrototype::finishCreation):
        (JSC::ErrorPrototype::getOwnPropertySlot): Deleted.
        * runtime/ErrorPrototype.h:
        (JSC::ErrorPrototype::create):
        * runtime/GeneratorPrototype.cpp:
        (JSC::GeneratorPrototype::finishCreation):
        (JSC::GeneratorPrototype::getOwnPropertySlot): Deleted.
        * runtime/GeneratorPrototype.h:
        (JSC::GeneratorPrototype::create):
        (JSC::GeneratorPrototype::createStructure):
        (JSC::GeneratorPrototype::GeneratorPrototype):
        * runtime/InspectorInstrumentationObject.cpp:
        (JSC::InspectorInstrumentationObject::finishCreation):
        (JSC::InspectorInstrumentationObject::isEnabled):
        (JSC::InspectorInstrumentationObject::getOwnPropertySlot): Deleted.
        * runtime/InspectorInstrumentationObject.h:
        (JSC::InspectorInstrumentationObject::create):
        (JSC::InspectorInstrumentationObject::createStructure):
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::IntlCollatorConstructor::getCallData):
        (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
        (JSC::IntlCollatorConstructor::getOwnPropertySlot): Deleted.
        * runtime/IntlCollatorConstructor.h:
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorPrototype::finishCreation):
        (JSC::IntlCollatorFuncCompare):
        (JSC::IntlCollatorPrototype::getOwnPropertySlot): Deleted.
        * runtime/IntlCollatorPrototype.h:
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::IntlDateTimeFormatConstructor::getCallData):
        (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
        (JSC::IntlDateTimeFormatConstructor::getOwnPropertySlot): Deleted.
        * runtime/IntlDateTimeFormatConstructor.h:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototype::finishCreation):
        (JSC::IntlDateTimeFormatFuncFormatDateTime):
        (JSC::IntlDateTimeFormatPrototype::getOwnPropertySlot): Deleted.
        * runtime/IntlDateTimeFormatPrototype.h:
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::IntlNumberFormatConstructor::getCallData):
        (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
        (JSC::IntlNumberFormatConstructor::getOwnPropertySlot): Deleted.
        * runtime/IntlNumberFormatConstructor.h:
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototype::finishCreation):
        (JSC::IntlNumberFormatFuncFormatNumber):
        (JSC::IntlNumberFormatPrototype::getOwnPropertySlot): Deleted.
        * runtime/IntlNumberFormatPrototype.h:
        * runtime/JSDataViewPrototype.cpp:
        (JSC::JSDataViewPrototype::createStructure):
        (JSC::getData):
        (JSC::JSDataViewPrototype::getOwnPropertySlot): Deleted.
        * runtime/JSDataViewPrototype.h:
        * runtime/JSInternalPromiseConstructor.cpp:
        (JSC::JSInternalPromiseConstructor::getCallData):
        (JSC::JSInternalPromiseConstructor::getOwnPropertySlot): Deleted.
        * runtime/JSInternalPromiseConstructor.h:
        * runtime/JSONObject.cpp:
        (JSC::Walker::Walker):
        (JSC::JSONObject::getOwnPropertySlot): Deleted.
        * runtime/JSONObject.h:
        (JSC::JSONObject::create):
        * runtime/JSPromiseConstructor.cpp:
        (JSC::JSPromiseConstructor::getCallData):
        (JSC::JSPromiseConstructor::getOwnPropertySlot): Deleted.
        * runtime/JSPromiseConstructor.h:
        * runtime/JSPromisePrototype.cpp:
        (JSC::JSPromisePrototype::addOwnInternalSlots):
        (JSC::JSPromisePrototype::getOwnPropertySlot): Deleted.
        * runtime/JSPromisePrototype.h:
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        (JSC::getMap):
        (JSC::MapPrototype::getOwnPropertySlot): Deleted.
        * runtime/MapPrototype.h:
        (JSC::MapPrototype::create):
        (JSC::MapPrototype::MapPrototype):
        * runtime/ModuleLoaderObject.cpp:
        (JSC::ModuleLoaderObject::finishCreation):
        (JSC::printableModuleKey):
        (JSC::ModuleLoaderObject::getOwnPropertySlot): Deleted.
        * runtime/ModuleLoaderObject.h:
        * runtime/NumberPrototype.cpp:
        (JSC::NumberPrototype::finishCreation):
        (JSC::toThisNumber):
        (JSC::NumberPrototype::getOwnPropertySlot): Deleted.
        * runtime/NumberPrototype.h:
        (JSC::NumberPrototype::create):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::addDefineProperty):
        (JSC::constructObject):
        (JSC::ObjectConstructor::getOwnPropertySlot): Deleted.
        * runtime/ObjectConstructor.h:
        (JSC::ObjectConstructor::create):
        (JSC::ObjectConstructor::createStructure):
        * runtime/ReflectObject.cpp:
        (JSC::ReflectObject::finishCreation):
        (JSC::ReflectObject::getOwnPropertySlot): Deleted.
        * runtime/ReflectObject.h:
        (JSC::ReflectObject::create):
        (JSC::ReflectObject::createStructure):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::getRightContext):
        (JSC::regExpConstructorDollar):
        (JSC::RegExpConstructor::getOwnPropertySlot): Deleted.
        * runtime/RegExpConstructor.h:
        (JSC::RegExpConstructor::create):
        (JSC::RegExpConstructor::createStructure):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        (JSC::getSet):
        (JSC::SetPrototype::getOwnPropertySlot): Deleted.
        * runtime/SetPrototype.h:
        (JSC::SetPrototype::create):
        (JSC::SetPrototype::SetPrototype):
        * runtime/StringConstructor.cpp:
        (JSC::StringConstructor::finishCreation):
        (JSC::stringFromCharCodeSlowCase):
        (JSC::StringConstructor::getOwnPropertySlot): Deleted.
        * runtime/StringConstructor.h:
        (JSC::StringConstructor::create):
        * runtime/StringIteratorPrototype.cpp:
        (JSC::StringIteratorPrototype::finishCreation):
        (JSC::StringIteratorPrototype::getOwnPropertySlot): Deleted.
        * runtime/StringIteratorPrototype.h:
        (JSC::StringIteratorPrototype::create):
        (JSC::StringIteratorPrototype::StringIteratorPrototype):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::create):
        (JSC::substituteBackreferencesSlow):
        (JSC::StringPrototype::getOwnPropertySlot): Deleted.
        * runtime/StringPrototype.h:
        * runtime/SymbolConstructor.cpp:
        (JSC::SymbolConstructor::finishCreation):
        (JSC::callSymbol):
        (JSC::SymbolConstructor::getOwnPropertySlot): Deleted.
        * runtime/SymbolConstructor.h:
        (JSC::SymbolConstructor::create):
        * runtime/SymbolPrototype.cpp:
        (JSC::SymbolPrototype::finishCreation):
        (JSC::SymbolPrototype::getOwnPropertySlot): Deleted.
        * runtime/SymbolPrototype.h:
        (JSC::SymbolPrototype::create):
            - remove getOwnPropertySlot, replace OverridesGetOwnPropertySlot flag with HasStaticPropertyTable.

2016-05-26  Commit Queue  <commit-queue@webkit.org>

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

        Caused 30% regression on Dromaeo DOM core tests (Requested by
        rniwa on #webkit).

        Reverted changeset:

        "REGRESSION: JSBench spends a lot of time transitioning
        to/from dictionary"
        https://bugs.webkit.org/show_bug.cgi?id=158045
        http://trac.webkit.org/changeset/201436

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

        REGRESSION: JSBench spends a lot of time transitioning to/from dictionary
        https://bugs.webkit.org/show_bug.cgi?id=158045

        Reviewed by Saam Barati.

        15% speedup on jsbench-amazon-firefox, possibly 5% speedup overall on jsbench.

        This regression seems to have two parts:

        (1) Transitioning the window object to/from dictionary is more expensive
        than it used to be to because the window object has lots more properties.
        The window object has more properties because, for WebIDL compatibility,
        we reify DOM APIs as properties when you delete.

        (2) DOM prototypes transition to/from dictionary upon creation
        because, once again for WebIDL compatibility, we reify their static
        APIs eagerly.

        The solution is to chill out a bit on dictionary transitions.

        * bytecode/ObjectPropertyConditionSet.cpp: Don't flatten a dictionary
        if we've already done so before. This avoids pathological churn, and it
        is our idiom in other places.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute): Do flatten the global object unconditionally
        if it is an uncacheable dictionary because the global object is super
        important.

        * runtime/BatchedTransitionOptimizer.h:
        (JSC::BatchedTransitionOptimizer::BatchedTransitionOptimizer):
        (JSC::BatchedTransitionOptimizer::~BatchedTransitionOptimizer): Deleted.
        Don't transition away from dictionary after a batched set of property
        puts because normal dictionaries are cacheable and that's a perfectly
        fine state to be in -- and the transition is expensive.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Do start the global object out as a cacheable
        dictionary because it will inevitably have enough properties to become
        a dictionary.

        * runtime/Operations.h:
        (JSC::normalizePrototypeChain): Same as ObjectPropertyConditionSet.cpp.

2016-05-25  Geoffrey Garen  <ggaren@apple.com>

        replaceable own properties seem to ignore replacement after property caching
        https://bugs.webkit.org/show_bug.cgi?id=158091

        Reviewed by Darin Adler.

        * runtime/Lookup.h:
        (JSC::replaceStaticPropertySlot): New helper function for replacing a
        static property with a direct property. We need to do an attribute changed
        transition because client code might have cached our static property.

2016-05-25  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] RegExp with deeply nested subexpressions overflow the stack in Yarr
        https://bugs.webkit.org/show_bug.cgi?id=158011
        rdar://problem/25946592

        Reviewed by Saam Barati.

        When generating the meta-data required for compilation,
        Yarr uses a recursive function over the various expression in the pattern.

        If you have many nested expressions, you can run out of stack
        and crash the WebProcess.
        This patch changes that into a soft failure. The expression is just
        considered invalid.

        * runtime/RegExp.cpp:
        (JSC::RegExp::finishCreation):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
        (JSC::Yarr::YarrPatternConstructor::setupOffsets):
        (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse):
        (JSC::Yarr::YarrPattern::compile):
        (JSC::Yarr::YarrPattern::YarrPattern):
        (JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets): Deleted.
        (JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets): Deleted.
        * yarr/YarrPattern.h:

2016-05-25  Alex Christensen  <achristensen@webkit.org>

        Fix Win64 build after r201335
        https://bugs.webkit.org/show_bug.cgi?id=158078

        Reviewed by Mark Lam.

        * offlineasm/x86.rb:
        Add intel implementations for loadbs and loadhs

2016-05-25  Carlos Garcia Campos  <cgarcia@igalia.com>

        REGRESSION(r201066): [GTK] Several intl tests started to fail in GTK+ bot after r201066
        https://bugs.webkit.org/show_bug.cgi?id=158066

        Reviewed by Darin Adler.

        run-javascriptcore-tests does $ENV{LANG}="en_US.UTF-8"; but we are not actually honoring the environment
        variables at all when using jsc binary. We are using setlocale() with a nullptr locale to get the current one, but
        the current one is always "C", because to set the locale according to the environment variables we need to call
        setlocale with an empty string as locale. That's done by gtk_init(), which is called by all our binaries (web
        process, network process, etc.), but not by jsc (because jsc doesn't depend on GTK+). The reason why it has
        always worked for EFL is because they call ecore_init() in jsc that calls setlocale.

        * jsc.cpp:
        (main): Call setlocale(LC_ALL, "") on GTK+.

2016-05-25  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Fix the Wcast-align warning in LinkBuffer.cpp
        https://bugs.webkit.org/show_bug.cgi?id=157889

        Reviewed by Darin Adler.

        * assembler/LinkBuffer.cpp:
        (JSC::recordLinkOffsets):

2016-05-24  Keith Miller  <keith_miller@apple.com>

        TypedArray.prototype.slice should not throw if no arguments are provided
        https://bugs.webkit.org/show_bug.cgi?id=158044
        <rdar://problem/26433280>

        Reviewed by Geoffrey Garen.

        We were throwing an exception if the TypedArray.prototype.slice function
        was not provided arguments. This was wrong. Instead we should just assume
        the first argument was 0.

        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncSlice): Deleted.
        * tests/stress/typedarray-slice.js:

2016-05-24  Keith Miller  <keith_miller@apple.com>

        LLInt should be able to cache prototype loads for values in GetById
        https://bugs.webkit.org/show_bug.cgi?id=158032

        Reviewed by Filip Pizlo.

        This patch adds prototype value caching to the LLInt for op_get_by_id.
        Two previously unused words in the op_get_by_id bytecode have been
        repurposed to hold extra information for the cache. The first is a
        counter that records the number of get_by_ids that hit a cacheable value
        on a prototype. When the counter is decremented from one to zero we
        attempt to cache the prototype load, which will be discussed further
        below. The second word is used to hold the prototype object when we have
        started caching.

        When the counter is decremented to zero we first attempt to generate and
        watch the property conditions needed to ensure the validity of prototype
        load. If the watchpoints are successfully created and installed we
        replace the op_get_by_id opcode with the new op_get_by_id_proto_load
        opcode, which tells the LLInt to use the cache prototype object for the
        load rather than the base value.

        Prior to this patch there was not LLInt specific data onCodeBlocks.
        Since the CodeBlock needs to own the Watchpoints for the cache, a weak
        map from each base structure to a bag of Watchpoints created for that
        structure by some op_get_by_id has been added to the CodeBlock. During
        GC, if we find that the a structure in the map has not been marked we
        free the associated bag on the CodeBlock.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdOp):
        (JSC::CodeBlock::printGetByIdCacheStatus):
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::llintGetByIdWatchpointMap):
        (JSC::clearLLIntGetByIdCache):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp: Added.
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::install):
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h: Added.
        * bytecode/ObjectPropertyConditionSet.cpp:
        (JSC::ObjectPropertyConditionSet::isValidAndWatchable):
        * bytecode/ObjectPropertyConditionSet.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitGetById):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setupGetByIdPrototypeCache):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/Options.h:
        * tests/stress/llint-get-by-id-cache-prototype-load-from-dictionary.js: Added.
        (test):

2016-05-24  Keith Miller  <keith_miller@apple.com>

        We should be able to use the sampling profiler with DRT/WTR.
        https://bugs.webkit.org/show_bug.cgi?id=158041

        Reviewed by Saam Barati.

        This patch makes the sampling profiler use a new option, samplingProfilerPath, which
        specifies the path to a directory to output sampling profiler data when the program
        terminates or the VM is destroyed. Additionally, it fixes some other issues with the
        bytecode profiler that would cause crashes on debug builds.

        * profiler/ProfilerDatabase.cpp:
        (JSC::Profiler::Database::ensureBytecodesFor):
        (JSC::Profiler::Database::performAtExitSave):
        * runtime/Options.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::registerForReportAtExit):
        (JSC::SamplingProfiler::reportDataToOptionFile):
        (JSC::SamplingProfiler::reportTopFunctions):
        (JSC::SamplingProfiler::reportTopBytecodes):
        * runtime/SamplingProfiler.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):

2016-05-24  Saam barati  <sbarati@apple.com>

        We can cache lookups to JSScope::abstractResolve inside CodeBlock::finishCreation
        https://bugs.webkit.org/show_bug.cgi?id=158036

        Reviewed by Geoffrey Garen.

        This patch implements a 1 item cache for JSScope::abstractResolve. I also tried
        implementing the cache as a HashMap, but it seemed either less profitable on some
        benchmarks or just as profitable on others. Therefore, it's cleaner to just
        use a 1 item cache.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::AbstractResolveKey::AbstractResolveKey):
        (JSC::AbstractResolveKey::operator==):
        (JSC::AbstractResolveKey::isEmptyValue):
        (JSC::CodeBlock::finishCreation):
        * runtime/GetPutInfo.h:
        (JSC::needsVarInjectionChecks):
        (JSC::ResolveOp::ResolveOp):

2016-05-24  Filip Pizlo  <fpizlo@apple.com>

        Unreviwed, add a comment to describe the test's failure mode. Suggested by mlam.

        * tests/stress/override-map-constructor.js:
        (Map):

2016-05-24  Filip Pizlo  <fpizlo@apple.com>

        Map should not be in JSGlobalObject's static hashtable because it's initialized eagerly via FOR_EACH_SIMPLE_BUILTIN_TYPE_WITH_CONSTRUCTOR
        https://bugs.webkit.org/show_bug.cgi?id=158031
        rdar://problem/26353661

        Reviewed by Geoffrey Garen.
        
        We were listing Map as being a lazy class structure. It's not. m_mapStructure is a WriteBarrier<>
        not a LazyClassStructure<> and there is nothing lazy about it.

        * runtime/JSGlobalObject.cpp: The fix is to remove Map here.
        * runtime/Lookup.cpp: Add some dumping on the assert path.
        (JSC::setUpStaticFunctionSlot):
        * tests/stress/override-map-constructor.js: Added. This test used to crash.
        (Map):

2016-05-24  Filip Pizlo  <fpizlo@apple.com>

        LLInt64 should have typed array fast paths for get_by_val
        https://bugs.webkit.org/show_bug.cgi?id=157931

        Reviewed by Keith Miller.

        I think that the LLInt should be able to access typed arrays more quickly than it does now.
        Ideally we would have fast paths for every major typed array operation and we would use
        inline cache optimizations. I don't want to do this all in one go, so my plan is to
        incrementally add support for this as time allows.
        
        This change just adds the easy typed array fast paths for get_by_val in the 64-bit version
        of LLInt.
        
        Another bug, https://bugs.webkit.org/show_bug.cgi?id=157922, tracks the overall task of
        adding all typed array fast paths to both versions of the LLInt.
        
        This is a 30% speed-up on typed array benchmarks in LLInt. This is not a speed-up when the
        JITs are enabled.

        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/backends.rb:
        * runtime/JSArrayBufferView.h:
        * runtime/JSType.h:

2016-05-24  Saam barati  <sbarati@apple.com> and Yusuke Suzuki <utatane.tea@gmail.com>

        ThisTDZMode is no longer needed
        https://bugs.webkit.org/show_bug.cgi?id=157209

        Reviewed by Saam Barati.

        ThisTDZMode is no longer needed because we have ConstructorKind
        and DerivedContextType. The value of ThisTDZMode is strictly less
        expressive than the combination of those two values. We were
        using those values anyways, and this patch just makes it official
        by removing ThisTDZMode.

        This patch also cleans up caching keys. We extract SourceCodeFlags
        from SourceCodeKey and use it in EvalCodeCache. It correctly
        contains needed cache attributes: EvalContextType, DerivedContextType,
        etc. Here, we still use specialized keys for EvalCodeCache instead
        of SourceCodeKey for performance; it does not include name String and
        does not allocate SourceCode.

        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::CacheKey::CacheKey):
        (JSC::EvalCodeCache::CacheKey::operator==):
        (JSC::EvalCodeCache::CacheKey::Hash::equal):
        (JSC::EvalCodeCache::tryGet):
        (JSC::EvalCodeCache::getSlow):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode): Deleted.
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createThisExpr):
        * 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/SourceCodeKey.h:
        (JSC::SourceCodeFlags::SourceCodeFlags):
        (JSC::SourceCodeFlags::operator==):
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::Hash::hash):
        (JSC::SourceCodeKey::Hash::equal):
        (JSC::SourceCodeKey::HashTraits::isEmptyValue):
        (JSC::SourceCodeKeyHash::hash): Deleted.
        (JSC::SourceCodeKeyHash::equal): Deleted.
        (JSC::SourceCodeKeyHashTraits::isEmptyValue): Deleted.
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createThisExpr):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        * 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/code-cache-incorrect-caching.js: Added.
        (shouldBe):
        (hello):
        (catch):
        (shouldBe.test.hello):
        (globalEval.ok):
        (global.hello.hello):

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

        Assertion failure for Reflect.get with Proxy and primitive value as explicit receiver
        https://bugs.webkit.org/show_bug.cgi?id=157080

        Reviewed by Saam Barati.

        In custom accessor getter, the argument "thisValue" can be altered by using `Reflect.get`.
        In this patch, we add a new parameter, "slotBase". This represents the base value offering
        this custom getter. And use it in ProxyObject's performGet custom accessor getter.

        * API/JSCallbackObject.h:
        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::staticFunctionGetter):
        (JSC::JSCallbackObject<Parent>::callbackGetter):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):
        In PolymorphicAccess case, the thisValue and the slotBase are always cells.
        This is because IC is enabled in the case that the base value is a cell.
        And slotBase is always on the prototype chain from this base value.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jsc.cpp:
        (WTF::CustomGetter::customGetter):
        (WTF::RuntimeArray::lengthGetter):
        * runtime/CustomGetterSetter.cpp:
        (JSC::callCustomSetter):
        * runtime/JSBoundSlotBaseFunction.cpp:
        (JSC::boundSlotBaseFunctionCall):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::argumentsGetter):
        (JSC::JSFunction::callerGetter):
        * runtime/JSFunction.h:
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::callbackGetter):
        * runtime/PropertySlot.cpp:
        (JSC::PropertySlot::customGetter):
        * runtime/PropertySlot.h:
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        * runtime/RegExpConstructor.cpp:
        (JSC::regExpConstructorDollar):
        (JSC::regExpConstructorInput):
        (JSC::regExpConstructorMultiline):
        (JSC::regExpConstructorLastMatch):
        (JSC::regExpConstructorLastParen):
        (JSC::regExpConstructorLeftContext):
        (JSC::regExpConstructorRightContext):
        (JSC::regExpConstructorDollar1): Deleted.
        (JSC::regExpConstructorDollar2): Deleted.
        (JSC::regExpConstructorDollar3): Deleted.
        (JSC::regExpConstructorDollar4): Deleted.
        (JSC::regExpConstructorDollar5): Deleted.
        (JSC::regExpConstructorDollar6): Deleted.
        (JSC::regExpConstructorDollar7): Deleted.
        (JSC::regExpConstructorDollar8): Deleted.
        (JSC::regExpConstructorDollar9): Deleted.
        * tests/stress/proxy-get-with-primitive-receiver.js: Added.
        (shouldBe):

2016-05-23  Geoffrey Garen  <ggaren@apple.com>

        REGRESSION (196374): deleting a global property is expensive
        https://bugs.webkit.org/show_bug.cgi?id=158005

        Reviewed by Chris Dumez.

        * runtime/JSObject.cpp:
        (JSC::JSObject::deleteProperty): We only need to reify static properties
        if the name being deleted matches a static property. Otherwise, we can
        be sure that delete won't observe any static properties.

2016-05-23  Saam barati  <sbarati@apple.com>

        The baseline JIT crashes when compiling "(1,1)/1"
        https://bugs.webkit.org/show_bug.cgi?id=157933

        Reviewed by Benjamin Poulain.

        op_div in the baseline JIT needed to better handle when both the lhs
        and rhs are constants. It needs to make sure to load either the lhs or
        the rhs into a register since the div generator can't handle both
        the lhs and rhs being constants.

        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_div):
        * tests/stress/jit-gracefully-handle-double-constants-in-math-operators.js: Added.
        (assert):
        (test):

2016-05-23  Saam barati  <sbarati@apple.com>

        String template don't handle let initialization properly inside eval
        https://bugs.webkit.org/show_bug.cgi?id=157991

        Reviewed by Oliver Hunt.

        The fix is to make sure we emit TDZ checks. 

        * bytecompiler/NodesCodegen.cpp:
        (JSC::TaggedTemplateNode::emitBytecode):
        * tests/stress/tagged-template-tdz.js: Added.
        (shouldThrowTDZ):
        (test):

2016-05-22  Saam barati  <sbarati@apple.com>

        Unreviewed. Fixed debug assertion failures from r201235.

        * runtime/JSScope.cpp:
        (JSC::abstractAccess):

2016-05-22  Brady Eidson  <beidson@apple.com>

        Attempted Yosemite build fix after http://trac.webkit.org/changeset/201255

        Suggested by and reviewed by Anders Carlsson.

        * b3/B3CCallValue.h: Initialize the effects member more conventionally.

2016-05-22  Brady Eidson  <beidson@apple.com>

        Move to C++14.
        https://bugs.webkit.org/show_bug.cgi?id=157948

        Reviewed by Michael Catanzaro.

        * Configurations/Base.xcconfig:

2016-05-22  Saam barati  <sbarati@apple.com>

        REGRESSION(r199075): String.prototype.replace fails after being used many times with different replace values
        https://bugs.webkit.org/show_bug.cgi?id=157968
        <rdar://problem/26404735>

        Reviewed by Ryosuke Niwa and Filip Pizlo.

        There was a bug in the DFG where we were checking a condition
        on the wrong variable.

        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):

2016-05-22  Chris Dumez  <cdumez@apple.com>

        Remove uses of PassRefPtr in JS bindings code
        https://bugs.webkit.org/show_bug.cgi?id=157949

        Reviewed by Andreas Kling.

        Remove uses of PassRefPtr in JS bindings code.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::queueMicrotask):
        * runtime/JSGlobalObject.h:

2016-05-20  Joseph Pecoraro  <pecoraro@apple.com>

        Remove LegacyProfiler
        https://bugs.webkit.org/show_bug.cgi?id=153565

        Reviewed by Mark Lam.

        JavaScriptCore now provides a sampling profiler and it is enabled
        by all ports. Web Inspector switched months ago to using the
        sampling profiler and displaying its data. Remove the legacy
        profiler, as it is no longer being used by anything other then
        console.profile and tests. We will update console.profile's
        behavior soon to have new behavior and use the sampling data.

        * API/JSProfilerPrivate.cpp: Removed.
        * API/JSProfilerPrivate.h: Removed.
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset): Deleted.
        (JSC::computeDefsForBytecodeOffset): Deleted.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode): Deleted.
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitCallVarargs):
        (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
        (JSC::BytecodeGenerator::emitConstructVarargs):
        (JSC::BytecodeGenerator::emitConstruct):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::CallArguments::profileHookRegister): Deleted.
        (JSC::BytecodeGenerator::shouldEmitProfileHooks): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::CallArguments::CallArguments): Deleted.
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock): Deleted.
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel): Deleted.
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize): Deleted.
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC): Deleted.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute): Deleted.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Deleted.
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Deleted.
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled):
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::operator()): Deleted.
        (JSC::Interpreter::execute): Deleted.
        (JSC::Interpreter::executeCall): Deleted.
        (JSC::Interpreter::executeConstruct): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass): Deleted.
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_profile_will_call): Deleted.
        (JSC::JIT::emit_op_profile_did_call): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_profile_will_call): Deleted.
        (JSC::JIT::emit_op_profile_did_call): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ParserModes.h:
        * profiler/CallIdentifier.h: Removed.
        * profiler/LegacyProfiler.cpp: Removed.
        * profiler/LegacyProfiler.h: Removed.
        * profiler/Profile.cpp: Removed.
        * profiler/Profile.h: Removed.
        * profiler/ProfileGenerator.cpp: Removed.
        * profiler/ProfileGenerator.h: Removed.
        * profiler/ProfileNode.cpp: Removed.
        * profiler/ProfileNode.h: Removed.
        * profiler/ProfilerJettisonReason.cpp:
        (WTF::printInternal): Deleted.
        * profiler/ProfilerJettisonReason.h:
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        * runtime/CodeCache.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock):
        (JSC::JSGlobalObject::createModuleProgramCodeBlock):
        (JSC::JSGlobalObject::~JSGlobalObject): Deleted.
        (JSC::JSGlobalObject::hasLegacyProfiler): Deleted.
        * runtime/JSGlobalObject.h:
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::VM): Deleted.
        (JSC::SetEnabledProfilerFunctor::operator()): Deleted.
        (JSC::VM::setEnabledProfiler): Deleted.
        * runtime/VM.h:
        (JSC::VM::enabledProfiler): Deleted.
        (JSC::VM::enabledProfilerAddress): Deleted.

2016-05-20  Joseph Pecoraro  <pecoraro@apple.com>

        Remove LegacyProfiler
        https://bugs.webkit.org/show_bug.cgi?id=153565

        Reviewed by Saam Barati.

        * inspector/protocol/Timeline.json:
        * jsc.cpp:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::hasLegacyProfiler):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::supportsLegacyProfiling): Deleted.

2016-05-20  Saam barati  <sbarati@apple.com>

        JSScope::abstractAccess doesn't need to copy the SymbolTableEntry, it can use it by reference
        https://bugs.webkit.org/show_bug.cgi?id=157956

        Reviewed by Geoffrey Garen.

        A SymbolTableEntry may be a FatEntry. Copying a FatEntry is slow because we have to
        malloc memory for it, then free the malloced memory once the entry goes out of
        scope. abstractAccess uses a SymbolTableEntry temporarily when performing scope
        accesses during bytecode linking. It copies out the SymbolTableEntry every time
        it does a SymbolTable lookup. This is not cheap when the entry happens to be a
        FatEntry. We should really just be using a reference to the entry because
        there is no need to copy it in such a scenario.

        * runtime/JSScope.cpp:
        (JSC::abstractAccess):

2016-05-20  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: retained size for typed arrays does not count native backing store
        https://bugs.webkit.org/show_bug.cgi?id=157945
        <rdar://problem/26392238>

        Reviewed by Geoffrey Garen.

        * runtime/JSArrayBuffer.h:
        * runtime/JSArrayBuffer.cpp:
        (JSC::JSArrayBuffer::estimatedSize):
        Include an estimatedSize implementation for JSArrayBuffer.
        ArrayBuffer has a unique path, different from other data
        stored in the Heap.

        * tests/heapProfiler/typed-array-sizes.js: Added.
        Test sizes of TypedArray with and without an ArrayBuffer.
        When the TypedArray is a view wrapping an ArrayBuffer, the
        ArrayBuffer has the size.

2016-05-20  Geoffrey Garen  <ggaren@apple.com>

        reifyAllStaticProperties makes two copies of every string
        https://bugs.webkit.org/show_bug.cgi?id=157953

        Reviewed by Mark Lam.

        Let's not do that.

        * runtime/JSObject.cpp:
        (JSC::JSObject::reifyAllStaticProperties): Pass our Identifier to
        reifyStaticProperty so it doesn't have to make its own.

        * runtime/Lookup.h:
        (JSC::reifyStaticProperty): No need to null check because callers never
        pass null anymore. No need to make an identifier because callers pass
        us one.

        (JSC::reifyStaticProperties): Honor new interface.

2016-05-20  Geoffrey Garen  <ggaren@apple.com>

        JSBench regression: CodeBlock linking always copies the symbol table
        https://bugs.webkit.org/show_bug.cgi?id=157951

        Reviewed by Saam Barati.

        We always put a SymbolTable into the constant pool, even in simple
        functions in which it won't be used -- i.e., there's on eval and there
        are no captured variables and so on.

        This is costly because linking must copy any provided symbol tables.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitProfileType): Only add the symbol table
        as a constant if we will use it at runtime.

2016-05-19  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Improve int->float conversion in FTL
        https://bugs.webkit.org/show_bug.cgi?id=157936

        Reviewed by Filip Pizlo.

        The integer -> floating point lowering was very barebone.

        For example, converting a constant integer to double
        was doing:
            mov #const, %eax
            xor %xmm0, %xmm0
            cvtsi2sd %eax, %xmm0

        Conversion from integer to float was also missing.
        We were always converting to double then rounding the double
        to float.

        This patch adds the basics:
        -Constant folding.
        -Integer to Float opcode.
        -Reducing int->double to int->float when used by DoubleToFloat.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::convertInt32ToFloat):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::convertInt64ToDouble):
        (JSC::MacroAssemblerX86_64::convertInt64ToFloat):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::cvtsi2ss_rr):
        (JSC::X86Assembler::cvtsi2ssq_rr):
        (JSC::X86Assembler::cvtsi2sdq_mr):
        (JSC::X86Assembler::cvtsi2ssq_mr):
        (JSC::X86Assembler::cvtsi2ss_mr):
        * assembler/MacroAssemblerARM64.h:
        * b3/B3Const32Value.cpp:
        (JSC::B3::Const32Value::iToDConstant):
        (JSC::B3::Const32Value::iToFConstant):
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.cpp:
        (JSC::B3::Const64Value::iToDConstant):
        (JSC::B3::Const64Value::iToFConstant):
        * b3/B3Const64Value.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3ReduceDoubleToFloat.cpp:
        * b3/B3ReduceStrength.cpp:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::iToDConstant):
        (JSC::B3::Value::iToFConstant):
        (JSC::B3::Value::isRounded):
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h:
        * b3/B3ValueKey.cpp:
        (JSC::B3::ValueKey::materialize):
        * b3/air/AirFixPartialRegisterStalls.cpp:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::int64Operands):
        (JSC::B3::testIToD64Arg):
        (JSC::B3::testIToF64Arg):
        (JSC::B3::testIToD32Arg):
        (JSC::B3::testIToF32Arg):
        (JSC::B3::testIToD64Mem):
        (JSC::B3::testIToF64Mem):
        (JSC::B3::testIToD32Mem):
        (JSC::B3::testIToF32Mem):
        (JSC::B3::testIToD64Imm):
        (JSC::B3::testIToF64Imm):
        (JSC::B3::testIToD32Imm):
        (JSC::B3::testIToF32Imm):
        (JSC::B3::testIToDReducedToIToF64Arg):
        (JSC::B3::testIToDReducedToIToF32Arg):
        (JSC::B3::run):

2016-05-19  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] FTL can crash on stack overflow
        https://bugs.webkit.org/show_bug.cgi?id=157881
        rdar://problem/24665964

        Reviewed by Michael Saboff.

        The VM's m_largestFTLStackSize was never set anywhere (updateFTLLargestStackSize()
        was never called). We forgot to change that when implementing B3.

        Even when it is set, we still have a problem on OSR Exit.
        If the last frame is a FTL frame and it OSR Exits, the space required for
        that frame becomes significantly larger. What happens is we crash in the OSR Exit
        instead of the FTL frame (this is what happens in rdar://problem/24665964).

        This patch changes the stack boundary checks in FTL to be the same as DFG:
        we verify that we have enough space for the current optimized function but
        also for the baseline version (including inlining) in case of exit.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM): Deleted.
        (JSC::VM::updateStackLimit): Deleted.
        (JSC::VM::updateFTLLargestStackSize): Deleted.
        * runtime/VM.h:
        (JSC::VM::addressOfFTLStackLimit): Deleted.

2016-05-18  Filip Pizlo  <fpizlo@apple.com>

        DFG::LICMPhase shouldn't hoist type checks unless it knows that the check will succeed at the loop pre-header
        https://bugs.webkit.org/show_bug.cgi?id=144527

        Reviewed by Saam Barati.
        
        This adds a control flow equivalence analysis (called ControlEquivalenceAnalysis) based on
        dominator analysis over the backwards CFG. Two basic blocks are control flow equivalent if
        the execution of one implies that the other one must also execute. It means that the two
        blocks' forward and backward dominance are reciprocated: (A dom B and B backdom A) or (B dom
        A and A backdom B). LICM now uses it to become more conservative about hoisting checks, if
        this has caused problems in the past. If we hoist something that may exit from a block that
        was not control equivalent to the pre-header then it's possible that the node's speculation
        will fail even though it wouldn't have if it wasn't hoisted. So, we flag these nodes'
        origins as being "wasHoisted" and we track all of their exits as "HoistingFailed". LICM will
        turn off such speculative hoisting if the CodeBlock from which we are hoisting had the
        HoistingFailed exit kind.
        
        Note that this deliberately still allows us to hoist things that may exit even if they are
        not control equivalent to the pre-header. This is necessary because the profitability of
        hoisting is so huge in all of the cases that we're aware of that it's worth giving it a
        shot.
        
        This is neutral on macrobenchmarks since none of the benchmarks we track have a hoistable
        operation that would exit only if hoisted. I added microbenchmarks to illustrate the problem
        and two of them speed up by ~40% while one of them is neutral (Int52 saves us from having
        problems on that program even though LICM previously did the wrong thing).

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/ExitKind.cpp:
        (JSC::exitKindToString):
        * bytecode/ExitKind.h:
        * dfg/DFGAtTailAbstractState.h:
        (JSC::DFG::AtTailAbstractState::operator bool):
        (JSC::DFG::AtTailAbstractState::initializeTo):
        * dfg/DFGBackwardsCFG.h: Added.
        (JSC::DFG::BackwardsCFG::BackwardsCFG):
        * dfg/DFGBackwardsDominators.h: Added.
        (JSC::DFG::BackwardsDominators::BackwardsDominators):
        * dfg/DFGCommon.h:
        (JSC::DFG::checkAndSet): Deleted.
        * dfg/DFGControlEquivalenceAnalysis.h: Added.
        (JSC::DFG::ControlEquivalenceAnalysis::ControlEquivalenceAnalysis):
        (JSC::DFG::ControlEquivalenceAnalysis::dominatesEquivalently):
        (JSC::DFG::ControlEquivalenceAnalysis::areEquivalent):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::dumpBlockHeader):
        (JSC::DFG::Graph::invalidateCFG):
        (JSC::DFG::Graph::substituteGetLocal):
        (JSC::DFG::Graph::handleAssertionFailure):
        (JSC::DFG::Graph::ensureDominators):
        (JSC::DFG::Graph::ensurePrePostNumbering):
        (JSC::DFG::Graph::ensureNaturalLoops):
        (JSC::DFG::Graph::ensureBackwardsCFG):
        (JSC::DFG::Graph::ensureBackwardsDominators):
        (JSC::DFG::Graph::ensureControlEquivalenceAnalysis):
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::hasDebuggerEnabled):
        * dfg/DFGInPlaceAbstractState.h:
        (JSC::DFG::InPlaceAbstractState::operator bool):
        (JSC::DFG::InPlaceAbstractState::createValueForNode):
        (JSC::DFG::InPlaceAbstractState::forNode):
        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::run):
        (JSC::DFG::LICMPhase::attemptHoist):
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGMayExit.h:
        * dfg/DFGNode.h:
        * dfg/DFGNodeOrigin.cpp:
        (JSC::DFG::NodeOrigin::dump):
        * dfg/DFGNodeOrigin.h:
        (JSC::DFG::NodeOrigin::takeValidExit):
        (JSC::DFG::NodeOrigin::withWasHoisted):
        (JSC::DFG::NodeOrigin::forInsertingAfter):
        * dfg/DFGNullAbstractState.h: Added.
        (JSC::DFG::NullAbstractState::NullAbstractState):
        (JSC::DFG::NullAbstractState::operator bool):
        (JSC::DFG::NullAbstractState::forNode):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExitBase.cpp:
        (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
        * dfg/DFGOSRExitBase.h:
        (JSC::DFG::OSRExitBase::OSRExitBase):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::run):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
        (JSC::FTL::OSRExit::OSRExit):
        * ftl/FTLOSRExit.h:

2016-05-19  Mark Lam  <mark.lam@apple.com>

        Code that null checks the VM pointer before any use should ref the VM.
        https://bugs.webkit.org/show_bug.cgi?id=157864

        Reviewed by Filip Pizlo and Keith Miller.

        JSLock::willReleaseLock() and HeapTimer::timerDidFire() need to reference the VM
        through a RefPtr.  Otherwise, there's no guarantee that the VM won't be deleted
        after their null checks.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::vm):
        (JSC::CodeBlock::setVM): Deleted.
        - Not used, and suggests that it can be changed during the lifetime of the
          CodeBlock (which should not be).

        * heap/HeapTimer.cpp:
        (JSC::HeapTimer::timerDidFire):
        * runtime/JSLock.cpp:
        (JSC::JSLock::willReleaseLock):
        - Store the VM pointer in a RefPtr first, and null check the RefPtr instead of
          the raw VM pointer.  This makes the null check a strong guarantee that the
          VM pointer is valid while these functions are using it.

2016-05-19  Saam barati  <sbarati@apple.com>

        arrow function lexical environment should reuse the same environment as the function's lexical environment where possible
        https://bugs.webkit.org/show_bug.cgi?id=157908

        Reviewed by Filip Pizlo.

        We can safely combine these two environment when we have
        a simple parameter list (no default parameters, no destructring parameters).

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        * bytecompiler/BytecodeGenerator.h:

2016-05-19  Michael Saboff  <msaboff@apple.com>

        Unreviewed build fix.

        Skipping this new test as it times out on the bots.

        Issue tracked in https://bugs.webkit.org/show_bug.cgi?id=157903

        * tests/stress/regress-157595.js:
        (MyRegExp):

2016-05-19  Guillaume Emont  <guijemont@igalia.com>

        JSC: DFG::SpeculativeJIT::compile special case for MIPS for PutByValWithThis
        https://bugs.webkit.org/show_bug.cgi?id=157741

        Reviewed by Saam Barati.

        The PutByValWithThis case needs a special case for MIPS because we
        don't have enough registers. The special case needs to be different
        from the x86 one because we have a different ABI.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2016-05-19  Brian Burg  <bburg@apple.com>

        Web Inspector: use a consistent prefix for injected scripts
        https://bugs.webkit.org/show_bug.cgi?id=157715
        <rdar://problem/26287188>

        Reviewed by Timothy Hatcher.

        * CMakeLists.txt:
        * DerivedSources.make:
        * inspector/InjectedScriptSource.js:

2016-05-19  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Remove redefined macro after r200606
        https://bugs.webkit.org/show_bug.cgi?id=157890

        Reviewed by Michael Saboff.

        * bytecode/PolymorphicAccess.cpp:
        * jit/CCallHelpers.h:

2016-05-18  Saam barati  <sbarati@apple.com>

        Function with default parameter values that are arrow functions that capture this isn't working
        https://bugs.webkit.org/show_bug.cgi?id=157786
        <rdar://problem/26327329>

        Reviewed by Geoffrey Garen.

        To make the scopes ordered properly, I needed to initialize the arrow 
        function lexical environment before initializing default parameter values.
        I also made the code easier to reason about by never reusing the function's
        var lexical environment for the arrow function lexical environment. The
        reason for this is that that code was wrong, and we just didn't have code to
        that properly tested it. It was easy for that code to be wrong because
        sometimes the function's lexical environment isn't the top-most scope
        (namely, when a function's parameter list is non-simple) and sometimes
        it is (when the function's parameter list is simple).

        Also, because a function's default parameter values may capture the
        'arguments' variable inside an arrow function, I needed to take care
        to initialize the 'arguments' variable as part of whichever scope
        is the top-most scope. It's either the function's var environment
        if the parameter list is simple, or it's the function's parameter
        environment if the parameter list is non-simple.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::initializeParameters):
        (JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
        (JSC::BytecodeGenerator::visibleNameForParameter):
        * bytecompiler/BytecodeGenerator.h:
        * tests/stress/arrow-functions-as-default-parameter-values.js: Added.
        (assert):
        (test):
        (test.foo):
        * tests/stress/op-push-name-scope-crashes-profiler.js:
        (test):

2016-05-18  Michael Saboff  <msaboff@apple.com>

        r199812 broke test262
        https://bugs.webkit.org/show_bug.cgi?id=157595

        Reviewed by Filip Pizlo.

        Added a reasonable limit to the size of the match result array to catch possible
        infinite loops when matching.
        Added a new tests that creates an infinite loop in RegExp.prototype.[Symbol.match]
        by creating a subclass of RegExp where the base RegExp's global flag is false and
        the subclass overrides .global with a getter that always returns true.

        * builtins/RegExpPrototype.js:
        (match):
        * tests/stress/regress-157595.js: Added.
        (MyRegExp):
        (MyRegExp.prototype.get global):
        (test):
        (catch):

2016-05-18  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Namespace object re-export should be handled as local export
        https://bugs.webkit.org/show_bug.cgi?id=157806

        Reviewed by Mark Lam.

        We align the implementation of ExportEntry to the spec; remove Type::Namespace.
        This Type::Namespace is used for re-exported namespace object binding. For example,

            import * as namespace from "namespace.js"
            export { namespace }

        In the above case, we used ExportEntry(Type::Namespace). In this patch, we drop this
        and use normal local export (Type::Local) instead because namespace object actually has
        the local binding in the above module environment. And this handling strictly meets the
        spec (Sec 15.2.1.16.1 step 11-a-ii-2-b).

        And we also clean up the ExportEntry implementation; dropping unnecessary information.
        This change fixes the test262/test/language/module-code/instn-star-equality.js crash.

        * parser/ModuleAnalyzer.cpp:
        (JSC::ModuleAnalyzer::exportVariable):
        * runtime/JSModuleRecord.cpp:
        (JSC::getExportedNames):
        (JSC::JSModuleRecord::dump): Deleted.
        * runtime/JSModuleRecord.h:
        * tests/modules/namespace-re-export.js: Added.
        * tests/modules/namespace-re-export/namespace-re-export-fixture.js: Added.
        * tests/modules/namespace-re-export/namespace-re-export.js: Added.
        * tests/modules/resources/assert.js:
        (export.shouldNotBe):

2016-05-17  Filip Pizlo  <fpizlo@apple.com>

        JSC should detect the right default locale even when it's not embedded in WebCore
        https://bugs.webkit.org/show_bug.cgi?id=157755
        rdar://problem/24665424

        Reviewed by Keith Miller.
        
        This makes JSC try to use WTF's platform user preferred language detection if the DOM did
        not register a defaultLanguage callback. The result is that when JSC runs standalone it
        will detect the platform user preferred language almost the same way as when it's embedded
        in WebCore. The only difference is that WebCore may have its own additional overrides via
        the WK API. But in the absence of overrides, WebCore uses the same WTF logic that JSC falls
        back to.
        
        We first found this bug because on iOS, the intl tests would fail because ICU would report
        a somewhat bogus locale on that platform. Prior to this change, standalone JSC would fall
        back to ICU's locale detection. It turns out that the ICU default locale is also bogus on
        OS X, just less so. For example, setting things to Poland did not result in the jsc shell
        printing dates Polish-style. Now it will print them Polish-style if your system preferences
        say so. Also, the tests don't fail on iOS anymore.
        
        * runtime/IntlObject.cpp:
        (JSC::defaultLocale):

2016-05-17  Dean Jackson  <dino@apple.com>

        Remove ES6_GENERATORS flag
        https://bugs.webkit.org/show_bug.cgi?id=157815
        <rdar://problem/26332894>

        Reviewed by Geoffrey Garen.

        This flag isn't needed. Generators are enabled everywhere and
        part of a stable specification.

        * Configurations/FeatureDefines.xcconfig:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionDeclaration): Deleted.
        (JSC::Parser<LexerType>::parseClass): Deleted.
        (JSC::Parser<LexerType>::parseExportDeclaration): Deleted.
        (JSC::Parser<LexerType>::parseAssignmentExpression): Deleted.
        (JSC::Parser<LexerType>::parseProperty): Deleted.
        (JSC::Parser<LexerType>::parseFunctionExpression): Deleted.

2016-05-17  Keith Miller  <keith_miller@apple.com>

        Rollout r200426 since it causes PLT regressions.
        https://bugs.webkit.org/show_bug.cgi?id=157812

        Unreviewed rollout of r200426 since the bots see a ~.6% PLT regression from the patch.

2016-05-17  Keith Miller  <keith_miller@apple.com>

        Add test262 harness support code
        https://bugs.webkit.org/show_bug.cgi?id=157797

        Reviewed by Filip Pizlo.

        This patch adds some new tooling needed to run Test262 with the jsc
        CLI. There were three options that needed to be added for Test262:

        1) "--test262-async" This option overrides the print function in the test runner to look for
        'Test262:AsyncTestComplete' instead of printing the passed text. If test262-async mode is on
        and that string is not passed then the test is marked as failing.

        2) "--strict-file=<file>" This option appends `"use strict";\n` to the beginning of the
        passed file before passing the source code to the VM. This option can, in theory, be passed
        multiple times.

        3) "--exception=<name>" This option asserts that at the end of the last script file passed
        the VM has an uncaught exception with its name property equal to the passed name.

        * jsc.cpp:
        (Script::Script):
        (fillBufferWithContentsOfFile):
        (functionPrint):
        (checkUncaughtException):
        (runWithScripts):
        (printUsageStatement):
        (CommandLine::parseArguments):
        (runJSC):

2016-05-17  Filip Pizlo  <fpizlo@apple.com>

        WTF should know about Language
        https://bugs.webkit.org/show_bug.cgi?id=157756

        Reviewed by Geoffrey Garen.

        Teach our scripts that a ObjC class beginning with WTF is totally cool.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2016-05-17  Joseph Pecoraro  <pecoraro@apple.com>

        console namespace breaks putting properties on console.__proto__
        https://bugs.webkit.org/show_bug.cgi?id=157782
        <rdar://problem/26250526>

        Reviewed by Geoffrey Garen.

        Some websites currently depend on console.__proto__ existing and being
        a separate object from Object.prototype. This patch adds back a basic
        console.__proto__ object, but all the console functions are left on
        the ConsoleObject itself.

        * runtime/JSGlobalObject.cpp:
        (JSC::createConsoleProperty):

2016-05-17  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, dump more information when math-pow-stable-results.js failed
        https://bugs.webkit.org/show_bug.cgi?id=157168

        * tests/stress/math-pow-stable-results.js:

2016-05-16  Saam barati  <sbarati@apple.com>

        ShadowChicken crashes when reading a scope from the frame during a stack overflow exception
        https://bugs.webkit.org/show_bug.cgi?id=157770

        Reviewed by Filip Pizlo.

        ShadowChicken was reading the scope from a half formed
        frame as it threw a stack overflow exception. The frame had
        a valid CodeBlock pointer, but it did not have a valid scope.
        The code in ShadowChicken's throw packet logging mechanism didn't
        account for this. The fix is to respect whether genericUnwind wants
        to unwind from the current frame or the caller's frame. For stack
        overflow errors, we always unwind the caller's frame.

        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):

2016-05-16  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION(r200208): It made 2 JSC stress tests fail on x86
        https://bugs.webkit.org/show_bug.cgi?id=157168

        Reviewed by Benjamin Poulain.

        The fast path in operationMathPow produces different results between x87 and the other environments.
        This is because x87 calculates the double value in 80bit precision.
        The situation is the following: in x86 32bit environment, floating point operations are compiled to
        x87 operations by default even if we can use SSE2. But in DFG environment, we aggressively use SSE2
        if the cpuid reports SSE2 is available. As a result, the implementations differ between C runtime
        and DFG JIT code. The C runtime uses x87 while DFG JIT code uses SSE2. This causes a precision
        problem since x87 has 80bit precision while SSE2 has 64bit precision.

        In this patch, in x86 32bit environment, we use `volatile double` if the `-mfpmath=sse and -msse2 (or later)`
        is not specified. This will round the x87 value into 64bit per multiplying. Note that this problem does not
        occur in OS X clang 32bit environment. This is because `-mfpmath=sse` is enabled by default in OS X clang 32bit.

        * b3/B3MathExtras.cpp:
        (JSC::B3::powDoubleInt32):
        * runtime/MathCommon.cpp:
        (JSC::operationMathPow):

2016-05-16  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] "return this" in a constructor does not need a branch on isObject(this)
        https://bugs.webkit.org/show_bug.cgi?id=157775

        Reviewed by Saam Barati and Ryosuke Niwa.

        When returning "this" in a constructor, the bytecode generator was generating:
            is_object         locX, this
            jtrue             locX, 5(->second ret)
            ret               this
            ret               this

        That code is eliminated in DFG but it is pretty costly lower tiers.

        This patch changes bytecode generation to avoid the is_object test
        when possible and not generate two ret if they encode the same thing.

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

2016-05-16  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove the index check from op_get_by_val/op_put_by_val when the index is constant
        https://bugs.webkit.org/show_bug.cgi?id=157766

        Reviewed by Geoffrey Garen.

        If the index is an integer constant, do not generate the index check.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emitSlow_op_put_by_val):

2016-05-16  Benjamin Poulain  <bpoulain@apple.com>

        [JSC][DFG] Fill spilled Int32 as Int32 instead of JSInt32
        https://bugs.webkit.org/show_bug.cgi?id=157700

        Reviewed by Michael Saboff.

        In general, fillSpeculateInt32() originate from SpeculateInt32
        and the user does not care about the tag.

        This is particularily obvious on Sunspider's math-spectral-norm.js.
        In that test, registers are frequently spilled because of x86's DIV.

        When they are re-filled, they were always tagged.
        Since the loops are small, all the tagging adds up.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):

2016-05-16  Saam barati  <sbarati@apple.com>

        Unreviewed Cloop build fix.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):

2016-05-16  Saam barati  <sbarati@apple.com>

        Hook up ShadowChicken to the debugger to show tail deleted frames
        https://bugs.webkit.org/show_bug.cgi?id=156685
        <rdar://problem/25770521>

        Reviewed by Filip Pizlo and Mark Lam and Joseph Pecoraro.

        The heart of this patch hooks up ShadowChicken to DebuggerCallFrame to
        allow the Web Inspector to display the ShadowChicken's shadow stack.
        This means the Web Inspector can now display tail deleted frames.
        To make this work, I made the necessary changes to ShadowChicken and
        DebuggerCallFrame to allow DebuggerCallFrame to keep the same API
        when representing both machine frames and tail deleted frames.

        - ShadowChicken prologue packets now log the current scope. Tail packets
          log the current scope, the 'this' value, the CodeBlock, and the
          CallSiteIndex. This allows the inspector to not only show the
          tail deleted frame, but also show exactly where the tail call happened (line and column numbers),
          with which scope it executed, and with which 'this' value. This
          patch also allows DebuggerCallFrame to execute console statements
          in a tail deleted frame.

        - I changed ShadowChicken's stack resizing algorithm. ShadowChicken
          now only keeps a maximum number of tail deleted frames in its shadow stack.
          It will happily represent all machine frames without limit. Right now, the
          maximum number of tail deleted frames I chose to keep alive is 128.
          We will keep frames alive starting from the top of the stack. This
          allows us to have a strong defense against runaway memory usage. We will only
          keep around at most 128 "shadow" frames that wouldn't have naturally been kept
          alive by the executing program. We can play around with this number
          if we find that 128 is either too many or too few frames.

        - DebuggerCallFrame is no longer a cheap class to create. When it is created,
          we will eagerly create the entire virtual debugger stack. So I modified the
          existing code to lazily create DebuggerCallFrames only when necessary. We
          used to eagerly create them at each op_debug statement even though we would
          just throw them away if we didn't hit a breakpoint.

        - A valid DebuggerCallFrame will always have a valid CallFrame* pointer
          into the stack. This pointer won't always refer to the logical frame
          that the DebuggerCallFrame represents because a DebuggerCallFrame can
          now represent a tail deleted frame. To do this, DebuggerCallFrame now
          has a ShadowChicken::Frame member variable. This allows DebuggerCallFrame
          to know when it represents a tail deleted frame and gives DebuggerCallFrame
          a mechanism to ask the tail deleted frame for interesting information
          (like its 'this' value, scope, CodeBlock, etc). A tail deleted frame's
          machine frame pointer will be the machine caller of the tail deleted frame
          (or the machine caller of the first of a series of consecutive tail calls).

        - I added a new flag to UnlinkedCodeBlock to indicate when it is compiled
          with debugging opcodes. I did this because ShadowChicken may read a JSScope
          from the machine stack. This is only safe if the machine CodeBlock was
          compiled with debugging opcodes. This is safer than asking if the
          CodeBlock's global object has an interactive debugger enabled because
          it's theoretically possible for the debugger to be enabled while code
          compiled without a debugger is still live on the stack. This field is
          also now used to indicate to the DFGGraph that the interactive debugger
          is enabled.

        - Finally, this patch adds a new field to the Inspector's CallFrame protocol
          object called 'isTailDeleted' to allow the Inspector to know when a
          CallFrame represents a tail deleted frame.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::findPC):
        (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::clearDebuggerRequests):
        (JSC::CodeBlock::wasCompiledWithDebuggingOpcodes):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes):
        (JSC::UnlinkedCodeBlock::finishCreation):
        (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitEnter):
        (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
        (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
        (JSC::BytecodeGenerator::emitCallDefineProperty):
        * debugger/Debugger.cpp:
        (JSC::DebuggerPausedScope::DebuggerPausedScope):
        (JSC::DebuggerPausedScope::~DebuggerPausedScope):
        (JSC::Debugger::didReachBreakpoint):
        (JSC::Debugger::currentDebuggerCallFrame):
        * debugger/Debugger.h:
        * debugger/DebuggerCallFrame.cpp:
        (JSC::LineAndColumnFunctor::operator()):
        (JSC::DebuggerCallFrame::create):
        (JSC::DebuggerCallFrame::DebuggerCallFrame):
        (JSC::DebuggerCallFrame::callerFrame):
        (JSC::DebuggerCallFrame::globalExec):
        (JSC::DebuggerCallFrame::vmEntryGlobalObject):
        (JSC::DebuggerCallFrame::sourceID):
        (JSC::DebuggerCallFrame::functionName):
        (JSC::DebuggerCallFrame::scope):
        (JSC::DebuggerCallFrame::type):
        (JSC::DebuggerCallFrame::thisValue):
        (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
        (JSC::DebuggerCallFrame::invalidate):
        (JSC::DebuggerCallFrame::currentPosition):
        (JSC::DebuggerCallFrame::positionForCallFrame):
        (JSC::DebuggerCallFrame::sourceIDForCallFrame):
        (JSC::FindCallerMidStackFunctor::FindCallerMidStackFunctor): Deleted.
        (JSC::FindCallerMidStackFunctor::operator()): Deleted.
        (JSC::FindCallerMidStackFunctor::getCallerFrame): Deleted.
        (JSC::DebuggerCallFrame::thisValueForCallFrame): Deleted.
        * debugger/DebuggerCallFrame.h:
        (JSC::DebuggerCallFrame::isValid):
        (JSC::DebuggerCallFrame::isTailDeleted):
        (JSC::DebuggerCallFrame::create): Deleted.
        (JSC::DebuggerCallFrame::exec): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::~Graph):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::addCallSite):
        (JSC::DFG::JITCompiler::emitStoreCodeOrigin):
        (JSC::DFG::JITCompiler::emitStoreCallSiteIndex):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue):
        (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail):
        (JSC::FTL::DFG::LowerDFGToB3::compileRecordRegExpCachedResult):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::ensureShadowChickenPacket):
        (JSC::FTL::DFG::LowerDFGToB3::setupShadowChickenPacket): Deleted.
        * inspector/InjectedScriptSource.js:
        (InjectedScript.CallFrameProxy):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::thisObject):
        (Inspector::JSJavaScriptCallFrame::isTailDeleted):
        (Inspector::JSJavaScriptCallFrame::type):
        * inspector/JSJavaScriptCallFrame.h:
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluateWithScopeExtension):
        (Inspector::jsJavaScriptCallFrameAttributeType):
        (Inspector::jsJavaScriptCallFrameIsTailDeleted):
        * inspector/JavaScriptCallFrame.h:
        (Inspector::JavaScriptCallFrame::type):
        (Inspector::JavaScriptCallFrame::scopeChain):
        (Inspector::JavaScriptCallFrame::vmEntryGlobalObject):
        (Inspector::JavaScriptCallFrame::isTailDeleted):
        (Inspector::JavaScriptCallFrame::thisValue):
        (Inspector::JavaScriptCallFrame::evaluateWithScopeExtension):
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::evaluateBreakpointAction):
        * inspector/protocol/Debugger.json:
        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::update):
        (JSC::ShadowChicken::visitChildren):
        (JSC::ShadowChicken::reset):
        * interpreter/ShadowChicken.h:
        (JSC::ShadowChicken::Packet::throwMarker):
        (JSC::ShadowChicken::Packet::prologue):
        (JSC::ShadowChicken::Packet::tail):
        (JSC::ShadowChicken::Frame::Frame):
        (JSC::ShadowChicken::Frame::operator==):
        * jit/CCallHelpers.cpp:
        (JSC::CCallHelpers::logShadowChickenProloguePacket):
        (JSC::CCallHelpers::logShadowChickenTailPacket):
        (JSC::CCallHelpers::ensureShadowChickenPacket):
        (JSC::CCallHelpers::setupShadowChickenPacket): Deleted.
        * jit/CCallHelpers.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_profile_type):
        (JSC::JIT::emit_op_log_shadow_chicken_prologue):
        (JSC::JIT::emit_op_log_shadow_chicken_tail):
        (JSC::JIT::emit_op_get_enumerable_length):
        (JSC::JIT::emit_op_resume):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_profile_type):
        (JSC::JIT::emit_op_log_shadow_chicken_prologue):
        (JSC::JIT::emit_op_log_shadow_chicken_tail):
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::webAssemblyCalleeSaveRegisters):
        (JSC::RegisterSet::argumentGPRS):
        (JSC::RegisterSet::registersToNotSaveForJSCall):
        * jit/RegisterSet.h:
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        * runtime/Options.h:
        * tests/stress/shadow-chicken-enabled.js:
        (test5a.foo):
        (test5a):
        (test5b.foo):
        (test5b):
        (test6.foo):
        (test6):

2016-05-16  Saam barati  <sbarati@apple.com>

        TypeSet/StructureShape have a flawed sense of JS prototype chains
        https://bugs.webkit.org/show_bug.cgi?id=157760

        Reviewed by Joseph Pecoraro.

        There was an assumption that we would bottom out in "Object". This is
        not true for many reasons. JS objects may not end in Object.prototype.
        Also, our mechanism of grabbing an Object's class name may also not
        bottom out in "Object". We were seeing this in the JS objects we use
        in the InjectedScriptSource.js inspector script.

        * runtime/TypeSet.cpp:
        (JSC::StructureShape::leastCommonAncestor):
        * tests/typeProfiler/weird-prototype-chain.js: Added.
        (wrapper.foo):
        (wrapper.let.o2):
        (wrapper):

2016-05-16  Joseph Pecoraro  <pecoraro@apple.com>

        Unreviewed rollout r200924. Caused js/regress/string-replace-generic.html to fail.

        * API/JSProfilerPrivate.cpp: Copied from Source/JavaScriptCore/profiler/ProfilerJettisonReason.h.
        (JSStartProfiling):
        (JSEndProfiling):
        * API/JSProfilerPrivate.h: Copied from Source/JavaScriptCore/profiler/ProfilerJettisonReason.h.
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitCallVarargs):
        (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
        (JSC::BytecodeGenerator::emitConstructVarargs):
        (JSC::BytecodeGenerator::emitConstruct):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::CallArguments::profileHookRegister):
        (JSC::BytecodeGenerator::shouldEmitProfileHooks):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::CallArguments::CallArguments):
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        * 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:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled):
        * inspector/protocol/Timeline.json:
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::operator()):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_profile_will_call):
        (JSC::JIT::emit_op_profile_did_call):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_profile_will_call):
        (JSC::JIT::emit_op_profile_did_call):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jsc.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ParserModes.h:
        * profiler/CallIdentifier.h: Added.
        (JSC::CallIdentifier::CallIdentifier):
        (JSC::CallIdentifier::functionName):
        (JSC::CallIdentifier::url):
        (JSC::CallIdentifier::lineNumber):
        (JSC::CallIdentifier::columnNumber):
        (JSC::CallIdentifier::operator==):
        (JSC::CallIdentifier::operator!=):
        (JSC::CallIdentifier::Hash::hash):
        (JSC::CallIdentifier::Hash::equal):
        (JSC::CallIdentifier::hash):
        (JSC::CallIdentifier::operator const char*):
        (JSC::CallIdentifier::c_str):
        (WTF::HashTraits<JSC::CallIdentifier>::constructDeletedValue):
        (WTF::HashTraits<JSC::CallIdentifier>::isDeletedValue):
        * profiler/LegacyProfiler.cpp: Added.
        (JSC::LegacyProfiler::profiler):
        (JSC::LegacyProfiler::startProfiling):
        (JSC::LegacyProfiler::stopProfiling):
        (JSC::callFunctionForProfilesWithGroup):
        (JSC::LegacyProfiler::suspendProfiling):
        (JSC::LegacyProfiler::unsuspendProfiling):
        (JSC::LegacyProfiler::willExecute):
        (JSC::LegacyProfiler::didExecute):
        (JSC::LegacyProfiler::exceptionUnwind):
        (JSC::LegacyProfiler::createCallIdentifier):
        (JSC::createCallIdentifierFromFunctionImp):
        * profiler/LegacyProfiler.h: Added.
        (JSC::LegacyProfiler::currentProfiles):
        * profiler/Profile.cpp: Added.
        (JSC::Profile::create):
        (JSC::Profile::Profile):
        (JSC::Profile::~Profile):
        (JSC::Profile::debugPrint):
        (JSC::functionNameCountPairComparator):
        (JSC::Profile::debugPrintSampleStyle):
        * profiler/Profile.h: Copied from Source/JavaScriptCore/profiler/ProfilerJettisonReason.h.
        * profiler/ProfileGenerator.cpp: Added.
        (JSC::ProfileGenerator::create):
        (JSC::ProfileGenerator::ProfileGenerator):
        (JSC::AddParentForConsoleStartFunctor::AddParentForConsoleStartFunctor):
        (JSC::AddParentForConsoleStartFunctor::foundParent):
        (JSC::AddParentForConsoleStartFunctor::operator()):
        (JSC::ProfileGenerator::addParentForConsoleStart):
        (JSC::ProfileGenerator::title):
        (JSC::ProfileGenerator::beginCallEntry):
        (JSC::ProfileGenerator::endCallEntry):
        (JSC::ProfileGenerator::willExecute):
        (JSC::ProfileGenerator::didExecute):
        (JSC::ProfileGenerator::exceptionUnwind):
        (JSC::ProfileGenerator::stopProfiling):
        (JSC::ProfileGenerator::removeProfileStart):
        (JSC::ProfileGenerator::removeProfileEnd):
        * profiler/ProfileGenerator.h: Added.
        (JSC::ProfileGenerator::profile):
        (JSC::ProfileGenerator::origin):
        (JSC::ProfileGenerator::profileGroup):
        (JSC::ProfileGenerator::setIsSuspended):
        * profiler/ProfileNode.cpp: Added.
        (JSC::ProfileNode::ProfileNode):
        (JSC::ProfileNode::addChild):
        (JSC::ProfileNode::removeChild):
        (JSC::ProfileNode::spliceNode):
        (JSC::ProfileNode::traverseNextNodePostOrder):
        (JSC::ProfileNode::debugPrint):
        (JSC::ProfileNode::debugPrintSampleStyle):
        (JSC::ProfileNode::debugPrintRecursively):
        (JSC::ProfileNode::debugPrintSampleStyleRecursively):
        * profiler/ProfileNode.h: Added.
        (JSC::ProfileNode::create):
        (JSC::ProfileNode::Call::Call):
        (JSC::ProfileNode::Call::startTime):
        (JSC::ProfileNode::Call::setStartTime):
        (JSC::ProfileNode::Call::elapsedTime):
        (JSC::ProfileNode::Call::setElapsedTime):
        (JSC::ProfileNode::operator==):
        (JSC::ProfileNode::callerCallFrame):
        (JSC::ProfileNode::callIdentifier):
        (JSC::ProfileNode::id):
        (JSC::ProfileNode::functionName):
        (JSC::ProfileNode::url):
        (JSC::ProfileNode::lineNumber):
        (JSC::ProfileNode::columnNumber):
        (JSC::ProfileNode::parent):
        (JSC::ProfileNode::setParent):
        (JSC::ProfileNode::calls):
        (JSC::ProfileNode::lastCall):
        (JSC::ProfileNode::appendCall):
        (JSC::ProfileNode::children):
        (JSC::ProfileNode::firstChild):
        (JSC::ProfileNode::lastChild):
        (JSC::ProfileNode::nextSibling):
        (JSC::ProfileNode::setNextSibling):
        (JSC::ProfileNode::forEachNodePostorder):
        (JSC::CalculateProfileSubtreeDataFunctor::operator()):
        (JSC::CalculateProfileSubtreeDataFunctor::returnValue):
        * profiler/ProfilerJettisonReason.cpp:
        (WTF::printInternal):
        * profiler/ProfilerJettisonReason.h:
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        * runtime/CodeCache.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::~JSGlobalObject):
        (JSC::JSGlobalObject::hasLegacyProfiler):
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock):
        (JSC::JSGlobalObject::createModuleProgramCodeBlock):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::supportsLegacyProfiling):
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::SetEnabledProfilerFunctor::operator()):
        (JSC::VM::setEnabledProfiler):
        * runtime/VM.h:
        (JSC::VM::enabledProfiler):
        (JSC::VM::enabledProfilerAddress):

2016-05-16  Konstantin Tokarev  <annulen@yandex.ru>

        Unreviewed, fixed typo in a comment.

        * assembler/MacroAssembler.h: Replaced "onvenience" with
        "convenience".

2016-05-16  Filip Pizlo  <fpizlo@apple.com>

        FixupPhase should be more eager to demote bit math to untyped
        https://bugs.webkit.org/show_bug.cgi?id=157746

        Reviewed by Mark Lam.
        
        This just makes the logic for how we fixup bit math match the way we do it in other places.
        This doesn't affect performance on any major benchmark but it's a big win on new
        microbenchmarks added in this change.
        
        Details:

        object-and                                     11.1610+-0.7602     ^      4.8105+-0.1690        ^ definitely 2.3201x faster
        object-or                                      11.0845+-0.2487     ^      4.7146+-0.0374        ^ definitely 2.3511x faster
        object-xor                                     10.2946+-0.9946     ^      4.7278+-0.0814        ^ definitely 2.1775x faster
        object-lshift                                  10.4896+-1.0867     ^      4.7699+-0.0721        ^ definitely 2.1991x faster
        object-rshift                                  11.1239+-0.5010     ^      4.7194+-0.0445        ^ definitely 2.3570x faster
        object-urshift                                 10.9745+-0.1315     ^      4.7848+-0.0479        ^ definitely 2.2936x faster

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

2016-05-15  Michael Saboff  <msaboff@apple.com>

        RegExp /y flag incorrect handling of mixed-length alternation
        https://bugs.webkit.org/show_bug.cgi?id=157723

        Reviewed by Filip Pizlo.

        Previously for sticky patterns, we were bailing out and exiting when backtracking
        alternatives with dissimilar match lengths.  Deleted that code.  Instead, for
        sticky patterns we need to process the backtracking except for advancing to the
        next input index.

        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::backtrack):

2016-05-15  Filip Pizlo  <fpizlo@apple.com>

        DFG::Plan shouldn't read from its VM once it's been cancelled
        https://bugs.webkit.org/show_bug.cgi?id=157726

        Reviewed by Saam Barati.
        
        Plan::vm was a reference, not a pointer, and so wasn't nulled by Plan::cancel(). So, a
        cancelled plan may have a dangling pointer to a VM: we could delete the VM after cancelling
        the plan.
        
        Prior to http://trac.webkit.org/changeset/200705, this was probably fine because nobody
        would read Plan::vm if the plan was cancelled. But r200705 changed that. It was a hard
        regression to spot because usually a cancelled plan will still refer to a valid VM.
        
        This change fixes the regression and makes it a lot easier to spot the regression in the
        future. Plan::vm is now a pointer and we null it in Plan::cancel(). Now if you make this
        mistake, you will get a crash anytime the Plan is cancelled, not just anytime the plan is
        cancelled and the VM gets deleted. Also, it's now very clear what to do when you want to
        use Plan::vm on the cancel path: you can null-check vm; if it's null, assume the worst.
        
        Because we null the VM of a cancelled plan, we cannot have Safepoint::vm() return the
        plan's VM anymore. That's because when we cancel a plan that is at a safepoint, we use the
        safepoint's VM to determine whether this is one of our safepoints *after* the plan is
        already cancelled. So, Safepoint now has its own copy of m_vm, and that copy gets nulled
        when the Safepoint is cancelled. The Safepoint's m_vm will be nulled moments after Plan's
        vm gets nulled (see Worklist::removeDeadPlans(), which has a cancel path for Plans in one
        loop and a cancel path for Safepoints in the loop after it).

        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::finalizeCommon):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::Plan):
        (JSC::DFG::Plan::computeCompileTimes):
        (JSC::DFG::Plan::reportCompileTimes):
        (JSC::DFG::Plan::compileInThreadImpl):
        (JSC::DFG::Plan::reallyAdd):
        (JSC::DFG::Plan::notifyCompiling):
        (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
        (JSC::DFG::Plan::cancel):
        * dfg/DFGPlan.h:
        (JSC::DFG::Plan::canTierUpAndOSREnter):
        * dfg/DFGSafepoint.cpp:
        (JSC::DFG::Safepoint::cancel):
        (JSC::DFG::Safepoint::vm):
        * dfg/DFGSafepoint.h:
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::isActiveForVM):
        (JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
        (JSC::DFG::Worklist::removeAllReadyPlansForVM):
        (JSC::DFG::Worklist::rememberCodeBlocks):
        (JSC::DFG::Worklist::visitWeakReferences):
        (JSC::DFG::Worklist::removeDeadPlans):
        (JSC::DFG::Worklist::runThread):
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):

2016-05-15  Yusuke Suzuki  <utatane.tea@gmail.com>

        Modernize Intl constructors; using InternalFunction::createSubclassStructure
        https://bugs.webkit.org/show_bug.cgi?id=157082

        Reviewed by Darin Adler.

        Previously, Intl constructors retrieve "prototype" to inherit the "new.target".
        At that time, this mis-assumed that getDirect() always returns meaningful JS value.
        Actually, it returns an empty value if a property does not exist.

        Instead of fixing this assertion, we now use InternalFunction::createSubclassStructure
        in Intl constructors. It is modern and preferable way since it can cache the derived
        structures in InternalFunction.

        This patch also cleans up the workaround in Intl.NumberFormat and Intl.DateTimeFormat.
        Those code are largely duplicate. This is now extracted into
        constructIntlInstanceWithWorkaroundForLegacyIntlConstructor. This clean up does not
        have any behavior changes. They are already tested in LayoutTests/js/intl-datetimeformat
        and LayoutTests/js/intl-numberformat.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/IntlCollator.cpp:
        (JSC::IntlCollator::create):
        * runtime/IntlCollator.h:
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::constructIntlCollator):
        (JSC::callIntlCollator):
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::create):
        * runtime/IntlDateTimeFormat.h:
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::constructIntlDateTimeFormat):
        (JSC::callIntlDateTimeFormat):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormat::create):
        * runtime/IntlNumberFormat.h:
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::constructIntlNumberFormat):
        (JSC::callIntlNumberFormat):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
        * runtime/IntlObjectInlines.h: Added.
        (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
        * tests/stress/intl-constructors-with-proxy.js: Added.
        (shouldBe):
        (throw.new.Error.Empty):
        (throw.new.Error):
        (shouldBe.Empty):

2016-05-14  Joseph Pecoraro  <pecoraro@apple.com>

        Remove LegacyProfiler
        https://bugs.webkit.org/show_bug.cgi?id=153565

        Reviewed by Mark Lam.

        JavaScriptCore now provides a sampling profiler and it is enabled
        by all ports. Web Inspector switched months ago to using the
        sampling profiler and displaying its data. Remove the legacy
        profiler, as it is no longer being used by anything other then
        console.profile and tests. We will update console.profile's
        behavior soon to have new behavior and use the sampling data.

        * API/JSProfilerPrivate.cpp: Removed.
        * API/JSProfilerPrivate.h: Removed.
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset): Deleted.
        (JSC::computeDefsForBytecodeOffset): Deleted.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode): Deleted.
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitCallVarargs):
        (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
        (JSC::BytecodeGenerator::emitConstructVarargs):
        (JSC::BytecodeGenerator::emitConstruct):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::CallArguments::profileHookRegister): Deleted.
        (JSC::BytecodeGenerator::shouldEmitProfileHooks): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::CallArguments::CallArguments): Deleted.
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock): Deleted.
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel): Deleted.
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize): Deleted.
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC): Deleted.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute): Deleted.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Deleted.
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Deleted.
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled):
        * inspector/protocol/Timeline.json:
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::operator()): Deleted.
        (JSC::Interpreter::execute): Deleted.
        (JSC::Interpreter::executeCall): Deleted.
        (JSC::Interpreter::executeConstruct): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass): Deleted.
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_profile_will_call): Deleted.
        (JSC::JIT::emit_op_profile_did_call): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_profile_will_call): Deleted.
        (JSC::JIT::emit_op_profile_did_call): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jsc.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ParserModes.h:
        * profiler/CallIdentifier.h: Removed.
        * profiler/LegacyProfiler.cpp: Removed.
        * profiler/LegacyProfiler.h: Removed.
        * profiler/Profile.cpp: Removed.
        * profiler/Profile.h: Removed.
        * profiler/ProfileGenerator.cpp: Removed.
        * profiler/ProfileGenerator.h: Removed.
        * profiler/ProfileNode.cpp: Removed.
        * profiler/ProfileNode.h: Removed.
        * profiler/ProfilerJettisonReason.cpp:
        (WTF::printInternal): Deleted.
        * profiler/ProfilerJettisonReason.h:
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        * runtime/CodeCache.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock):
        (JSC::JSGlobalObject::createModuleProgramCodeBlock):
        (JSC::JSGlobalObject::~JSGlobalObject): Deleted.
        (JSC::JSGlobalObject::hasLegacyProfiler): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::supportsLegacyProfiling): Deleted.
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::VM): Deleted.
        (JSC::SetEnabledProfilerFunctor::operator()): Deleted.
        (JSC::VM::setEnabledProfiler): Deleted.
        * runtime/VM.h:
        (JSC::VM::enabledProfiler): Deleted.
        (JSC::VM::enabledProfilerAddress): Deleted.

2016-05-13  Joseph Pecoraro  <pecoraro@apple.com>

        jsc: samplingProfilerStackTraces() without starting sampling should not cause jsc to crash
        https://bugs.webkit.org/show_bug.cgi?id=157704

        Reviewed by Saam Barati.

        * jsc.cpp:
        (functionStartSamplingProfiler):
        (functionSamplingProfilerStackTraces):
        Throw an exception instead of crashing if we haven't started sampling.

        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::startTracking):
        * runtime/VM.h:
        * runtime/VM.cpp:
        (JSC::VM::ensureSamplingProfiler):
        Switch ensure to returning a reference, like most other ensures.

2016-05-13  Saam barati  <sbarati@apple.com>

        DFG/FTL have a few bugs in their reasoning about the scope
        https://bugs.webkit.org/show_bug.cgi?id=157696

        Reviewed by Benjamin Poulain.

        1. When the debugger is enabled, it is easier for the DFG to reason
        about the scope register by simply claiming all nodes read the scope
        register. This prevents us from ever entering the runtime where we
        may take a stack trace but there isn't a scope on the stack.

        2. This patch fixes a bug where the FTL compilation wasn't properly
        setting the CodeBlock register. It was only doing this when there
        was inline data, but when the debugger is enabled, we never inline.
        So this code just needed to be removed from that loop. It was never
        right for it to be inside the loop.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):

2016-05-13  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] SetLocal without exit do not need phantoms
        https://bugs.webkit.org/show_bug.cgi?id=157653

        Reviewed by Filip Pizlo.

        I made a mistake in r200498.

        If a SetLocal cannot possibly exit, we were not clearing
        the source of the operand. As a result, we sometime kept
        a value alive up to the end of the block.

        That's uncommon because SetLocal typically appear
        toward the end of blocks. That's probably why there was
        no perf impact with that fix.

        * dfg/DFGPhantomInsertionPhase.cpp:

2016-05-13  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Move the CheckTierUp function calls out of the main path
        https://bugs.webkit.org/show_bug.cgi?id=157668

        Reviewed by Mark Lam.

        If you have a tiny tiny loop (for example, Sunspider's bits-in-byte),
        the size of CheckTierUp is a problem.

        On multi-issue CPUs, the node is so big that we do not
        get to run anything from the loop in the instruction fetch.

        On x86, having a bigger loop also pushes us out of the LSD.

        This is a 6% improvement on bits-in-byte. Other Sunspider tests
        only improves marginally.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
        (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::silentSpill):
        (JSC::DFG::SpeculativeJIT::silentFill):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2016-05-13  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Emit the loads of emitLoadWithStructureCheck() in the order they are used
        https://bugs.webkit.org/show_bug.cgi?id=157671

        Reviewed by Mark Lam.

        This improves the chances of having a value
        when issuing the TEST.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitLoadWithStructureCheck):

2016-05-13  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Inform augmenting client when inspector controller is destroyed
        https://bugs.webkit.org/show_bug.cgi?id=157688
        <rdar://problem/25832724>

        Reviewed by Timothy Hatcher.

        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::~JSGlobalObjectInspectorController):
        * inspector/augmentable/AugmentableInspectorControllerClient.h:
        There is a weak relationship between the InspectorController and the
        AugmentingClient. Let the augmenting client know when the controller
        is destroyed so it doesn't try to use us anymore.

2016-05-13  Geoffrey Garen  <ggaren@apple.com>

        Runaway malloc memory usage in this simple JSC program
        https://bugs.webkit.org/show_bug.cgi?id=157682

        Reviewed by Mark Lam.

        * heap/WeakSet.cpp:
        (JSC::WeakSet::sweep): Whenever we might add a block to
        m_logicallyEmptyWeakBlocks, be sure also to sweep a block in
        m_logicallyEmptyWeakBlocks. Otherwise, additions might outpace removals
        even when all memory is freed.

        We do this whenever we *might* add a block and not just whenever we *do*
        add a block because we'd like to sweep the entries in
        m_logicallyEmptyWeakBlocks promptly even when it's not growing, and this
        is a reasonably rate-limited opportunity to do so.

2016-05-13  Mark Lam  <mark.lam@apple.com>

        We should have one calleeSaveRegistersBuffer per VMEntryFrame, not one per VM.
        https://bugs.webkit.org/show_bug.cgi?id=157537
        <rdar://problem/24794845>

        Reviewed by Michael Saboff.

        The pre-existing code behaves this way:

        1. When JS code throws an exception, it saves callee save registers in
           the VM calleeSaveRegistersBuffer.  These values are meant to be restored
           to the callee save registers later either at the catch handler or at the
           uncaught exception handler.

        2. If the Inspector is enable, the VM will invoke inspector C++ code to inspect
           the exception.  That C++ code can change the values of the callee save
           registers.

           The inspector code in turn re-enters the VM to execute JS inspector code.

           The JS inspector code can run hot enough that we do an enterOptimizationCheck
           on it.  The enterOptimizationCheck first saves all callee save registers
           into the VM calleeSaveRegistersBuffer.

           This effectively overwrites the values in the VM calleeSaveRegistersBuffer
           from (1).

        3. Eventually, execution returns to the catch handler or the uncaught exception
           handler which restores the overwritten values in the VM
           calleeSaveRegistersBuffer to the callee save registers.

           When execution returns to the C++ code that entered the VM before (1), the
           values in the callee registers are not what that code expects, and badness
           and/or crashes ensues.

        This patch applies the following fix:
        
        1. Allocate space in the VMEntryFrame for the calleeSaveRegistersBuffer.
           This ensures that each VM entry session has its own buffer to use, and will
           not corrupt the one from the previous VM entry session.

           Delete the VM calleeSaveRegistersBuffer.

        2. Change all locations that uses the VM calleeSaveRegistersBuffer to use the
           calleeSaveRegistersBuffer in the current VMEntryFrame.

        3. Renamed all uses of the term "VMCalleeSavesBuffer" to
           "VMEntryFrameCalleeSavesBuffer".

        This fix has been tested on the following configurations:
        1. JSC and layout tests on a debug ASan build for 64-bit x86_64.
        2. JSC tests on a release ASan build for 32-bit x86.
        3. JSC tests on a release normal (non-ASan) build for ARM64.
        4. JSC tests on a release normal (non-ASan) build for ARMv7 and ARMv7s.
        5. JSC tests on a release ASan CLOOP build for x86_64.

        These test runs did not produce any new crashes.  The ASan CLOOP has some
        pre-existing crashes which are not due to this patch.

        This bug can be tested by running the inspector/debugger/regress-133182.html test
        on an ASan build.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessGenerationState::emitExplicitExceptionHandler):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileExceptionHandlers):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrEntryThunkGenerator):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::operator()):
        (JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
        (JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer): Deleted.
        * interpreter/Interpreter.h:
        (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
        * interpreter/VMEntryRecord.h:
        (JSC::VMEntryRecord::calleeSaveRegistersBufferOffset):
        (JSC::VMEntryRecord::prevTopCallFrame):
        (JSC::VMEntryRecord::unsafePrevTopCallFrame):
        (JSC::VMEntryFrame::vmEntryRecordOffset):
        (JSC::VMEntryFrame::calleeSaveRegistersBufferOffset):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitRandomThunk):
        (JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::restoreCalleeSavesFromVMCalleeSavesBuffer): Deleted.
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitRestoreSavedTagRegisters):
        (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::copyCalleeSavesToVMCalleeSavesBuffer): Deleted.
        (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMCalleeSavesBuffer): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::emitEnterOptimizationCheck):
        (JSC::JIT::privateCompileExceptionHandlers):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emitSlow_op_loop_hint):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::emit_op_catch):
        * jit/ThunkGenerators.cpp:
        (JSC::throwExceptionFromCallSlowPathGenerator):
        (JSC::nativeForGenerator):
        * llint/LLIntThunks.cpp:
        (JSC::vmEntryRecord):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/VM.h:
        (JSC::VM::getCTIStub):
        (JSC::VM::calleeSaveRegistersBufferOffset): Deleted.
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::endFunction):

2016-05-13  Beth Dakin  <bdakin@apple.com>

        Add dyldSPI.h for linked on or after checks, and add one for link preview
        https://bugs.webkit.org/show_bug.cgi?id=157401
        -and corresponding-
        rdar://problem/26253396

        Reviewed by Darin Adler.

        Import #import <wtf/spi/darwin/dyldSPI.h> which now declares all of the 
        needed dyld code.
        * API/JSWrapperMap.mm:

2016-05-13  Yusuke Suzuki  <utatane.tea@gmail.com>

        Assertion failure for direct eval in non-class method
        https://bugs.webkit.org/show_bug.cgi?id=157138

        Reviewed by Saam Barati.

        This assertion was incorrect. In method definitions in object literals,
        it can be sloppy mode, but its DerivedContextType may not be DerivedContextType::None.

        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::CacheKey::CacheKey):
        (JSC::EvalCodeCache::CacheKey::operator==):
        (JSC::EvalCodeCache::CacheKey::Hash::equal):
        (JSC::EvalCodeCache::tryGet):
        (JSC::EvalCodeCache::getSlow):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * tests/stress/direct-eval-in-object-literal-methods.js: Added.
        (shouldBe):
        (throw.new.Error):
        (shouldBe.Parent.prototype.l):
        (shouldBe.Parent):
        (shouldBe.Derived.prototype.m):
        (shouldBe.Derived):

2016-05-13  Skachkov Oleksandr  <gskachkov@gmail.com>

        Assertion failure for super() call in arrow function default parameters
        https://bugs.webkit.org/show_bug.cgi?id=157079

        Reviewed by Saam Barati.

        Root of the issue that in arrow function we load bounded variables this/super/new.target just after 
        input parameters were initialized, and did not covered case of default values for 
        function parameters. 
        Current patch tried to fix issue and allow to load bounded variables earlier, before the input 
        parameters are assigned by default values.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * tests/stress/arrowfunction-lexical-bind-this-2.js:

2016-05-12  Mark Lam  <mark.lam@apple.com>

        Baseline and DFG's JSC_report...CompileTimes needs CodeBlock hashes.
        https://bugs.webkit.org/show_bug.cgi?id=157643

        Reviewed by Keith Miller.

        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

2016-05-12  Csaba Osztrogonác  <ossy@webkit.org>

        Remove ENABLE(ES6_ARROWFUNCTION_SYNTAX) guards
        https://bugs.webkit.org/show_bug.cgi?id=157564

        Reviewed by Darin Adler.

        * Configurations/FeatureDefines.xcconfig:
        * parser/Parser.cpp:

2016-05-12  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: CRASH getting internal properties of function with no bound arguments causes
        https://bugs.webkit.org/show_bug.cgi?id=157613
        <rdar://problem/26238754>

        Reviewed by Timothy Hatcher.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        Gracefully handle a JSBoundFunction with no bound arguments.
        In this case boundArgs is JSValue() which we don't want to
        expose as the value of the internal property.

2016-05-11  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Make sure StringRange is passed to Vector by register
        https://bugs.webkit.org/show_bug.cgi?id=157603

        Reviewed by Darin Adler.

        This is bizarre, but on my SDK, Vector::append(StringRange)
        is passing the values on the stack.
        The two integers are written to the stack, the address given
        to append(), then append() reads it back and store it.

        This patch changes the code to use constructAndAppend(), ensuring
        the values are used directly.

        On my machine, this helps Sunspider and Octane.
        This might be something wrong with my SDK but the fix is so easy
        that we might as well do this.

        * runtime/StringPrototype.cpp:
        (JSC::removeUsingRegExpSearch):
        (JSC::replaceUsingRegExpSearch):

2016-05-11  Zan Dobersek  <zdobersek@igalia.com>

        ARMv7Assembler: suppress a -Wnarrowing warning when compiling with GCC
        https://bugs.webkit.org/show_bug.cgi?id=157576

        Reviewed by Csaba Osztrogonác.

        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2): Explicitly cast the
        `OP_CMP_reg_T2 | left` value to uint16_t, avoiding a narrowing conversion
        warning that's being reported when compiling with GCC. The warning is sprung
        due to RegisterID (which is the type of `left`) being an enum based on int,
        even when the enum itself only declares 23 values.

2016-05-11  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: `this` in Scope Chain Sidebar does not have preview, looks poor
        https://bugs.webkit.org/show_bug.cgi?id=157602

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.CallFrameProxy):
        Include a preview when creating the RemoteObject for `this`.

2016-05-11  Keith Miller  <keith_miller@apple.com>

        Unreviewed, correct the title of the ChangeLog for r200667.

2016-05-11  Joseph Pecoraro  <pecoraro@apple.com>

        JSC test stress/reflect-set.js failing after 200694
        https://bugs.webkit.org/show_bug.cgi?id=157586

        Unreviewed test rebaseline.

        * tests/stress/reflect-set.js:
        Update the expected error message. We are in strict mode, so the
        improved error message makes sense.

2016-05-11  Filip Pizlo  <fpizlo@apple.com>

        Beef up JSC profiler event log
        https://bugs.webkit.org/show_bug.cgi?id=157584

        Reviewed by Saam Barati.
        
        Also log more about compilation.

        * bytecode/ExecutionCounter.cpp: Changed the meaning of codeBlock to be the codeBlock that is doing the profiling. This will now get the baseline version if it needs it. This is needed for logging the threshold checking event.
        (JSC::applyMemoryUsageHeuristics):
        (JSC::ExecutionCounter<countingVariant>::hasCrossedThreshold):
        * dfg/DFGJITCode.cpp: Pass the right codeBlock.
        (JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
        (JSC::DFG::JITCode::optimizeNextInvocation):
        (JSC::DFG::JITCode::dontOptimizeAnytimeSoon):
        (JSC::DFG::JITCode::optimizeSoon):
        (JSC::DFG::JITCode::forceOptimizationSlowPathConcurrently):
        * dfg/DFGPlan.cpp: Log things about compile times and whether the compiler succeeded or failed.
        (JSC::DFG::Plan::computeCompileTimes):
        (JSC::DFG::Plan::reportCompileTimes):
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
        * jit/ExecutableAllocatorFixedVMPool.cpp: Make it possible to look at memory usage, though separately from the log, for now.
        (JSC::ExecutableAllocator::allocate):
        * runtime/Options.h:

2016-05-11  Saam barati  <sbarati@apple.com>

        Air may decide to put the result register of an arithmetic snippet in the tag register
        https://bugs.webkit.org/show_bug.cgi?id=157548

        Reviewed by Filip Pizlo.

        This patch adds a new ValueRep to B3 called LateRegister. The semantics
        are similar to Register in that it can be used to pin an argument to
        a particular register. It differs from ValueRep::Register in that the semantics of
        LateRegister are that it is used after the result of the node its an argument to
        is computed. This means that a LateRegister argument will interfere with the result
        of a node. LateRegister is not a valid result ValueRep.

        This was needed because there was a bug where B3/Air would assign the
        result of a patchpoint to the TagTypeNumber register. This broke our
        code when we would box a double into a JSValue in a snippet when the
        result is the same as the TagTypeNumber register. To fix the issue,
        we pass TagMaskRegister and TagTypeNumberRegister as ValueRep::LateRegister
        arguments to various patchpoints.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::fillStackmap):
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::admitsStack):
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        (JSC::B3::StackmapSpecial::isArgValidForRep):
        * b3/B3Validate.cpp:
        * b3/B3ValueRep.cpp:
        (JSC::B3::ValueRep::addUsedRegistersTo):
        (JSC::B3::ValueRep::dump):
        (JSC::B3::ValueRep::emitRestore):
        (JSC::B3::ValueRep::recoveryForJSValue):
        (WTF::printInternal):
        * b3/B3ValueRep.h:
        (JSC::B3::ValueRep::reg):
        (JSC::B3::ValueRep::lateReg):
        (JSC::B3::ValueRep::stack):
        (JSC::B3::ValueRep::operator==):
        (JSC::B3::ValueRep::isSomeRegister):
        (JSC::B3::ValueRep::isReg):
        * b3/testb3.cpp:
        (JSC::B3::testSpillUseLargerThanDef):
        (JSC::B3::testLateRegister):
        (JSC::B3::zero):
        (JSC::B3::run):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):
        (JSC::FTL::DFG::LowerDFGToB3::getById):
        (JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet):
        (JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet):
        (JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet):

2016-05-11  Joseph Pecoraro  <pecoraro@apple.com>

        Improve error messages for accessing arguments.callee and similar getters in strict mode
        https://bugs.webkit.org/show_bug.cgi?id=157545

        Reviewed by Mark Lam.

        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::getOwnPropertySlot):
        (JSC::ClonedArguments::materializeSpecials):
        Provide better error GetterSetter in strict mode.

        * runtime/JSFunction.cpp:
        (JSC::getThrowTypeErrorGetterSetter):
        (JSC::JSFunction::defineOwnProperty):
        Provide better error GetterSetter in strict mode.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
        (JSC::JSGlobalObject::throwTypeErrorCalleeAndCallerGetterSetter):
        (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInStrictModeGetterSetter):
        (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInClassContextGetterSetter):
        (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerGetterSetter): Deleted.
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncThrowTypeErrorCalleeAndCaller):
        (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInStrictMode):
        (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInClassContext):
        (JSC::globalFuncThrowTypeErrorArgumentsAndCaller): Deleted.
        * runtime/JSGlobalObjectFunctions.h:
        Rename and expose new handles for new error getter setter native functions.

2016-05-11  Commit Queue  <commit-queue@webkit.org>

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

        it's bad news for asm.js (Requested by pizlo on #webkit).

        Reverted changeset:

        "Reduce maximum JIT pool size on X86_64."
        http://trac.webkit.org/changeset/200481

2016-05-10  Keith Miller  <keith_miller@apple.com>

        TypedArray.prototype.slice should not use the byteLength of the passed array for memmove
        https://bugs.webkit.org/show_bug.cgi?id=157551
        <rdar://problem/26179914>

        Reviewed by Michael Saboff.

        The TypedArray.prototype.slice function would use the byteLength of the passed array
        to determine the amount of data to copy. It should have been using the passed length
        times the size of each element. This fixes a crash on JavaPoly.com

        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::set):
        * tests/stress/typedarray-slice.js:

2016-05-10  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r200447): Unable to build C_LOOP with clang version 800.0.12 or higher
        https://bugs.webkit.org/show_bug.cgi?id=157549

        Reviewed by Keith Miller.

        Disable debug annotations for C_LOOP builds.  They are inline assembly directives,
        unnecessary and they cause syntax errors.

        * offlineasm/asm.rb:

2016-05-10  Filip Pizlo  <fpizlo@apple.com>

        Internal JSC profiler should have a timestamped log of events for each code block
        https://bugs.webkit.org/show_bug.cgi?id=157538

        Reviewed by Benjamin Poulain.
        
        For example, in 3d-cube, I can query the events for MMulti and I get:

        1462917476.17083  MMulti#DTZ7qc                          installCode        
        1462917476.179663 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode        
        1462917476.179664 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline osrEntry           at bc#49
        1462917476.185651 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1011.214233/1717.000000, -707
        1462917476.187913 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG      installCode        
        1462917476.187917 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG      osrEntry           at bc#49
        1462917476.205365 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG      jettison           due to OSRExit, counting = true, detail = (null)
        1462917476.205368 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit       bc#65: BadCache/FromDFG
        1462917476.205369 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode        
        1462917476.205482 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1013.000000/3434.000000, -1000
        1462917476.211547 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 2013.000000/3434.000000, -1000
        1462917476.213721 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG      installCode        
        1462917476.213726 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG      osrEntry           at bc#49
        1462917476.223976 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG      jettison           due to OSRExit, counting = true, detail = (null)
        1462917476.223981 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit       bc#77: BadCache/FromDFG
        1462917476.223982 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit       bc#94: BadCache/FromDFG
        1462917476.223982 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode        
        1462917476.224064 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1013.000000/6868.000000, -1000
        1462917476.224151 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 2013.000000/6868.000000, -1000
        1462917476.224258 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 3013.000000/6868.000000, -1000
        1462917476.224337 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 4023.000000/6868.000000, -1000
        1462917476.224425 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 5023.000000/6868.000000, -1000
        1462917476.224785 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 6023.396484/6868.000000, -862
        1462917476.227669 MMulti#DTZ7qc MMulti#DTZ7qc-4-DFG      installCode        
        1462917476.227675 MMulti#DTZ7qc MMulti#DTZ7qc-4-DFG      osrEntry           at bc#0
        
        The output is ugly but useful. We can make it less ugly later.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::jettison):
        * bytecode/CodeBlock.h:
        (JSC::ScriptExecutable::forEachCodeBlock):
        * bytecode/DFGExitProfile.cpp:
        (JSC::DFG::ExitProfile::add):
        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::finalizeCommon):
        * dfg/DFGOperations.cpp:
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        (JSC::LLInt::entryOSR):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * profiler/ProfilerCompilation.cpp:
        (JSC::Profiler::Compilation::Compilation):
        (JSC::Profiler::Compilation::setJettisonReason):
        (JSC::Profiler::Compilation::dump):
        (JSC::Profiler::Compilation::toJS):
        * profiler/ProfilerCompilation.h:
        (JSC::Profiler::Compilation::uid):
        * profiler/ProfilerDatabase.cpp:
        (JSC::Profiler::Database::ensureBytecodesFor):
        (JSC::Profiler::Database::notifyDestruction):
        (JSC::Profiler::Database::addCompilation):
        (JSC::Profiler::Database::toJS):
        (JSC::Profiler::Database::registerToSaveAtExit):
        (JSC::Profiler::Database::logEvent):
        (JSC::Profiler::Database::addDatabaseToAtExit):
        * profiler/ProfilerDatabase.h:
        * profiler/ProfilerEvent.cpp: Added.
        (JSC::Profiler::Event::dump):
        (JSC::Profiler::Event::toJS):
        * profiler/ProfilerEvent.h: Added.
        (JSC::Profiler::Event::Event):
        (JSC::Profiler::Event::operator bool):
        (JSC::Profiler::Event::time):
        (JSC::Profiler::Event::bytecodes):
        (JSC::Profiler::Event::compilation):
        (JSC::Profiler::Event::summary):
        (JSC::Profiler::Event::detail):
        * profiler/ProfilerUID.cpp: Added.
        (JSC::Profiler::UID::create):
        (JSC::Profiler::UID::dump):
        (JSC::Profiler::UID::toJS):
        * profiler/ProfilerUID.h: Added.
        (JSC::Profiler::UID::UID):
        (JSC::Profiler::UID::fromInt):
        (JSC::Profiler::UID::toInt):
        (JSC::Profiler::UID::operator==):
        (JSC::Profiler::UID::operator!=):
        (JSC::Profiler::UID::operator bool):
        (JSC::Profiler::UID::isHashTableDeletedValue):
        (JSC::Profiler::UID::hash):
        (JSC::Profiler::UIDHash::hash):
        (JSC::Profiler::UIDHash::equal):
        * runtime/CommonIdentifiers.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::installCode):
        * runtime/VM.h:
        (JSC::VM::bytecodeIntrinsicRegistry):
        (JSC::VM::shadowChicken):
        * runtime/VMInlines.h:
        (JSC::VM::shouldTriggerTermination):
        (JSC::VM::logEvent):

2016-05-10  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Backend should initiate timeline recordings on page navigations to ensure nothing is missed
        https://bugs.webkit.org/show_bug.cgi?id=157504
        <rdar://problem/26188642>

        Reviewed by Brian Burg.

        * inspector/protocol/Timeline.json:
        Add protocol commands to enable/disable auto capture and list the
        instruments that should be enabled when auto capture starts.
        Add protocol event for when the backend starts an auto capture.

2016-05-10  Joseph Pecoraro  <pecoraro@apple.com>

        Make the different evaluateWithScopeExtension implementations more consistent
        https://bugs.webkit.org/show_bug.cgi?id=157536

        Reviewed by Timothy Hatcher.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
        Throw the exception consistent with JSJavaScriptCallFrame.

        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
        Better error message consistent with InjectedScriptHost.

        * runtime/Completion.h:
        * runtime/Completion.cpp:
        (JSC::evaluateWithScopeExtension):
        Give this an Exception out parameter like other evaluations
        so the caller can decide what to do with it.

2016-05-10  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] FTL can produce GetByVal nodes without proper bounds checking
        https://bugs.webkit.org/show_bug.cgi?id=157502
        rdar://problem/26027027

        Reviewed by Filip Pizlo.

        It was possible for FTL to generates GetByVal on arbitrary offsets
        without any bounds checking.

        The bug is caused by the order of optimization phases:
        -First, the Integer Range Optimization proves that a CheckInBounds
         test can never fail.
         This proof is based on control flow or preceeding instructions
         inside a loop.
        -The Loop Invariant Code Motion phase finds that the GetByVal does not
         depend on anything in the loop and hoist it out of the loop.
        -> As a result, the conditions that were necessary to eliminate
           the CheckInBounds are no longer met before the GetByVal.

        This patch just moves the Integer Range Optimization phase after
        Loop Invariant Code Motion to make sure no code is moved after
        its integer ranges bounds proofs have been used.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * tests/stress/bounds-check-not-eliminated-by-licm.js: Added.
        (testInLoopTests):

2016-05-10  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Eliminate the crazy code for evaluateOnCallFrame
        https://bugs.webkit.org/show_bug.cgi?id=157510
        <rdar://problem/26191332>

        Reviewed by Timothy Hatcher.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
        Set and clear an optional scope extension object.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype.evaluate):
        (InjectedScript.prototype._evaluateOn):
        (InjectedScript.prototype.evaluateOnCallFrame):
        Unify the code to use the passed in evaluate function and object.
        When evaluating on a call frame the evaluate function ends up being
        DebuggerCallFrame::evaluateWithScopeExtension. When evaluating globally
        this ends up being JSInjectedScriptHost::evaluateWithScopeExtension.
        In both cases "object" is the preferred this object to use.

        * debugger/DebuggerCallFrame.h:
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
        (Inspector::JSJavaScriptCallFrame::evaluate): Deleted.
        * inspector/JSJavaScriptCallFrame.h:
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluateWithScopeExtension):
        * inspector/JavaScriptCallFrame.h:
        (Inspector::JavaScriptCallFrame::evaluateWithScopeExtension):
        (Inspector::JavaScriptCallFrame::evaluate): Deleted.
        Pass through to DebuggerCallFrame with the proper arguments.

        * debugger/Debugger.cpp:
        (JSC::Debugger::hasBreakpoint):
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::evaluateBreakpointAction):
        Use the new evaluate on call frame method name and no scope extension object.

2016-05-10  Saam barati  <sbarati@apple.com>

        Make super-property-access.js test run for less time because it was timing out in debug builds.

        Rubber stamped by Filip Pizlo.

        * tests/stress/super-property-access.js:
        (test):
        (test.value):
        (test.foo):
        (test.B.prototype.bar):
        (test.B):

2016-05-10  Csaba Osztrogonác  <ossy@webkit.org>

        [JSC] Fix the !ENABLE(DFG_JIT) build
        https://bugs.webkit.org/show_bug.cgi?id=157512

        Reviewed by Mark Lam.

        * jit/Repatch.cpp:

2016-05-09  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: CRASH under JSC::DebuggerCallFrame::thisValue when hitting breakpoint
        https://bugs.webkit.org/show_bug.cgi?id=157442
        <rdar://problem/24172015>

        Reviewed by Saam Barati.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::thisValueForCallFrame):
        When the thisValue is JSValue() return undefined and avoid calling
        toThisValue which would lead to a crash. Having `this` be an empty
        JSValue could happen inside an ES6 class constructor, before
        calling super.

2016-05-09  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix cloop.

        * bytecode/ValueProfile.cpp:
        (JSC::ResultProfile::emitDetectNumericness):
        (JSC::ResultProfile::emitSetNonNumber):
        * bytecode/ValueProfile.h:
        (JSC::ResultProfile::addressOfFlags):
        (JSC::ResultProfile::addressOfSpecialFastPathCount):
        (JSC::ResultProfile::detectNumericness):
        (JSC::ResultProfile::hasBits):

2016-05-09  Michael Saboff  <msaboff@apple.com>

        Crash beneath ObjCCallbackFunctionImpl::call
        https://bugs.webkit.org/show_bug.cgi?id=157491

        Reviewed by Saam Barati.

        Clear any exceptions after the micro task runs.

        Tried creating a test case, but I don't have source for the app.
        I can't seem to find the right combination of Promises and ObjC code.

        * runtime/JSJob.cpp:
        (JSC::JSJobMicrotask::run):

2016-05-09  Filip Pizlo  <fpizlo@apple.com>

        Polymorphic operands in operators coerces downstream values to double.
        https://bugs.webkit.org/show_bug.cgi?id=151793

        Reviewed by Mark Lam.
        
        Previously if an object flowed into arithmetic, the prediction propagation phase would either
        assume that the output of the arithmetic had to be double or sometimes it would assume that it
        couldn't be double. We want it to only assume that the output is double if it actually had been.
        
        The first part of this patch is to roll out http://trac.webkit.org/changeset/200502. That removed
        some of the machinery that we had in place to detect whether the output of an operation is int or
        double. That changeset claimed that the machinery was "fundamentally broken". It actually wasn't.
        The reason why it didn't work was that ByteCodeParser was ignoring it if likelyToTakeSlowCase was
        false. I think this was a complete goof-up: the code in ByteCodeParser::makeSafe was structured
        in a way that made it non-obvious that the method is a no-op if !likelyToTakeSlowCase. So, this
        change rolls out r200502 and makes ResultProfile do its job by reshaping how makeSafe processes
        it.
        
        This also makes two other changes to shore up ResultProfile:
        - OSR exit can now refine a ResultProfile the same way that it refines ValueProfile.
        - Baseline JIT slow paths now set bits in ResultProfile.
        
        Based on this stuff, the DFG now predicts int/double/string in op_add/op_sub/op_mul based on
        ResultProfiles. To be conservative, we still only use the ResultProfiles if the incoming
        prediction is not number-or-boolean. This ensures that we exactly retain our old behavior in
        those cases for which it was tuned. But I hope to remove this soon. I believe that ResultProfile
        is already strictly better than what prediction propagation was doing before.
        
        This can be an enormous win. This patch adds some simple microbenchmarks that demonstrate the
        problem of assuming that arithmetic on objects returns double. The most extreme of these speeds
        up 8x with this change (object-int-add-array).
        
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::addFrequentExitSite):
        (JSC::CodeBlock::hasExitSite):
        * bytecode/DFGExitProfile.cpp:
        (JSC::DFG::FrequentExitSite::dump):
        (JSC::DFG::ExitProfile::ExitProfile):
        (JSC::DFG::ExitProfile::~ExitProfile):
        (JSC::DFG::ExitProfile::add):
        * bytecode/DFGExitProfile.h:
        (JSC::DFG::FrequentExitSite::isHashTableDeletedValue):
        * bytecode/MethodOfGettingAValueProfile.cpp:
        (JSC::MethodOfGettingAValueProfile::fromLazyOperand):
        (JSC::MethodOfGettingAValueProfile::emitReportValue):
        (JSC::MethodOfGettingAValueProfile::getSpecFailBucket): Deleted.
        * bytecode/MethodOfGettingAValueProfile.h:
        (JSC::MethodOfGettingAValueProfile::MethodOfGettingAValueProfile):
        (JSC::MethodOfGettingAValueProfile::operator bool):
        (JSC::MethodOfGettingAValueProfile::operator!): Deleted.
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):
        * bytecode/ValueProfile.cpp:
        (JSC::ResultProfile::emitDetectBitsLight):
        (JSC::ResultProfile::emitSetDouble):
        (JSC::ResultProfile::emitSetNonNumber):
        (WTF::printInternal):
        * bytecode/ValueProfile.h:
        (JSC::ResultProfile::ResultProfile):
        (JSC::ResultProfile::bytecodeOffset):
        (JSC::ResultProfile::specialFastPathCount):
        (JSC::ResultProfile::didObserveNonInt32):
        (JSC::ResultProfile::didObserveDouble):
        (JSC::ResultProfile::didObserveNonNegZeroDouble):
        (JSC::ResultProfile::didObserveNegZeroDouble):
        (JSC::ResultProfile::didObserveNonNumber):
        (JSC::ResultProfile::didObserveInt32Overflow):
        (JSC::ResultProfile::didObserveInt52Overflow):
        (JSC::ResultProfile::setObservedNonNegZeroDouble):
        (JSC::ResultProfile::setObservedNegZeroDouble):
        (JSC::ResultProfile::setObservedNonNumber):
        (JSC::ResultProfile::setObservedInt32Overflow):
        (JSC::ResultProfile::addressOfFlags):
        (JSC::ResultProfile::addressOfSpecialFastPathCount):
        (JSC::ResultProfile::detectBitsLight):
        (JSC::ResultProfile::hasBits):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::makeSafe):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::ensureNaturalLoops):
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        (JSC::DFG::Graph::valueProfileFor): Deleted.
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::hasExitSite):
        (JSC::DFG::Graph::numBlocks):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::arithNodeFlags):
        (JSC::DFG::Node::mayHaveNonIntResult):
        (JSC::DFG::Node::mayHaveDoubleResult):
        (JSC::DFG::Node::mayHaveNonNumberResult):
        (JSC::DFG::Node::hasConstantBuffer):
        * dfg/DFGNodeFlags.cpp:
        (JSC::DFG::dumpNodeFlags):
        * dfg/DFGNodeFlags.h:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfEqual):
        (JSC::AssemblyHelpers::branchIfNotCell):
        (JSC::AssemblyHelpers::branchIfNotNumber):
        (JSC::AssemblyHelpers::branchIfNotDoubleKnownNotInt32):
        (JSC::AssemblyHelpers::branchIfBoolean):
        (JSC::AssemblyHelpers::branchIfEmpty):
        (JSC::AssemblyHelpers::branchStructure):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::CCallHelpers):
        (JSC::CCallHelpers::setupArguments):
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jit/IntrinsicEmitter.cpp:
        (JSC::AccessCase::emitIntrinsicGetter):
        * jit/JIT.h:
        * jit/JITAddGenerator.cpp:
        (JSC::JITAddGenerator::generateFastPath):
        * jit/JITAddGenerator.h:
        (JSC::JITAddGenerator::JITAddGenerator):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitSlow_op_add):
        (JSC::JIT::emit_op_div):
        (JSC::JIT::emit_op_mul):
        (JSC::JIT::emitSlow_op_mul):
        (JSC::JIT::emit_op_sub):
        (JSC::JIT::emitSlow_op_sub):
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        (JSC::JIT::callOperationNoExceptionCheck):
        * jit/JITMulGenerator.cpp:
        (JSC::JITMulGenerator::generateFastPath):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITSubGenerator.cpp:
        (JSC::JITSubGenerator::generateFastPath):
        * jit/JITSubGenerator.h:
        (JSC::JITSubGenerator::JITSubGenerator):
        * jit/TagRegistersMode.cpp: Added.
        (WTF::printInternal):
        * jit/TagRegistersMode.h: Added.
        * runtime/CommonSlowPaths.cpp:
        (JSC::updateResultProfileForBinaryArithOp):

2016-05-09  Keith Miller  <keith_miller@apple.com>

        CallObjectConstructor should not call operationToThis in the FTL
        https://bugs.webkit.org/show_bug.cgi?id=157492
        <rdar://problem/26149904>

        Reviewed by Mark Lam.

        At some point when I was working on intrinsifying the Object
        constructor, I realized that the Object constructor was different
        from the ToObject operation. I fixed the DFG but I guess I didn't
        fix the FTL.

        This patch fixes an issue with www.wunderground.com not loading
        the 10-day forecast and local map.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
        * tests/stress/call-object-constructor.js: Added.
        (test):
        (assert):

2016-05-09  Saam barati  <sbarati@apple.com>

        Getter and setter on super are called with wrong "this" object
        https://bugs.webkit.org/show_bug.cgi?id=147064
        <rdar://problem/21885916>

        Reviewed by Filip Pizlo.

        This patch implements calls to 'super' getters and setters.
        The problem before is we were passing the 'super' (i.e, the prototype
        object) as the this value to these getters/setters, which is wrong. 
        We should be passing the caller's this value.

        To implement this behavior, I've introduced four new opcodes and their corresponding DFG nodes:
        - op_get_by_id_with_this | GetByIdWithThis
        - op_put_by_id_with_this | PutByIdWithThis
        - op_get_by_val_with_this | GetByValWithThis
        - op_put_by_val_with_this | PutByValWithThis

        These are implemented with no optimizations. The future plan is 
        to unite them with the *by_id and *by_val opcodes and nodes:
        https://bugs.webkit.org/show_bug.cgi?id=157215

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitGetById):
        (JSC::BytecodeGenerator::emitPutById):
        (JSC::BytecodeGenerator::emitDirectPutById):
        (JSC::BytecodeGenerator::emitGetByVal):
        (JSC::BytecodeGenerator::emitPutByVal):
        (JSC::BytecodeGenerator::emitDirectPutByVal):
        (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::ensureThis):
        (JSC::BytecodeGenerator::isThisUsedInInnerArrowFunction):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode):
        (JSC::emitHomeObjectForCallee):
        (JSC::emitSuperBaseForCallee):
        (JSC::emitGetSuperFunctionForConstruct):
        (JSC::SuperNode::emitBytecode):
        (JSC::NewTargetNode::emitBytecode):
        (JSC::TaggedTemplateNode::emitBytecode):
        (JSC::BracketAccessorNode::emitBytecode):
        (JSC::DotAccessorNode::emitBytecode):
        (JSC::FunctionCallValueNode::emitBytecode):
        (JSC::FunctionCallBracketNode::emitBytecode):
        (JSC::FunctionCallDotNode::emitBytecode):
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::PostfixNode::emitBracket):
        (JSC::PostfixNode::emitDot):
        (JSC::PrefixNode::emitBracket):
        (JSC::PrefixNode::emitDot):
        (JSC::AssignDotNode::emitBytecode):
        (JSC::ReadModifyDotNode::emitBytecode):
        (JSC::AssignBracketNode::emitBytecode):
        (JSC::ReadModifyBracketNode::emitBytecode):
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForOfNode::emitBytecode):
        (JSC::AssignmentElementNode::bindValue):
        * 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/DFGNode.h:
        (JSC::DFG::Node::hasIdentifier):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        (JSC::DFG::newTypedArrayWithSize):
        (JSC::DFG::putWithThis):
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.h:
        (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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByValWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByIdWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByValWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutById):
        * jit/CCallHelpers.cpp:
        (JSC::CCallHelpers::setupShadowChickenPacket):
        (JSC::CCallHelpers::setupFourStubArgsGPR):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        (JSC::CCallHelpers::setupThreeStubArgsGPR):
        (JSC::CCallHelpers::setupTwoStubArgsFPR):
        (JSC::CCallHelpers::setupStubArguments134):
        * jit/GPRInfo.h:
        (JSC::argumentRegisterFor): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emit_op_put_by_val_with_this):
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emit_op_get_by_id):
        (JSC::JIT::emit_op_get_by_id_with_this):
        (JSC::JIT::emit_op_get_by_val_with_this):
        (JSC::JIT::emitSlow_op_get_by_id):
        (JSC::JIT::emit_op_put_by_id):
        (JSC::JIT::emit_op_put_by_id_with_this):
        (JSC::JIT::emitSlow_op_put_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_to_arguments):
        (JSC::JIT::emit_op_get_by_id_with_this):
        (JSC::JIT::emit_op_get_by_val_with_this):
        (JSC::JIT::emit_op_put_by_id_with_this):
        (JSC::JIT::emit_op_put_by_val_with_this):
        * llint/LowLevelInterpreter.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * tests/stress/super-property-access-exceptions.js: Added.
        (assert):
        (test):
        (test.fooProp):
        (test.A.prototype.get foo):
        (test.A.prototype.get x):
        (test.A):
        (test.B):
        (test.B.prototype.bar):
        (test.B.prototype.baz):
        (test.foo):
        (test.func):
        (test.A.prototype.set foo):
        * tests/stress/super-property-access-tdz.js: Added.
        (assert):
        (test):
        (shouldThrowTDZ):
        (test.A.prototype.get foo):
        (test.A.prototype.set foo):
        (test.A):
        (test.fooProp):
        (test.B):
        (test.C):
        (test.D):
        (test.E):
        (test.F):
        * tests/stress/super-property-access.js: Added.
        (assert):
        (test):
        (func):
        (test.A):
        (test.A.prototype.set value):
        (test.A.prototype.get value):
        (test.B.prototype.set value):
        (test.B.prototype.get value):
        (test.B):
        (test.value):
        (test.A.prototype.get func):
        (test.B.prototype.inc):
        (test.B.prototype.dec):
        (test.B.prototype.preInc):
        (test.B.prototype.preDec):
        (test.B.prototype.plusEq):
        (test.B.prototype.minusEq):
        (test.B.prototype.timesEq):
        (test.B.prototype.divEq):
        (test.B.prototype.funcDot):
        (test.B.prototype.funcBracket):
        (test.foo):
        (test.B.prototype.baz):
        (test.B.prototype.jaz):
        (test.B.prototype.bar):
        (test.B.prototype.index):
        (test.):
        (test.prototype.bar):
        (test.A.prototype.set foo):
        (test.A.prototype.get array):
        (test.A.prototype.get foo):
        (test.obj):
        (test.A.prototype.get call):
        (test.A.prototype.get apply):
        (test.B.prototype.foo):
        (test.A.prototype.get i):

2016-05-08  Chris Dumez  <cdumez@apple.com>

        [COCOA] Disable HAVE_DTRACE at build time
        https://bugs.webkit.org/show_bug.cgi?id=157433
        <rdar://problem/26148841>

        Reviewed by Mark Lam.

        Drop DTRACE-related code from JSC since it is very old and seems
        unused.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * PlatformMac.cmake:
        * heap/Heap.cpp:
        (JSC::Heap::collectImpl): Deleted.
        (JSC::Heap::didFinishCollection): Deleted.
        * profiler/ProfileGenerator.cpp:
        (JSC::ProfileGenerator::willExecute): Deleted.
        (JSC::ProfileGenerator::didExecute): Deleted.
        * runtime/Tracing.d: Removed.
        * runtime/Tracing.h: Removed.

2016-05-07  Mark Lam  <mark.lam@apple.com>

        Add JSC options bytecodeRangeToJITCompile and jitWhitelist.
        https://bugs.webkit.org/show_bug.cgi?id=157428

        Reviewed by Michael Saboff.

        1. Added Options::bytecodeRangeToJITCompile and Options::jitWhitelist options.

        2. Moved DFGFunctionWhitelist* to FunctionWhitelist* and made it generic so that
           it can be used for more than one whitelist instance.  In this case, we now have
           two: the dfgWhitelist and the jitWhitelist.

        3. Added "can compile" checks in LLInt::shouldJIT() to check
           Options::bytecodeRangeToJITCompile and Options::jitWhitelist.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGDriver.cpp:
        (JSC::DFG::getNumCompilations):
        (JSC::DFG::ensureGlobalDFGWhitelist):
        (JSC::DFG::compileImpl):
        * dfg/DFGFunctionWhitelist.cpp: Removed.
        * dfg/DFGFunctionWhitelist.h: Removed.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::ensureGlobalJITWhitelist):
        (JSC::LLInt::shouldJIT):

        * runtime/Options.h:

        * tools/FunctionWhitelist.cpp: Copied from Source/JavaScriptCore/dfg/DFGFunctionWhitelist.cpp.
        (JSC::FunctionWhitelist::FunctionWhitelist):
        (JSC::FunctionWhitelist::contains):
        (JSC::DFG::FunctionWhitelist::ensureGlobalWhitelist): Deleted.
        (JSC::DFG::FunctionWhitelist::FunctionWhitelist): Deleted.
        (JSC::DFG::FunctionWhitelist::parseFunctionNamesInFile): Deleted.
        (JSC::DFG::FunctionWhitelist::contains): Deleted.
        * tools/FunctionWhitelist.h: Copied from Source/JavaScriptCore/dfg/DFGFunctionWhitelist.h.

2016-05-07  Benjamin Poulain  <bpoulain@apple.com>

        [JSC][32bit] stress/tagged-templates-template-object.js fails in debug
        https://bugs.webkit.org/show_bug.cgi?id=157436

        Reviewed by Filip Pizlo.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        The node OverridesHasInstance had a speculation after a jump.

2016-05-06  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Misc CommandLineAPI cleanup
        https://bugs.webkit.org/show_bug.cgi?id=157450

        Reviewed by Ryosuke Niwa.

        * inspector/InjectedScriptSource.js:
        (BasicCommandLineAPI):
        Fix mistake in r200533, and modernize related code.

2016-05-06  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Improve console.count()
        https://bugs.webkit.org/show_bug.cgi?id=157439
        <rdar://problem/26152654>

        Reviewed by Timothy Hatcher.

          - make console.count() increment an unnamed global counter.
          - make console.count(label) increment a counter with that label name.

        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::count):

2016-05-06  Simon Fraser  <simon.fraser@apple.com>

        Enable IOS_TEXT_AUTOSIZING on Mac and make it testable
        https://bugs.webkit.org/show_bug.cgi?id=157432
        rdar://problem/16406720

        Reviewed by Dean Jackson.

        Enable IOS_TEXT_AUTOSIZING on Mac so it can be tested.

        * Configurations/FeatureDefines.xcconfig:

2016-05-06  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Console: Variables defined with let/const aren't accessible outside of console's scope
        https://bugs.webkit.org/show_bug.cgi?id=150752
        <rdar://problem/23343385>

        Reviewed by Mark Lam.

        This approach allows Web Inspector to hang a "Scope Extension", a
        WithObjectScope, off the GlobalObject. When resolving identifiers
        in fails to resolve anything in the normal scope chain, consult
        the scope extension.

        This allows us to eliminate the `with (commandLineAPI) { ... }`
        block in global console evaluations, and instead makes it a full
        program evaluation, with the commandLineAPI available and safely
        shadowed by actual variables as expected.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype._evaluateOn):
        Use the new evaluateWithScopeExtension and provide the CommandLineAPI
        object as the scope extension object.

        (BasicCommandLineAPI):
        (BasicCommandLineAPI.inScopeVariables): Deleted.
        Simplify now that we don't need to check for variable shadowing ourselves.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
        * inspector/JSInjectedScriptHost.h:
        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        (Inspector::jsInjectedScriptHostPrototypeFunctionEvaluateWithScopeExtension):
        Provide a new InjectedScriptHost method to evaluate a program
        with a scope extension.

        * runtime/Completion.cpp:
        (JSC::evaluateWithScopeExtension):
        * runtime/Completion.h:
        General JSC::evaluate function to evaluate a program with a scope extension.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::setGlobalScopeExtension):
        (JSC::JSGlobalObject::clearGlobalScopeExtension):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::globalScopeExtension):
        Hang a scope extension off the global object.

        * runtime/JSScope.cpp:
        (JSC::JSScope::resolve):
        Consult the scope extension when resolve fails to find anything normally.

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

        Add JSC options reportBaselineCompileTimes and reportDFGCompileTimes.
        https://bugs.webkit.org/show_bug.cgi?id=157427

        Reviewed by Filip Pizlo and Keith Miller.

        The compile times reporting options are now:
            reportCompileTimes         -> report compile times in all tiers.
            reportBaselineCompileTimes -> report compile times in baseline JIT.
            reportDFGCompileTimes      -> report compile times in DFG and FTL.
            reportFTLCompileTimes      -> report compile times in FTL.

        Also updated reportTotalCompileTimes() to collect stats that include the baseline
        JIT.  compileTimeStats() is now moved into JIT.cpp (from DFGPlan.cpp). 

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::reportCompileTimes):
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::compileInThreadImpl):
        (JSC::DFG::Plan::cancel):
        (JSC::DFG::Plan::compileTimeStats): Deleted.
        * dfg/DFGPlan.h:
        (JSC::DFG::Plan::compileTimeStats): Deleted.
        * jit/JIT.cpp:
        (JSC::ctiPatchCallByReturnAddress):
        (JSC::JIT::privateCompile):
        (JSC::JIT::stackPointerOffsetFor):
        (JSC::JIT::reportCompileTimes):
        (JSC::JIT::computeCompileTimes):
        (JSC::JIT::compileTimeStats):
        * jit/JIT.h:
        (JSC::JIT::shouldEmitProfiling):
        * jsc.cpp:
        (runJSC):
        * runtime/Options.h:

2016-05-05  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Get rid of NonNegZeroDouble, it is broken
        https://bugs.webkit.org/show_bug.cgi?id=157399
        rdar://problem/25339647

        Reviewed by Mark Lam.

        The profile "NonNegZeroDouble" is fundamentally broken.

        It is used by DFG to predict the result of ArithMul as being a Double
        or Int32.
        The problem is you are likely to mispredict, and when you do, you are
        guaranteed to end up in a recompile loop.

        The compile loops usually happen like this:
        -We speculate you have Int32 despite producing doubles.
        -We OSR exit on another node (ValueToInt32 for example) from the result of this ArithMul.
        -When we compile this block again, ArithMul will do the same misprediction
         because it unconditionally predicts Int32.

        The flag NonNegZeroDouble was very unlikely to be set correctly
        in the first place.

        In LLINT, the flag is only set on the slow path.
        Since double*double is on the fast path, those cases are ignored.

        In Baseline, the flag is set for any case that falls back on double
        multiplication. BUT, the DFG flag was only set for nodes that spend
        many iteration in slow path, which obviously does not apply to double*double.

        Given the perf drawbacks and the recompile loops, I removed
        the whole flag for now.

        * bytecode/ValueProfile.cpp:
        (WTF::printInternal):
        * bytecode/ValueProfile.h:
        (JSC::ResultProfile::didObserveNonInt32): Deleted.
        (JSC::ResultProfile::didObserveDouble): Deleted.
        (JSC::ResultProfile::didObserveNonNegZeroDouble): Deleted.
        (JSC::ResultProfile::setObservedNonNegZeroDouble): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::makeSafe): Deleted.
        * dfg/DFGNode.h:
        (JSC::DFG::Node::mayHaveNonIntResult): Deleted.
        * dfg/DFGNodeFlags.cpp:
        (JSC::DFG::dumpNodeFlags): Deleted.
        * dfg/DFGNodeFlags.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * jit/JITMulGenerator.cpp:
        (JSC::JITMulGenerator::generateFastPath): Deleted.
        * runtime/CommonSlowPaths.cpp:
        (JSC::updateResultProfileForBinaryArithOp): Deleted.

2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION(r200422): Web Inspector: Make new Array Iterator objects play nice with Web Inspector
        https://bugs.webkit.org/show_bug.cgi?id=157361
        <rdar://problem/26099793>

        Reviewed by Timothy Hatcher.

        * builtins/ArrayPrototype.js:
        (createArrayIterator):
        (values):
        (keys):
        (entries):
        * builtins/TypedArrayPrototype.js:
        (values):
        (keys):
        (entries):
        * runtime/CommonIdentifiers.h:
        Set the kind on the iterator object, that can be shown
        to the inspector if the object is shown in the console.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype._describe):
        Get a better name for the new Array Iterator which is just an Object.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        Detect and handle ArrayIterator object instances. Porting the code
        from the JSArrayIterator code path.

2016-05-05  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] In DFG, an OSR Exit on SetLocal can trash its child node
        https://bugs.webkit.org/show_bug.cgi?id=157358
        rdar://problem/25339647

        Reviewed by Filip Pizlo.

        When we OSR Exit on SetLocal, the child is never restored if its representation
        was changed since the MovHint.

        For example, say we have:
            @1 = SomethingProducingDouble()
            @2 = MovHint(@1)
            @3 = ValueRep(@1)
            @4 = SetLocal(@3, FlushedInt32)

        When we lower SetLocal(), we start by speculating that @3 is an Int32.
        Now this can fail if @1 was really a double.
        When that happens, we go over the VariableEventStream to find where values
        are, and @1 died at @3. Since the speculation failure happens before
        the SetLocal event, we don't do anything with @3.

        In this patch, I extend the PhantomInsertion phase to keep the MovHint
        alive past the SetLocal.

        * dfg/DFGPhantomInsertionPhase.cpp:
        * tests/stress/multiply-typed-double-and-object.js: Added.
        (otherObject.valueOf):
        (targetDFG.multiply):
        (targetFTL.multiply):

2016-05-05  Oliver Hunt  <oliver@apple.com>

        Enable separated heap by default on ios
        https://bugs.webkit.org/show_bug.cgi?id=156720

        Reviewed by Geoffrey Garen.

        We've fixed the xnu side of things, so we can reland this.

        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>

        JSContext Inspector: Better CommandLineAPI in JSContext inspection
        https://bugs.webkit.org/show_bug.cgi?id=157387
        <rdar://problem/22630583>

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype._evaluateOn):
        (BasicCommandLineAPI.inScopeVariables):
        (BasicCommandLineAPI):
        When creating a BasicCommandLineAPI, pass the call frame so
        that we don't shadow variables in the callstack.

        (BasicCommandLineAPI.methods):
        (clear):
        (table):
        (profile):
        (profileEnd):
        (keys):
        (values):
        Some just pass through to console, others are tiny methods.
        Implement them, and give them the expected toString string.

2016-05-05  Filip Pizlo  <fpizlo@apple.com>

        Reduce maximum JIT pool size on X86_64.

        Rubber stamped by Geoffrey Garen.
        
        This changes our maximum pool size to 100MB. The problem with letting a page allocate much
        more than this is that we will sometimes call deleteAllCode() or one of its friends. Deleting
        a huge amount of memory is expensive in our allocator.
        
        So long as we allow for such large-scale code death to happen, and so long as it's expensive,
        we should bound the amount of code we end up with in the first place.
        
        In the long run, we should fix our executable allocator so that it's not so expensive to kill
        all code.
        
        * jit/ExecutableAllocator.h:

2016-05-05  Filip Pizlo  <fpizlo@apple.com>

        Reduce thresholds that control the maximum IC stub size.

        Rubber stamped by Chris Dumez and Benjamin Poulain.
        
        This reduces the thresholds to before the megamorphic load optimizations to see if that
        recovers a PLT regression.

        * runtime/Options.h:

2016-05-05  Filip Pizlo  <fpizlo@apple.com>

        We shouldn't crash if DFG AI proved that something was unreachable on one run but then decided not to prove it on another run
        https://bugs.webkit.org/show_bug.cgi?id=157379

        Reviewed by Mark Lam.
        
        Any run of DFG AI is a fixpoint that loosens the proof until it can't find any more
        counterexamples to the proof.  It errs on the side of loosening proofs, i.e., on the side of
        proving fewer things.

        We run this fixpoint multiple times since there are multiple points in the DFG optimization
        pipeline when we run DFG AI.  Each of those runs completes a fixpoint and produces the
        tightest proof it can that did not result in counterexamples being found.

        It's possible that on run K of DFG AI, we prove some property, but on run K+1, we don't prove
        that property. The code could have changed between the two runs due to other phases. Other
        phases may modify the code in such a way that it's less amenable to AI's analysis. Our design
        allows this because DFG AI is not 100% precise. It defends itself from making unsound choices
        or running forever by sometimes punting on proving some property. It must be able to do this,
        and so therefore, it might sometimes prove fewer things on a later run.

        Currently in trunk if the property that AI proves on run K but fails to prove on run K+1 is
        the reachability of a piece of code, then run K+1 will crash on an assertion at the
        Unreachable node. It will complain that it reached an Unreachable. But it might be reaching
        that Unreachable because it failed to prove that something earlier was always exiting. That's
        OK, see above.

        So, we should remove the assertion that AI doesn't see Unreachable.
        
        No new tests because I don't know how to make this happen. I believe that this happens in the
        wild based on crash logs.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>

        Crash if you type "debugger" in the console and continue
        https://bugs.webkit.org/show_bug.cgi?id=156924
        <rdar://problem/25884189>

        Reviewed by Mark Lam.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
        Bail with an error when we are not paused.

        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::callFunctionOn):
        (Inspector::InspectorRuntimeAgent::getProperties):
        (Inspector::InspectorRuntimeAgent::getDisplayableProperties):
        (Inspector::InspectorRuntimeAgent::getCollectionEntries):
        (Inspector::InspectorRuntimeAgent::saveResult):
        Update poor error message.

2016-05-05  Keith Miller  <keith_miller@apple.com>

        Add support for delete by value to the DFG
        https://bugs.webkit.org/show_bug.cgi?id=157372

        Reviewed by Filip Pizlo.

        This patch adds basic support for delete by value to the DFG. delete by value
        just calls out to a C++ operation on each execution. Additionally, this patch
        fixes an issue with delete by id where we would crash if the base was null
        or undefined.

        * 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:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileDeleteById):
        (JSC::DFG::SpeculativeJIT::compileDeleteByVal):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_del_by_val):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_del_by_val):
        * tests/stress/delete-by-val.js: Added.
        (assert):
        (test):
        * tests/stress/delete-to-object-exception.js: Added.
        (assert):
        (test):

2016-05-05  Michael Saboff  <msaboff@apple.com>

        Unreviewed build fix after change set r200447.

        Made the detection of clang version XCode build specific.
        Now shouldEnableDebugAnnotations() should return false for all other build types.

        * offlineasm/config.rb:

2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>

        Create console object lazily
        https://bugs.webkit.org/show_bug.cgi?id=157328

        Reviewed by Geoffrey Garen.

        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::createConsoleProperty):
        (JSC::JSGlobalObject::init): Deleted.

2016-05-04  Michael Saboff  <msaboff@apple.com>

        Enable Dwarf2 debug information in offline assembler for clang compiler
        https://bugs.webkit.org/show_bug.cgi?id=157364.

        Reviewed by Mark Lam.

        Added a new function shouldEnableDebugAnnotations() that determines if
        we are using clang and a new enough version to support the debug annotations.

        * offlineasm/config.rb:
        (shouldEnableDebugAnnotations): Added.

2016-05-04  Keith Miller  <keith_miller@apple.com>

        Unreviewed, fix test for new ArrayIteratorPrototype.next() error message.

        * tests/stress/array-iterators-next-with-call.js:

2016-05-04  Filip Pizlo  <fpizlo@apple.com>

        Speed up JSGlobalObject initialization by making some properties lazy
        https://bugs.webkit.org/show_bug.cgi?id=157045

        Reviewed by Keith Miller.
        
        This makes about half of JSGlobalObject's state lazy. There are three categories of
        state in JSGlobalObject:
        
        1) C++ fields in JSGlobalObject.
        2) JS object properties in JSGlobalObject's JSObject superclass.
        3) JS variables in JSGlobalObject's JSSegmentedVariableObject superclass.
        
        State held in JS variables cannot yet be made lazy. That's why this patch only goes
        half-way.
        
        State in JS object properties can be made lazy if we move it to the static property
        hashtable. JSGlobalObject already had one of those. This patch makes static property
        hashtables a lot more powerful, by adding three new kinds of static properties. These
        new kinds allow us to make almost all of JSGlobalObject's object properties lazy.
        
        State in C++ fields can now be made lazy thanks in part to WTF's support for stateless
        lambdas. You can of course make anything lazy by hand, but there are many C++ fields in
        JSGlobalObject and we are adding more all the time. We don't want to require that each
        of these has a getter with an initialization check and a corresponding out-of-line slow
        path that does the initialization. We want this kind of boilerplate to be handled by
        some abstractions.
        
        The primary abstraction introduced in this patch is LazyProperty<Type>. Currently, this
        only works where Type is a subclass of JSCell. Such a property holds a pointer to Type.
        You can use it like you would a WriteBarrier<Type>. It even has set() and get() methods,
        so it's almost a drop-in replacement.
        
        The key to LazyProperty<Type>'s power is that you can do this:
        
            class Bar {
                ...
                LazyProperty<Foo> m_foo;
            };
            ...
            m_foo.initLater(
                [] (const LazyProperty<Foo>::Initializer<Bar>& init) {
                    init.set(Foo::create(init.vm, init.owner));
                });
        
        This initLater() call requires that you pass a stateless lambda (see WTF changelog for
        the definition). Miraculously, this initLater() call is guaranteed to compile to a store
        of a pointer constant to m_foo, as in:
        
            movabsq 0xBLAH, %rax
            movq %rax, &m_foo
        
        This magical pointer constant points to a callback that was generated by the template
        instantiation of initLater(). That callback knows to call your stateless lambda, but
        also does some other bookkeeping: it makes sure that you indeed initialized the property
        inside the callback and it manages recursive initializations. It's totally legal to call
        m_foo.get() inside the initLater() callback. If you do that before you call init.set(),
        m_foo.get() will return null. This is an excellent escape hatch if we ever find
        ourselves in a dependency cycle. I added this feature because I already had to create a
        dependency cycle.
        
        Note that using LazyProperties from DFG threads is super awkward. It's going to be hard
        to get this right. The DFG thread cannot initialize those fields, so it has to make sure
        that it does conservative things. But for some nodes this could mean adding a lot of new
        logic, like NewTypedArray, which currently is written in such a way that it assumes that
        we always have the typed array structure. Currently we take a two-fold approach: for
        typed arrays we don't handle the NewTypedArray intrinsic if the structure isn't
        initialized, and for everything else we don't make the properties lazy if the DFG needs
        them. As we optimize this further we might need to teach the DFG to handle more lazy
        properties. I tried to do this for RegExp but found it to be very confusing. With typed
        arrays I got lucky.
        
        There is also a somewhat more powerful construct called LazyClassStructure. We often
        need to keep around the structure of some standard JS class, like Date. We also need to
        make sure that the constructor ends up in the global object's property table. And we
        often need to keep the original value of the constructor for ourselves. In this case, we
        want to make sure that the creation of the structure-prototype-constructor constellation
        is atomic. We don't want code to start looking at the structure if it points to a
        prototype that doesn't have its "constructor" property set yet, for example.
        LazyClassStructure solves this by abstracting that whole initialization. You provide the
        callback that allocates everything, since we are super inconsistent about the way we
        initialize things, but LazyClassStructure establishes the workflow and helps you not
        mess up.
        
        Finally, the new static hashtable attributes allow for all of this to work with the JS
        property table:
        
        PropertyCallback: if you use this attribute, the second column in the table should be
        the name of a function to call to initialize this property. This is useful for things
        like the Math property. The Math object turns out to be very expensive to allocate.
        Delaying its allocation is super easy with the PropertyCallback attribute.
        
        CellProperty: with this attribute the second column should be a C++ field name like
        JSGlobalObject::m_evalErrorConstructor. The static hashtable will grab the offset of
        this property, and when it needs to be initialized, Lookup will assume you have a
        LazyProperty<JSCell> and call its get() method. It will initialize the property to
        whatever get() returned. Note that it's legal to cast a LazyProperty<Anything> to
        LazyProperty<JSCell> for the purpose of calling get() because the get() method will just
        call whatever callback function pointer is encoded in the property and it does not need
        to know anything about what type that callback will instantiate.
        
        ClassStructure: with this attribute the second column should be a C++ field name. The
        static hashtable will initialize the property by treating the field as a
        LazyClassStructure and it will call get(). LazyClassStructure completely owns the whole
        initialization workflow, so Lookup assumes that when LazyClassStructure::get() returns,
        the property in question will already be set. By convention, we have LazyClassStructure
        initialize the property with a pointer to the constructor, since that's how all of our
        classes work: "globalObject.Date" points to the DateConstructor.
        
        This is a 2x speed-up in JSGlobalObject initialization time in a microbenchmark that
        calls our C API. This is a 1% speed-up on SunSpider and JSRegress.
        
        Rolling this back in after fixing the function pointer alignment issue. The last version
        relied on function pointers being aligned to a 4-byte boundary. We cannot rely on this,
        especially since ARMv7 uses the low bit of function pointers as a tag to indicate the
        instruction set. This version adds an extra indirection, so that
        LazyProperty<>::m_pointer points to a pointer that points to the function. A pointer to
        a pointer is guaranteed to be at least 4-byte aligned.

        * API/JSCallbackFunction.cpp:
        (JSC::JSCallbackFunction::create):
        * API/ObjCCallbackFunction.h:
        (JSC::ObjCCallbackFunction::impl):
        * API/ObjCCallbackFunction.mm:
        (JSC::ObjCCallbackFunction::ObjCCallbackFunction):
        (JSC::ObjCCallbackFunction::create):
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * create_hash_table:
        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::create):
        (JSC::DebuggerScope::DebuggerScope):
        * debugger/DebuggerScope.h:
        (JSC::DebuggerScope::jsScope):
        (JSC::DebuggerScope::create): Deleted.
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::set):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::originalArrayStructure):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::getOwnPropertySlot):
        (JSC::ClonedArguments::materializeSpecials):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::visitChildren):
        (JSC::InternalFunction::name):
        (JSC::InternalFunction::calculatedDisplayName):
        (JSC::InternalFunction::createSubclassStructure):
        * runtime/InternalFunction.h:
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::finishCreation):
        (JSC::JSBoundFunction::visitChildren):
        * runtime/JSBoundSlotBaseFunction.cpp:
        (JSC::JSBoundSlotBaseFunction::create):
        * runtime/JSFunction.cpp:
        (JSC::retrieveCallerFunction):
        (JSC::getThrowTypeErrorGetterSetter):
        (JSC::JSFunction::callerGetter):
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGlobalObject.cpp:
        (JSC::createProxyProperty):
        (JSC::createJSONProperty):
        (JSC::createMathProperty):
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::stringPrototypeChainIsSane):
        (JSC::JSGlobalObject::resetPrototype):
        (JSC::JSGlobalObject::visitChildren):
        (JSC::JSGlobalObject::toThis):
        (JSC::JSGlobalObject::getOwnPropertySlot):
        (JSC::JSGlobalObject::createThrowTypeError): Deleted.
        (JSC::JSGlobalObject::createThrowTypeErrorArgumentsAndCaller): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::objectConstructor):
        (JSC::JSGlobalObject::promiseConstructor):
        (JSC::JSGlobalObject::internalPromiseConstructor):
        (JSC::JSGlobalObject::evalErrorConstructor):
        (JSC::JSGlobalObject::rangeErrorConstructor):
        (JSC::JSGlobalObject::referenceErrorConstructor):
        (JSC::JSGlobalObject::syntaxErrorConstructor):
        (JSC::JSGlobalObject::typeErrorConstructor):
        (JSC::JSGlobalObject::URIErrorConstructor):
        (JSC::JSGlobalObject::nullGetterFunction):
        (JSC::JSGlobalObject::nullSetterFunction):
        (JSC::JSGlobalObject::callFunction):
        (JSC::JSGlobalObject::applyFunction):
        (JSC::JSGlobalObject::definePropertyFunction):
        (JSC::JSGlobalObject::arrayProtoValuesFunction):
        (JSC::JSGlobalObject::initializePromiseFunction):
        (JSC::JSGlobalObject::newPromiseCapabilityFunction):
        (JSC::JSGlobalObject::functionProtoHasInstanceSymbolFunction):
        (JSC::JSGlobalObject::regExpProtoExecFunction):
        (JSC::JSGlobalObject::regExpProtoSymbolReplaceFunction):
        (JSC::JSGlobalObject::regExpProtoGlobalGetter):
        (JSC::JSGlobalObject::regExpProtoUnicodeGetter):
        (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
        (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerGetterSetter):
        (JSC::JSGlobalObject::moduleLoader):
        (JSC::JSGlobalObject::objectPrototype):
        (JSC::JSGlobalObject::functionPrototype):
        (JSC::JSGlobalObject::arrayPrototype):
        (JSC::JSGlobalObject::booleanPrototype):
        (JSC::JSGlobalObject::stringPrototype):
        (JSC::JSGlobalObject::symbolPrototype):
        (JSC::JSGlobalObject::numberPrototype):
        (JSC::JSGlobalObject::datePrototype):
        (JSC::JSGlobalObject::regExpPrototype):
        (JSC::JSGlobalObject::errorPrototype):
        (JSC::JSGlobalObject::iteratorPrototype):
        (JSC::JSGlobalObject::generatorFunctionPrototype):
        (JSC::JSGlobalObject::generatorPrototype):
        (JSC::JSGlobalObject::debuggerScopeStructure):
        (JSC::JSGlobalObject::withScopeStructure):
        (JSC::JSGlobalObject::strictEvalActivationStructure):
        (JSC::JSGlobalObject::activationStructure):
        (JSC::JSGlobalObject::moduleEnvironmentStructure):
        (JSC::JSGlobalObject::directArgumentsStructure):
        (JSC::JSGlobalObject::scopedArgumentsStructure):
        (JSC::JSGlobalObject::clonedArgumentsStructure):
        (JSC::JSGlobalObject::isOriginalArrayStructure):
        (JSC::JSGlobalObject::booleanObjectStructure):
        (JSC::JSGlobalObject::callbackConstructorStructure):
        (JSC::JSGlobalObject::callbackFunctionStructure):
        (JSC::JSGlobalObject::callbackObjectStructure):
        (JSC::JSGlobalObject::propertyNameIteratorStructure):
        (JSC::JSGlobalObject::objcCallbackFunctionStructure):
        (JSC::JSGlobalObject::objcWrapperObjectStructure):
        (JSC::JSGlobalObject::dateStructure):
        (JSC::JSGlobalObject::nullPrototypeObjectStructure):
        (JSC::JSGlobalObject::errorStructure):
        (JSC::JSGlobalObject::calleeStructure):
        (JSC::JSGlobalObject::functionStructure):
        (JSC::JSGlobalObject::boundFunctionStructure):
        (JSC::JSGlobalObject::boundSlotBaseFunctionStructure):
        (JSC::JSGlobalObject::getterSetterStructure):
        (JSC::JSGlobalObject::nativeStdFunctionStructure):
        (JSC::JSGlobalObject::namedFunctionStructure):
        (JSC::JSGlobalObject::functionNameOffset):
        (JSC::JSGlobalObject::numberObjectStructure):
        (JSC::JSGlobalObject::privateNameStructure):
        (JSC::JSGlobalObject::mapStructure):
        (JSC::JSGlobalObject::regExpStructure):
        (JSC::JSGlobalObject::generatorFunctionStructure):
        (JSC::JSGlobalObject::setStructure):
        (JSC::JSGlobalObject::stringObjectStructure):
        (JSC::JSGlobalObject::symbolObjectStructure):
        (JSC::JSGlobalObject::iteratorResultObjectStructure):
        (JSC::JSGlobalObject::lazyTypedArrayStructure):
        (JSC::JSGlobalObject::typedArrayStructure):
        (JSC::JSGlobalObject::typedArrayStructureConcurrently):
        (JSC::JSGlobalObject::isOriginalTypedArrayStructure):
        (JSC::JSGlobalObject::typedArrayConstructor):
        (JSC::JSGlobalObject::actualPointerFor):
        (JSC::JSGlobalObject::internalFunctionStructure): Deleted.
        * runtime/JSNativeStdFunction.cpp:
        (JSC::JSNativeStdFunction::create):
        * runtime/JSWithScope.cpp:
        (JSC::JSWithScope::create):
        (JSC::JSWithScope::visitChildren):
        (JSC::JSWithScope::createStructure):
        (JSC::JSWithScope::JSWithScope):
        * runtime/JSWithScope.h:
        (JSC::JSWithScope::object):
        (JSC::JSWithScope::create): Deleted.
        (JSC::JSWithScope::createStructure): Deleted.
        (JSC::JSWithScope::JSWithScope): Deleted.
        * runtime/LazyClassStructure.cpp: Added.
        (JSC::LazyClassStructure::Initializer::Initializer):
        (JSC::LazyClassStructure::Initializer::setPrototype):
        (JSC::LazyClassStructure::Initializer::setStructure):
        (JSC::LazyClassStructure::Initializer::setConstructor):
        (JSC::LazyClassStructure::visit):
        (JSC::LazyClassStructure::dump):
        * runtime/LazyClassStructure.h: Added.
        (JSC::LazyClassStructure::LazyClassStructure):
        (JSC::LazyClassStructure::get):
        (JSC::LazyClassStructure::prototype):
        (JSC::LazyClassStructure::constructor):
        (JSC::LazyClassStructure::getConcurrently):
        (JSC::LazyClassStructure::prototypeConcurrently):
        (JSC::LazyClassStructure::constructorConcurrently):
        * runtime/LazyClassStructureInlines.h: Added.
        (JSC::LazyClassStructure::initLater):
        * runtime/LazyProperty.h: Added.
        (JSC::LazyProperty::Initializer::Initializer):
        (JSC::LazyProperty::LazyProperty):
        (JSC::LazyProperty::get):
        (JSC::LazyProperty::getConcurrently):
        * runtime/LazyPropertyInlines.h: Added.
        (JSC::ElementType>::Initializer::set):
        (JSC::ElementType>::initLater):
        (JSC::ElementType>::setMayBeNull):
        (JSC::ElementType>::set):
        (JSC::ElementType>::visit):
        (JSC::ElementType>::dump):
        (JSC::ElementType>::callFunc):
        * runtime/Lookup.cpp:
        (JSC::setUpStaticFunctionSlot):
        * runtime/Lookup.h:
        (JSC::HashTableValue::function):
        (JSC::HashTableValue::functionLength):
        (JSC::HashTableValue::propertyGetter):
        (JSC::HashTableValue::propertyPutter):
        (JSC::HashTableValue::accessorGetter):
        (JSC::HashTableValue::accessorSetter):
        (JSC::HashTableValue::constantInteger):
        (JSC::HashTableValue::lexerValue):
        (JSC::HashTableValue::lazyCellPropertyOffset):
        (JSC::HashTableValue::lazyClassStructureOffset):
        (JSC::HashTableValue::lazyPropertyCallback):
        (JSC::getStaticPropertySlot):
        (JSC::getStaticValueSlot):
        (JSC::putEntry):
        (JSC::reifyStaticProperty):
        * runtime/PropertySlot.h:
        * runtime/TypedArrayType.h:

2016-05-04  Joseph Pecoraro  <pecoraro@apple.com>

        Improve the grammar of some error messages 'a argument list' => 'an argument list'
        https://bugs.webkit.org/show_bug.cgi?id=157350
        <rdar://problem/26082108>

        Reviewed by Mark Lam.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseIfStatement):
        (JSC::Parser<LexerType>::parseImportDeclaration):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        (JSC::Parser<LexerType>::parseObjectLiteral):
        (JSC::Parser<LexerType>::parseStrictObjectLiteral):
        (JSC::Parser<LexerType>::parseArguments):
        Use the alternate error message formatter macro which outputs 'an'
        instead of 'a' preceding the last argument.

2016-05-04  Keith Miller  <keith_miller@apple.com>

        Corrections to r200422
        https://bugs.webkit.org/show_bug.cgi?id=157351

        Reviewed by Joseph Pecoraro.

        Fix some typos in various files. Also, make separate error messages
        for the this value being undefined vs null in the ArrayIteratorprototype
        next function and add test.

        * Scripts/builtins/builtins_model.py:
        * builtins/ArrayIteratorPrototype.js:
        (next):
        (arrayIteratorValueNext):
        (arrayIteratorKeyNext):
        (arrayIteratorKeyValueNext):
        * builtins/ArrayPrototype.js:
        (keys):
        (entries):
        * builtins/TypedArrayPrototype.js:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Deleted.
        * tests/stress/array-iterators-next-error-messages.js: Added.
        (assert):
        (catch):

2016-05-04  Keith Miller  <keith_miller@apple.com>

        Unreviewed, reland r200149 since the rollout had inconclusive PLT AB testing results.

2016-05-04  Mark Lam  <mark.lam@apple.com>

        ES6 Function.name inferred from property names of literal objects can break some websites.
        https://bugs.webkit.org/show_bug.cgi?id=157246

        Reviewed by Geoffrey Garen.

        Specifically, the library mathjs (see http://mathjs.org and https://github.com/josdejong/mathjs)
        uses an idiom where it created literal objects with property names that look like
        this: 'number | BigNumber | Unit'.  Later, this name is used in a string to create
        function source code that gets eval'ed.  Since 'number | BigNumber | Unit' is not
        a valid function name, we get a syntax error.

        Here are the details:

        1. mathjs uses object literals with the funky property names for its function members.
           For example, 

              // helper function to type check the middle value of the array
              var middle = typed({
                'number | BigNumber | Unit': function (value) {
                  return value;
                }
              });

        2. mathjs' getName() uses Function.name to get the name of functions (hence, picks
           up the property name as inferred value of Function.name as specified by ES6):

                /**
                 * Retrieve the function name from a set of functions, and check
                 * whether the name of all functions match (if given)
                 ...
                 */
                function getName (fns) {
                  var name = '';

                  for (var i = 0; i < fns.length; i++) {
                    var fn = fns[i];
                    ...
                        name = fn.name;
                    ...
                  return name;
                }

        3. mathjs uses that name to assembler new function source code that gets eval'ed:

                /**
                 * Compose a function from sub-functions each handling a single type signature.
                 ...
                 */
                function _typed(name, signatures) {
                  ...
                  // generate code for the typed function
                  var code = [];
                  var _name = name || '';
                  ...
                  code.push('function ' + _name + '(' + _args.join(', ') + ') {');
                  code.push('  "use strict";');
                  code.push('  var name = \'' + _name + '\';');
                  code.push(node.toCode(refs, '  '));
                  code.push('}');

                  // generate body for the factory function
                  var body = [
                    refs.toCode(),
                    'return ' + code.join('\n')
                  ].join('\n');

                  // evaluate the JavaScript code and attach function references
                  var factory = (new Function(refs.name, 'createError', body));  // <== Syntax Error here!
                  var fn = factory(refs, createError);
                  ...
                  return fn;
                }

        Until mathjs (and any other frameworks that does similar things) and sites that
        uses mathjs has been updated to work with ES6, we'll need a compatibility hack to
        work around it.

        Here's what we'll do:
        1. Introduce a needsSiteSpecificQuirks flag in JSGlobalObject.
        2. Have WebCore's JSDOMWindowBase set that flag if the browser's
           needsSiteSpecificQuirks is enabled in its settings.
        3. If needsSiteSpecificQuirks is enabled, have JSFunction::reifyName() check for
           ' ' or '|' in the name string it will use to reify the Function.name property.
           If those characters exists in the name, we'll replace the name string with a
           null string.

        * runtime/JSFunction.cpp:
        (JSC::JSFunction::reifyName):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::needsSiteSpecificQuirks):
        (JSC::JSGlobalObject::GlobalPropertyInfo::GlobalPropertyInfo):
        (JSC::JSGlobalObject::setNeedsSiteSpecificQuirks):

2016-05-04  Keith Miller  <keith_miller@apple.com>

        Speedup array iterators
        https://bugs.webkit.org/show_bug.cgi?id=157315

        Reviewed by Michael Saboff.

        This patch improves the performance of Array iterators in ES6. There are two main changes
        that make things faster. The first is that the value, keys and entries functions have been
        moved to JS. This enables us to inline the construction of the iterator. Thus, when we get
        to the FTL we are able to sink the allocation of the iterator object. This significantly
        improves the performance of any for-of loop since we are now able to have both the iteration
        counter and the iterated object in local variables rather than in the heap.

        Secondly, instead of using a number to store the iteratation kind we now use a virtual
        method on the iteration object to indicate which next function to use. This ends up being
        helpful because it means we can eliminate the branches in the old next function that decide
        what value to return. With those branches gone the various next functions are now small
        enough to inline. Once the next functions are inlined then the FTL is able to sink the
        allocation of next() result object. There is still room for optimization in the loop since
        we currently don't recognize that the array access in the next function is in bounds or that
        the increment to the loop counter cannot overflow.

        The overall performance changes appear to be a ~4-6x speedup in a simple microbenchmark that
        computes the sum of an array with some extra arithmetic. The variance depends on the exact
        body of the loop. Additionally, on a new regress test that changes all the loops in
        deltablue into for-of loops this patch is a 1.8x progression. Overall, it still looks like
        for-of loops are significantly slower than an indexed for loop. In the first test it's ~2-4x
        slower with the difference depending on the body of the loop. If the loop is just the sum
        then we see a much larger regression than if the loop does even simple arithmetic. It looks
        like the indexed for loop without extra arithmetic is small enough to fit into the x86
        replay buffer on my machine, which would explain why there is such a big difference between
        the for of loop in that case. On the deltablue benchmark it's 1.4x slower. It's clear from
        these numbers that there is still a lot of work we can do to make for of loops faster.

        This patch also makes some changes to the way that we decorate our builtin js
        functions. Instead of the old syntax (putting the decorated values in [] before the function
        declaration i.e. [intrinsic=foo]) this patch changes the syntax to be closer to the way that
        decorators are proposed in a future ECMAScript proposal (using @ followed by the entry on a
        new line before the function declaration i.e. @intrinsic=foo).

        Finally, in the builtin scripts regular expressions re.S has been changed to re.DOTALL since
        DOTALL is easier to understand without going to the reference page for python regular
        expressions.

        * Scripts/builtins/builtins_model.py:
        * builtins/ArrayIteratorPrototype.js:
        (next):
        (arrayIteratorValueNext):
        (arrayIteratorKeyNext):
        (arrayIteratorKeyValueNext):
        * builtins/ArrayPrototype.js:
        (createArrayIterator):
        (values):
        (keys):
        (entries):
        * builtins/RegExpPrototype.js:
        (intrinsic.RegExpTestIntrinsic.test):
        * builtins/StringPrototype.js:
        (intrinsic.StringPrototypeReplaceIntrinsic.replace):
        * builtins/TypedArrayPrototype.js:
        (values):
        (keys):
        (entries):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::cloneArrayIteratorObject):
        (Inspector::JSInjectedScriptHost::iteratorEntries):
        * jit/ThunkGenerators.cpp:
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::arrayProtoFuncValues): Deleted.
        (JSC::arrayProtoFuncEntries): Deleted.
        (JSC::arrayProtoFuncKeys): Deleted.
        * runtime/CommonIdentifiers.h:
        * runtime/JSArrayIterator.cpp:
        (JSC::JSArrayIterator::clone): Deleted.
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncEntries): Deleted.
        (JSC::genericTypedArrayViewProtoFuncKeys): Deleted.
        (JSC::typedArrayViewProtoFuncValues): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        (JSC::typedArrayViewProtoFuncEntries): Deleted.
        (JSC::typedArrayViewProtoFuncKeys): Deleted.
        (JSC::typedArrayViewProtoFuncValues): Deleted.
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):

2016-05-04  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Object constructor need to be aware of new.target
        https://bugs.webkit.org/show_bug.cgi?id=157196

        Reviewed by Darin Adler.

        Object constructor should be aware of new.target.
        When the new.target is specified, we should store it.prototype to the newly created
        object's [[Prototype]].

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        Take the design that caches the structure used for empty object.
        This structure is also used in constructEmptyObject frequently.

        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::objectStructureForObjectConstructor):
        * runtime/ObjectConstructor.cpp:
        (JSC::constructObject):
        (JSC::constructWithObjectConstructor):
        (JSC::callObjectConstructor):
        * runtime/ObjectConstructor.h:
        (JSC::constructEmptyObject):
        Construct the object by using the plain structure that is also used in the ObjectConstructor.

        * tests/stress/object-constructor-should-be-new-target-aware.js: Added.
        (shouldBe):
        (Hello):

2016-05-04  Chris Dumez  <cdumez@apple.com>

        Unreviewed, rolling out r200383 and r200406.

        Seems to have caused crashes on iOS / ARMv7s

        Reverted changesets:

        "Speed up JSGlobalObject initialization by making some
        properties lazy"
        https://bugs.webkit.org/show_bug.cgi?id=157045
        http://trac.webkit.org/changeset/200383

        "REGRESSION(r200383): Setting lazily initialized properties
        across frame boundaries crashes"
        https://bugs.webkit.org/show_bug.cgi?id=157333
        http://trac.webkit.org/changeset/200406

2016-05-04  Yusuke Suzuki  <utatane.tea@gmail.com>

        Assertion failure for super() call in direct eval in method function
        https://bugs.webkit.org/show_bug.cgi?id=157091

        Reviewed by Darin Adler.

        While we ensure that direct super is under the correct context,
        we don't check it for the eval code. This patch moves the check from the end of parsing the function
        to the places where we found the direct super or the super bindings. This covers the direct eval that
        contains the direct super calls.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/Parser.h:
        (JSC::Scope::hasDirectSuper):
        (JSC::Scope::setHasDirectSuper):
        (JSC::Scope::needsSuperBinding):
        (JSC::Scope::setNeedsSuperBinding):
        (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope):
        * tests/stress/eval-and-super.js: Added.
        (shouldBe):
        (shouldThrow):
        (prototype.m):
        (prototype.n):
        * tests/stress/generator-and-super.js: Added.
        (testSyntaxError):
        (testSyntaxError.Base.prototype.hello):
        (testSyntaxError.Base.prototype.ok):
        (testSyntaxError.Base):
        (Hello.prototype.gen):
        (Hello):
        (testSyntaxError.hello):

2016-05-03  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(r200383): Setting lazily initialized properties across frame boundaries crashes
        https://bugs.webkit.org/show_bug.cgi?id=157333

        Reviewed by Benjamin Poulain.
        
        I forgot to add logic for lazy properties in putEntry(). It turns out that it's easy to
        add.

        * runtime/Lookup.h:
        (JSC::putEntry):
        * runtime/PropertySlot.h:

2016-05-03  Filip Pizlo  <fpizlo@apple.com>

        References from code to Structures should be stronger than weak
        https://bugs.webkit.org/show_bug.cgi?id=157324

        Reviewed by Mark Lam.
        
        If code refers to a Structure and the Structure dies, then previously we'd kill the code. 
        This makes sense because the Structure could be the only thing left referring to some global
        object or prototype.

        But this also causes unnecessary churn. Sometimes there will be a structure that we just
        haven't really done anything with recently and so it appears dead. The approach we use
        elsewhere in our type inference is that the type that the code uses is general enough to
        handle every past execution. Having the GC clear code when some Structure it uses dies means
        that we forget that the code used that Structure. We'll either assume that the code is more
        monomorphic than it really is (because after GC we patch in some other structure but not the
        deleted one, so it looks like we only ever saw the new structure), or we'll assume that it's
        crazier than it really is (because we'll remember that there had been some structure that
        caused deletion, so we'll assume that deletions might happen in the future, so we'll use a
        fully dynamic IC).

        This change introduces a more nuanced policy: if it's cheap to mark a dead Structure then we
        should mark it just so that all of the code that refers to it remembers that there had been
        this exact Structure in the past. If the code often goes through different Structures then
        we already have great mechanisms to realize that the code is nutty (namely, the
        PolymorphicAccess size limit). But if the code just does this a handful of times then
        remembering this old Structure is probably net good:

        - It obeys the "handle all past executions" law.
        - It preserves the history of the property access, allowing a precise measure of its past
          polymorphism.
        - It makes the code ready to run fast if the user decides to use that Structure again.
          Marking the Structure means it will stay in whatever property transition tables it was in,
          so if the program does the same thing it did in the past, it will get this old Structure.

        It looks like this is a progression in gbemu and it makes gbemu perform more
        deterministically. Also, it seems that this makes JetStream run faster.
        
        Over five in-browser runs of JetStream, here's what we see before and after:
        
        Geometric Mean:
            Before              After
            229.23 +- 8.2523    230.70 +- 12.888
            232.91 +- 15.638    239.04 +- 13.766
            234.79 +- 12.760    236.32 +- 15.562
            236.20 +- 23.125    242.02 +- 3.3865
            237.22 +- 2.1929    237.23 +- 17.664
        
        Just gbemu:
            Before              After
            541.0 +- 135.8      481.7 +- 143.4
            518.9 +- 15.65      508.1 +- 136.3
            362.5 +- 0.8884     489.7 +- 101.4
            470.7 +- 313.3      530.7 +- 11.49
            418.7 +- 180.6      537.2 +- 6.514
        
        Notice that there is plenty of noise before and after, but the noise is now far less severe.
        After this change I did not see any runs like "470.7 +- 313.3" where the size of the 
        confidence interval (313.3 * 2) is greater than the score (470.7). Also, notice that the
        least noisy run before the change also got a lower score than we ever observed after the
        change (36.5 +- 0.8884). The noise, and these occasional very low scores, are due to a
        pathology where the GC would reset some stubs at an unfortunate time during profiling,
        causing the optimizing compiler to make many poor decisions. That pathology doesn't exist
        anymore.
        
        On the other hand, prior to this change it was possible for gbemu to sometimes run sooooper
        fast because the GC would cause the profiler to forget gbemu's behavior on the first tick
        and focus only on its behavior in subsequent ticks. So, in steady state, we'd optimize gbemu
        for its later behavior rather than a combination of its early behavior and later behavior.
        We rarely got lucky this way, so it's not fair to view this quirk as a feature.
        
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::propagateTransitions):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::visitWeak):
        (JSC::AccessCase::propagateTransitions):
        (JSC::AccessCase::generateWithGuard):
        (JSC::PolymorphicAccess::visitWeak):
        (JSC::PolymorphicAccess::propagateTransitions):
        (JSC::PolymorphicAccess::dump):
        * bytecode/PolymorphicAccess.h:
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::visitWeakReferences):
        (JSC::StructureStubInfo::propagateTransitions):
        (JSC::StructureStubInfo::containsPC):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::considerCaching):
        * runtime/Structure.cpp:
        (JSC::Structure::visitChildren):
        (JSC::Structure::isCheapDuringGC):
        (JSC::Structure::markIfCheap):
        (JSC::Structure::prototypeChainMayInterceptStoreTo):
        * runtime/Structure.h:

2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Simplify console.clear
        https://bugs.webkit.org/show_bug.cgi?id=157316

        Reviewed by Timothy Hatcher.

        * inspector/ScriptArguments.cpp:
        (Inspector::ScriptArguments::createEmpty):
        (Inspector::ScriptArguments::ScriptArguments):
        * inspector/ScriptArguments.h:
        Provide a way to create an empty list.

        * runtime/ConsoleClient.cpp:
        (JSC::ConsoleClient::clear):
        * runtime/ConsoleClient.h:
        Drop unnecessary parameter.

        * runtime/ConsoleObject.cpp:
        (JSC::consoleProtoFuncClear):
        No need to parse arguments.

2016-05-03  Yusuke Suzuki  <utatane.tea@gmail.com>

        Improve Symbol() to string coercion error message
        https://bugs.webkit.org/show_bug.cgi?id=157317

        Reviewed by Geoffrey Garen.

        Improve error messages related to Symbols.

        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::toStringSlowCase):
        * runtime/Symbol.cpp:
        (JSC::Symbol::toNumber):
        * runtime/SymbolConstructor.cpp:
        (JSC::symbolConstructorKeyFor):
        * runtime/SymbolPrototype.cpp:
        (JSC::symbolProtoFuncToString):
        (JSC::symbolProtoFuncValueOf):
        * tests/stress/dfg-to-primitive-pass-symbol.js:
        * tests/stress/floating-point-div-to-mul.js:
        (i.catch):
        * tests/stress/string-from-code-point.js:
        (shouldThrow):
        (string_appeared_here.shouldThrow):
        * tests/stress/symbol-error-messages.js: Added.
        (shouldThrow):
        * tests/stress/symbol-registry.js:

2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Give console.time/timeEnd a default label and warnings
        https://bugs.webkit.org/show_bug.cgi?id=157325
        <rdar://problem/26073290>

        Reviewed by Timothy Hatcher.

        Provide more user friendly console.time/timeEnd. The timer name
        is now optional, and is "default" if not provided. Also provide
        warnings when attempting to start an already started timer,
        or stop a timer that does not exist.

        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::startTiming):
        (Inspector::InspectorConsoleAgent::stopTiming):
        Warnings for bad cases.

        * runtime/ConsoleObject.cpp:
        (JSC::defaultLabelString):
        (JSC::consoleProtoFuncTime):
        (JSC::consoleProtoFuncTimeEnd):
        Optional label becomes "default".

2016-05-03  Xan Lopez  <xlopez@igalia.com>

        Fix the ENABLE(WEBASSEMBLY) build
        https://bugs.webkit.org/show_bug.cgi?id=157312

        Reviewed by Darin Adler.

        * runtime/Executable.cpp:
        (JSC::WebAssemblyExecutable::WebAssemblyExecutable):
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::convertValueToDouble):

2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove unused parameter of ScriptArguments::getFirstArgumentAsString
        https://bugs.webkit.org/show_bug.cgi?id=157301

        Reviewed by Timothy Hatcher.

        * inspector/ScriptArguments.cpp:
        (Inspector::ScriptArguments::getFirstArgumentAsString):
        * inspector/ScriptArguments.h:
        Remove unused argument and related code.

        * runtime/ConsoleClient.cpp:
        (JSC::ConsoleClient::printConsoleMessageWithArguments):
        Drive by remove unnecessary cast.

2016-05-03  Michael Saboff  <msaboff@apple.com>

        Crash: Array.prototype.slice() and .splice() can call fastSlice() after an array is truncated
        https://bugs.webkit.org/show_bug.cgi?id=157322

        Reviewed by Filip Pizlo.

        Check to see if the source array has changed length before calling fastSlice().
        If it has, take the slow path.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSlice):
        (JSC::arrayProtoFuncSplice):
        * tests/stress/regress-157322.js: New test.

2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>

        Eliminate PassRefPtr conversion from ConsoleObject
        https://bugs.webkit.org/show_bug.cgi?id=157300

        Reviewed by Timothy Hatcher.

        * runtime/ConsoleObject.cpp:
        (JSC::consoleLogWithLevel):
        (JSC::consoleProtoFuncClear):
        (JSC::consoleProtoFuncDir):
        (JSC::consoleProtoFuncDirXML):
        (JSC::consoleProtoFuncTable):
        (JSC::consoleProtoFuncTrace):
        (JSC::consoleProtoFuncAssert):
        (JSC::consoleProtoFuncCount):
        (JSC::consoleProtoFuncTimeStamp):
        (JSC::consoleProtoFuncGroup):
        (JSC::consoleProtoFuncGroupCollapsed):
        (JSC::consoleProtoFuncGroupEnd):
        No need to release to a PassRefPtr, we can just move into the RefPtr<>&&.

2016-05-01  Filip Pizlo  <fpizlo@apple.com>

        Speed up JSGlobalObject initialization by making some properties lazy
        https://bugs.webkit.org/show_bug.cgi?id=157045

        Reviewed by Keith Miller.
        
        This makes about half of JSGlobalObject's state lazy. There are three categories of
        state in JSGlobalObject:
        
        1) C++ fields in JSGlobalObject.
        2) JS object properties in JSGlobalObject's JSObject superclass.
        3) JS variables in JSGlobalObject's JSSegmentedVariableObject superclass.
        
        State held in JS variables cannot yet be made lazy. That's why this patch only goes
        half-way.
        
        State in JS object properties can be made lazy if we move it to the static property
        hashtable. JSGlobalObject already had one of those. This patch makes static property
        hashtables a lot more powerful, by adding three new kinds of static properties. These
        new kinds allow us to make almost all of JSGlobalObject's object properties lazy.
        
        State in C++ fields can now be made lazy thanks in part to WTF's support for stateless
        lambdas. You can of course make anything lazy by hand, but there are many C++ fields in
        JSGlobalObject and we are adding more all the time. We don't want to require that each
        of these has a getter with an initialization check and a corresponding out-of-line slow
        path that does the initialization. We want this kind of boilerplate to be handled by
        some abstractions.
        
        The primary abstraction introduced in this patch is LazyProperty<Type>. Currently, this
        only works where Type is a subclass of JSCell. Such a property holds a pointer to Type.
        You can use it like you would a WriteBarrier<Type>. It even has set() and get() methods,
        so it's almost a drop-in replacement.
        
        The key to LazyProperty<Type>'s power is that you can do this:
        
            class Bar {
                ...
                LazyProperty<Foo> m_foo;
            };
            ...
            m_foo.initLater(
                [] (const LazyProperty<Foo>::Initializer<Bar>& init) {
                    init.set(Foo::create(init.vm, init.owner));
                });
        
        This initLater() call requires that you pass a stateless lambda (see WTF changelog for
        the definition). Miraculously, this initLater() call is guaranteed to compile to a store
        of a pointer constant to m_foo, as in:
        
            movabsq 0xBLAH, %rax
            movq %rax, &m_foo
        
        This magical pointer constant points to a callback that was generated by the template
        instantiation of initLater(). That callback knows to call your stateless lambda, but
        also does some other bookkeeping: it makes sure that you indeed initialized the property
        inside the callback and it manages recursive initializations. It's totally legal to call
        m_foo.get() inside the initLater() callback. If you do that before you call init.set(),
        m_foo.get() will return null. This is an excellent escape hatch if we ever find
        ourselves in a dependency cycle. I added this feature because I already had to create a
        dependency cycle.
        
        Note that using LazyProperties from DFG threads is super awkward. It's going to be hard
        to get this right. The DFG thread cannot initialize those fields, so it has to make sure
        that it does conservative things. But for some nodes this could mean adding a lot of new
        logic, like NewTypedArray, which currently is written in such a way that it assumes that
        we always have the typed array structure. Currently we take a two-fold approach: for
        typed arrays we don't handle the NewTypedArray intrinsic if the structure isn't
        initialized, and for everything else we don't make the properties lazy if the DFG needs
        them. As we optimize this further we might need to teach the DFG to handle more lazy
        properties. I tried to do this for RegExp but found it to be very confusing. With typed
        arrays I got lucky.
        
        There is also a somewhat more powerful construct called LazyClassStructure. We often
        need to keep around the structure of some standard JS class, like Date. We also need to
        make sure that the constructor ends up in the global object's property table. And we
        often need to keep the original value of the constructor for ourselves. In this case, we
        want to make sure that the creation of the structure-prototype-constructor constellation
        is atomic. We don't want code to start looking at the structure if it points to a
        prototype that doesn't have its "constructor" property set yet, for example.
        LazyClassStructure solves this by abstracting that whole initialization. You provide the
        callback that allocates everything, since we are super inconsistent about the way we
        initialize things, but LazyClassStructure establishes the workflow and helps you not
        mess up.
        
        Finally, the new static hashtable attributes allow for all of this to work with the JS
        property table:
        
        PropertyCallback: if you use this attribute, the second column in the table should be
        the name of a function to call to initialize this property. This is useful for things
        like the Math property. The Math object turns out to be very expensive to allocate.
        Delaying its allocation is super easy with the PropertyCallback attribute.
        
        CellProperty: with this attribute the second column should be a C++ field name like
        JSGlobalObject::m_evalErrorConstructor. The static hashtable will grab the offset of
        this property, and when it needs to be initialized, Lookup will assume you have a
        LazyProperty<JSCell> and call its get() method. It will initialize the property to
        whatever get() returned. Note that it's legal to cast a LazyProperty<Anything> to
        LazyProperty<JSCell> for the purpose of calling get() because the get() method will just
        call whatever callback function pointer is encoded in the property and it does not need
        to know anything about what type that callback will instantiate.
        
        ClassStructure: with this attribute the second column should be a C++ field name. The
        static hashtable will initialize the property by treating the field as a
        LazyClassStructure and it will call get(). LazyClassStructure completely owns the whole
        initialization workflow, so Lookup assumes that when LazyClassStructure::get() returns,
        the property in question will already be set. By convention, we have LazyClassStructure
        initialize the property with a pointer to the constructor, since that's how all of our
        classes work: "globalObject.Date" points to the DateConstructor.
        
        This is a 2x speed-up in JSGlobalObject initialization time in a microbenchmark that
        calls our C API. This is a 1% speed-up on SunSpider and JSRegress.

        * API/JSCallbackFunction.cpp:
        (JSC::JSCallbackFunction::create):
        * API/ObjCCallbackFunction.h:
        (JSC::ObjCCallbackFunction::impl):
        * API/ObjCCallbackFunction.mm:
        (JSC::ObjCCallbackFunction::ObjCCallbackFunction):
        (JSC::ObjCCallbackFunction::create):
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * create_hash_table:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::set):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::originalArrayStructure):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::getOwnPropertySlot):
        (JSC::ClonedArguments::materializeSpecials):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::visitChildren):
        (JSC::InternalFunction::name):
        (JSC::InternalFunction::calculatedDisplayName):
        (JSC::InternalFunction::createSubclassStructure):
        * runtime/InternalFunction.h:
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::finishCreation):
        (JSC::JSBoundFunction::visitChildren):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGlobalObject.cpp:
        (JSC::createProxyProperty):
        (JSC::createJSONProperty):
        (JSC::createMathProperty):
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::stringPrototypeChainIsSane):
        (JSC::JSGlobalObject::resetPrototype):
        (JSC::JSGlobalObject::visitChildren):
        (JSC::JSGlobalObject::toThis):
        (JSC::JSGlobalObject::getOwnPropertySlot):
        (JSC::JSGlobalObject::createThrowTypeError): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::objectConstructor):
        (JSC::JSGlobalObject::promiseConstructor):
        (JSC::JSGlobalObject::internalPromiseConstructor):
        (JSC::JSGlobalObject::evalErrorConstructor):
        (JSC::JSGlobalObject::rangeErrorConstructor):
        (JSC::JSGlobalObject::referenceErrorConstructor):
        (JSC::JSGlobalObject::syntaxErrorConstructor):
        (JSC::JSGlobalObject::typeErrorConstructor):
        (JSC::JSGlobalObject::URIErrorConstructor):
        (JSC::JSGlobalObject::nullGetterFunction):
        (JSC::JSGlobalObject::nullSetterFunction):
        (JSC::JSGlobalObject::callFunction):
        (JSC::JSGlobalObject::applyFunction):
        (JSC::JSGlobalObject::definePropertyFunction):
        (JSC::JSGlobalObject::arrayProtoValuesFunction):
        (JSC::JSGlobalObject::initializePromiseFunction):
        (JSC::JSGlobalObject::newPromiseCapabilityFunction):
        (JSC::JSGlobalObject::functionProtoHasInstanceSymbolFunction):
        (JSC::JSGlobalObject::regExpProtoExecFunction):
        (JSC::JSGlobalObject::regExpProtoSymbolReplaceFunction):
        (JSC::JSGlobalObject::regExpProtoGlobalGetter):
        (JSC::JSGlobalObject::regExpProtoUnicodeGetter):
        (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
        (JSC::JSGlobalObject::moduleLoader):
        (JSC::JSGlobalObject::objectPrototype):
        (JSC::JSGlobalObject::functionPrototype):
        (JSC::JSGlobalObject::arrayPrototype):
        (JSC::JSGlobalObject::booleanPrototype):
        (JSC::JSGlobalObject::stringPrototype):
        (JSC::JSGlobalObject::symbolPrototype):
        (JSC::JSGlobalObject::numberPrototype):
        (JSC::JSGlobalObject::datePrototype):
        (JSC::JSGlobalObject::regExpPrototype):
        (JSC::JSGlobalObject::errorPrototype):
        (JSC::JSGlobalObject::iteratorPrototype):
        (JSC::JSGlobalObject::generatorFunctionPrototype):
        (JSC::JSGlobalObject::generatorPrototype):
        (JSC::JSGlobalObject::debuggerScopeStructure):
        (JSC::JSGlobalObject::withScopeStructure):
        (JSC::JSGlobalObject::strictEvalActivationStructure):
        (JSC::JSGlobalObject::activationStructure):
        (JSC::JSGlobalObject::moduleEnvironmentStructure):
        (JSC::JSGlobalObject::directArgumentsStructure):
        (JSC::JSGlobalObject::scopedArgumentsStructure):
        (JSC::JSGlobalObject::clonedArgumentsStructure):
        (JSC::JSGlobalObject::isOriginalArrayStructure):
        (JSC::JSGlobalObject::booleanObjectStructure):
        (JSC::JSGlobalObject::callbackConstructorStructure):
        (JSC::JSGlobalObject::callbackFunctionStructure):
        (JSC::JSGlobalObject::callbackObjectStructure):
        (JSC::JSGlobalObject::propertyNameIteratorStructure):
        (JSC::JSGlobalObject::objcCallbackFunctionStructure):
        (JSC::JSGlobalObject::objcWrapperObjectStructure):
        (JSC::JSGlobalObject::dateStructure):
        (JSC::JSGlobalObject::nullPrototypeObjectStructure):
        (JSC::JSGlobalObject::errorStructure):
        (JSC::JSGlobalObject::calleeStructure):
        (JSC::JSGlobalObject::functionStructure):
        (JSC::JSGlobalObject::boundFunctionStructure):
        (JSC::JSGlobalObject::boundSlotBaseFunctionStructure):
        (JSC::JSGlobalObject::getterSetterStructure):
        (JSC::JSGlobalObject::nativeStdFunctionStructure):
        (JSC::JSGlobalObject::namedFunctionStructure):
        (JSC::JSGlobalObject::functionNameOffset):
        (JSC::JSGlobalObject::numberObjectStructure):
        (JSC::JSGlobalObject::privateNameStructure):
        (JSC::JSGlobalObject::mapStructure):
        (JSC::JSGlobalObject::regExpStructure):
        (JSC::JSGlobalObject::generatorFunctionStructure):
        (JSC::JSGlobalObject::setStructure):
        (JSC::JSGlobalObject::stringObjectStructure):
        (JSC::JSGlobalObject::symbolObjectStructure):
        (JSC::JSGlobalObject::iteratorResultObjectStructure):
        (JSC::JSGlobalObject::lazyTypedArrayStructure):
        (JSC::JSGlobalObject::typedArrayStructure):
        (JSC::JSGlobalObject::typedArrayStructureConcurrently):
        (JSC::JSGlobalObject::isOriginalTypedArrayStructure):
        (JSC::JSGlobalObject::typedArrayConstructor):
        (JSC::JSGlobalObject::actualPointerFor):
        (JSC::JSGlobalObject::internalFunctionStructure): Deleted.
        * runtime/JSNativeStdFunction.cpp:
        (JSC::JSNativeStdFunction::create):
        * runtime/JSWithScope.cpp:
        (JSC::JSWithScope::create):
        (JSC::JSWithScope::visitChildren):
        (JSC::JSWithScope::createStructure):
        (JSC::JSWithScope::JSWithScope):
        * runtime/JSWithScope.h:
        (JSC::JSWithScope::object):
        (JSC::JSWithScope::create): Deleted.
        (JSC::JSWithScope::createStructure): Deleted.
        (JSC::JSWithScope::JSWithScope): Deleted.
        * runtime/LazyClassStructure.cpp: Added.
        (JSC::LazyClassStructure::Initializer::Initializer):
        (JSC::LazyClassStructure::Initializer::setPrototype):
        (JSC::LazyClassStructure::Initializer::setStructure):
        (JSC::LazyClassStructure::Initializer::setConstructor):
        (JSC::LazyClassStructure::visit):
        (JSC::LazyClassStructure::dump):
        * runtime/LazyClassStructure.h: Added.
        (JSC::LazyClassStructure::LazyClassStructure):
        (JSC::LazyClassStructure::get):
        (JSC::LazyClassStructure::prototype):
        (JSC::LazyClassStructure::constructor):
        (JSC::LazyClassStructure::getConcurrently):
        (JSC::LazyClassStructure::prototypeConcurrently):
        (JSC::LazyClassStructure::constructorConcurrently):
        * runtime/LazyClassStructureInlines.h: Added.
        (JSC::LazyClassStructure::initLater):
        * runtime/LazyProperty.h: Added.
        (JSC::LazyProperty::Initializer::Initializer):
        (JSC::LazyProperty::LazyProperty):
        (JSC::LazyProperty::get):
        (JSC::LazyProperty::getConcurrently):
        * runtime/LazyPropertyInlines.h: Added.
        (JSC::LazyProperty<ElementType>::Initializer<OwnerType>::set):
        (JSC::LazyProperty<ElementType>::initLater):
        (JSC::LazyProperty<ElementType>::setMayBeNull):
        (JSC::LazyProperty<ElementType>::set):
        (JSC::LazyProperty<ElementType>::visit):
        (JSC::LazyProperty<ElementType>::dump):
        (JSC::LazyProperty<ElementType>::callFunc):
        * runtime/Lookup.cpp:
        (JSC::setUpStaticFunctionSlot):
        * runtime/Lookup.h:
        (JSC::HashTableValue::function):
        (JSC::HashTableValue::functionLength):
        (JSC::HashTableValue::propertyGetter):
        (JSC::HashTableValue::propertyPutter):
        (JSC::HashTableValue::accessorGetter):
        (JSC::HashTableValue::accessorSetter):
        (JSC::HashTableValue::constantInteger):
        (JSC::HashTableValue::lexerValue):
        (JSC::HashTableValue::lazyCellPropertyOffset):
        (JSC::HashTableValue::lazyClassStructureOffset):
        (JSC::HashTableValue::lazyPropertyCallback):
        (JSC::getStaticPropertySlot):
        (JSC::getStaticValueSlot):
        (JSC::reifyStaticProperty):
        * runtime/PropertySlot.h:
        * runtime/TypedArrayType.h:

2016-05-03  Per Arne Vollan  <peavo@outlook.com>

        [Win] Remove Windows XP Compatibility Requirements
        https://bugs.webkit.org/show_bug.cgi?id=152899

        Reviewed by Brent Fulgham.

        Windows XP is not supported anymore, we can remove workarounds.

        * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp:
        (enableTerminationOnHeapCorruption):

2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: console.assert should do far less work when the assertion is true
        https://bugs.webkit.org/show_bug.cgi?id=157297
        <rdar://problem/26056556>

        Reviewed by Timothy Hatcher.

        * runtime/ConsoleClient.h:
        * runtime/ConsoleClient.cpp:
        (JSC::ConsoleClient::assertion):
        (JSC::ConsoleClient::assertCondition): Deleted.
        Rename, now that this will only get called when the assertion failed.

        * runtime/ConsoleObject.cpp:
        (JSC::consoleProtoFuncAssert):
        Avoid doing any work if the assertion succeeded.

2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>

        Unreviewed follow-up testapi fix after r200355.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        Revert back to non-enumerable. This matches our older behavior,
        we can decide to make this Enumerable later if needed.

2016-05-02  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Reflect.toString() should be [object Object] not [object Reflect]
        https://bugs.webkit.org/show_bug.cgi?id=157288

        Reviewed by Darin Adler.

        * runtime/ReflectObject.cpp:
        * tests/stress/reflect.js: Added.

2016-05-02  Jon Davis  <jond@apple.com>

        Add Resource Timing entry to the Feature Status page.
        https://bugs.webkit.org/show_bug.cgi?id=157285

        Reviewed by Timothy Hatcher.

        * features.json:

2016-05-02  Joseph Pecoraro  <pecoraro@apple.com>

        Make console a namespace object (like Math/JSON), allowing functions to be called unbound
        https://bugs.webkit.org/show_bug.cgi?id=157286
        <rdar://problem/26052830>

        Reviewed by Timothy Hatcher.

        This changes `console` to be a global namespace object, like `Math` and `JSON`.
        It just holds a bunch of functions, that can be used on their own, unbound.
        For example, `[1,2,3].forEach(console.log)` and `var log = console.log; log(1)`
        used to throw exceptions and now do not.

        Previously console was an Object/Prototype pair, so functions were on
        ConsolePrototype (console.__proto__.log) and they needed to be called
        Console objects as the `this` value. Now, `console` is just a standard
        object with a bunch of functions. Since there is no console prototype the
        functions can be passed around and called as expected and they will
        just do the right thing.

        For compatability with other browsers, `console` was made enumerable
        on the global object.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        Add new files and remove old files.

        * runtime/CommonIdentifiers.h:
        Add "console".

        * runtime/ConsoleObject.cpp: Renamed from Source/JavaScriptCore/runtime/ConsolePrototype.cpp.
        (JSC::ConsoleObject::ConsoleObject):
        (JSC::ConsoleObject::finishCreation):
        (JSC::valueToStringWithUndefinedOrNullCheck):
        (JSC::consoleLogWithLevel):
        (JSC::consoleProtoFuncDebug):
        (JSC::consoleProtoFuncError):
        (JSC::consoleProtoFuncLog):
        (JSC::consoleProtoFuncInfo):
        (JSC::consoleProtoFuncWarn):
        (JSC::consoleProtoFuncClear):
        (JSC::consoleProtoFuncDir):
        (JSC::consoleProtoFuncDirXML):
        (JSC::consoleProtoFuncTable):
        (JSC::consoleProtoFuncTrace):
        (JSC::consoleProtoFuncAssert):
        (JSC::consoleProtoFuncCount):
        (JSC::consoleProtoFuncProfile):
        (JSC::consoleProtoFuncProfileEnd):
        (JSC::consoleProtoFuncTakeHeapSnapshot):
        (JSC::consoleProtoFuncTime):
        (JSC::consoleProtoFuncTimeEnd):
        (JSC::consoleProtoFuncTimeStamp):
        (JSC::consoleProtoFuncGroup):
        (JSC::consoleProtoFuncGroupCollapsed):
        (JSC::consoleProtoFuncGroupEnd):
        Console functions no longer need to check if the this object is
        a Console object. They will always just work now.

        * runtime/MathObject.cpp:
        * runtime/MathObject.h:
        * runtime/ConsoleObject.h: Renamed from Source/JavaScriptCore/runtime/ConsolePrototype.h.
        (JSC::ConsoleObject::create):
        (JSC::ConsoleObject::createStructure):
        ConsoleObject is a basic object like MathObject.

        * runtime/JSConsole.cpp: Removed.
        * runtime/JSConsole.h: Removed.
        * runtime/JSGlobalObject.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        Remove JSConsole / ConsolePrototype in favor of the single ConsoleObject.

2016-05-02  Per Arne Vollan  <peavo@outlook.com>

        [Win] Clean up annoying compiler warnings
        https://bugs.webkit.org/show_bug.cgi?id=149813

        Reviewed by Alex Christensen.

        * bytecode/PropertyCondition.cpp:
        (JSC::PropertyCondition::isWatchableWhenValid):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * inspector/InspectorBackendDispatcher.cpp:
        (Inspector::BackendDispatcher::sendPendingErrors):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileOpCall):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createWithInlineFrame):
        * runtime/Error.cpp:
        (JSC::addErrorInfoAndGetBytecodeOffset):
        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormat::initializeNumberFormat):
        * runtime/JSObject.cpp:
        (JSC::JSObject::heapSnapshot):
        (JSC::callToPrimitiveFunction):
        * runtime/RegExpPrototype.cpp:
        (JSC::flagsString):
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::StackFrame::functionStartColumn):

2016-05-02  Keith Miller  <keith_miller@apple.com>

        ToThis should be able to be eliminated in Constant Folding
        https://bugs.webkit.org/show_bug.cgi?id=157213

        Reviewed by Saam Barati.

        This patch enables eliminating the ToThis value when we have abstract interpreter
        indicates the node is not needed. Since there are Objects that override their
        ToThis behavior we first check if we can eliminate the node by looking at its
        speculated type. If the function is in strict mode then we can eliminate ToThis as
        long as the speculated type is not SpecObjectOther since that contains objects
        that may set OverridesToThis. If the function is not in strict mode then we can
        eliminate ToThis as long is the speculated type is an object that is not SpecObjectOther.

        If we can't eliminate with type information we can still eliminate the ToThis node with
        the proven structure set. When ToThis only sees structures that do not set OverridesToThis
        it can be eliminated. Additionally, if the function is in strict mode then we can eliminate
        ToThis as long as all only the object structures don't set OverridesToThis.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::isToThisAnIdentity):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupToThis):
        * tests/stress/to-this-global-object.js: Added.
        (test):
        (test2):
        (get for):

2016-05-01  Skachkov Oleksandr  <gskachkov@gmail.com>

        Class contructor and methods shouldn't have "arguments" and "caller"
        https://bugs.webkit.org/show_bug.cgi?id=144238

        Reviewed by Ryosuke Niwa.

        Added TypeError that is raised in case of access to properties 'arguments' or 'caller'
        of constructor or method of class. Actually TypeError already raised for most cases, except
        case with undeclared constructor e. g. 
        class A {}
        (new A).constructor.caller 
        (new A).constructor.arguments

        * runtime/JSFunction.cpp:
        (JSC::getThrowTypeErrorGetterSetter):
        (JSC::JSFunction::getOwnPropertySlot):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createThrowTypeErrorArgumentsAndCaller):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerGetterSetter):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncThrowTypeErrorArgumentsAndCaller):
        * runtime/JSGlobalObjectFunctions.h:

2016-05-02  Yoav Weiss  <yoav@yoav.ws>

        Move ResourceTiming behind a runtime flag
        https://bugs.webkit.org/show_bug.cgi?id=157133

        Reviewed by Alex Christensen.

        * runtime/CommonIdentifiers.h: Added PerformanceEntry, PerformanceEntryList and PerformanceResourceTiming as property names.

2016-05-02  Yusuke Suzuki  <utatane.tea@gmail.com>

        Assertion failure for bound function with custom prototype and Reflect.construct
        https://bugs.webkit.org/show_bug.cgi?id=157081

        Reviewed by Saam Barati.

        We ensured `newTarget != exec->callee()`. However, it does not mean `newTarget.get("prototype") != exec->callee()->get("prototype")`.
        When the given `prototype` is the same to `baseStructure->sotredPrototype()`, it is unnecessary to create a new structure from this
        baseStructure.

        * bytecode/InternalFunctionAllocationProfile.h:
        (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
        * tests/stress/custom-prototype-may-be-same-to-original-one.js: Added.
        (shouldBe):
        (boundFunction):

2016-04-30  Konstantin Tokarev  <annulen@yandex.ru>

        Guard ObjC-specific code in Heap.cpp with USE(FOUNDATION)
        https://bugs.webkit.org/show_bug.cgi?id=157236

        Reviewed by Darin Adler.

        This also fixes build with GCC 4.8 which does not provide
        __has_include.

        * heap/Heap.cpp:

2016-04-30  Yusuke Suzuki  <utatane.tea@gmail.com>

        Assertion failure for destructuring assignment with new.target and unary operator
        https://bugs.webkit.org/show_bug.cgi?id=157149

        Reviewed by Saam Barati.

        The caller of parseDefaultValueForDestructuringPattern() should propagate errors.
        And this patch also cleans up createSavePoint and createSavePointForError; introducing SavePointWithError.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseSourceElements):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        Add propagateErorr() for parseDefaultValueForDestructuringPattern.

        (JSC::Parser<LexerType>::parseAssignmentExpression):
        * parser/Parser.h:
        (JSC::Parser::restoreLexerState):
        (JSC::Parser::internalSaveState):
        (JSC::Parser::createSavePointForError):
        (JSC::Parser::createSavePoint):
        (JSC::Parser::internalRestoreState):
        (JSC::Parser::restoreSavePointWithError):
        (JSC::Parser::restoreSavePoint):
        * tests/stress/default-value-parsing-should-propagate-error.js: Added.
        (testSyntaxError):
        (testSyntaxError.f):

2016-04-28  Darin Adler  <darin@apple.com>

        First step in using "enum class" instead of "String" for enumerations in DOM
        https://bugs.webkit.org/show_bug.cgi?id=157163

        Reviewed by Chris Dumez.

        * runtime/JSString.h:
        (JSC::jsStringWithCache): Deleted unneeded overload for AtomicString.

2016-04-29  Benjamin Poulain  <bpoulain@apple.com>

        [JSC][ARMv7S] Arithmetic module results change when tiering up to DFG
        https://bugs.webkit.org/show_bug.cgi?id=157217
        rdar://problem/24733432

        Reviewed by Mark Lam.

        ARMv7's fmod() returns less accurate results than an integer division.
        Since we have integer div on ARMv7s, the results start changing when
        we reach DFG.

        In this patch, I change our fmod slow path to behave like the fast path
        on ARMv7s.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithMod):
        (JSC::DFG::fmodAsDFGOperation): Deleted.
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/MathCommon.cpp:
        (JSC::isStrictInt32):
        * runtime/MathCommon.h:

2016-04-29  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Issues inspecting the inspector, pausing on breakpoints causes content to not load
        https://bugs.webkit.org/show_bug.cgi?id=157198
        <rdar://problem/26011049>

        Reviewed by Timothy Hatcher.

        * inspector/InspectorBackendDispatcher.cpp:
        (Inspector::BackendDispatcher::sendResponse):
        While auditing the code, add a WTFMove.

2016-04-29  Mark Lam  <mark.lam@apple.com>

        Make RegExp.prototype.test spec compliant.
        https://bugs.webkit.org/show_bug.cgi?id=155862

        Reviewed by Saam Barati.

        * builtins/RegExpPrototype.js:
        (intrinsic.RegExpTestIntrinsic.test):

        * create_hash_table:
        - Delete obsoleted code.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addToGraph):
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        - We now have 2 intrinsics for RegExp.prototype.test:
          RegExpTestIntrinsic and RegExpTestFastIntrinsic.

          RegExpTestIntrinsic maps to the entry at the top of the builtin ES6
          RegExp.prototype.test.
          RegExpTestFastIntrinsic maps to the fast path in the builtin ES6
          RegExp.prototype.test.

          Both will end up using the RegExpTest DFG node to implement the fast path
          of RegExp.prototype.test.  RegExpTestIntrinsic will have some additional checks
          before the RegExpTest node.  Those checks are for speculating that it is ok for
          us to take the fast path.

        * runtime/CommonIdentifiers.h:
        * runtime/Intrinsic.h:

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        - Added the regExpTestFast function.
        - Also fixed the parameter length on 2 other functions that were erroneous.

        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        (JSC::regExpProtoFuncTestFast):
        (JSC::regExpProtoFuncTest): Deleted.
        * runtime/RegExpPrototype.h:
        * tests/es6.yaml:

2016-04-29  Benjamin Poulain  <benjamin@webkit.org>

        Extend math-pow-stable-results.js to get more information about the failure

        * tests/stress/math-pow-stable-results.js:

2016-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>

        Assertion failure for exception in "prototype" property getter and Reflect.construct
        https://bugs.webkit.org/show_bug.cgi?id=157084

        Reviewed by Mark Lam.

        InternalFunction::createSubclassStrucuture may throw exceptions because it performs [[Get]] to
        look up the "prototype" object. The current assertion is invalid.
        We also found that Object constructor is not aware of new.target. This is filed[1].

        [1]: https://bugs.webkit.org/show_bug.cgi?id=157196

        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::createSubclassStructure):
        * tests/stress/create-subclass-structure-may-throw-exception-when-getting-prototype.js: Added.
        (shouldThrow):
        (bf):

2016-04-29  Commit Queue  <commit-queue@webkit.org>

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

        This change broke the Mac CMake build and its LayoutTest is
        failing and/or flaky on all platforms (Requested by ryanhaddad
        on #webkit).

        Reverted changeset:

        "Move ResourceTiming behind a runtime flag"
        https://bugs.webkit.org/show_bug.cgi?id=157133
        http://trac.webkit.org/changeset/200232

2016-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] RegExp.prototype.@@replace should use @isObject instead of `instanceof` for object guard
        https://bugs.webkit.org/show_bug.cgi?id=157124

        Reviewed by Keith Miller.

        Use @isObject instead of `instanceof @Object`.
        The `instanceof` check is not enough to check Object Type.
        This fix itself is the same to r199647, and this patch is for RegExp.prototype.@@replace.

        * builtins/RegExpPrototype.js:
        (replace):
        * tests/stress/regexp-replace-in-other-realm-should-work.js: Added.
        (shouldBe):
        * tests/stress/regexp-replace-should-work-with-objects-not-inheriting-object-prototype.js: Added.
        (shouldBe):
        (regexp.exec):

2016-04-29  Yoav Weiss  <yoav@yoav.ws>

        Move ResourceTiming behind a runtime flag
        https://bugs.webkit.org/show_bug.cgi?id=157133

        Reviewed by Alex Christensen.

        * runtime/CommonIdentifiers.h: Added PerformanceEntry, PerformanceEntryList and PerformanceResourceTiming as property names.

2016-04-28  Joseph Pecoraro  <pecoraro@apple.com>

        Remove unused bool parameter in CodeCache::getGlobalCodeBlock
        https://bugs.webkit.org/show_bug.cgi?id=157156

        Reviewed by Mark Lam.

        The bool parameter appears to be isArrowFunctionContext, but the method's
        contents just get that property from the Executable, so the parameter is
        unnecessary and unused.

        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        * runtime/CodeCache.h:
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::create):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createEvalCodeBlock):
        * runtime/JSGlobalObject.h:

2016-04-28  Caitlin Potter  <caitp@igalia.com>

        [JSC] re-implement String#padStart and String#padEnd in JavaScript
        https://bugs.webkit.org/show_bug.cgi?id=157146

        Reviewed by Saam Barati.

        * builtins/StringPrototype.js:
        (repeatCharactersSlowPath):
        (padStart):
        (padEnd):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation): Deleted.
        (JSC::repeatStringPattern): Deleted.
        (JSC::padString): Deleted.
        (JSC::stringProtoFuncPadEnd): Deleted.
        (JSC::stringProtoFuncPadStart): Deleted.

2016-04-28  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Tweak auto attach initialization on some platforms
        https://bugs.webkit.org/show_bug.cgi?id=157150
        <rdar://problem/21222045>

        Reviewed by Timothy Hatcher.

        * inspector/EventLoop.cpp:
        (Inspector::EventLoop::cycle):
        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):

2016-04-28  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Unify Math.pow() accross all tiers
        https://bugs.webkit.org/show_bug.cgi?id=157121

        Reviewed by Geoffrey Garen.

        My previous optimizations of DFG compile time have slowly
        regressed Sunspider's math-partial-sums.

        What is happenning is baseline used a thunk for Math.pow()
        that has a special case for an exponent of -0.5, while
        DFG/FTL have other special cases for other exponents.
        The faster we get to DFG, the less time we spend in that fast
        case for -0.5.

        While looking into this, I discovered some correctness issues. Baseline
        optimizes y=-0.5 by turning it into 1/sqrt(). DFG/FTL optimize constant
        y=0.5 by turning it into sqrt(). The problem is sqrt() behaves differently
        for -0 and -Infinity. With sqrt(), negative numbers are undefined,
        and the result is NaN. With pow(), they have a result.

        Something else that has bothered me for a while is that Math.pow()
        with the same arguments give you different results in LLINT, Baseline,
        and DFG/FTL. This seems a bit dangerous for numerical stability.

        With this patch, I unify the behaviors for all tiers while keeping
        the "special cases".

        We have pow() that is super slow, but most callers don't need the
        full power. We have:
        -pow() with an exponent between 0 and 1000 is a fast path implemented
         by multiplication only.
        -pow(x, 0.5) is sqrt with special checks for negative values.
        -pow(x, -0.5) is sqrt with special checks for negative values.

        The C++ implementation handles all those optimizations too. This ensure
        you get the same results from LLINT to FTL.

        The thunk is eliminated, it was producing incorrect results and only
        optimized Sunspider's partial-sums.

        DFG gets the optimized integer, 0.5 and -0.5 cases since those are important
        for somewhat-hot code. DFG falls back to the C++ code for any non-obvious case.

        FTL gets the full C++ implementation inlined in B3. B3 knows how to eliminate
        all the dead cases so you get the best if your code is hot enough to reach FTL.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): Deleted.
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToArithSqrt): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::compileArithPowIntegerFastPath):
        (JSC::DFG::SpeculativeJIT::compileArithPow):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArithPow):
        * jit/ThunkGenerators.cpp:
        (JSC::powThunkGenerator): Deleted.
        * jit/ThunkGenerators.h:
        * runtime/MathCommon.cpp:
        (JSC::operationMathPow):
        * runtime/MathCommon.h:
        * runtime/VM.cpp:
        (JSC::thunkGeneratorForIntrinsic): Deleted.
        * tests/stress/math-pow-stable-results.js: Added.
        Getting consistent results when tiering up is new.
        This test verify that results always remains the same as LLINT.

        * tests/stress/math-pow-with-constants.js:
        (testPowUsedAsSqrt):
        (powUsedAsOneOverSqrt):
        (testPowUsedAsOneOverSqrt):
        (powUsedAsSquare):
        (testPowUsedAsSquare):

2016-04-28  Mark Lam  <mark.lam@apple.com>

        DebuggerScope::className() should not assert scope->isValid().
        https://bugs.webkit.org/show_bug.cgi?id=157143

        Reviewed by Keith Miller.

        DebuggerScope::className() should not assert scope->isValid() because the
        TypeProfiler logs objects it encounters, and may indirectly call
        JSObject::calculatedClassName() on those objects later, thereby calling
        DebuggerScope::className() on an invalidated DebuggerScope.

        The existing handling in DebuggerScope::className() for an invalidated scope
        (that returns a null string) is sufficient.

        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::className):

2016-04-28  Caitlin Potter  <caitp@igalia.com>

        [JSC] implement spec changes for String#padStart and String#padEnd
        https://bugs.webkit.org/show_bug.cgi?id=157139

        Reviewed by Keith Miller.

        Previously, if the fill string was the empty string, it was treated as a
        single U+0020 SPACE character. Now, if this occurs, the original string
        is returned instead.

        Change was discussed at TC39 in March [1], and is reflected in new
        test262 tests for the feature.

        [1] https://github.com/tc39/tc39-notes/blob/master/es7/2016-03/march-29.md#stringprototypepadstartpadend

        * runtime/StringPrototype.cpp:
        (JSC::padString):
        * tests/es6/String.prototype_methods_String.prototype.padEnd.js:
        (TestFillerToString):
        (TestFillerEmptyString):
        * tests/es6/String.prototype_methods_String.prototype.padStart.js:
        (TestFillerToString):
        (TestFillerEmptyString):

2016-04-28  Skachkov Oleksandr  <gskachkov@gmail.com>

        Crash for non-static super property call in derived class constructor
        https://bugs.webkit.org/show_bug.cgi?id=157089

        Reviewed by Darin Adler.
       
        Added tdz check of the 'this' before access to the 'super' for FunctionCallBracketNode, 
        the same as it was done for FunctionCallDotNode.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionCallBracketNode::emitBytecode):

2016-04-27  Mark Lam  <mark.lam@apple.com>

        The GetterSetter structure needs a globalObject.
        https://bugs.webkit.org/show_bug.cgi?id=157120

        Reviewed by Filip Pizlo.

        In r199170: <http://trac.webkit.org/r199170>, GetterSetter was promoted from
        being a JSCell to a JSObject.  JSObject methods expect their structure to have a
        globalObject.  For example, see JSObject::calculatedClassName().  GetterSetter
        was previously using a singleton getterSetterStructure owned by the VM.  That
        singleton getterSetterStructure is not associated with any globalObjects.  As a
        result, JSObject::calculatedClassName() will run into a null globalObject when it
        is called on a GetterSetter object.

        This patch removes the VM singleton getterSetterStructure, and instead, creates
        a getterSetterStructure for each JSGlobalObject.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):
        * runtime/GetterSetter.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::functionStructure):
        (JSC::JSGlobalObject::boundFunctionStructure):
        (JSC::JSGlobalObject::boundSlotBaseFunctionStructure):
        (JSC::JSGlobalObject::getterSetterStructure):
        (JSC::JSGlobalObject::nativeStdFunctionStructure):
        (JSC::JSGlobalObject::namedFunctionStructure):
        (JSC::JSGlobalObject::functionNameOffset):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2016-04-27  Keith Miller  <keith_miller@apple.com>

        Unreviewed, Revert r199397 due to PLT regressions

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ArrayPrototype.js:
        (concatSlowPath): Deleted.
        (concat): Deleted.
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): Deleted.
        * bytecode/BytecodeIntrinsicRegistry.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall): Deleted.
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC): Deleted.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute): Deleted.
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::compileIsJSArray): Deleted.
        (JSC::DFG::SpeculativeJIT::compileIsArrayObject): Deleted.
        (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor): Deleted.
        (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation): Deleted.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Deleted.
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile): Deleted.
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayObject): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayConstructor): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::isArray): Deleted.
        * jit/JITOperations.h:
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionDataLogValue): Deleted.
        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
        * runtime/ArrayConstructor.h:
        (JSC::isArrayConstructor): Deleted.
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::arrayProtoFuncConcat):
        (JSC::arrayProtoPrivateFuncIsJSArray): Deleted.
        (JSC::moveElements): Deleted.
        (JSC::arrayProtoPrivateFuncConcatMemcpy): Deleted.
        (JSC::arrayProtoPrivateFuncAppendMemcpy): Deleted.
        * runtime/ArrayPrototype.h:
        * runtime/CommonIdentifiers.h:
        * runtime/Intrinsic.h:
        * runtime/JSArray.cpp:
        (JSC::JSArray::fastConcatWith):
        (JSC::JSArray::appendMemcpy): Deleted.
        * runtime/JSArray.h:
        (JSC::JSArray::fastConcatType):
        (JSC::JSArray::createStructure):
        (JSC::isJSArray):
        * runtime/JSArrayInlines.h: Removed.
        (JSC::JSArray::memCopyWithIndexingType): Deleted.
        (JSC::JSArray::canFastCopy): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSType.h:
        * runtime/ObjectConstructor.h:
        (JSC::constructObject): Deleted.
        * tests/es6.yaml:
        * tests/stress/array-concat-spread-object.js: Removed.
        (arrayEq): Deleted.
        * tests/stress/array-concat-spread-proxy-exception-check.js: Removed.
        (arrayEq): Deleted.
        * tests/stress/array-concat-spread-proxy.js: Removed.
        (arrayEq): Deleted.
        * tests/stress/array-concat-with-slow-indexingtypes.js: Removed.
        (arrayEq): Deleted.
        * tests/stress/array-species-config-array-constructor.js:

2016-04-27  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r200117): Crash in lowerDFGToB3::compileStringReplace()
        https://bugs.webkit.org/show_bug.cgi?id=157099

        Reviewed by Saam Barati.

        Given that the DFGFixupPhase could mark the edge of child2 as StringUse,
        we need to lower that edge appropriately.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):

2016-04-27  Mark Lam  <mark.lam@apple.com>

        Address feedback from https://bugs.webkit.org/show_bug.cgi?id=157048#c5.
        https://bugs.webkit.org/show_bug.cgi?id=157096

        Reviewed by Geoffrey Garen.

        1. Check for USE(APPLE_INTERNAL_SDK) instead of __has_include(<mach-o/dyld_priv.h>).
        2. Rename webkitFirstSDKVersionWithInitConstructorSupport to
           firstSDKVersionWithInitConstructorSupport.

        * API/JSWrapperMap.mm:
        (supportsInitMethodConstructors):

2016-04-27  Mark Lam  <mark.lam@apple.com>

        Restrict the availability of some JSC options to local debug builds only.
        https://bugs.webkit.org/show_bug.cgi?id=157058

        Reviewed by Geoffrey Garen.

        1. Each option will be given an availability flag.
        2. The functionOverrides and useDollarVM (along with its alias, enableDollarVM)
           will have "Restricted" availability.
        3. All other options will have “Normal” availability.
        4. Any options with "Restricted" availability will only be accessible if function
           allowRestrictedOptions() returns true.
        5. For now, allowRestrictedOptions() always returns false for release builds, and
           true for debug builds.

        If an option is "Restricted" and restricted options are not allowed, the VM will
        behave semantically as if that option does not exist at all:
        1. Option dumps will not show the option.
        2. Attempts to set the option will fail as if the option does not exist.

        Behind the scene, the option does exist, and is set to its default value
        (whatever that may be) once and only once on options initialization.

        * runtime/Options.cpp:
        (JSC::allowRestrictedOptions):
        (JSC::parse):
        (JSC::overrideOptionWithHeuristic):
        (JSC::Options::initialize):
        (JSC::Options::setOptionWithoutAlias):
        (JSC::Options::dumpOption):
        * runtime/Options.h:
        (JSC::Option::type):
        (JSC::Option::availability):
        (JSC::Option::isOverridden):

2016-04-27  Gavin Barraclough  <barraclough@apple.com>

        Enable separated heap by default on ios
        https://bugs.webkit.org/show_bug.cgi?id=156720
        <rdar://problem/25841790>

        Unreviewed rollout - caused memory regression.

        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

2016-04-27  Benjamin Poulain  <bpoulain@apple.com>

        Follow up for r200113 on 32bit

        I forgot to do the 32bit counterpart of r200113.
        The test fails on the bots.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2016-04-27  Alberto Garcia  <berto@igalia.com>

        [GTK] Fails to build randomly when generating LLIntDesiredOffsets.h
        https://bugs.webkit.org/show_bug.cgi?id=155427

        Reviewed by Carlos Garcia Campos.

        If the build directory contains the -I string, the script that
        generates LLIntDesiredOffsets.h will confuse it with an option to
        declare an include directory.

        In order to avoid that we should only use the arguments that start
        with -I when extracting the list of include directories, instead
        of using the ones that simply contain that string.

        * offlineasm/parser.rb:

2016-04-27  Saam barati  <sbarati@apple.com>

        JSC should have an option to allow global const redeclarations
        https://bugs.webkit.org/show_bug.cgi?id=157006

        Reviewed by Geoffrey Garen.

        This patch implements an option that dictates whether
        const redeclarations at the program level will throw.
        This option defaults to true but allows users of JSC
        to set it to false. This option is per VM. This is needed
        for backwards compatibility with our old const implementation.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionShadowChickenFunctionsOnStack):
        (functionSetGlobalConstRedeclarationShouldNotThrow):
        (functionReadline):
        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * runtime/JSGlobalLexicalEnvironment.cpp:
        (JSC::JSGlobalLexicalEnvironment::put):
        (JSC::JSGlobalLexicalEnvironment::isConstVariable):
        * runtime/JSGlobalLexicalEnvironment.h:
        (JSC::JSGlobalLexicalEnvironment::isEmpty):
        * runtime/VM.h:
        (JSC::VM::setGlobalConstRedeclarationShouldThrow):
        (JSC::VM::globalConstRedeclarationShouldThrow):
        * tests/stress/global-const-redeclaration-setting: Added.
        * tests/stress/global-const-redeclaration-setting-2.js: Added.
        (assert):
        * tests/stress/global-const-redeclaration-setting-3.js: Added.
        (assert):
        (catch):
        * tests/stress/global-const-redeclaration-setting-4.js: Added.
        (assert):
        (catch):
        * tests/stress/global-const-redeclaration-setting-5.js: Added.
        (assert):
        (catch):
        * tests/stress/global-const-redeclaration-setting.js: Added.
        (assert):
        * tests/stress/global-const-redeclaration-setting/first.js: Added.
        * tests/stress/global-const-redeclaration-setting/let.js: Added.
        * tests/stress/global-const-redeclaration-setting/second.js: Added.
        * tests/stress/global-const-redeclaration-setting/strict.js: Added.

2016-04-26  Michael Saboff  <msaboff@apple.com>

        [ES] Implement RegExp.prototype.@@replace and use it for String.prototype.replace
        https://bugs.webkit.org/show_bug.cgi?id=156562

        Reviewed by Filip Pizlo.

        Added builtins for String.prototype.replace as well as RegExp.prototype[Symbol.replace].

        The String.prototype.replace also has an intrinsic, StringPrototypeReplaceIntrinsic.
        This original intrinsic was copied to make StringPrototypeReplaceRegExpIntrinsic.
        The difference between the two intrinsics is that StringPrototypeReplaceIntrinsic has
        the same checks found in the new builtin hasObservableSideEffectsForStringReplace.
        We implement these primordial checks for StringPrototypeReplaceIntrinsic in two places.
        First, we do a trial check during ByteCode parsing time to see if the current
        RegExp.prototype properties have changed from the original.  If they have, we don't
        inline the intrinsic.  Later, in the fixup phase, we add nodes to the IR to emit the
        checks at runtime.

        The new intrinsic StringPrototypeReplaceRegExpIntrinsic is only available via the
        private @replaceUsingRegExp, which is called in the String.prototype.replace builtin.
        It is only called after hasObservableSideEffectsForStringReplace has been called

        Both of these intrinsics are needed, because the JS code containing String.replace() calls
        runs initially in the LLint and then the baseline JIT.  Even after the function tiers up
        to the DFG JIT, the inlining budget may not allow StringPrototypeReplaceIntrinsic to be inlined.
        Having StringPrototypeReplaceRegExpIntrinsic allows for the String.prototype.replace builtin to
        get reasonable performance before the other intrinsic is inlined or when it can't.

        * builtins/RegExpPrototype.js:
        (match):
        (getSubstitution):
        (replace):
        (search):
        (split):
        * builtins/StringPrototype.js:
        (repeat):
        (hasObservableSideEffectsForStringReplace):
        (intrinsic.StringPrototypeReplaceIntrinsic.replace):
        (localeCompare):
        New builtins for String.prototype.replace and RegExp.prototype[Symbol.replace].

        * bytecode/BytecodeIntrinsicRegistry.cpp:
        * bytecode/BytecodeIntrinsicRegistry.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupGetAndSetLocalsInBlock):
        (JSC::DFG::FixupPhase::tryAddStringReplacePrimordialChecks):
        (JSC::DFG::FixupPhase::checkArray):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::getRegExpPrototypeProperty):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::getRegExpPrototypeProperty):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        * runtime/CommonIdentifiers.h:
        * runtime/Intrinsic.h:
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::replace):
        (JSC::stringProtoFuncReplaceUsingRegExp):
        (JSC::stringProtoFuncReplaceUsingStringSearch):
        (JSC::operationStringProtoFuncReplaceGeneric):
        (JSC::stringProtoFuncReplace): Deleted.
        Added StringReplaceRegExp intrinsic.  Added checks for RegExp profiled arguments to StringReplace
        that mirror what is in hasObservableSideEffectsForStringReplace().  If we aren't able to add the
        checks, we OSR exit.  Add Graph::getPrimordialRegExpPrototypeProperty() as a helper to get the
        primordial values from RegExp.prototype.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Added @regExpPrototypeSymbolReplace and
        @hasObservableSideEffectsForStringReplace here instead og String.prototype so that we reduce the
        number of objects we have to traverse.

        * tests/es6.yaml: Changed expectations for the various replace related tests to passing.

        * tests/stress/regexp-replace-proxy.js:
        (assert):
        (let.getProxyNullExec.new.Proxy):
        (let.getSetProxyNullExec.new.Proxy):
        (get resetTracking):
        (let.getSetProxyMatches_comma.new.Proxy):
        (set get getSetProxyNullExec):
        (let.getSetProxyReplace_phoneNumber.new.Proxy):
        (set get getSetProxyMatches_comma):
        (let.getSetProxyReplaceUnicode_digit_nonGreedy.new.Proxy):
        (set get resetTracking):
        * tests/stress/string-replace-proxy.js:
        (assert):
        (let.getSetProxyReplace.new.Proxy.replace):
        New tests.

2016-04-26  Mark Lam  <mark.lam@apple.com>

        Gardening: speculative build fix.

        Not reviewed.

        * API/JSWrapperMap.mm:

2016-04-26  Mark Lam  <mark.lam@apple.com>

        Update the compatibility version check for the ObjC API's InitConstructorSupport to use dyld_get_program_sdk_version().
        https://bugs.webkit.org/show_bug.cgi?id=157048

        Reviewed by Geoffrey Garen.

        * API/JSWrapperMap.mm:
        (supportsInitMethodConstructors):
        (getJSExportProtocol):

2016-04-26  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] GetByVal on Undecided use its children before its OSR Exit
        https://bugs.webkit.org/show_bug.cgi?id=157046

        Reviewed by Mark Lam.

        Very silly bug: GetByVal on Undecided uses its children before
        the speculationCheck(). If we fail the speculation, we have already
        lost how to recover the values.

        The existing tests did not catch this because we tier up to B3
        before such Exits happen. B3 has explicit liveness and did not suffer
        from this bug.
        The new test has a smaller warmup to exercise the OSR Exit in DFG
        instead of FTL.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * tests/stress/get-by-val-on-undecided-out-of-bounds.js: Added.
        (string_appeared_here.opaqueGetByValKnownArray):

2016-04-26  Skachkov Oleksandr  <gskachkov@gmail.com>

        calling super() a second time in a constructor should throw
        https://bugs.webkit.org/show_bug.cgi?id=151113

        Reviewed by Saam Barati.

        Currently, our implementation checks if 'super()' was called in a constructor more
        than once and raises a RuntimeError before the second call. According to the spec
        we need to raise an error just after the second super() is finished and before
        the new 'this' is assigned https://esdiscuss.org/topic/duplicate-super-call-behaviour.
        To implement this behavior this patch adds a new op code, op_is_empty, that is used
        to check if 'this' is empty.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitIsEmpty):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionCallValueNode::emitBytecode):
        * 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:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsEmpty):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_empty):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_empty):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * tests/stress/class-syntax-double-constructor.js: Added.

2016-04-26  Mark Lam  <mark.lam@apple.com>

        Changed jsc options title to be more descriptive.
        https://bugs.webkit.org/show_bug.cgi?id=157036

        Reviewed by Joseph Pecoraro.

        Let the title for --dumpOptions be "Modified JSC runtime options:" since it only
        dumps overridden options.  The title for --options will remain "All JSC runtime
        options:" since it dumps all all options with verbose detail.

        * jsc.cpp:
        (CommandLine::parseArguments):

2016-04-26  Oliver Hunt  <oliver@apple.com>

        Enable separated heap by default on ios
        https://bugs.webkit.org/show_bug.cgi?id=156720

        Unreviewed roll-in of this change. There is only one
        additional allocation involved in this logic, and that
        is a duplicate mapping.

        Either our tools are not report real memory usage
        or this revision is not responsible for the regression.

        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

2016-04-26  Filip Pizlo  <fpizlo@apple.com>

        DFG backends shouldn't emit type checks at KnownBlah edges
        https://bugs.webkit.org/show_bug.cgi?id=157025

        Reviewed by Michael Saboff.
        
        This fixes a crash I found when browsing Bing maps with forceEagerCompilation. I include a
        100% repro test case.
        
        The issue is that our code still doesn't fully appreciate the devious implications of
        KnownBlah use kinds. Consider KnownCell for example. It means: "trust me, I know that this
        value will be a cell". You aren't required to provide a proof when you use KnownCell. Often,
        we use it as a result of a path-sensitive proof. The abstract interpreter is not
        path-sensitive, so AI will be absolutely sure that the KnownCell use might see a non-cell.
        This can lead to debug assertions (which this change removes) and it can lead to the backends
        emitting a type check. That type check can be pure evil if the node that has this edge does
        not have an exit origin. Such a node would have passed validation because the validater would
        have thought that the node cannot exit (after all, according to the IR semantics, there is no
        speculation at KnownCell).

        This comprehensively fixes the issue by recognizing that Foo(KnownCell:@x) means: I have
        already proved that by the time you start executing Foo, @x will already be a cell. I cannot
        tell you how I proved this but you can rely on it anyway. AI now takes advantage of this
        meaning and will always do filtering of KnownBlah edges regardless of whether the backend
        actually emits any type checks for those edges. Since the filtering runs before the backend,
        the backend will not emit any checks because it will know that the edge was already checked
        (by whatever mechanism we used when we made the edge KnownBlah).
        
        Note that it's good that we found this bug now. The DFG currently does very few
        sparse-conditional or path-sensitive optimizations, but it will probably do more in the
        future. The bug happens because GetByOffset and friends can achieve path-sensitive proofs via
        watchpoints on the inferred type. Normally, AI can follow along with this proof. But in the
        example program, and on Bing maps, we would GCSE one GetByOffset with another that had a
        weaker proven type. That turned out to be completely sound - between the two GetByOffset's
        there was a Branch to null check it. The inferred type of the second GetByOffset ended up
        knowing that it cannot be null because null only occurred in some structures but not others.
        If we added more sparse-conditional stuff to Branch, then AI would know how to follow along
        with the proof but it would also create more situations where we'd have a path-sensitive
        proof. So, it's good that we're now getting this right.

        * dfg/DFGAbstractInterpreter.h:
        (JSC::DFG::AbstractInterpreter::filterEdgeByUse):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEdges):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeKnownEdgeTypes):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::verifyEdge):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        * tests/stress/path-sensitive-known-cell-crash.js: Added.
        (bar):
        (foo):

2016-04-26  Gavin Barraclough  <barraclough@apple.com>

        Enable separated heap by default on ios
        https://bugs.webkit.org/show_bug.cgi?id=156720

        Unreviewed rollout - caused memory regression.

        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

2016-04-26  Joseph Pecoraro  <pecoraro@apple.com>

        Improve jsc --help and making sampling options
        https://bugs.webkit.org/show_bug.cgi?id=157015

        Reviewed by Saam Barati.

        Simplify sampling options to be easier to remember:

          * --reportSamplingProfilerData => --sample
          * --samplingProfilerTimingInterval => --sampleInterval

        Update the --help to mention --sample, and restore the behavior of
        --options outputing all possible options so you can discover which
        options are available.        

        * jsc.cpp:
        (printUsageStatement):
        (CommandLine::parseArguments):
        Improve help and modify option dumping.

        * runtime/Options.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::SamplingProfiler):
        Rename the sampling interval option.

2016-04-26  Commit Queue  <commit-queue@webkit.org>

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

         It brokes the debug build (Requested by gskachkov on
        #webkit).

        Reverted changeset:

        "calling super() a second time in a constructor should throw"
        https://bugs.webkit.org/show_bug.cgi?id=151113
        http://trac.webkit.org/changeset/200083

2016-04-26  Skachkov Oleksandr  <gskachkov@gmail.com>

        calling super() a second time in a constructor should throw
        https://bugs.webkit.org/show_bug.cgi?id=151113

        Reviewed by Saam Barati.

        Currently, our implementation checks if 'super()' was called in a constructor more 
        than once and raises a RuntimeError before the second call. According to the spec 
        we need to raise an error just after the second super() is finished and before 
        the new 'this' is assigned https://esdiscuss.org/topic/duplicate-super-call-behaviour. 
        To implement this behavior this patch adds a new op code, op_is_empty, that is used 
        to check if 'this' is empty.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitIsEmpty):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionCallValueNode::emitBytecode):
        * 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/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsEmpty):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_empty):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_empty):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * tests/stress/class-syntax-double-constructor.js: Added.

2016-04-25  Ryosuke Niwa  <rniwa@webkit.org>

        Remove the build flag for template elements
        https://bugs.webkit.org/show_bug.cgi?id=157022

        Reviewed by Daniel Bates.

        * Configurations/FeatureDefines.xcconfig:

2016-04-25  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Constant folding of UInt32ToNumber is incorrect
        https://bugs.webkit.org/show_bug.cgi?id=157011
        rdar://problem/25769641

        Reviewed by Geoffrey Garen.

        UInt32ToNumber should return the unsigned 32bit value of
        its child. The abstract interpreter fails to do that when handling
        Int52.

        None of the tests caught that because the bytecode generator already
        fold the operation if given a constant. If the constant is not visible
        from the bytecode generator (for example because it comes from an inlined call),
        then the abstract interpreter folding was producing invalid results.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * tests/stress/uint32-to-number-constant-folding.js: Added.
        (uint32ToNumberMinusOne):
        (uint32ToNumberMinusOnePlusInteger):
        (inlineMinusOne):
        (uint32ToNumberOnHiddenMinusOne):
        (uint32ToNumberOnHiddenMinusOnePlusInteger):
        (inlineLargeNegativeNumber1):
        (inlineLargeNegativeNumber2):
        (inlineLargeNegativeNumber3):
        (uint32ToNumberOnHiddenLargeNegativeNumber1):
        (uint32ToNumberOnHiddenLargeNegativeNumber2):
        (uint32ToNumberOnHiddenLargeNegativeNumber3):

2016-04-25  Fujii Hironori  <Hironori.Fujii@sony.com>

        Heap corruption is detected when destructing JSGlobalObject
        https://bugs.webkit.org/show_bug.cgi?id=156831

        Reviewed by Mark Lam.

        WebKit uses CRT static library on Windows.  Each copy of the CRT
        library has its own heap manager, allocating memory in one CRT
        library and passing the pointer across a DLL boundary to be freed
        by a different copy of the CRT library is a potential cause for
        heap corruption.

          Potential Errors Passing CRT Objects Across DLL Boundaries
          <https://msdn.microsoft.com/en-us/library/ms235460(v=vs.140).aspx>

        JSGlobalObject::createRareDataIfNeeded is inlined but
        JSGlobalObject::~JSGlobalObject is not.  Then, the heap of
        allocating JSGlobalObjectRareData is WebKit.dll, but deallocating
        JavaScriptCore.dll.  Adding WTF_MAKE_FAST_ALLOCATED to
        JSGlobalObjectRareData ensures heap consistency of it.  WTF::Lock
        also needs WTF_MAKE_FAST_ALLOCATED because it is allocated from
        the inlined constructor of JSGlobalObjectRareData.

        Test: fast/dom/insertedIntoDocument-iframe.html

        * runtime/JSGlobalObject.h:
        Add WTF_MAKE_FAST_ALLOCATED to JSGlobalObjectRareData.

2016-04-25  Michael Saboff  <msaboff@apple.com>

        Crash using @tryGetById in DFG
        https://bugs.webkit.org/show_bug.cgi?id=156992

        Reviewed by Filip Pizlo.

        We need to spill live registers when compiling TryGetById in DFG.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileTryGetById):
        * tests/stress/regress-156992.js: New test.
        (tryMultipleGetByIds):
        (test):

2016-04-25  Saam barati  <sbarati@apple.com>

        We don't have to parse a function's parameters every time if the function is in the source provider cache
        https://bugs.webkit.org/show_bug.cgi?id=156943

        Reviewed by Filip Pizlo.

        This patch makes a few changes to make parsing inner functions
        faster.

        First, we were always parsing an inner function's parameter
        list using the templatized TreeBuiler. This means if our parent scope
        was building an AST, we ended up building AST nodes for the inner
        function's parameter list even though these nodes would go unused.
        This patch fixes that to *always* build an inner function's parameter
        list using the SyntaxChecker. (Note that this is consistent now with
        always building an inner function's body with a SyntaxChecker.)

        Second, we were always parsing an inner function's parameter list
        even if we had that function saved in the source provider cache.
        I've fixed that bug and made it so that we skip over the parsing 
        of a function's parameter list when it's in the source provider
        cache. We could probably enhance this in the future to skip
        over the entirety of a function starting at the "function"
        keyword or any other start of the function (depending on
        the function type: arrow function, method, etc).

        This patch also renames a few fields. First, I fixed a typo
        from "tocken" => "token" for a few field names. Secondly,
        I renamed a field that was called 'bodyStartColumn' to 
        'parametersStartColumn' because the field really held the
        parameter list's start column.

        I'm benchmarking this as a 1.5-2% octane/jquery speedup
        on a 15" MBP.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFunctionExpr):
        (JSC::ASTBuilder::createMethodDefinition):
        (JSC::ASTBuilder::createArrowFunctionExpr):
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createFuncDeclStatement):
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::lex):
        * parser/Lexer.h:
        (JSC::Lexer::currentPosition):
        (JSC::Lexer::positionBeforeLastNewline):
        (JSC::Lexer::lastTokenLocation):
        (JSC::Lexer::setLastLineNumber):
        (JSC::Lexer::lastLineNumber):
        (JSC::Lexer::prevTerminator):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
        (JSC::Parser<LexerType>::parseFunctionBody):
        (JSC::stringForFunctionMode):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/Parser.h:
        (JSC::Scope::usedVariablesContains):
        (JSC::Scope::forEachUsedVariable):
        (JSC::Scope::useVariable):
        (JSC::Scope::copyCapturedVariablesToVector):
        (JSC::Scope::fillParametersForSourceProviderCache):
        (JSC::Scope::restoreFromSourceProviderCache):
        * parser/ParserFunctionInfo.h:
        * parser/SourceProviderCacheItem.h:
        (JSC::SourceProviderCacheItem::endFunctionToken):
        (JSC::SourceProviderCacheItem::usedVariables):
        (JSC::SourceProviderCacheItem::SourceProviderCacheItem):

2016-04-25  Mark Lam  <mark.lam@apple.com>

        Renaming SpecInt32, SpecInt52, MachineInt to SpecInt32Only, SpecInt52Only, AnyInt.
        https://bugs.webkit.org/show_bug.cgi?id=156941

        Reviewed by Filip Pizlo.

        While looking at https://bugs.webkit.org/show_bug.cgi?id=153431, it was decided
        that SpecInt32Only, SpecInt52Only, and AnyInt would be better names for
        SpecInt32, SpecInt52, and MachineInt.  Let's do a bulk rename.

        This is only a renaming patch, and deletion of a piece of unused code.  There are
        no semantic changes.

        * bindings/ScriptValue.cpp:
        (Inspector::jsToInspectorValue):
        * bytecode/SpeculatedType.cpp:
        (JSC::dumpSpeculation):
        (JSC::speculationToAbbreviatedString):
        (JSC::speculationFromValue):
        (JSC::leastUpperBoundOfStrictlyEquivalentSpeculations):
        (JSC::typeOfDoubleNegation):
        (JSC::typeOfDoubleRounding):
        * bytecode/SpeculatedType.h:
        (JSC::isInt32Speculation):
        (JSC::isInt32OrBooleanSpeculation):
        (JSC::isInt32SpeculationForArithmetic):
        (JSC::isInt32OrBooleanSpeculationForArithmetic):
        (JSC::isInt32OrBooleanSpeculationExpectingDefined):
        (JSC::isInt52Speculation):
        (JSC::isAnyIntSpeculation):
        (JSC::isAnyIntAsDoubleSpeculation):
        (JSC::isDoubleRealSpeculation):
        (JSC::isMachineIntSpeculation): Deleted.
        (JSC::isInt52AsDoubleSpeculation): Deleted.
        (JSC::isIntegerSpeculation): Deleted.
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::set):
        (JSC::DFG::AbstractValue::fixTypeForRepresentation):
        (JSC::DFG::AbstractValue::checkConsistency):
        (JSC::DFG::AbstractValue::resultType):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::validateType):
        * dfg/DFGArgumentsUtilities.cpp:
        (JSC::DFG::emitCodeToGetArgumentsArrayLength):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupToThis):
        (JSC::DFG::FixupPhase::observeUseKindOnNode):
        (JSC::DFG::FixupPhase::fixIntConvertingEdge):
        (JSC::DFG::FixupPhase::fixIntOrBooleanEdge):
        (JSC::DFG::FixupPhase::fixDoubleOrBooleanEdge):
        (JSC::DFG::FixupPhase::truncateConstantToInt32):
        (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):
        (JSC::DFG::FixupPhase::prependGetArrayLength):
        (JSC::DFG::FixupPhase::fixupChecksInBlock):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addShouldSpeculateInt32):
        (JSC::DFG::Graph::addShouldSpeculateAnyInt):
        (JSC::DFG::Graph::binaryArithShouldSpeculateInt32):
        (JSC::DFG::Graph::binaryArithShouldSpeculateAnyInt):
        (JSC::DFG::Graph::unaryArithShouldSpeculateInt32):
        (JSC::DFG::Graph::unaryArithShouldSpeculateAnyInt):
        (JSC::DFG::Graph::addShouldSpeculateMachineInt): Deleted.
        (JSC::DFG::Graph::binaryArithShouldSpeculateMachineInt): Deleted.
        (JSC::DFG::Graph::unaryArithShouldSpeculateMachineInt): Deleted.
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::noticeOSREntry):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::convertToIdentityOn):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::asNumber):
        (JSC::DFG::Node::isAnyIntConstant):
        (JSC::DFG::Node::asAnyInt):
        (JSC::DFG::Node::isBooleanConstant):
        (JSC::DFG::Node::shouldSpeculateInt32OrBooleanExpectingDefined):
        (JSC::DFG::Node::shouldSpeculateAnyInt):
        (JSC::DFG::Node::shouldSpeculateDouble):
        (JSC::DFG::Node::shouldSpeculateNumber):
        (JSC::DFG::Node::isMachineIntConstant): Deleted.
        (JSC::DFG::Node::asMachineInt): Deleted.
        (JSC::DFG::Node::shouldSpeculateMachineInt): Deleted.
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::OSREntryData::dumpInContext):
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSREntry.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSSALoweringPhase.cpp:
        (JSC::DFG::SSALoweringPhase::handleNode):
        (JSC::DFG::SSALoweringPhase::lowerBoundsCheck):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::operator()):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::silentFill):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compileArithAdd):
        (JSC::DFG::SpeculativeJIT::compileArithSub):
        (JSC::DFG::SpeculativeJIT::compileArithNegate):
        (JSC::DFG::SpeculativeJIT::speculateInt32):
        (JSC::DFG::SpeculativeJIT::speculateNumber):
        (JSC::DFG::SpeculativeJIT::speculateMisc):
        (JSC::DFG::SpeculativeJIT::speculate):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::spill):
        (JSC::DFG::SpeculativeJIT::isKnownInteger):
        (JSC::DFG::SpeculativeJIT::isKnownCell):
        (JSC::DFG::SpeculativeJIT::isKnownNotInteger):
        (JSC::DFG::SpeculativeJIT::isKnownNotNumber):
        (JSC::DFG::SpeculativeJIT::isKnownNotCell):
        (JSC::DFG::SpeculativeJIT::isKnownNotOther):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::blessBoolean):
        (JSC::DFG::SpeculativeJIT::convertAnyInt):
        (JSC::DFG::SpeculativeJIT::speculateAnyInt):
        (JSC::DFG::SpeculativeJIT::speculateDoubleRepAnyInt):
        (JSC::DFG::SpeculativeJIT::convertMachineInt): Deleted.
        (JSC::DFG::SpeculativeJIT::speculateMachineInt): Deleted.
        (JSC::DFG::SpeculativeJIT::speculateDoubleRepMachineInt): Deleted.
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        (JSC::DFG::isNumerical):
        (JSC::DFG::isDouble):
        * dfg/DFGValidate.cpp:
        * dfg/DFGVariableAccessData.cpp:
        (JSC::DFG::VariableAccessData::makePredictionForDoubleFormat):
        (JSC::DFG::VariableAccessData::couldRepresentInt52Impl):
        (JSC::DFG::VariableAccessData::flushFormat):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileInt52Constant):
        (JSC::FTL::DFG::LowerDFGToB3::compileInt52Rep):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
        (JSC::FTL::DFG::LowerDFGToB3::lowInt32):
        (JSC::FTL::DFG::LowerDFGToB3::strictInt52ToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::isInt32):
        (JSC::FTL::DFG::LowerDFGToB3::isNotInt32):
        (JSC::FTL::DFG::LowerDFGToB3::jsValueToStrictInt52):
        (JSC::FTL::DFG::LowerDFGToB3::doubleToStrictInt52):
        (JSC::FTL::DFG::LowerDFGToB3::speculate):
        (JSC::FTL::DFG::LowerDFGToB3::speculateCellOrOther):
        (JSC::FTL::DFG::LowerDFGToB3::speculateAnyInt):
        (JSC::FTL::DFG::LowerDFGToB3::speculateDoubleRepReal):
        (JSC::FTL::DFG::LowerDFGToB3::speculateDoubleRepAnyInt):
        (JSC::FTL::DFG::LowerDFGToB3::speculateMachineInt): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::speculateDoubleRepMachineInt): Deleted.
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_profile_type):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_profile_type):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::isInt52):
        (JSC::JSValue::isAnyInt):
        (JSC::JSValue::asAnyInt):
        (JSC::JSValue::isMachineInt): Deleted.
        (JSC::JSValue::asMachineInt): Deleted.
        * runtime/RuntimeType.cpp:
        (JSC::runtimeTypeForValue):
        (JSC::runtimeTypeAsString):
        * runtime/RuntimeType.h:
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::dumpTypes):
        (JSC::TypeSet::displayName):
        (JSC::TypeSet::inspectorTypeSet):
        (JSC::TypeSet::toJSONString):

2016-04-24  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Optimize JSON.parse string fast path
        https://bugs.webkit.org/show_bug.cgi?id=156953

        Reviewed by Mark Lam.

        This patch further optimizes the string parsing fast path.
        Previously, we generated the WTF::String to hold the ownership of the token's string.
        And always copied the token in LiteralParser side.
        Instead, we hold the ownership of the token String by the StringBuilder in LiteralParser::Lexer,
        and remove the processing in the string parsing fast path.
        This patch gives us stable 1 - 2.5% improvement in Kraken json-parse-financial.

                                       Baseline                  Modified

        json-parse-financial        41.383+-0.248      ^      40.894+-0.189         ^ definitely 1.0120x faster

        * runtime/LiteralParser.cpp:
        (JSC::LiteralParser<CharType>::tryJSONPParse):
        (JSC::LiteralParser<CharType>::Lexer::lex):
        (JSC::LiteralParser<CharType>::Lexer::lexStringSlow):
        (JSC::LiteralParser<CharType>::parse):
        (JSC::LiteralParser<CharType>::Lexer::lexString): Deleted.
        * runtime/LiteralParser.h:
        (JSC::LiteralParser::tryLiteralParse):
        (JSC::LiteralParser::Lexer::currentToken):
        (JSC::LiteralParser::Lexer::LiteralParserTokenPtr::LiteralParserTokenPtr):
        (JSC::LiteralParser::Lexer::LiteralParserTokenPtr::operator->):

2016-04-24  Filip Pizlo <fpizlo@apple.com> and Andy VanWagoner <thetalecrafter@gmail.com>

        [INTL] Implement String.prototype.localeCompare in ECMA-402
        https://bugs.webkit.org/show_bug.cgi?id=147607

        Reviewed by Darin Adler.
        
        Part of this change is just rolling 194394 back in.
        
        The other part is making that not a regression on CDjs. Other than the fact that it uses
        bound functions, the problem with this new localeCompare implementation is that it uses
        the arguments object. It uses it in a way that *seems* like ArgumentsEliminationPhase
        ought to handle, but to my surprise it didn't:
        
        - If we have a ForceExit GetByVal on the arguments object, we would previously assume that
          it escaped. That's false since we just exit at ForceExit. On the other hand we probably
          should be pruning unreachable paths before we get here, but that's a separate issue. I
          don't want to play with phase order right now.
        
        - If we have a OutOfBounds GetByVal on the arguments object, then the best that would
          previously happen is that we'd compile it into an in-bounds arguments access. That's quite
          bad, as Andy's localeCompare illustrates: it uses out-of-bounds access on the arguments
          object to detect if an argument was passed. This change introduces an OutOfBounds version
          of GetMyArgumentByVal for this purpose.
        
        This change required registering sane chain watchpoints. In the process, I noticed that the
        old way of doing it had a race condition: we might register watchpoints for the structure
        that had become insane. This change introduces a double-checking idiom that I believe works
        because once the structure becomes insane it can't go back to sane and watchpoints
        registration already involves executing the hardest possible fences.

        * builtins/StringPrototype.js:
        (repeat):
        (localeCompare):
        (search):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::refine):
        * 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/DFGNodeType.h:
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
        * ftl/FTLTypedPointer.h:
        (JSC::FTL::TypedPointer::TypedPointer):
        (JSC::FTL::TypedPointer::operator bool):
        (JSC::FTL::TypedPointer::heap):
        (JSC::FTL::TypedPointer::operator!): Deleted.
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):

2016-04-23  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, unbreak cloop.

        * runtime/VM.cpp:
        (JSC::VM::getHostFunction):

2016-04-22  Filip Pizlo  <fpizlo@apple.com>

        Speed up bound functions a bit
        https://bugs.webkit.org/show_bug.cgi?id=156889

        Reviewed by Saam Barati.
        
        Bound functions are hard to optimize because JSC doesn't have a good notion of non-JS code
        that does JS-ey things like make JS calls. What I mean by "non-JS code" is code that did not
        originate from JS source. A bound function does a highly polymorphic call to the target
        stored in the JSBoundFunction. Prior to this change, we represented it as native code that
        used the generic native->JS call API. That's not cheap.
        
        We could model bound functions using a builtin, but it's not clear that this would be easy
        to grok, since so much of the code would have to access special parts of the JSBoundFunction
        type. Doing it that way might solve the performance problems but it would mean extra work to
        arrange for the builtin to have speedy access to the call target, the bound this, and the
        bound arguments. Also, optimizing bound functions that way would mean that bound function
        performance would be gated on the performance of a bunch of other things in our system. For
        example, we'd want this polymorphic call to be handled like the funnel that it is: if we're
        compiling the bound function's outgoing call with no context then we should compile it as
        fully polymorphic but we can let it assume basic sanity like that the callee is a real
        function; but if we're compiling the call with any amount of calling context then we want to
        use normal call IC's.
        
        Since the builtin path wouldn't lead to a simpler patch and since I think that the VM will
        benefit in the long run from using custom handling for bound functions, I kept the native
        code and just added Intrinsic/thunk support.
        
        This just adds an Intrinsic for bound function calls where the JSBoundFunction targets a
        JSFunction instance and has no bound arguments (only bound this). This intrinsic is
        currently only implemented as a thunk and not yet recognized by the DFG bytecode parser.

        I needed to loosen some restrictions to do this. For one, I was really tired of our bad use
        of ENABLE(JIT) conditionals, which made it so that any serious client of Intrinsics would
        have to have #ifdefs. Really what should happen is that if the JIT is not enabled then we
        just ignore intrinsics. Also, the code was previously assuming that having a native
        constructor and knowing the Intrinsic for your native call were mutually exclusive. This
        change makes it possible to have a native executable that has a custom function, custom
        constructor, and an Intrinsic.
        
        This is a >4x speed-up on bound function calls with no bound arguments.

        In the future, we should teach the DFG Intrinsic handling to deal with bound functions and
        we should teach the inliner (and ByteCodeParser::handleCall() in general) how to deal with
        the function call inside the bound function. That would be super awesome.

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::timesPtr):
        (JSC::AbstractMacroAssembler::Address::withOffset):
        (JSC::AbstractMacroAssembler::BaseIndex::BaseIndex):
        (JSC::MacroAssemblerType>::Address::indexedBy):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::storeCell):
        (JSC::AssemblyHelpers::loadCell):
        (JSC::AssemblyHelpers::storeValue):
        (JSC::AssemblyHelpers::emitSaveCalleeSaves):
        (JSC::AssemblyHelpers::emitSaveThenMaterializeTagRegisters):
        (JSC::AssemblyHelpers::emitRestoreCalleeSaves):
        (JSC::AssemblyHelpers::emitRestoreSavedTagRegisters):
        (JSC::AssemblyHelpers::copyCalleeSavesToVMCalleeSavesBuffer):
        * jit/JITThunks.cpp:
        (JSC::JITThunks::ctiNativeTailCall):
        (JSC::JITThunks::ctiNativeTailCallWithoutSavedTags):
        (JSC::JITThunks::ctiStub):
        (JSC::JITThunks::hostFunctionStub):
        (JSC::JITThunks::clearHostFunctionStubs):
        * jit/JITThunks.h:
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::callDoubleToDoublePreservingReturn):
        (JSC::SpecializedThunkJIT::tagReturnAsInt32):
        (JSC::SpecializedThunkJIT::emitSaveThenMaterializeTagRegisters): Deleted.
        (JSC::SpecializedThunkJIT::emitRestoreSavedTagRegisters): Deleted.
        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):
        (JSC::nativeForGenerator):
        (JSC::nativeCallGenerator):
        (JSC::nativeTailCallGenerator):
        (JSC::nativeTailCallWithoutSavedTagsGenerator):
        (JSC::nativeConstructGenerator):
        (JSC::randomThunkGenerator):
        (JSC::boundThisNoArgsFunctionCallGenerator):
        * jit/ThunkGenerators.h:
        * runtime/Executable.cpp:
        (JSC::NativeExecutable::create):
        (JSC::NativeExecutable::destroy):
        (JSC::NativeExecutable::createStructure):
        (JSC::NativeExecutable::finishCreation):
        (JSC::NativeExecutable::NativeExecutable):
        (JSC::ScriptExecutable::ScriptExecutable):
        * runtime/Executable.h:
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncBind):
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorPrototypeGetterCompare):
        * runtime/Intrinsic.h:
        * runtime/JSBoundFunction.cpp:
        (JSC::boundThisNoArgsFunctionCall):
        (JSC::boundFunctionCall):
        (JSC::boundThisNoArgsFunctionConstruct):
        (JSC::boundFunctionConstruct):
        (JSC::getBoundFunctionStructure):
        (JSC::JSBoundFunction::create):
        (JSC::JSBoundFunction::customHasInstance):
        (JSC::JSBoundFunction::JSBoundFunction):
        * runtime/JSBoundFunction.h:
        (JSC::JSBoundFunction::targetFunction):
        (JSC::JSBoundFunction::boundThis):
        (JSC::JSBoundFunction::boundArgs):
        (JSC::JSBoundFunction::createStructure):
        (JSC::JSBoundFunction::offsetOfTargetFunction):
        (JSC::JSBoundFunction::offsetOfBoundThis):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::lookUpOrCreateNativeExecutable):
        (JSC::JSFunction::create):
        * runtime/VM.cpp:
        (JSC::thunkGeneratorForIntrinsic):
        (JSC::VM::getHostFunction):
        * runtime/VM.h:
        (JSC::VM::getCTIStub):
        (JSC::VM::exceptionOffset):

2016-04-22  Joonghun Park  <jh718.park@samsung.com>

        [JSC] Fix build break since r199866
        https://bugs.webkit.org/show_bug.cgi?id=156892

        Reviewed by Darin Adler.

        * runtime/MathCommon.cpp: Follow up to r199913. Remove 'include cmath' in cpp file.

2016-04-22  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Optimize number parsing and string parsing in LiteralParser
        https://bugs.webkit.org/show_bug.cgi?id=156896

        Reviewed by Mark Lam.

        This patch aim to improve JSON.parse performance. Major 2 optimizations are included.

        1. Change `double result` to `int32_t result` in integer parsing case.
        We already have the optimized path for integer parsing, when it's digits are less than 10.
        At that case, the maximum number is 999999999, and the minimum number is -99999999.
        The both are in range of Int32. So We can use int32_t for accumulation instead of double.

        2. Add the string parsing fast / slow cases.
        We add the fast case for string parsing, which does not include any escape sequences.

        Both optimizations improve Kraken json-parse-financial, roughly 3.5 - 4.5%.

        json-parse-financial        49.128+-1.589             46.979+-0.912           might be 1.0457x faster

        * runtime/LiteralParser.cpp:
        (JSC::isJSONWhiteSpace):
        (JSC::isSafeStringCharacter):
        (JSC::LiteralParser<CharType>::Lexer::lexString):
        (JSC::LiteralParser<CharType>::Lexer::lexStringSlow):
        (JSC::LiteralParser<CharType>::Lexer::lexNumber):
        * runtime/LiteralParser.h:

2016-04-22  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Source directives lost when using Function constructor repeatedly
        https://bugs.webkit.org/show_bug.cgi?id=156863
        <rdar://problem/25861064>

        Reviewed by Geoffrey Garen.

        Source directives (sourceURL and sourceMappingURL) are normally accessed through
        the SourceProvider and normally set when the script is parsed. However, when a
        CodeCache lookup skips parsing, the new SourceProvider never gets the directives
        (sourceURL/sourceMappingURL). This patch stores the directives on the UnlinkedCodeBlock
        and UnlinkedFunctionExecutable when entering the cache, and copies to the new providers
        when the cache is used.

        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::sourceURLDirective):
        (JSC::UnlinkedCodeBlock::sourceMappingURLDirective):
        (JSC::UnlinkedCodeBlock::setSourceURLDirective):
        (JSC::UnlinkedCodeBlock::setSourceMappingURLDirective):
        * bytecode/UnlinkedFunctionExecutable.h:
        * parser/SourceProvider.h:
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        Store directives on the unlinked code block / executable when adding
        to the cache, so they can be used to update new providers when the
        cache gets used.

        * runtime/JSGlobalObject.cpp:
        Add needed header after CodeCache header cleanup.

2016-04-22  Mark Lam  <mark.lam@apple.com>

        javascript jit bug affecting Google Maps.
        https://bugs.webkit.org/show_bug.cgi?id=153431

        Reviewed by Filip Pizlo.

        The issue was due to the abstract interpreter wrongly marking the type of the
        value read from the Uint3Array as SpecInt52, which precludes it from being an
        Int32.  This proves to be false, and the generated code failed to handle the case
        where the read value is actually an Int32.

        The fix is to have the abstract interpreter use SpecMachineInt instead of
        SpecInt52.

        * bytecode/SpeculatedType.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2016-04-22  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] PredictionPropagation should not be in the top 5 heaviest phases
        https://bugs.webkit.org/show_bug.cgi?id=156891

        Reviewed by Mark Lam.

        In DFG, PredictionPropagation is often way too high in profiles.
        It is a simple phase, it should not be that hot.

        Most of the time is spent accessing memory. This patch attempts
        to reduce that.

        First, propagate() is split in processInvariants() and propagates().
        The step processInvariants() sets all the types for nodes for which
        the type does not depends on other nodes.

        Adding processInvariants() lowers two hotspot inside PredictionPropagation:
        speculationFromValue() and setPrediction().

        Next, to avoid touching all the nodes at every operation, we keep
        track of the nodes that actually need propagate().
        The vector m_dependentNodes keeps the list of those nodes and propagate()
        only need to process them at each phase.

        This is a smaller gain because growing m_dependentNodes negates
        some of the gains.

        On 3d-cube, this moves PredictionPropagation from fifth position
        to ninth. A lot of the remaining overhead is caused by double-voting
        and cannot be fixed by moving stuff around.

        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagateToFixpoint): Deleted.
        (JSC::DFG::PredictionPropagationPhase::propagate): Deleted.
        (JSC::DFG::PredictionPropagationPhase::propagateForward): Deleted.
        (JSC::DFG::PredictionPropagationPhase::propagateBackward): Deleted.
        (JSC::DFG::PredictionPropagationPhase::doDoubleVoting): Deleted.
        (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): Deleted.
        (JSC::DFG::PredictionPropagationPhase::propagateThroughArgumentPositions): Deleted.

2016-04-22  Geoffrey Garen  <ggaren@apple.com>

        super should be available in object literals
        https://bugs.webkit.org/show_bug.cgi?id=156933

        Reviewed by Saam Barati.

        When we originally implemented classes, super seemed to be a class-only
        feature. But the final spec says it's available in object literals too.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode): Having 'super' and being a class
        property are no longer synonymous, so we track two separate variables.

        (JSC::PropertyListNode::emitPutConstantProperty): Being inside the super
        branch no longer guarantees that you're a class property, so we decide
        our attributes and our function name dynamically.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createArrowFunctionExpr):
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createArguments):
        (JSC::ASTBuilder::createArgumentsList):
        (JSC::ASTBuilder::createProperty):
        (JSC::ASTBuilder::createPropertyList): Pass through state to indicate
        whether we're a class property, since we can't infer it from 'super'
        anymore.

        * parser/NodeConstructors.h:
        (JSC::PropertyNode::PropertyNode): See ASTBuilder.h.

        * parser/Nodes.h:
        (JSC::PropertyNode::expressionName):
        (JSC::PropertyNode::name):
        (JSC::PropertyNode::type):
        (JSC::PropertyNode::needsSuperBinding):
        (JSC::PropertyNode::isClassProperty):
        (JSC::PropertyNode::putType): See ASTBuilder.h.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parseGetterSetter):
        (JSC::Parser<LexerType>::parseMemberExpression): I made these error
        messages generic because it is no longer practical to say concise things
        about the list of places you can use super.

        * parser/Parser.h:

        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createArgumentsList):
        (JSC::SyntaxChecker::createProperty):
        (JSC::SyntaxChecker::appendExportSpecifier):
        (JSC::SyntaxChecker::appendConstDecl):
        (JSC::SyntaxChecker::createGetterOrSetterProperty): Updated for
        interface change.

        * tests/stress/generator-with-super.js:
        (test):
        * tests/stress/modules-syntax-error.js:
        * tests/stress/super-in-lexical-scope.js:
        (testSyntaxError):
        (testSyntaxError.test):
        * tests/stress/tagged-templates-syntax.js: Updated for error message
        changes. See Parser.cpp.

2016-04-22  Filip Pizlo  <fpizlo@apple.com>

        ASSERT(m_stack.last().isTailDeleted) at ShadowChicken.cpp:127 inspecting the inspector
        https://bugs.webkit.org/show_bug.cgi?id=156930

        Reviewed by Joseph Pecoraro.
        
        The loop that prunes the stack from the top should preserve the invariant that the top frame
        cannot be tail-deleted.

        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::update):

2016-04-22  Benjamin Poulain  <benjamin@webkit.org>

        Attempt to fix the CLoop after r199866

        * runtime/MathCommon.h:

2016-04-22  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Integer Multiply of a number by itself does not need negative zero support
        https://bugs.webkit.org/show_bug.cgi?id=156895

        Reviewed by Saam Barati.

        You cannot produce negative zero by squaring an integer.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithMul):
        Minor codegen fixes:
        -Use the right form of multiply for ARM.
        -Use a sign-extended 32bit immediates, that's the one with fast forms
         in the MacroAssembler.

2016-04-21  Darin Adler  <darin@apple.com>

        Follow-on to the build fix.

        * runtime/MathCommon.h: Use the C++ std namespace version of the
        frexp function too.

2016-04-21  Joonghun Park  <jh718.park@samsung.com>

        [JSC] Fix build break since r199866. Unreviewed.
        https://bugs.webkit.org/show_bug.cgi?id=156892

        * runtime/MathCommon.h: Add namespace std to isnormal invoking.

2016-04-21  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add primitive String support to compare operators
        https://bugs.webkit.org/show_bug.cgi?id=156783

        Reviewed by Geoffrey Garen.

        Just the basics.
        We should eventually inline some of the simplest cases.

        This is a 2% improvement on Longspider. It is unfortunately neutral
        for Sunspider on my machine because most of the comparison are from
        baseline.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compare):
        (JSC::DFG::SpeculativeJIT::compileStringCompare):
        (JSC::DFG::SpeculativeJIT::compileStringIdentCompare):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareLess):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareLessEq):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareGreater):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareGreaterEq):
        (JSC::FTL::DFG::LowerDFGToB3::compare):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::callWithoutSideEffects):
        * jit/JITOperations.h:
        * tests/stress/string-compare.js: Added.
        (makeRope):
        (makeString):
        (let.operator.of.operators.eval.compareStringIdent):
        (let.operator.of.operators.compareStringString):
        (let.operator.of.operators.compareStringIdentString):
        (let.operator.of.operators.compareStringStringIdent):
        (let.operator.of.operators.let.left.of.typeCases.let.right.of.typeCases.eval):

2016-04-21  Benjamin Poulain  <bpoulain@webkit.org>

        [JSC] Commute FDiv-by-constant into FMul-by-reciprocal when it is safe
        https://bugs.webkit.org/show_bug.cgi?id=156871

        Reviewed by Filip Pizlo.

        FMul is significantly faster than FDiv.
        For example, on Haswell, FMul has a latency of 5, a throughput of 1
        while FDiv has latency 10-24, throughput 8-18.

        Fortunately for us, Sunspider and Kraken have plenty of division
        by a simple power of 2 constant. Those are just exponent operations
        and can be easily reversed to use FMul instead of FDiv.

        LLVM does something similar in InstCombine.

        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * jit/JITDivGenerator.cpp:
        (JSC::JITDivGenerator::loadOperand):
        (JSC::JITDivGenerator::generateFastPath):
        * jit/SnippetOperand.h:
        (JSC::SnippetOperand::asConstNumber):
        * runtime/MathCommon.h:
        (JSC::safeReciprocalForDivByConst):
        * tests/stress/floating-point-div-to-mul.js: Added.
        (opaqueDivBy2):
        (opaqueDivBy3):
        (opaqueDivBy4):
        (opaqueDivBySafeMaxMinusOne):
        (opaqueDivBySafeMax):
        (opaqueDivBySafeMaxPlusOne):
        (opaqueDivBySafeMin):
        (opaqueDivBySafeMinMinusOne):
        (i.catch):
        (i.result.opaqueDivBySafeMin.valueOf):

2016-04-21  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Improve the absThunkGenerator() for 64bit
        https://bugs.webkit.org/show_bug.cgi?id=156888

        Reviewed by Michael Saboff.

        A few tests spend a lot of time in this abs() with double argument.

        This patch adds custom handling for the JSValue64 representation.
        In particular:
        -Do not load the value twice. Unbox the GPR if it is not an Int32.
        -Deal with IntMin inline instead of falling back to the C function call.
        -Box the values ourself to avoid a duplicate function tail and return.

        * jit/ThunkGenerators.cpp:
        (JSC::absThunkGenerator):

2016-04-21  Saam barati  <sbarati@apple.com>

        LLInt CallSiteIndex off by 1
        https://bugs.webkit.org/show_bug.cgi?id=156886

        Reviewed by Benjamin Poulain.

        I think was done for historical reasons but isn't needed anymore.

        * llint/LLIntSlowPaths.cpp:

2016-04-21  Keith Miller  <keith_miller@apple.com>

        FTL should handle exceptions in operationInOptimize
        https://bugs.webkit.org/show_bug.cgi?id=156885

        Reviewed by Michael Saboff.

        For some reasone we didn't handle any exceptions in "in" when we called
        operationInOptimize in the FTL.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpAssumingJITType):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):
        * ftl/FTLPatchpointExceptionHandle.h: Add comments explaining which
        function to use for different exception types.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionNoFTL):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::ScriptExecutable):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::setNeverFTLOptimize):
        (JSC::ScriptExecutable::neverFTLOptimize):
        * tests/stress/in-ftl-exception-check.js: Added.
        (foo):
        (bar):
        (catch):

2016-04-21  Filip Pizlo  <fpizlo@apple.com>

        JSC virtual call thunk shouldn't do a structure->classInfo lookup
        https://bugs.webkit.org/show_bug.cgi?id=156874

        Reviewed by Keith Miller.
        
        This lookup was unnecessary because we can just test the inlined type field.

        But also, this meant that we were exempting JSBoundFunction from the virtual call optimization.
        That's pretty bad.

        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):

2016-04-21  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: sourceMappingURL not loaded in generated script
        https://bugs.webkit.org/show_bug.cgi?id=156022
        <rdar://problem/25438595>

        Reviewed by Geoffrey Garen.

        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
        Synthetic CallFrames for native code will not have script identifiers.

        * inspector/ScriptCallFrame.cpp:
        (Inspector::ScriptCallFrame::ScriptCallFrame):
        (Inspector::ScriptCallFrame::isEqual):
        (Inspector::ScriptCallFrame::buildInspectorObject):
        * inspector/ScriptCallFrame.h:
        * inspector/protocol/Console.json:
        Include the script identifier in ScriptCallFrame so we can correlate this
        to the exactly script, even if there isn't a URL. The Script may have a
        sourceURL, so the Web Inspector frontend may decide to show / link to it.

        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::CreateScriptCallStackFunctor::operator()):
        (Inspector::createScriptCallStackFromException):
        Include SourceID when we have it.

        * interpreter/Interpreter.cpp:
        (JSC::GetStackTraceFunctor::operator()):
        * interpreter/Interpreter.h:
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::sourceID):
        * interpreter/StackVisitor.h:
        Access the SourceID when we have it.

2016-04-21  Saam barati  <sbarati@apple.com>

        Lets do less locking of symbol tables in the BytecodeGenerator where we don't have race conditions
        https://bugs.webkit.org/show_bug.cgi?id=156821

        Reviewed by Filip Pizlo.

        The BytecodeGenerator allocates all the SymbolTables that it uses.
        This is before any concurrent compiler thread can use that SymbolTable.
        This means we don't actually need to lock for any operations of the
        SymbolTable. This patch makes this change by removing all locking.
        To do this, I've introduced a new constructor for ConcurrentJITLocker
        which implies no locking is necessary. You instantiate such a ConcurrentJITLocker like so:
        `ConcurrentJITLocker locker(ConcurrentJITLocker::NoLockingNecessary);`

        This patch also removes all uses of Strong<SymbolTable> from the bytecode
        generator and instead wraps bytecode generation in a DeferGC.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::instantiateLexicalVariables):
        (JSC::BytecodeGenerator::emitPrefillStackTDZVariables):
        (JSC::BytecodeGenerator::pushLexicalScopeInternal):
        (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
        (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
        (JSC::BytecodeGenerator::popLexicalScopeInternal):
        (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
        (JSC::BytecodeGenerator::variable):
        (JSC::BytecodeGenerator::createVariable):
        (JSC::BytecodeGenerator::emitResolveScope):
        (JSC::BytecodeGenerator::emitPushWithScope):
        (JSC::BytecodeGenerator::emitPushFunctionNameScope):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::constructorKind):
        (JSC::BytecodeGenerator::superBinding):
        (JSC::BytecodeGenerator::generate):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        * runtime/ConcurrentJITLock.h:
        (JSC::ConcurrentJITLockerBase::ConcurrentJITLockerBase):
        (JSC::ConcurrentJITLockerBase::~ConcurrentJITLockerBase):
        (JSC::ConcurrentJITLocker::ConcurrentJITLocker):

2016-04-21  Saam barati  <sbarati@apple.com>

        Remove some unnecessary RefPtrs in the parser
        https://bugs.webkit.org/show_bug.cgi?id=156865

        Reviewed by Filip Pizlo.

        The IdentifierArena or the SourceProviderCacheItem will own these UniquedStringImpls
        while we are using them. There is no need for us to reference count them.

        This might be a 0.5% speedup on octane code-load.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        * parser/Parser.h:
        (JSC::Scope::setIsLexicalScope):
        (JSC::Scope::isLexicalScope):
        (JSC::Scope::closedVariableCandidates):
        (JSC::Scope::declaredVariables):
        (JSC::Scope::lexicalVariables):
        (JSC::Scope::finalizeLexicalEnvironment):
        (JSC::Scope::computeLexicallyCapturedVariablesAndPurgeCandidates):
        (JSC::Scope::collectFreeVariables):
        (JSC::Scope::getCapturedVars):
        (JSC::Scope::setStrictMode):
        (JSC::Scope::isValidStrictMode):
        (JSC::Scope::shadowsArguments):
        (JSC::Scope::copyCapturedVariablesToVector):
        * parser/SourceProviderCacheItem.h:
        (JSC::SourceProviderCacheItem::usedVariables):
        (JSC::SourceProviderCacheItem::~SourceProviderCacheItem):
        (JSC::SourceProviderCacheItem::create):
        (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
        (JSC::SourceProviderCacheItem::writtenVariables): Deleted.

2016-04-21  Filip Pizlo  <fpizlo@apple.com>

        PolymorphicAccess adds sizeof(CallerFrameAndPC) rather than subtracting it when calculating stack height
        https://bugs.webkit.org/show_bug.cgi?id=156872

        Reviewed by Geoffrey Garen.
        
        The code that added sizeof(CallerFrameAndPC) emerged from a bad copy-paste in r189586. That was
        the revision that created the PolymorphicAccess class. It moved code for generating a
        getter/setter call from Repatch.cpp to PolymorphicAccess.cpp. You can see the code doing a
        subtraction here:
        
            http://trac.webkit.org/changeset/189586/trunk/Source/JavaScriptCore/jit/Repatch.cpp
        
        This makes the world right again.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):

2016-04-21  Geoffrey Garen  <ggaren@apple.com>

        Build warning: CODE_SIGN_ENTITLEMENTS specified without specifying CODE_SIGN_IDENTITY
        https://bugs.webkit.org/show_bug.cgi?id=156862

        Reviewed by Joseph Pecoraro.

        * Configurations/Base.xcconfig: Specify the ad hoc signing identity by
        default. See <http://trac.webkit.org/changeset/143544>.

2016-04-21  Andy Estes  <aestes@apple.com>

        REGRESSION (r199734): WebKit crashes loading numerous websites in iOS Simulator
        https://bugs.webkit.org/show_bug.cgi?id=156842

        Reviewed by Daniel Bates.

        Disable separated heap on iOS Simulator.

        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

2016-04-21  Michael Saboff  <msaboff@apple.com>

        Align RegExp[@@match] with other @@ methods
        https://bugs.webkit.org/show_bug.cgi?id=156832

        Reviewed by Mark Lam.

        Various changes to align the RegExp[@@match] with [@@search] and [@@split].

        Made RegExp.prototype.@exec a hidden property on the global object and
        called it @regExpBuiltinExec to match the name it has in the standard.
        Changed all places that used the old name to use the new one.

        Made the match fast path function, which used to be call @match, to be called
        @regExpMatchFast and put it on the global object.  Changed it to also handle
        expressions both with and without the global flag.  Refactored the builtin
        @match accordingly.

        Added the builtin function @hasObservableSideEffectsForRegExpMatch() that
        checks to see if we can use the fast path of if we need the explicit version.

        Put the main RegExp functions @match, @search and @split in alphabetical
        order in RegExpPrototype.js.  Did the same for @match, @repeat, @search and 
        @split in StringPrototype.js.
        
        * builtins/RegExpPrototype.js:
        (regExpExec):
        (hasObservableSideEffectsForRegExpMatch): New.
        (match):
        (search):
        (hasObservableSideEffectsForRegExpSplit):
        Reordered in the file and updated to use @regExpBuiltinExec.

        * builtins/StringPrototype.js:
        (match):
        (repeatSlowPath):
        (repeat):
        (search):
        (split):
        Reordered functions in the file.

        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::setGlobalThis):
        (JSC::getById):
        (JSC::getGetterById):
        (JSC::JSGlobalObject::init):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        (JSC::regExpProtoFuncExec):
        (JSC::regExpProtoFuncMatchFast):
        (JSC::regExpProtoFuncMatchPrivate): Deleted.
        * runtime/RegExpPrototype.h:

2016-04-20  Geoffrey Garen  <ggaren@apple.com>

        JavaScriptCore garbage collection is missing an autorelease pool
        https://bugs.webkit.org/show_bug.cgi?id=156751
        <rdar://problem/25787802>

        Reviewed by Mark Lam.

        * heap/Heap.cpp:
        (JSC::Heap::releaseDelayedReleasedObjects): Add an autorelease pool to
        catch autoreleases when we call out to arbitrary ObjC code.

        We use the C interface here because this is not an ObjC compilation unit.

2016-04-20  Filip Pizlo  <fpizlo@apple.com>

        DFG del_by_id support forgets to set()
        https://bugs.webkit.org/show_bug.cgi?id=156830

        Reviewed by Saam Barati.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * tests/stress/dfg-del-by-id.js: Added.

2016-04-20  Saam barati  <sbarati@apple.com>

        Improve sampling profiler CLI JSC tool
        https://bugs.webkit.org/show_bug.cgi?id=156824

        Reviewed by Mark Lam.

        This patch enhances the Sampling Profiler CLI tool from the JSC shell
        to display the JITType of a particular CodeBlock. Because this happens
        once we process a log of stack frames, the data for a particular frame
        being in LLInt vs. Baseline could be wrong. For example, we may have taken 
        a stack trace of a CodeBlock while it was executing in the LLInt, then 
        it tiers up to the baseline, then we process the log. We will show such CodeBlocks
        as being in the baseline JIT. We could be smarter about this in the future if
        it turns out to truly be a problem.

        This patch also adds a 'samplingProfilerTimingInterval' JSC option to allow
        CLI users to control the sleep time between stack traces.

        * jsc.cpp:
        (jscmain):
        * runtime/Options.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::SamplingProfiler):
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        (JSC::SamplingProfiler::reportTopBytecodes):
        * runtime/SamplingProfiler.h:
        (JSC::SamplingProfiler::StackFrame::hasExpressionInfo):

2016-04-20  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] DFG should not generate two jumps when the target of DoubleBranch is the next block  
        https://bugs.webkit.org/show_bug.cgi?id=156815

        Reviewed by Mark Lam.

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

2016-04-20  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add register reuse for ArithAdd of an Int32 and constant in DFG
        https://bugs.webkit.org/show_bug.cgi?id=155164

        Reviewed by Mark Lam.

        Every "inc" in loop was looking like this:
            move rX, rY
            inc rY
            jo 0x230f4a200580

        This patch add register Reuse to that case to remove
        the extra "move".

        * dfg/DFGOSRExit.h:
        (JSC::DFG::SpeculationRecovery::SpeculationRecovery):
        (JSC::DFG::SpeculationRecovery::immediate):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithAdd):
        * tests/stress/arith-add-with-constant-overflow.js: Added.
        (opaqueAdd):

2016-04-20  Saam barati  <sbarati@apple.com>

        We don't need a manual stack for an RAII object when the machine's stack will do just fine
        https://bugs.webkit.org/show_bug.cgi?id=156807

        Reviewed by Mark Lam.

        We kept around a vector for an RAII object to maintain
        the recursive nature of having these RAII objects on
        the stack as the parser recursed. Instead, the RAII object
        can just have a field with the value it wants to restore
        and use the machine's stack.

        This is a 1% octane code-load progression.

        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::BinaryExprContext::BinaryExprContext):
        (JSC::SyntaxChecker::BinaryExprContext::~BinaryExprContext):
        (JSC::SyntaxChecker::UnaryExprContext::UnaryExprContext):
        (JSC::SyntaxChecker::UnaryExprContext::~UnaryExprContext):
        (JSC::SyntaxChecker::operatorStackPop):

2016-04-20  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r190289): Spin trying to view/sign in to hbogo.com
        https://bugs.webkit.org/show_bug.cgi?id=156765

        Reviewed by Saam Barati.

        In the op_get_by_val case, we were holding the lock on a profiled CodeBlock
        when we call into handleGetById(). Changed to drop the lock before calling
        handleGetById().

        The bug here was that the call to handleGetById() may end up calling in to
        getPredictionWithoutOSRExit() for a tail call opcode. As part of that
        processing, we walk back up the stack to find the effective caller and when
        found, we lock the corresponding CodeBlock to get the predicition.
        That CodeBLock may be the same one locked above. There is no need anyway
        to hold the CodeBlock lock when calling handleGetById().

        Added a new stress test.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * tests/stress/regress-156765.js: Added.
        (realValue):
        (object.get hello):
        (ok):

2016-04-20  Mark Lam  <mark.lam@apple.com>

        Unindent an unnecessary block in stringProtoFuncSplitFast().
        https://bugs.webkit.org/show_bug.cgi?id=156802

        Reviewed by Filip Pizlo.

        In webkit.org/b/156013, I refactored stringProtoFuncSplit into
        stringProtoFuncSplitFast.  In that patch, I left an unnecessary block of code in
        its original block (with FIXMEs) to keep the diff for that patch minimal.  Now
        that the patch for webkit.org/b/156013 has landed, I will unindent that block and
        remove the FIXMEs.

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

2016-04-20  Brady Eidson  <beidson@apple.com>

        Modern IDB (Workers): Enable INDEXED_DATABASE_IN_WORKERS compile time flag, but disabled in RuntimeEnabledFeatures.
        https://bugs.webkit.org/show_bug.cgi?id=156782

        Reviewed by Alex Christensen.

        * Configurations/FeatureDefines.xcconfig:

2016-04-20  Saam barati  <sbarati@apple.com>

        Remove unused m_writtenVariables from the parser and related bits
        https://bugs.webkit.org/show_bug.cgi?id=156784

        Reviewed by Yusuke Suzuki.

        This isn't a octane/codeload speedup even though we're doing less work in
        collectFreeVariables. But it's good to get rid of things that are not used.

        * parser/Nodes.h:
        (JSC::ScopeNode::usesEval):
        (JSC::ScopeNode::usesArguments):
        (JSC::ScopeNode::usesArrowFunction):
        (JSC::ScopeNode::isStrictMode):
        (JSC::ScopeNode::setUsesArguments):
        (JSC::ScopeNode::usesThis):
        (JSC::ScopeNode::modifiesParameter): Deleted.
        (JSC::ScopeNode::modifiesArguments): Deleted.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::hasDeclaredParameter):
        (JSC::Scope::preventAllVariableDeclarations):
        (JSC::Scope::collectFreeVariables):
        (JSC::Scope::mergeInnerArrowFunctionFeatures):
        (JSC::Scope::getSloppyModeHoistedFunctions):
        (JSC::Scope::getCapturedVars):
        (JSC::Scope::setStrictMode):
        (JSC::Scope::strictMode):
        (JSC::Scope::fillParametersForSourceProviderCache):
        (JSC::Scope::restoreFromSourceProviderCache):
        (JSC::Parser::hasDeclaredParameter):
        (JSC::Parser::exportName):
        (JSC::Scope::declareWrite): Deleted.
        (JSC::Parser::declareWrite): Deleted.
        * parser/ParserModes.h:

2016-04-19  Saam barati  <sbarati@apple.com>

        Unreviewed, fix cloop build after r199754.

        * jsc.cpp:
        (jscmain):

2016-04-19  Michael Saboff  <msaboff@apple.com>

        iTunes crashing JavaScriptCore.dll
        https://bugs.webkit.org/show_bug.cgi?id=156647

        Reviewed by Filip Pizlo.

        Given that there there are only 128 FLS indices compared to over a 1000 for TLS,
        I eliminated the thread specific m_threadSpecificForThread and instead we look
        for the current thread in m_registeredThreads list when we need it.
        In most cases there will only be one thread.

        Added THREAD_SPECIFIC_CALL to signature of ThreadSpecific remove callbacks
        to set the calling convention correctly for Windows 32 bit.

        * heap/MachineStackMarker.cpp:
        (JSC::ActiveMachineThreadsManager::remove):
        (JSC::MachineThreads::MachineThreads):
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::addCurrentThread):
        (JSC::MachineThreads::machineThreadForCurrentThread):
        (JSC::MachineThreads::removeThread):
        * heap/MachineStackMarker.h:

2016-04-19  Benjamin Poulain  <bpoulain@webkit.org>

        [JSC] Small cleanup of RegisterAtOffsetList
        https://bugs.webkit.org/show_bug.cgi?id=156779

        Reviewed by Mark Lam.

        I was wondering why RegisterAtOffsetList always cache-miss.
        It looks like it is doing more than it needs to.

        We do not need to sort the values. The total order of
        RegisterAtOffset is:
        1) Order of Reg.
        2) Order of offsets.
        We already generate the list in order.

        Also allocate the right array size ahead of filling the array.

        * jit/RegisterAtOffsetList.cpp:
        (JSC::RegisterAtOffsetList::RegisterAtOffsetList):
        (JSC::RegisterAtOffsetList::sort): Deleted.
        * jit/RegisterAtOffsetList.h:
        (JSC::RegisterAtOffsetList::append): Deleted.

2016-04-19  Saam barati  <sbarati@apple.com>

        Add a couple UNLIKELY macros in parseMemberExpression
        https://bugs.webkit.org/show_bug.cgi?id=156775

        Reviewed by Filip Pizlo.

        These UNLIKELY macros have to do with the base of the
        member expression being 'super'. I think it's safe to
        argue that this is truly UNLIKELY. I am seeing speedups
        sometimes on Octane codeload. Usually around 0.5%. Sometimes 1%.

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

2016-04-19  Saam barati  <sbarati@apple.com>

        allow jsc shell to dump sampling profiler data
        https://bugs.webkit.org/show_bug.cgi?id=156725

        Reviewed by Benjamin Poulain.

        This patch adds a '--reportSamplingProfilerData' option to the
        JSC shell which will enable the sampling profiler and dump
        its data at the end of execution. The dump will include the
        40 hottest functions and the 80 hottest bytecode locations.
        If you're using this option to debug, it's easy to just hack
        on the code to make it dump more or less information.

        * jsc.cpp:
        (CommandLine::parseArguments):
        (jscmain):
        * runtime/Options.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        (JSC::SamplingProfiler::stackTracesAsJSON):
        (JSC::SamplingProfiler::reportTopFunctions):
        (JSC::SamplingProfiler::reportTopBytecodes):
        * runtime/SamplingProfiler.h:
        (JSC::SamplingProfiler::StackFrame::hasExpressionInfo):
        (JSC::SamplingProfiler::StackFrame::hasBytecodeIndex):
        (JSC::SamplingProfiler::StackFrame::hasCodeBlockHash):
        (JSC::SamplingProfiler::setStopWatch):

2016-04-19  Mark Lam  <mark.lam@apple.com>

        Re-landing: ES6: Implement RegExp.prototype[@@search].
        https://bugs.webkit.org/show_bug.cgi?id=156331

        Reviewed by Keith Miller.

        What changed?
        1. Implemented search builtin in RegExpPrototype.js.
           The native path is now used as a fast path.
        2. Added DFG support for an IsRegExpObjectIntrinsic (modelled after the
           IsJSArrayIntrinsic).
        3. Renamed @isRegExp to @isRegExpObject to match the new IsRegExpObjectIntrinsic.
        4. Change the esSpecIsRegExpObject() implementation to check if the object's
           JSType is RegExpObjectType instead of walking the classinfo chain.

        * builtins/RegExpPrototype.js:
        (search):
        * builtins/StringPrototype.js:
        (search):
        - fixed some indentation.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * 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::compileIsArrayConstructor):
        (JSC::DFG::SpeculativeJIT::compileIsRegExpObject):
        (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
        * 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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsRegExpObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileTypeOf):
        (JSC::FTL::DFG::LowerDFGToB3::isExoticForTypeof):
        (JSC::FTL::DFG::LowerDFGToB3::isRegExpObject):
        (JSC::FTL::DFG::LowerDFGToB3::isType):
        * runtime/Intrinsic.h:
        - Added IsRegExpObjectIntrinsic.

        * runtime/CommonIdentifiers.h:

        * runtime/ECMAScriptSpecInternalFunctions.cpp:
        (JSC::esSpecIsConstructor):
        - Changed to use uncheckedArgument since this is only called from internal code.
        (JSC::esSpecIsRegExpObject):
        (JSC::esSpecIsRegExp): Deleted.
        * runtime/ECMAScriptSpecInternalFunctions.h:
        - Changed to check the object for a JSType of RegExpObjectType.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        - Added split fast path.

        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        (JSC::regExpProtoFuncSearchFast):
        (JSC::regExpProtoFuncSearch): Deleted.
        * runtime/RegExpPrototype.h:

        * tests/es6.yaml:
        * tests/stress/regexp-search.js:
        - Rebased test.

2016-04-19  Mark Lam  <mark.lam@apple.com>

        Replace $vm.printValue() with $vm.value().
        https://bugs.webkit.org/show_bug.cgi?id=156767

        Reviewed by Saam Barati.

        When debugging with $vm, this change allows us to do this:

            $vm.print("myObj = " + $vm.value(myObj) + "\n");

        ... instead of having to do this:

            $vm.print("myObj = ");
            $vm.printValue(myObj);
            $vm.print("\n");

        * tools/JSDollarVMPrototype.cpp:
        (JSC::JSDollarVMPrototype::printValue):
        (JSC::functionValue):
        (JSC::JSDollarVMPrototype::finishCreation):
        (JSC::functionPrintValue): Deleted.

2016-04-19  Mark Lam  <mark.lam@apple.com>

        Re-landing: ES6: Implement String.prototype.split and RegExp.prototype[@@split].
        https://bugs.webkit.org/show_bug.cgi?id=156013

        Reviewed by Keith Miller.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/GlobalObject.js:
        (speciesConstructor):
        * builtins/PromisePrototype.js:
        - refactored to use the @speciesConstructor internal function.

        * builtins/RegExpPrototype.js:
        (advanceStringIndex):
        - refactored from @advanceStringIndexUnicode() to be match the spec.
          Benchmarks show that there's no advantage in doing the unicode check outside
          of the advanceStringIndexUnicode part.  So, I simplified the code to match the
          spec (especially since @@split needs to call advanceStringIndex from more than
          1 location).
        (match):
        - Removed an unnecessary call to @Object because it was already proven above.
        - Changed to use advanceStringIndex instead of advanceStringIndexUnicode.
          Again, there's no perf regression for this.
        (regExpExec):
        (hasObservableSideEffectsForRegExpSplit):
        (split):
        (advanceStringIndexUnicode): Deleted.

        * builtins/StringPrototype.js:
        (split):
        - Modified to use RegExp.prototype[@@split].

        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        (JSC::BytecodeIntrinsicRegistry::lookup):
        * bytecode/BytecodeIntrinsicRegistry.h:
        - Added the @@split symbol.

        * runtime/CommonIdentifiers.h:
        * runtime/ECMAScriptSpecInternalFunctions.cpp: Added.
        (JSC::esSpecIsConstructor):
        (JSC::esSpecIsRegExp):
        * runtime/ECMAScriptSpecInternalFunctions.h: Added.

        * runtime/JSGlobalObject.cpp:
        (JSC::getGetterById):
        (JSC::JSGlobalObject::init):

        * runtime/PropertyDescriptor.cpp:
        (JSC::PropertyDescriptor::setDescriptor):
        - Removed an assert that is no longer valid.

        * runtime/RegExpObject.h:
        - Made advanceStringUnicode() public so that it can be re-used by the regexp split
          fast path.

        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        (JSC::regExpProtoFuncExec):
        (JSC::regExpProtoFuncSearch):
        (JSC::advanceStringIndex):
        (JSC::regExpProtoFuncSplitFast):
        * runtime/RegExpPrototype.h:

        * runtime/StringObject.h:
        (JSC::jsStringWithReuse):
        (JSC::jsSubstring):
        - Hoisted some utility functions from StringPrototype.cpp so that they can be
          reused by the regexp split fast path.

        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::stringProtoFuncSplitFast):
        (JSC::stringProtoFuncSubstr):
        (JSC::builtinStringSubstrInternal):
        (JSC::stringProtoFuncSubstring):
        (JSC::stringIncludesImpl):
        (JSC::stringProtoFuncIncludes):
        (JSC::builtinStringIncludesInternal):
        (JSC::jsStringWithReuse): Deleted.
        (JSC::jsSubstring): Deleted.
        (JSC::stringProtoFuncSplit): Deleted.
        * runtime/StringPrototype.h:

        * tests/es6.yaml:

2016-04-19  Commit Queue  <commit-queue@webkit.org>

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

        WebKit tests crash on Windows 32 (Requested by msaboff on
        #webkit).

        Reverted changeset:

        "iTunes crashing JavaScriptCore.dll"
        https://bugs.webkit.org/show_bug.cgi?id=156647
        http://trac.webkit.org/changeset/199726

2016-04-19  Michael Saboff  <msaboff@apple.com>

        iTunes crashing JavaScriptCore.dll
        https://bugs.webkit.org/show_bug.cgi?id=156647

        Reviewed by Saam Barati.

        Given that there there are only 128 FLS indices compared to over a 1000 for TLS, I
        eliminated the thread specific m_threadSpecificForThread and instead we look for the
        current thread in m_registeredThreads list when we need it.  In most cases there
        will only be one thread.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThreads):
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::addCurrentThread):
        (JSC::MachineThreads::machineThreadForCurrentThread):
        (JSC::MachineThreads::removeThread):
        * heap/MachineStackMarker.h:

2016-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>

        [INTL] Use @thisNumberValue instead of `instanceof @Number`
        https://bugs.webkit.org/show_bug.cgi?id=156680

        Reviewed by Saam Barati.

        Use @thisNumberValue instead of `instanceof @Number`.
        `instanceof @Number` is not enough;
        For example, given 2 realms, the object created in one realm does not
        inherit the Number of another realm.
        Another example is that the object which does not inherit Number.

        ```
        var number = new Number(42);
        number.__proto__ = null;
        ```

        * builtins/NumberPrototype.js:
        (toLocaleString):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/NumberPrototype.cpp:
        (JSC::numberProtoFuncValueOf):
        * runtime/NumberPrototype.h:
        * tests/stress/number-to-locale-string-should-accept-strange-number-objects.js: Added.
        (shouldBe):

2016-04-19  Commit Queue  <commit-queue@webkit.org>

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

        It caused a serious regression on 32 bit platform (Requested
        by gskachkov on #webkit).

        Reverted changeset:

        "calling super() a second time in a constructor should throw"
        https://bugs.webkit.org/show_bug.cgi?id=151113
        http://trac.webkit.org/changeset/199712

2016-04-09  Skachkov Oleksandr  <gskachkov@gmail.com>

        calling super() a second time in a constructor should throw
        https://bugs.webkit.org/show_bug.cgi?id=151113

        Reviewed by Saam Barati and Keith Miller.

        Currently, our implementation checks if 'super()' was called in a constructor more 
        than once and raises a RuntimeError before the second call. According to the spec 
        we need to raise an error just after the second super() is finished and before 
        the new 'this' is assigned https://esdiscuss.org/topic/duplicate-super-call-behaviour. 
        To implement this behavior this patch adds a new op code, op_is_empty, that is used 
        to check if 'this' is empty.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitIsEmpty):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionCallValueNode::emitBytecode):
        * 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/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsEmpty):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_empty):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_empty):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * tests/stress/class-syntax-double-constructor.js: Added.

2016-04-18  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Fix some overhead affecting small codegen
        https://bugs.webkit.org/show_bug.cgi?id=156728

        Reviewed by Filip Pizlo.

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::AbstractMacroAssembler):
        (JSC::AbstractMacroAssembler::random):
        cryptographicallyRandomNumber() is very costly.
        We only need it in lowering some very particular cases
        of non-trusted immediates. No inline cache needs that.

        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::link):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::addSlowCase):
        Do not copy the JumpList to access its elements.

2016-04-18  Saam barati  <sbarati@apple.com>

        implement dynamic scope accesses in the DFG/FTL
        https://bugs.webkit.org/show_bug.cgi?id=156567

        Reviewed by Geoffrey Garen.

        This patch adds dynamic scope operations to the DFG/FTL.
        This patch adds three new DFG nodes: ResolveScope, PutDynamicVar and GetDynamicVar.
        When we encounter a Dynamic/UnresolvedProperty/UnresolvedPropertyWithVarInjectionChecks
        resolve type, we will compile dynamic scope resolution nodes. When we encounter
        a resolve type that needs var injection checks and the var injection
        watchpoint has already been fired, we will compile dynamic scope resolution
        nodes.

        This patch also adds a new value to the InitializationMode enum: ConstInitialization.
        There was a subtle bug where we used to never compile the var injection variant of the 
        resolve type for an eval that injected a var where there was also a global lexical variable with the same name. 
        For example, the store compiled in this eval("var foo = 20;") wouldn't be compiled 
        with var injection checks if there was global let/const variable named "foo".
        So there was the potential for the injected var to store to the GlobalLexicalObject.
        I found this bug because my initial implementation in the DFG/FTL ran into it.
        The reason this bug existed is because when we compile a const initialization,
        we never need a var injections check. The const initialization always
        knows where to store its value. This same logic leaked into the above eval's 
        "var foo = 20" store. This new enum value allows us to distinguish const
        initialization stores from non-const initialization stores.

        (I also changed InitializationMode to be an enum class instead of an enum).

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
        (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
        (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
        (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
        (JSC::BytecodeGenerator::emitGetFromScope):
        (JSC::BytecodeGenerator::initializeVariable):
        (JSC::BytecodeGenerator::emitInstanceOf):
        (JSC::BytecodeGenerator::emitPushFunctionNameScope):
        (JSC::BytecodeGenerator::pushScopedControlFlowContext):
        (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PostfixNode::emitResolve):
        (JSC::PrefixNode::emitResolve):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::initializationModeForAssignmentContext):
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::EmptyLetExpression::emitBytecode):
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForOfNode::emitBytecode):
        (JSC::ClassExprNode::emitBytecode):
        (JSC::BindingNode::bindValue):
        (JSC::AssignmentElementNode::bindValue):
        (JSC::RestParameterNode::emit):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::noticeArgumentsUse):
        (JSC::DFG::ByteCodeParser::promoteToConstant):
        (JSC::DFG::ByteCodeParser::needsDynamicLookup):
        (JSC::DFG::ByteCodeParser::planLoad):
        (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/DFGNode.h:
        (JSC::DFG::Node::hasIdentifier):
        (JSC::DFG::Node::identifierNumber):
        (JSC::DFG::Node::hasGetPutInfo):
        (JSC::DFG::Node::getPutInfo):
        (JSC::DFG::Node::hasAccessorAttributes):
        * 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::compilePutGetterSetterById):
        (JSC::DFG::SpeculativeJIT::compileResolveScope):
        (JSC::DFG::SpeculativeJIT::compileGetDynamicVar):
        (JSC::DFG::SpeculativeJIT::compilePutDynamicVar):
        (JSC::DFG::SpeculativeJIT::compilePutAccessorByVal):
        * dfg/DFGSpeculativeJIT.h:
        (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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compare):
        (JSC::FTL::DFG::LowerDFGToB3::compileResolveScope):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetDynamicVar):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutDynamicVar):
        (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitSlow_op_put_to_scope):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitSlow_op_put_to_scope):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/GetPutInfo.h:
        (JSC::resolveModeName):
        (JSC::initializationModeName):
        (JSC::isInitialization):
        (JSC::makeType):
        (JSC::GetPutInfo::GetPutInfo):
        * runtime/JSScope.cpp:
        (JSC::abstractAccess):

2016-04-18  Filip Pizlo  <fpizlo@apple.com>

        Disable AVX.

        Rubber stampted by Benjamin Poulain.

        AVX is silly. If you use it and some of your other code isn't careful with float register bits, you
        will run 10x slower. We could fix the underlying issue, but it's better to stay away from this odd
        instruction subset.

        This fixes a massive regression on some real code.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::supportsAVX):
        (JSC::MacroAssemblerX86Common::updateEax1EcxFlags):

2016-04-18  Filip Pizlo  <fpizlo@apple.com>

        ToThis should have a fast path based on type info flags
        https://bugs.webkit.org/show_bug.cgi?id=156712

        Reviewed by Geoffrey Garen.

        Prior to this change, if we couldn't nail down the type of ToThis to something easy, we'd emit code
        that would take slow path if the argument was not a final object. We'd end up taking that slow path
        a lot.

        This adds a type info flag for ToThis having non-obvious behavior and changes the DFG and FTL paths
        to test this flag. This is a sub-1% speed-up on SunSpider and Octane.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileToThis):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::create):
        * runtime/JSLexicalEnvironment.h:
        (JSC::JSLexicalEnvironment::create):
        * runtime/JSString.h:
        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::overridesGetOwnPropertySlot):
        (JSC::TypeInfo::interceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero):
        (JSC::TypeInfo::structureIsImmortal):
        (JSC::TypeInfo::overridesToThis):
        (JSC::TypeInfo::overridesGetPropertyNames):
        (JSC::TypeInfo::prohibitsPropertyCaching):
        (JSC::TypeInfo::getOwnPropertySlotIsImpure):
        * runtime/StrictEvalActivation.h:
        (JSC::StrictEvalActivation::create):
        * runtime/Symbol.h:

2016-04-18  Filip Pizlo  <fpizlo@apple.com>

        Check to see how the perf bots react to megamorphic load being disabled.

        Rubber stamped by Chris Dumez.

        * runtime/Options.h:

2016-04-18  Keith Miller  <keith_miller@apple.com>

        We should support delete in the DFG
        https://bugs.webkit.org/show_bug.cgi?id=156607

        Reviewed by Benjamin Poulain.

        This patch adds support for the delete in the DFG as it appears that
        some major frameworks use the operation in particularly hot functions.
        As a result, even if the function rarely ever calls delete we would never
        tier up to the DFG. This patch also changes operationDeleteById to take a
        UniquedStringImpl and return a size_t.

        * 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/DFGNode.h:
        (JSC::DFG::Node::hasIdentifier):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileDeleteById):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_del_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_del_by_id):

2016-04-17  Filip Pizlo  <fpizlo@apple.com>

        FTL should pin the tag registers at inline caches
        https://bugs.webkit.org/show_bug.cgi?id=156678

        Reviewed by Saam Barati.

        This is a long-overdue fix to our inline caches. Back when we had LLVM, we couldn't rely on the tags
        being pinned to any registers. So, if the inline caches needed tags, they'd have to materialize them.
        
        This removes those materializations. This should reduce the amount of code generated in inline caches
        and it should make inline caches faster. The effect appears to be small.

        It may be that after this change, we'll even be able to kill the
        HaveTagRegisters/DoNotHaveTagRegisters logic.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateWithGuard):
        (JSC::AccessCase::generateImpl):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compilePutById):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):
        (JSC::FTL::DFG::LowerDFGToB3::getById):
        * jit/Repatch.cpp:
        (JSC::readCallTarget):
        (JSC::linkPolymorphicCall):
        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):

2016-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES7] yield star should not return if the inner iterator.throw returns { done: true }
        https://bugs.webkit.org/show_bug.cgi?id=156576

        Reviewed by Saam Barati.

        This is slight generator fix in ES7. When calling generator.throw(),
        the yield-star should call the throw() of the inner generator. At that
        time, when the result of throw() is { done: true}, the generator should
        not stop itself.

            function * gen()
            {
                yield * (function * () {
                    try {
                        yield 42;
                    } catch (error) { }
                }());
                // Continue executing.
                yield 42;
            }

            let g = gen();
            g.next();
            shouldBe(g.throw().value, 42);


        * builtins/GeneratorPrototype.js:
        (generatorResume):
        (next):
        (return):
        (throw):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitDelegateYield):
        * runtime/JSGeneratorFunction.h:
        * tests/stress/generator-yield-star.js:
        (gen):
        * tests/stress/yield-star-throw-continue.js: Added.
        (shouldBe):
        (generator):
        (shouldThrow):

2016-04-17  Jeremy Huddleston Sequoia  <jeremyhu@apple.com>

        Fix incorrect assumption that APPLE implies Mac.
        https://bugs.webkit.org/show_bug.cgi?id=156683
    
        Addresses build failure introduced in r199094

        Reviewed by Alex Christensen.

        * CMakeLists.txt:

2016-04-17  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] ReduceDoubleToFloat should work accross Phis
        https://bugs.webkit.org/show_bug.cgi?id=156603
        <rdar://problem/25736205>

        Reviewed by Saam Barati and Filip Pizlo.

        This patch extends B3's ReduceDoubleToFloat phase to work accross
        Upsilon-Phis. This is important to optimize loops and some crazy cases.

        In its simplest form, we can have conversion propagated from something
        like this:
            Double @1 = Phi()
            Float @2 = DoubleToFloat(@1)

        When that happens, we just need to propagate that the result only
        need float precision accross all values coming to this Phi.


        There are more complicated cases when the value produced is effectively Float
        but the user of the value does not do DoubleToFloat.

        Typically, we have something like:
            #1
                @1 = ConstDouble(1)
                @2 = Upsilon(@1, ^5)
            #2
                @3 = FloatToDouble(@x)
                @4 = Upsilon(@3, ^5)
            #3
                @5 = Phi()
                @6 = Add(@5, @somethingFloat)
                @7 = DoubleToFloat(@6)

        Here with a Phi-Upsilon that is a Double but can be represented
        as Float without loss of precision.

        It is valuable to convert such Phis to float if and only if the value
        is used as float. Otherwise, you may be just adding useless conversions
        (for example, two double constants that flow into a double Add should not
        turn into two float constant flowing into a FloatToDouble then Add).


        ReduceDoubleToFloat do two analysis passes to gather the necessary
        meta information. Then we have a simplify() phase to actually reduce
        operation. Finally, the cleanup() pass put the graph into a valid
        state again.

        The two analysis passes work by disproving that something is float.
        -findCandidates() accumulates anything used as Double.
        -findPhisContainingFloat() accumulates phis that would lose precision
         by converting the input to float.

        With this change, Unity3D improves by ~1.5%, box2d-f32 improves
        by ~2.8% (on Haswell).

        * b3/B3ReduceDoubleToFloat.cpp:
        (JSC::B3::reduceDoubleToFloat):
        * b3/testb3.cpp:
        (JSC::B3::testCompareTwoFloatToDouble):
        (JSC::B3::testCompareOneFloatToDouble):
        (JSC::B3::testCompareFloatToDoubleThroughPhi):
        (JSC::B3::testDoubleToFloatThroughPhi):
        (JSC::B3::testDoubleProducerPhiToFloatConversion):
        (JSC::B3::testDoubleProducerPhiToFloatConversionWithDoubleConsumer):
        (JSC::B3::testDoubleProducerPhiWithNonFloatConst):
        (JSC::B3::testStoreDoubleConstantAsFloat):
        (JSC::B3::run):
        * tests/stress/double-compare-to-float.js: Added.
        (canSimplifyToFloat):
        (canSimplifyToFloatWithConstant):
        (cannotSimplifyA):
        (cannotSimplifyB):
        * tests/stress/double-to-float.js: Added.
        (upsilonReferencingItsPhi):
        (upsilonReferencingItsPhiAllFloat):
        (upsilonReferencingItsPhiWithoutConversion):
        (conversionPropagages):
        (chainedUpsilonBothConvert):
        (chainedUpsilonFirstConvert):

2016-04-17  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Use @isObject to check Object Type instead of using instanceof
        https://bugs.webkit.org/show_bug.cgi?id=156676

        Reviewed by Darin Adler.

        Use @isObject instead of `instanceof @Object`.
        The `instanceof` check is not enough to check Object Type.
        For example, given 2 realms, the object created in one realm does not inherit the Object of another realm.
        Another example is that the object which does not inherit Object.
        This object can be easily created by calling `Object.create(null)`.

        * builtins/RegExpPrototype.js:
        (match):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionCreateGlobalObject):
        * tests/stress/regexp-match-in-other-realm-should-work.js: Added.
        (shouldBe):
        * tests/stress/regexp-match-should-work-with-objects-not-inheriting-object-prototype.js: Added.
        (shouldBe):
        (regexp.exec):

2016-04-17  Darin Adler  <darin@apple.com>

        Remove more uses of Deprecated::ScriptXXX
        https://bugs.webkit.org/show_bug.cgi?id=156660

        Reviewed by Antti Koivisto.

        * bindings/ScriptFunctionCall.cpp:
        (Deprecated::ScriptCallArgumentHandler::appendArgument): Deleted
        unneeded overloads that take a ScriptObject and ScriptValue.
        * bindings/ScriptFunctionCall.h: Ditto.

        * bindings/ScriptObject.h: Added operator so this can change
        itself into a JSObject*. Helps while phasing this class out.

        * bindings/ScriptValue.h: Export toInspectorValue so it can be
        used in WebCore.

        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::createInjectedScript): Changed
        return value from Deprecated::ScriptObject to JSObject*.
        (Inspector::InjectedScriptManager::injectedScriptFor): Updated for
        the return value change above.
        * inspector/InjectedScriptManager.h: Ditto.

2016-04-16  Benjamin Poulain  <bpoulain@webkit.org>

        [JSC] DFG should support relational comparisons of Number and Other
        https://bugs.webkit.org/show_bug.cgi?id=156669

        Reviewed by Darin Adler.

        In Sunspider/3d-raytrace, DFG falls back to JSValue in some important
        relational compare because profiling sees "undefined" from time to time.

        This case is fairly common outside Sunspider too because of out-of-bounds array access.
        Unfortunately for us, our fallback for compare is really inefficient.

        Fortunately, relational comparison with null/undefined/true/false are trival.
        We can just convert both side to Double. That's what this patch adds.

        I also extended constant folding for those cases because I noticed
        a bunch of "undefined" constant going through DoubleRep at runtime.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * tests/stress/compare-number-and-other.js: Added.
        (opaqueSideEffect):
        (let.operator.of.operators.eval.testPolymorphic):
        (let.operator.of.operators.let.left.of.typeCases.let.right.of.typeCases.eval.testMonomorphic):
        (let.operator.of.operators.let.left.of.typeCases.let.right.of.typeCases.testMonomorphicLeftConstant):
        (let.operator.of.operators.let.left.of.typeCases.let.right.of.typeCases.testMonomorphicRightConstant):
        (let.operator.of.operators.let.left.of.typeCases.let.right.of.typeCases.i.testPolymorphic):

2016-04-16  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] FRound/Negate can produce an impure NaN out of a pure NaN
        https://bugs.webkit.org/show_bug.cgi?id=156528

        Reviewed by Filip Pizlo.

        If you fround a double with the bits 0xfff7000000000000
        you get 0xfffe000000000000. The first is a pure NaN, the second isn't.

        This is without test because I could not find a way to create a 0xfff7000000000000
        while convincing DFG that its pure.
        When we purify NaNs from typed array, we use a specific value of NaN if the input
        is any NaN, making testing tricky.

        * bytecode/SpeculatedType.cpp:
        (JSC::typeOfDoubleNegation):

2016-04-16  Konstantin Tokarev  <annulen@yandex.ru>

        JS::DFG::nodeValuePairListDump does not compile with libstdc++ 4.8
        https://bugs.webkit.org/show_bug.cgi?id=156670

        Reviewed by Darin Adler.

        * dfg/DFGNode.h:
        (JSC::DFG::nodeValuePairListDump): Modified to use lambda as comparator.

2016-04-16  Konstantin Tokarev  <annulen@yandex.ru>

        [mips] Implemented moveZeroToDouble.
        https://bugs.webkit.org/show_bug.cgi?id=155429

        Reviewed by Darin Adler.

        This function is required to fix compilation after r197687.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::moveZeroToDouble):

2016-04-15  Darin Adler  <darin@apple.com>

        Reduce use of Deprecated::ScriptXXX classes
        https://bugs.webkit.org/show_bug.cgi?id=156632

        Reviewed by Alex Christensen.

        * bindings/ScriptFunctionCall.cpp:
        (Deprecated::ScriptCallArgumentHandler::appendArgument): Deleted version that takes a Deprecated::ScriptValue.
        (Deprecated::ScriptFunctionCall::call): Changed to return a JSValue.
        * bindings/ScriptFunctionCall.h: Updated for the above.

        * bindings/ScriptValue.cpp:
        (Inspector::jsToInspectorValue): Moved from Deprecated namespace to Inspector namespace. Later, we should
        move this to another source file in the inspector directory.
        (Inspector::toInspectorValue): Added.
        (Deprecated::ScriptValue::toInspectorValue): Updated for change to underlying function.
        * bindings/ScriptValue.h: Update for the above.

        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::evaluateOnCallFrame): Changed arguments and return values from
        Deprecated::ScriptValue to JSC::JSValue.
        (Inspector::InjectedScript::functionDetails): Ditto.
        (Inspector::InjectedScript::wrapCallFrames): Ditto.
        (Inspector::InjectedScript::wrapObject): Ditto.
        (Inspector::InjectedScript::wrapTable): Ditto.
        (Inspector::InjectedScript::previewValue): Ditto.
        (Inspector::InjectedScript::setExceptionValue): Ditto.
        (Inspector::InjectedScript::findObjectById): Ditto.
        (Inspector::InjectedScript::inspectObject): Ditto.
        * inspector/InjectedScript.h: Ditto.
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled): Ditto.
        (Inspector::InjectedScriptBase::makeCall): Ditto.
        * inspector/InjectedScriptBase.h: Ditto.
        * inspector/InjectedScriptModule.cpp:
        (Inspector::InjectedScriptModule::ensureInjected): Ditto.
        * inspector/ScriptDebugListener.h: Ditto.
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::evaluateBreakpointAction): Ditto.
        (Inspector::ScriptDebugServer::dispatchDidPause): Ditto.
        (Inspector::ScriptDebugServer::dispatchBreakpointActionProbe): Ditto.
        (Inspector::ScriptDebugServer::exceptionOrCaughtValue): Ditto.
        * inspector/ScriptDebugServer.h: Ditto.
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::buildExceptionPauseReason): Ditto.
        (Inspector::InspectorDebuggerAgent::didPause): Ditto.
        (Inspector::InspectorDebuggerAgent::breakpointActionProbe): Ditto.
        (Inspector::InspectorDebuggerAgent::didContinue): Ditto.
        (Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState): Ditto.
        * inspector/agents/InspectorDebuggerAgent.h: Ditto.
        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::getPreview): Ditto.
        (Inspector::InspectorHeapAgent::getRemoteObject): Ditto.

2016-04-15  Keith Miller  <keith_miller@apple.com>

        Some JIT/DFG operations need NativeCallFrameTracers
        https://bugs.webkit.org/show_bug.cgi?id=156650

        Reviewed by Michael Saboff.

        Some of our operation functions did not have native call frame
        tracers. This meant that we would crash occasionally on some
        of our tests when they triggered a GC in one of the functions
        without a tracer. In particular, this was exemplified by another
        upcoming patch when calling operationSetFunctionName.

        This patch does not add tests since this happens consistently in
        the patch adding delete_by_id to the DFG.

        * dfg/DFGOperations.cpp:
        * jit/JITOperations.cpp:

2016-04-15  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: sourceMappingURL not used when sourceURL is set
        https://bugs.webkit.org/show_bug.cgi?id=156021
        <rdar://problem/25438417>

        Reviewed by Timothy Hatcher.

        Clean up Debugger.sourceParsed to separately include:

            - url ("resource URL", "source url" in JSC APIs)
            - sourceURL - //# sourceURL directive

        By always having the resource URL the Web Inspector frontend
        can better match this Script to a Resource of the same URL,
        and decide to use the sourceURL if it is available when
        appropriate.

        * inspector/protocol/Debugger.json:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
        (Inspector::InspectorDebuggerAgent::didParseSource):
        Send the new sourceParsed parameters.

2016-04-14  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Cleanup inspector/debugger tests
        https://bugs.webkit.org/show_bug.cgi?id=156619

        Reviewed by Brian Burg.

        While cleaning up the tests it exposed the fact that breakpoints
        were not getting disabled when the inspector closes. This means
        that opening the inspector, with breakpoints, and closing the
        inspector, would leave the JSC::Debugger thinking breakpoints
        are active. The JSC::Debugger should be reset.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::disable):

2016-04-14  Geoffrey Garen  <ggaren@apple.com>

        CopiedBlock should be 64kB

        Reviewed by Benjamin Poulain.

        Let's try another value.

        This is 25% faster on kraken-audio-beat-detection on Mac Pro.

        * heap/CopiedBlock.h:

2016-04-15  Zan Dobersek  <zdobersek@igalia.com>

        Tail call optimizations lead to crashes on ARM Thumb + Linux
        https://bugs.webkit.org/show_bug.cgi?id=150083

        Reviewed by Csaba Osztrogonác.

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::repatchNearCall): In case of a tail call relink to the
        data location of the destination, and not the executable address. This is needed for
        the ARM Thumb2 platform where both the source and destination addresses of a jump relink
        must not have the bottom bit decorated, as asserted in ARMv7Assembler::relinkJump().
        * jit/Repatch.cpp:
        (JSC::linkPolymorphicCall): Similarly, when linking a tail call we must link to the
        address that has a non-decorated bottom bit, as asserted in ARMv7Assembler::linkJumpAbsolute().

2016-04-14  Geoffrey Garen  <ggaren@apple.com>

        Unreviewed, rolling out r199567.

        performance regression on kraken on macbook*

        Reverted changeset:

        "CopiedBlock should be 8kB"
        https://bugs.webkit.org/show_bug.cgi?id=156610
        http://trac.webkit.org/changeset/199567

2016-04-14  Geoffrey Garen  <ggaren@apple.com>

        CopiedBlock should be 8kB
        https://bugs.webkit.org/show_bug.cgi?id=156610

        Reviewed by Michael Saboff.

        On Mac Pro, this is:

            15% faster on kraken-audio-beat-detection

            5% faster on v8-splay

        Hopefully, this will be OK on MacBook* bots as well.

        32kB is the full size of L1 cache on x86. So, allocating and zero-filling
        a 32kB CopiedBlock would basically flush the L1 cache. We can ameliorate
        this problem by using smaller blocks -- or, if that doesn't work, we can
        use larger blocks to amortize the cost.

        * heap/CopiedBlock.h:

2016-04-14  Filip Pizlo  <fpizlo@apple.com>

        PolymorphicAccess should try to generate a stub only once
        https://bugs.webkit.org/show_bug.cgi?id=156555

        Reviewed by Geoffrey Garen.
        
        This changes the PolymorphicAccess heuristics to reduce the amount of code generation even
        more than before. We used to always generate a monomorphic stub for the first case we saw.
        This change disables that. This change also increases the buffering countdown to match the
        cool-down repatch count. This means that we will allow for ten slow paths for adding cases,
        then we will generate a stub, and then we will go into cool-down and the repatching slow
        paths will not even attempt repatching for a while. After we emerge from cool-down - which
        requires a bunch of slow path calls - we will again wait for ten slow paths to get new
        cases. Note that it only takes 13 cases to cause the stub to give up on future repatching
        entirely. Also, most stubs don't ever get to 10 cases. Therefore, for most stubs this change
        means that each IC will repatch once. If they make it to two repatching, then the likelihood
        of a third becomes infinitesimal because of all of the rules that come into play at that
        point (the size limit being 13, the fact that we go into exponential cool-down every time we
        generate code, and the fact that if we have lots of self cases then we will create a
        catch-all megamorphic load case).

        This also undoes a change to the megamorphic optimization that I think was unintentional.
        As in the change that originally introduced megamorphic loads, we want to do this only if we
        would otherwise exhaust the max size of the IC. This is because megamorphic loads are pretty
        expensive and it's best to use them only if we know that the alternative is giving up on
        caching.

        This is neutral on JS benchmarks, but looks like it's another speed-up for page loading.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::canBeReplacedByMegamorphicLoad):
        (JSC::AccessCase::canReplace):
        (JSC::AccessCase::dump):
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::StructureStubInfo):
        * runtime/Options.h:

2016-04-14  Mark Lam  <mark.lam@apple.com>

        Update treatment of invoking RegExp.prototype methods on RegExp.prototype.
        https://bugs.webkit.org/show_bug.cgi?id=155922

        Reviewed by Keith Miller.

        According to the TC39 committee, when invoking the following RegExp.prototype
        methods on the RegExp.prototype:
        1. RegExp.prototype.flags yields ""
        2. RegExp.prototype.global yields undefined
        3. RegExp.prototype.ignoreCase yields undefined
        4. RegExp.prototype.multiline yields undefined
        5. RegExp.prototype.unicode yields undefined
        6. RegExp.prototype.source yields "(?:)"
        7. RegExp.prototype.sticky yields undefined
        8. RegExp.prototype.toString() yields "/(?:)/"

        and RegExp.prototype is still NOT an instance of RegExp.  The above behavior
        changes is a special dispensation applicable only to RegExp.prototype.  The ES6
        spec of throwing errors still applies if those methods are applied to anything =
        else that is not a RegExp object.

        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoGetterGlobal):
        (JSC::regExpProtoGetterIgnoreCase):
        (JSC::regExpProtoGetterMultiline):
        (JSC::regExpProtoGetterSticky):
        (JSC::regExpProtoGetterUnicode):
        (JSC::regExpProtoGetterFlags):
        (JSC::regExpProtoGetterSource):
        - Implemented new behavior.

        * tests/es6/miscellaneous_built-in_prototypes_are_not_instances.js:
        (test):
        - Updated to match current kangax test.

2016-04-14  Geoffrey Garen  <ggaren@apple.com>

        Some imported ES6 tests are missing __createIterableObject
        https://bugs.webkit.org/show_bug.cgi?id=156584

        Reviewed by Keith Miller.

        These tests were failing because I neglected to include __createIterableObject
        when I first imported them. Now they pass.

        * tests/es6.yaml:
        * tests/es6/Array_static_methods_Array.from_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/Array_static_methods_Array.from_instances_of_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/Array_static_methods_Array.from_iterator_closing.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/Array_static_methods_Array.from_map_function_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/Array_static_methods_Array.from_map_function_instances_of_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/Map_iterator_closing.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/Promise_Promise.all_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test.asyncTestPassed):
        * tests/es6/Promise_Promise.race_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test.asyncTestPassed):
        * tests/es6/Set_iterator_closing.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/WeakMap_iterator_closing.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/WeakSet_iterator_closing.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/destructuring_iterator_closing.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/destructuring_with_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/destructuring_with_instances_of_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/for..of_loops_iterator_closing_break.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/for..of_loops_iterator_closing_throw.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/for..of_loops_with_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/for..of_loops_with_instances_of_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/generators_yield_star_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/generators_yield_star_iterator_closing_via_throw.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/spread_..._operator_with_generic_iterables_in_arrays.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/spread_..._operator_with_generic_iterables_in_calls.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/spread_..._operator_with_instances_of_iterables_in_arrays.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/spread_..._operator_with_instances_of_iterables_in_calls.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):

2016-04-13  Alex Christensen  <achristensen@webkit.org>

        CMake MiniBrowser should be an app bundle
        https://bugs.webkit.org/show_bug.cgi?id=156521

        Reviewed by Brent Fulgham.

        * PlatformMac.cmake:
        Unreviewed build fix.  Define __STDC_WANT_LIB_EXT1__ so we can find memset_s.

2016-04-13  Joseph Pecoraro  <pecoraro@apple.com>

        JSContext Inspector: Improve Class instances and JSC API Exported Values view in Console / ObjectTree
        https://bugs.webkit.org/show_bug.cgi?id=156566
        <rdar://problem/16392365>

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
        Treat non-basic object types as not lossless so they can be expanded.
        Show non-enumerable native getters in Object previews.

2016-04-13  Michael Saboff  <msaboff@apple.com>

        Some tests fail with ES6 `u` (Unicode) flag for regular expressions
        https://bugs.webkit.org/show_bug.cgi?id=151597

        Reviewed by Geoffrey Garen.

        Added two new tables to handle the anomolies of \w and \W CharacterClassEscapes
        when specified in RegExp's with both the unicode and ignoreCase flags.  Given the
        case folding rules described in the standard vie the meta function Canonicalize(),
        which allow cross ASCII case folding when unicode is specified, the unicode characters
        \u017f (small sharp s) and \u212a (kelvin symbol) are part of the \w (word) characterClassEscape.
        This is true because they case fold to 's' and 'k' respectively.  Because they case fold
        to lower case letters, the corresponding letters, 'k', 'K', 's' and 'S', are also matched with
        \W with the unicode and ignoreCase flags.

        * create_regex_tables:
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass):
        (JSC::Yarr::YarrPatternConstructor::atomCharacterClassBuiltIn):
        (JSC::Yarr::YarrPattern::YarrPattern):
        * yarr/YarrPattern.h:
        (JSC::Yarr::YarrPattern::wordcharCharacterClass):
        (JSC::Yarr::YarrPattern::wordUnicodeIgnoreCaseCharCharacterClass):
        (JSC::Yarr::YarrPattern::nonwordcharCharacterClass):
        (JSC::Yarr::YarrPattern::nonwordUnicodeIgnoreCaseCharCharacterClass):

2016-04-13  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r199502 and r199511.
        https://bugs.webkit.org/show_bug.cgi?id=156557

        Appears to have in-browser perf regression (Requested by mlam
        on #webkit).

        Reverted changesets:

        "ES6: Implement String.prototype.split and
        RegExp.prototype[@@split]."
        https://bugs.webkit.org/show_bug.cgi?id=156013
        http://trac.webkit.org/changeset/199502

        "ES6: Implement RegExp.prototype[@@search]."
        https://bugs.webkit.org/show_bug.cgi?id=156331
        http://trac.webkit.org/changeset/199511

2016-04-13  Keith Miller  <keith_miller@apple.com>

        isJSArray should use ArrayType rather than the ClassInfo
        https://bugs.webkit.org/show_bug.cgi?id=156551

        Reviewed by Filip Pizlo.

        Using the JSType rather than the ClassInfo should be slightly faster
        since the type is inline on the cell whereas the ClassInfo is only
        on the structure.

        * runtime/JSArray.h:
        (JSC::isJSArray):

2016-04-13  Mark Lam  <mark.lam@apple.com>

        ES6: Implement RegExp.prototype[@@search].
        https://bugs.webkit.org/show_bug.cgi?id=156331

        Reviewed by Keith Miller.

        What changed?
        1. Implemented search builtin in RegExpPrototype.js.
           The native path is now used as a fast path.
        2. Added DFG support for an IsRegExpObjectIntrinsic (modelled after the
           IsJSArrayIntrinsic).
        3. Renamed @isRegExp to @isRegExpObject to match the new IsRegExpObjectIntrinsic.
        4. Change the esSpecIsRegExpObject() implementation to check if the object's
           JSType is RegExpObjectType instead of walking the classinfo chain.

        * builtins/RegExpPrototype.js:
        (search):
        * builtins/StringPrototype.js:
        (search):
        - fixed some indentation.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * 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::compileIsArrayConstructor):
        (JSC::DFG::SpeculativeJIT::compileIsRegExpObject):
        (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
        * 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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsRegExpObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileTypeOf):
        (JSC::FTL::DFG::LowerDFGToB3::isExoticForTypeof):
        (JSC::FTL::DFG::LowerDFGToB3::isRegExpObject):
        (JSC::FTL::DFG::LowerDFGToB3::isType):
        * runtime/Intrinsic.h:
        - Added IsRegExpObjectIntrinsic.

        * runtime/CommonIdentifiers.h:

        * runtime/ECMAScriptSpecInternalFunctions.cpp:
        (JSC::esSpecIsConstructor):
        - Changed to use uncheckedArgument since this is only called from internal code.
        (JSC::esSpecIsRegExpObject):
        (JSC::esSpecIsRegExp): Deleted.
        * runtime/ECMAScriptSpecInternalFunctions.h:
        - Changed to check the object for a JSType of RegExpObjectType.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        - Added split fast path.

        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        (JSC::regExpProtoFuncSearchFast):
        (JSC::regExpProtoFuncSearch): Deleted.
        * runtime/RegExpPrototype.h:

        * tests/es6.yaml:
        * tests/stress/regexp-search.js:
        - Rebased test.

2016-04-12  Filip Pizlo  <fpizlo@apple.com>

        PolymorphicAccess::regenerate() shouldn't have to clone non-generated AccessCases
        https://bugs.webkit.org/show_bug.cgi?id=156493

        Reviewed by Geoffrey Garen.

        Cloning AccessCases is only necessary if they hold some artifacts that are used by code that
        they already generated. So, if the state is not Generated, we don't have to bother with
        cloning them.

        This should speed up PolymorphicAccess regeneration a bit more.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::commit):
        (JSC::PolymorphicAccess::regenerate):

2016-04-13  Mark Lam  <mark.lam@apple.com>

        ES6: Implement String.prototype.split and RegExp.prototype[@@split].
        https://bugs.webkit.org/show_bug.cgi?id=156013

        Reviewed by Keith Miller.

        Re-landing r199393 now that the shadow chicken crash has been fixed.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/GlobalObject.js:
        (speciesConstructor):
        * builtins/PromisePrototype.js:
        - refactored to use the @speciesConstructor internal function.

        * builtins/RegExpPrototype.js:
        (advanceStringIndex):
        - refactored from @advanceStringIndexUnicode() to be match the spec.
          Benchmarks show that there's no advantage in doing the unicode check outside
          of the advanceStringIndexUnicode part.  So, I simplified the code to match the
          spec (especially since @@split needs to call advanceStringIndex from more than
          1 location).
        (match):
        - Removed an unnecessary call to @Object because it was already proven above.
        - Changed to use advanceStringIndex instead of advanceStringIndexUnicode.
          Again, there's no perf regression for this.
        (regExpExec):
        (hasObservableSideEffectsForRegExpSplit):
        (split):
        (advanceStringIndexUnicode): Deleted.

        * builtins/StringPrototype.js:
        (split):
        - Modified to use RegExp.prototype[@@split].

        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        (JSC::BytecodeIntrinsicRegistry::lookup):
        * bytecode/BytecodeIntrinsicRegistry.h:
        - Added the @@split symbol.

        * runtime/CommonIdentifiers.h:
        * runtime/ECMAScriptSpecInternalFunctions.cpp: Added.
        (JSC::esSpecIsConstructor):
        (JSC::esSpecIsRegExp):
        * runtime/ECMAScriptSpecInternalFunctions.h: Added.

        * runtime/JSGlobalObject.cpp:
        (JSC::getGetterById):
        (JSC::JSGlobalObject::init):

        * runtime/PropertyDescriptor.cpp:
        (JSC::PropertyDescriptor::setDescriptor):
        - Removed an assert that is no longer valid.

        * runtime/RegExpObject.h:
        - Made advanceStringUnicode() public so that it can be re-used by the regexp split
          fast path.

        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        (JSC::regExpProtoFuncExec):
        (JSC::regExpProtoFuncSearch):
        (JSC::advanceStringIndex):
        (JSC::regExpProtoFuncSplitFast):
        * runtime/RegExpPrototype.h:

        * runtime/StringObject.h:
        (JSC::jsStringWithReuse):
        (JSC::jsSubstring):
        - Hoisted some utility functions from StringPrototype.cpp so that they can be
          reused by the regexp split fast path.

        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::stringProtoFuncSplitFast):
        (JSC::stringProtoFuncSubstr):
        (JSC::builtinStringSubstrInternal):
        (JSC::stringProtoFuncSubstring):
        (JSC::stringIncludesImpl):
        (JSC::stringProtoFuncIncludes):
        (JSC::builtinStringIncludesInternal):
        (JSC::jsStringWithReuse): Deleted.
        (JSC::jsSubstring): Deleted.
        (JSC::stringProtoFuncSplit): Deleted.
        * runtime/StringPrototype.h:

        * tests/es6.yaml:

2016-04-13  Mark Lam  <mark.lam@apple.com>

        ShadowChicken::visitChildren() should not visit tailMarkers and throwMarkers.
        https://bugs.webkit.org/show_bug.cgi?id=156532

        Reviewed by Saam Barati and Filip Pizlo.

        ShadowChicken can store tailMarkers and throwMarkers in its log, specifically in
        the callee field of a log packet.  However, ShadowChicken::visitChildren()
        unconditionally visits the callee field of each packet as if they are real
        objects.  If visitChildren() encounters one of these markers in the log, we get a
        crash.

        This crash was observed in the v8-v6/v8-regexp.js stress test running with shadow
        chicken when r199393 landed.  r199393 introduced tail calls to a RegExp split
        fast path, and the v8-regexp.js test exercised this fast path a lot.  Throw in
        some timely GCs, and we get a crash party.

        The fix is to have ShadowChicken::visitChildren() filter out the tailMarker and
        throwMarker.

        Alternatively, if perf is an issue, we can allocate 2 dedicated objects for
        these markers so that ShadowChicken can continue to visit them.  For now, I'm
        going with the filter.

        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::visitChildren):

2016-04-13  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Add @@toStringTag to GeneratorFunction
        https://bugs.webkit.org/show_bug.cgi?id=156499

        Reviewed by Mark Lam.

        GeneratorFunction.prototype has @@toStringTag property, "GeneratorFunction".
        https://tc39.github.io/ecma262/#sec-generatorfunction.prototype-@@tostringtag

        * runtime/GeneratorFunctionPrototype.cpp:
        (JSC::GeneratorFunctionPrototype::finishCreation):
        * tests/es6.yaml:
        * tests/es6/well-known_symbols_Symbol.toStringTag_new_built-ins.js: Added.
        (test):

2016-04-13  Alberto Garcia  <berto@igalia.com>

        Fix build in glibc-based BSD systems
        https://bugs.webkit.org/show_bug.cgi?id=156533

        Reviewed by Carlos Garcia Campos.

        Change the order of the #elif conditionals so glibc-based BSD
        systems (e.g. Debian GNU/kFreeBSD) use the code inside the
        OS(FREEBSD) blocks.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::Thread::Registers::stackPointer):
        (JSC::MachineThreads::Thread::Registers::framePointer):
        (JSC::MachineThreads::Thread::Registers::instructionPointer):
        (JSC::MachineThreads::Thread::Registers::llintPC):

2016-04-12  Keith Miller  <keith_miller@apple.com>

        Unreviewed undo change from ArrayClass to ArrayWithUndecided, which
        was not intedend to land with r199397.

        * runtime/ArrayPrototype.h:
        (JSC::ArrayPrototype::createStructure):

2016-04-12  Mark Lam  <mark.lam@apple.com>

        Rollout: ES6: Implement String.prototype.split and RegExp.prototype[@@split].
        https://bugs.webkit.org/show_bug.cgi?id=156013

        Speculative rollout to fix 32-bit shadow-chicken.yaml/tests/v8-v6/v8-regexp.js.shadow-chicken test failure.

        Not reviewed.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/GlobalObject.js:
        (speciesGetter):
        (speciesConstructor): Deleted.
        * builtins/PromisePrototype.js:
        * builtins/RegExpPrototype.js:
        (advanceStringIndexUnicode):
        (match):
        (advanceStringIndex): Deleted.
        (regExpExec): Deleted.
        (hasObservableSideEffectsForRegExpSplit): Deleted.
        (split): Deleted.
        * builtins/StringPrototype.js:
        (repeat):
        (split): Deleted.
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        (JSC::BytecodeIntrinsicRegistry::lookup):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * runtime/CommonIdentifiers.h:
        * runtime/ECMAScriptSpecInternalFunctions.cpp: Removed.
        * runtime/ECMAScriptSpecInternalFunctions.h: Removed.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::setGlobalThis):
        (JSC::JSGlobalObject::init):
        (JSC::getGetterById): Deleted.
        * runtime/PropertyDescriptor.cpp:
        (JSC::PropertyDescriptor::setDescriptor):
        * runtime/RegExpObject.h:
        (JSC::RegExpObject::offsetOfLastIndexIsWritable):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        (JSC::regExpProtoFuncExec):
        (JSC::regExpProtoFuncSearch):
        (JSC::advanceStringIndex): Deleted.
        (JSC::regExpProtoFuncSplitFast): Deleted.
        * runtime/RegExpPrototype.h:
        * runtime/StringObject.h:
        (JSC::jsStringWithReuse): Deleted.
        (JSC::jsSubstring): Deleted.
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::jsStringWithReuse):
        (JSC::jsSubstring):
        (JSC::substituteBackreferencesSlow):
        (JSC::splitStringByOneCharacterImpl):
        (JSC::stringProtoFuncSplit):
        (JSC::stringProtoFuncSubstr):
        (JSC::stringProtoFuncSubstring):
        (JSC::stringProtoFuncEndsWith):
        (JSC::stringProtoFuncIncludes):
        (JSC::stringProtoFuncIterator):
        (JSC::stringProtoFuncSplitFast): Deleted.
        (JSC::builtinStringSubstrInternal): Deleted.
        (JSC::stringIncludesImpl): Deleted.
        (JSC::builtinStringIncludesInternal): Deleted.
        * runtime/StringPrototype.h:
        * tests/es6.yaml:

2016-04-12  Mark Lam  <mark.lam@apple.com>

        Remove 2 unused JSC options.
        https://bugs.webkit.org/show_bug.cgi?id=156526

        Reviewed by Benjamin Poulain.

        The options JSC_assertICSizing and JSC_dumpFailedICSizing are no longer in use
        now that we have B3.

        * runtime/Options.h:

2016-04-12  Keith Miller  <keith_miller@apple.com>

        [ES6] Add support for Symbol.isConcatSpreadable.
        https://bugs.webkit.org/show_bug.cgi?id=155351

        Reviewed by Saam Barati.

        This patch adds support for Symbol.isConcatSpreadable. In order to do so it was necessary to move the
        Array.prototype.concat function to JS. A number of different optimizations were needed to make such the move to
        a builtin performant. First, four new DFG intrinsics were added.

        1) IsArrayObject (I would have called it IsArray but we use the same name for an IndexingType): an intrinsic of
           the Array.isArray function.
        2) IsJSArray: checks the first child is a JSArray object.
        3) IsArrayConstructor: checks the first child is an instance of ArrayConstructor.
        4) CallObjectConstructor: an intrinsic of the Object constructor.

        IsActualObject, IsJSArray, and CallObjectConstructor can all be converted into constants in the abstract interpreter if
        we are able to prove that the first child is an Array or for ToObject an Object.

        In order to further improve the perfomance we also now cover more indexing types in our fast path memcpy
        code. Before we would only memcpy Arrays if they had the same indexing type and did not have Array storage and
        were not undecided. Now the memcpy code covers the following additional two cases: One array is undecided and
        the other is a non-array storage and the case where one array is Int32 and the other is contiguous (we map this
        into a contiguous array).

        This patch also adds a new fast path for concat with more than one array argument by using memcpy to append
        values onto the result array. This works roughly the same as the two array fast path using the same methodology
        to decide if we can memcpy the other butterfly into the result butterfly.

        Two new debugging tools are also added to the jsc cli. One is a version of the print function with a private
        name so it can be used for debugging builtins. The other is dumpDataLog, which takes a JSValue and runs our
        dataLog function on it.

        Finally, this patch add a new constructor to JSValueRegsTemporary that allows it to reuse the the registers of a
        JSValueOperand if the operand's use count is one.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ArrayPrototype.js:
        (concatSlowPath):
        (concat):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * 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::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::compileIsJSArray):
        (JSC::DFG::SpeculativeJIT::compileIsArrayObject):
        (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor):
        (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
        * dfg/DFGSpeculativeJIT.h:
        (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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::isArray):
        * jit/JITOperations.h:
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionDataLogValue):
        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
        * runtime/ArrayConstructor.h:
        (JSC::isArrayConstructor):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::arrayProtoPrivateFuncIsJSArray):
        (JSC::moveElements):
        (JSC::arrayProtoPrivateFuncConcatMemcpy):
        (JSC::arrayProtoPrivateFuncAppendMemcpy):
        (JSC::arrayProtoFuncConcat): Deleted.
        * runtime/ArrayPrototype.h:
        (JSC::ArrayPrototype::createStructure):
        * runtime/CommonIdentifiers.h:
        * runtime/Intrinsic.h:
        * runtime/JSArray.cpp:
        (JSC::JSArray::appendMemcpy):
        (JSC::JSArray::fastConcatWith): Deleted.
        * runtime/JSArray.h:
        (JSC::JSArray::createStructure):
        (JSC::JSArray::fastConcatType): Deleted.
        * runtime/JSArrayInlines.h: Added.
        (JSC::JSArray::memCopyWithIndexingType):
        (JSC::JSArray::canFastCopy):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSType.h:
        * runtime/ObjectConstructor.h:
        (JSC::constructObject):
        * tests/es6.yaml:
        * tests/stress/array-concat-spread-object.js: Added.
        (arrayEq):
        * tests/stress/array-concat-spread-proxy-exception-check.js: Added.
        (arrayEq):
        * tests/stress/array-concat-spread-proxy.js: Added.
        (arrayEq):
        * tests/stress/array-concat-with-slow-indexingtypes.js: Added.
        (arrayEq):
        * tests/stress/array-species-config-array-constructor.js:

2016-04-12  Saam barati  <sbarati@apple.com>

        Lets not iterate over the constant pool twice every time we link a code block
        https://bugs.webkit.org/show_bug.cgi?id=156517

        Reviewed by Mark Lam.

        I introduced a second iteration over the constant pool when I implemented
        block scoping. I did this because we must clone all the symbol tables when
        we link a CodeBlock. We can just do this cloning when setting the constant
        registers for the first time. There is no need to iterate over the constant
        pool a second time.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::~CodeBlock):
        (JSC::CodeBlock::setConstantRegisters):
        (JSC::CodeBlock::setAlternative):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::replaceConstant):
        (JSC::CodeBlock::setConstantRegisters): Deleted.

2016-04-12  Mark Lam  <mark.lam@apple.com>

        ES6: Implement String.prototype.split and RegExp.prototype[@@split].
        https://bugs.webkit.org/show_bug.cgi?id=156013

        Reviewed by Keith Miller.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/GlobalObject.js:
        (speciesConstructor):
        * builtins/PromisePrototype.js:
        - refactored to use the @speciesConstructor internal function.

        * builtins/RegExpPrototype.js:
        (advanceStringIndex):
        - refactored from @advanceStringIndexUnicode() to be match the spec.
          Benchmarks show that there's no advantage in doing the unicode check outside
          of the advanceStringIndexUnicode part.  So, I simplified the code to match the
          spec (especially since @@split needs to call advanceStringIndex from more than
          1 location).
        (match):
        - Removed an unnecessary call to @Object because it was already proven above.
        - Changed to use advanceStringIndex instead of advanceStringIndexUnicode.
          Again, there's no perf regression for this.
        (regExpExec):
        (hasObservableSideEffectsForRegExpSplit):
        (split):
        (advanceStringIndexUnicode): Deleted.

        * builtins/StringPrototype.js:
        (split):
        - Modified to use RegExp.prototype[@@split].

        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        (JSC::BytecodeIntrinsicRegistry::lookup):
        * bytecode/BytecodeIntrinsicRegistry.h:
        - Added the @@split symbol.

        * runtime/CommonIdentifiers.h:
        * runtime/ECMAScriptSpecInternalFunctions.cpp: Added.
        (JSC::esSpecIsConstructor):
        (JSC::esSpecIsRegExp):
        * runtime/ECMAScriptSpecInternalFunctions.h: Added.

        * runtime/JSGlobalObject.cpp:
        (JSC::getGetterById):
        (JSC::JSGlobalObject::init):

        * runtime/PropertyDescriptor.cpp:
        (JSC::PropertyDescriptor::setDescriptor):
        - Removed an assert that is no longer valid.

        * runtime/RegExpObject.h:
        - Made advanceStringUnicode() public so that it can be re-used by the regexp split
          fast path.

        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        (JSC::regExpProtoFuncExec):
        (JSC::regExpProtoFuncSearch):
        (JSC::advanceStringIndex):
        (JSC::regExpProtoFuncSplitFast):
        * runtime/RegExpPrototype.h:

        * runtime/StringObject.h:
        (JSC::jsStringWithReuse):
        (JSC::jsSubstring):
        - Hoisted some utility functions from StringPrototype.cpp so that they can be
          reused by the regexp split fast path.

        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::stringProtoFuncSplitFast):
        (JSC::stringProtoFuncSubstr):
        (JSC::builtinStringSubstrInternal):
        (JSC::stringProtoFuncSubstring):
        (JSC::stringIncludesImpl):
        (JSC::stringProtoFuncIncludes):
        (JSC::builtinStringIncludesInternal):
        (JSC::jsStringWithReuse): Deleted.
        (JSC::jsSubstring): Deleted.
        (JSC::stringProtoFuncSplit): Deleted.
        * runtime/StringPrototype.h:

        * tests/es6.yaml:

2016-04-12  Keith Miller  <keith_miller@apple.com>

        AbstractValue should use the result type to filter structures
        https://bugs.webkit.org/show_bug.cgi?id=156516

        Reviewed by Geoffrey Garen.

        When filtering an AbstractValue with a SpeculatedType we would not use the merged type when
        filtering out the valid structures (despite what the comment directly above said). This
        would cause us to crash if our structure-set was Top and the two speculated types were
        different kinds of cells.

        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::filter):
        * tests/stress/ai-consistency-filter-cells.js: Added.
        (get value):
        (attribute.value.get record):
        (attribute.attrs.get this):
        (get foo):
        (let.thisValue.return.serialize):
        (let.thisValue.transformFor):

2016-04-12  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, remove FIXME for https://bugs.webkit.org/show_bug.cgi?id=156457 and replace it
        with a comment that describes what we do now.

        * bytecode/PolymorphicAccess.h:

2016-04-12  Saam barati  <sbarati@apple.com>

        isLocked() assertion broke builds because ConcurrentJITLock isn't always a real lock.

        Rubber-stamped by Filip Pizlo.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::resultProfileForBytecodeOffset):
        (JSC::CodeBlock::ensureResultProfile):

2016-04-11  Filip Pizlo  <fpizlo@apple.com>

        PolymorphicAccess should buffer AccessCases before regenerating
        https://bugs.webkit.org/show_bug.cgi?id=156457

        Reviewed by Benjamin Poulain.

        Prior to this change, whenever we added an AccessCase to a PolymorphicAccess, we would
        regenerate the whole stub. That meant that we'd do O(N^2) work for N access cases.

        One way to fix this is to have each AccessCase generate a stub just for itself, which
        cascades down to the already-generated cases. But that removes the binary switch
        optimization, which makes the IC perform great even when there are many cases.

        This change fixes the issue by buffering access cases. When we take slow path and try to add
        a new case, the StructureStubInfo will usually just buffer the new case without generating
        new code. We simply guarantee that after we buffer a case, we will take at most
        Options::repatchBufferingCountdown() slow path calls before generating code for it. That
        option is currently 7. Taking 7 more slow paths means that we have 7 more opportunities to
        gather more access cases, or to realize that this IC is too crazy to bother with.

        This change ensures that the DFG still gets the same kind of profiling. This is because the
        buffered AccessCases are still part of PolymorphicAccess and so are still scanned by
        GetByIdStatus and PutByIdStatus. The fact that the AccessCases hadn't been generated and so
        hadn't executed doesn't change much. Mainly, it increases the likelihood that the DFG will
        see an access case that !couldStillSucceed(). The DFG's existing profile parsing logic can
        handle this just fine.
        
        There are a bunch of algorithmic changes here. StructureStubInfo now caches the set of
        structures that it has seen as a guard to prevent adding lots of redundant cases, in case
        we see the same 7 cases after buffering the first one. This cache means we won't wastefully
        allocate 7 identical AccessCase instances. PolymorphicAccess is now restructured around
        having separate addCase() and regenerate() calls. That means a bit more moving data around.
        So far that seems OK for performance, probably since it's O(N) work rather than O(N^2) work.
        There is room for improvement for future patches, to be sure.
        
        This is benchmarking as slightly positive or neutral on JS benchmarks. It's meant to reduce
        pathologies I saw in page loads.

        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::PolymorphicAccess):
        (JSC::PolymorphicAccess::~PolymorphicAccess):
        (JSC::PolymorphicAccess::addCases):
        (JSC::PolymorphicAccess::addCase):
        (JSC::PolymorphicAccess::visitWeak):
        (JSC::PolymorphicAccess::dump):
        (JSC::PolymorphicAccess::commit):
        (JSC::PolymorphicAccess::regenerate):
        (JSC::PolymorphicAccess::aboutToDie):
        (WTF::printInternal):
        (JSC::PolymorphicAccess::regenerateWithCases): Deleted.
        (JSC::PolymorphicAccess::regenerateWithCase): Deleted.
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessCase::isGetter):
        (JSC::AccessCase::callLinkInfo):
        (JSC::AccessGenerationResult::AccessGenerationResult):
        (JSC::AccessGenerationResult::madeNoChanges):
        (JSC::AccessGenerationResult::gaveUp):
        (JSC::AccessGenerationResult::buffered):
        (JSC::AccessGenerationResult::generatedNewCode):
        (JSC::AccessGenerationResult::generatedFinalCode):
        (JSC::AccessGenerationResult::shouldGiveUpNow):
        (JSC::AccessGenerationResult::generatedSomeCode):
        (JSC::PolymorphicAccess::isEmpty):
        (JSC::PolymorphicAccess::size):
        (JSC::PolymorphicAccess::at):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeForStubInfo):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::StructureStubInfo):
        (JSC::StructureStubInfo::addAccessCase):
        (JSC::StructureStubInfo::reset):
        (JSC::StructureStubInfo::visitWeakReferences):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::considerCaching):
        (JSC::StructureStubInfo::willRepatch): Deleted.
        (JSC::StructureStubInfo::willCoolDown): Deleted.
        * jit/JITOperations.cpp:
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        (JSC::repatchGetByID):
        (JSC::tryCachePutByID):
        (JSC::repatchPutByID):
        (JSC::tryRepatchIn):
        (JSC::repatchIn):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::putByIndex):
        (JSC::JSValue::structureOrNull):
        (JSC::JSValue::structureOrUndefined):
        * runtime/Options.h:

2016-04-12  Saam barati  <sbarati@apple.com>

        There is a race with the compiler thread and the main thread with result profiles
        https://bugs.webkit.org/show_bug.cgi?id=156503

        Reviewed by Filip Pizlo.

        The compiler thread should not be asking for a result
        profile while the execution thread is creating one.
        We must guard against such races with a lock.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::resultProfileForBytecodeOffset):
        (JSC::CodeBlock::ensureResultProfile):
        (JSC::CodeBlock::capabilityLevel):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::couldTakeSlowCase):
        (JSC::CodeBlock::numberOfResultProfiles):
        (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
        (JSC::CodeBlock::ensureResultProfile): Deleted.

2016-04-12  Commit Queue  <commit-queue@webkit.org>

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

        memset_s is indeed necessary (Requested by alexchristensen_ on
        #webkit).

        Reverted changeset:

        "Build fix after r199299."
        https://bugs.webkit.org/show_bug.cgi?id=155508
        http://trac.webkit.org/changeset/199339

2016-04-12  Guillaume Emont  <guijemont@igalia.com>

        MIPS: add MacroAssemblerMIPS::store8(TrustedImm32,ImplicitAddress)
        https://bugs.webkit.org/show_bug.cgi?id=156481

        This method with this signature is used by r199075, and therefore
        WebKit doesn't build on MIPS since then.

        Reviewed by Mark Lam.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::store8):

2016-04-12  Saam barati  <sbarati@apple.com>

        We incorrectly parse arrow function expressions
        https://bugs.webkit.org/show_bug.cgi?id=156373

        Reviewed by Mark Lam.

        This patch removes the notion of "isEndOfArrowFunction".
        This was a very weird function and it was incorrect.
        It checked that the arrow functions with concise body
        grammar production "had a valid ending". "had a valid
        ending" is in quotes because concise body arrow functions
        have a valid ending as long as their body has a valid
        assignment expression. I've removed all notion of this
        function because it was wrong and was causing us
        to throw syntax errors on valid programs.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::nextTokenIsColon):
        (JSC::Lexer<T>::lex):
        (JSC::Lexer<T>::setTokenPosition): Deleted.
        * parser/Lexer.h:
        (JSC::Lexer::setIsReparsingFunction):
        (JSC::Lexer::isReparsingFunction):
        (JSC::Lexer::lineNumber):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBodySourceElements):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/Parser.h:
        (JSC::Parser::matchIdentifierOrKeyword):
        (JSC::Parser::tokenStart):
        (JSC::Parser::autoSemiColon):
        (JSC::Parser::canRecurse):
        (JSC::Parser::isEndOfArrowFunction): Deleted.
        (JSC::Parser::setEndOfStatement): Deleted.
        * tests/stress/arrowfunction-others.js:
        (testCase):
        (simpleArrowFunction):
        (truthy):
        (falsey):

2016-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] addStaticGlobals should emit SymbolTableEntry watchpoints to encourage constant folding in DFG
        https://bugs.webkit.org/show_bug.cgi?id=155110

        Reviewed by Saam Barati.

        `addStaticGlobals` does not emit SymbolTableEntry watchpoints for the added entries.
        So, all the global variable lookups pointing to these static globals are not converted
        into constants in DFGBytecodeGenerator: this fact leaves these lookups as GetGlobalVar.
        Such thing avoids constant folding chance and emits CheckCell for @privateFunction inlining.
        This operation is pure overhead.

        Static globals are not configurable, and they are typically non-writable.
        So they are constants in almost all the cases.

        This patch initializes watchpoints for these static globals.
        These watchpoints allow DFG to convert these nodes into constants in DFG BytecodeParser.
        These watchpoints includes many builtin operations and `undefined`.

        The microbenchmark, many-foreach-calls shows 5 - 7% improvement since it removes unnecessary CheckCell.

        * bytecode/VariableWriteFireDetail.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::addGlobalVar):
        (JSC::JSGlobalObject::addStaticGlobals):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTablePutTouchWatchpointSet):
        (JSC::symbolTablePutInvalidateWatchpointSet):
        (JSC::symbolTablePut):
        (JSC::symbolTablePutWithAttributesTouchWatchpointSet): Deleted.
        * runtime/SymbolTable.h:
        (JSC::SymbolTableEntry::SymbolTableEntry):
        (JSC::SymbolTableEntry::operator=):
        (JSC::SymbolTableEntry::swap):

2016-04-12  Alex Christensen  <achristensen@webkit.org>

        Build fix after r199299.
        https://bugs.webkit.org/show_bug.cgi?id=155508

        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
        memset_s is not defined.  __STDC_WANT_LIB_EXT1__ is not defined anywhere.
        Since the return value is unused and set_constraint_handler_s is never called
        I'm chaning it to memset.

2016-04-11  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] B3 can use undefined bits or not defined required bits when spilling
        https://bugs.webkit.org/show_bug.cgi?id=156486

        Reviewed by Filip Pizlo.

        Spilling had issues when replacing arguments in place.

        The problems are:
        1) If we have a 32bit stackslot, a x86 instruction could still try to load 64bits from it.
        2) If we have a 64bit stackslot, Move32 would only set half the bits.
        3) We were reducing Move to Move32 even if the top bits are read from the stack slot.

        The case 1 appear with something like this:
            Move32 %tmp0, %tmp1
            Op64 %tmp1, %tmp2, %tmp3
        When we spill %tmp1, the stack slot is 32bit, Move32 sets 32bits
        but Op64 supports addressing for %tmp1. When we substitute %tmp1 in Op64,
        we are creating a 64bit read for a 32bit stack slot.

        The case 2 is an other common one. If we have:
            BB#1
                Move32 %tmp0, %tmp1
                Jump #3
            BB#2
                Op64 %tmp0, %tmp1
                Jump #3
            BB#3
                Use64 %tmp1

        We have a stack slot of 64bits. When spilling %tmp1 in #1, we are
        effectively doing a 32bit store on the stack slot, leaving the top bits undefined.

        Case 3 is pretty much the same as 2 but we create the Move32 ourself
        because the source is a 32bit with ZDef.

        Case (1) is solved by requiring that the stack slot is at least as large as the largest
        use/def of that tmp.

        Case (2) and (3) are solved by not replacing a Tmp by an Address if the Def
        is smaller than the stack slot.

        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testSpillDefSmallerThanUse):
        (JSC::B3::testSpillUseLargerThanDef):
        (JSC::B3::run):

2016-04-11  Brian Burg  <bburg@apple.com>

        Web Inspector: get rid of InspectorBasicValue and InspectorString subclasses
        https://bugs.webkit.org/show_bug.cgi?id=156407
        <rdar://problem/25627659>

        Reviewed by Joseph Pecoraro.

        There's no point having these subclasses as they don't save any space.
        Add a StringImpl to the union and merge some implementations of writeJSON.

        Rename m_data to m_map and explicitly name the union as InspectorValue::m_value.
        If the value is a string and the string is not empty or null (i.e., it has a
        StringImpl), then we need to ref() and deref() the string as the InspectorValue
        is created or destroyed.

        Move uses of the subclass to InspectorValue and delete redundant methods.
        Now, most InspectorValue methods are non-virtual so they can be templated.

        * bindings/ScriptValue.cpp:
        (Deprecated::jsToInspectorValue):
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::makeCall):
        Don't used deleted subclasses.

        * inspector/InspectorValues.cpp:
        (Inspector::InspectorValue::null):
        (Inspector::InspectorValue::create):
        (Inspector::InspectorValue::asValue):
        (Inspector::InspectorValue::asBoolean):
        (Inspector::InspectorValue::asDouble):
        (Inspector::InspectorValue::asInteger):
        (Inspector::InspectorValue::asString):
        These only need one implementation now.

        (Inspector::InspectorValue::writeJSON):
        Still a virtual method since Object and Array need their members.

        (Inspector::InspectorObjectBase::InspectorObjectBase):
        (Inspector::InspectorBasicValue::asBoolean): Deleted.
        (Inspector::InspectorBasicValue::asDouble): Deleted.
        (Inspector::InspectorBasicValue::asInteger): Deleted.
        (Inspector::InspectorBasicValue::writeJSON): Deleted.
        (Inspector::InspectorString::asString): Deleted.
        (Inspector::InspectorString::writeJSON): Deleted.
        (Inspector::InspectorString::create): Deleted.
        (Inspector::InspectorBasicValue::create): Deleted.

        * inspector/InspectorValues.h:
        (Inspector::InspectorObjectBase::find):
        (Inspector::InspectorObjectBase::setBoolean):
        (Inspector::InspectorObjectBase::setInteger):
        (Inspector::InspectorObjectBase::setDouble):
        (Inspector::InspectorObjectBase::setString):
        (Inspector::InspectorObjectBase::setValue):
        (Inspector::InspectorObjectBase::setObject):
        (Inspector::InspectorObjectBase::setArray):
        (Inspector::InspectorArrayBase::pushBoolean):
        (Inspector::InspectorArrayBase::pushInteger):
        (Inspector::InspectorArrayBase::pushDouble):
        (Inspector::InspectorArrayBase::pushString):
        (Inspector::InspectorArrayBase::pushValue):
        (Inspector::InspectorArrayBase::pushObject):
        (Inspector::InspectorArrayBase::pushArray):
        Use new factory methods.

        * replay/EncodedValue.cpp:
        (JSC::ScalarEncodingTraits<bool>::encodeValue):
        (JSC::ScalarEncodingTraits<double>::encodeValue):
        (JSC::ScalarEncodingTraits<float>::encodeValue):
        (JSC::ScalarEncodingTraits<int32_t>::encodeValue):
        (JSC::ScalarEncodingTraits<int64_t>::encodeValue):
        (JSC::ScalarEncodingTraits<uint32_t>::encodeValue):
        (JSC::ScalarEncodingTraits<uint64_t>::encodeValue):
        * replay/EncodedValue.h:
        Use new factory methods.

2016-04-11  Filip Pizlo  <fpizlo@apple.com>

        It should be possible to edit StructureStubInfo without recompiling the world
        https://bugs.webkit.org/show_bug.cgi?id=156470

        Reviewed by Keith Miller.

        This change makes it less painful to make changes to the IC code. It used to be that any
        change to StructureStubInfo caused every JIT-related file to get recompiled. Now only a
        smaller set of files - ones that actually peek into StructureStubInfo - will recompile. This
        is mainly because CodeBlock.h no longer includes StructureStubInfo.h.

        * bytecode/ByValInfo.h:
        * bytecode/CodeBlock.cpp:
        * bytecode/CodeBlock.h:
        * bytecode/GetByIdStatus.cpp:
        * bytecode/GetByIdStatus.h:
        * bytecode/PutByIdStatus.cpp:
        * bytecode/PutByIdStatus.h:
        * bytecode/StructureStubInfo.h:
        (JSC::getStructureStubInfoCodeOrigin):
        * dfg/DFGByteCodeParser.cpp:
        * dfg/DFGJITCompiler.cpp:
        * dfg/DFGOSRExitCompilerCommon.cpp:
        * dfg/DFGSpeculativeJIT.h:
        * ftl/FTLLowerDFGToB3.cpp:
        * ftl/FTLSlowPathCall.h:
        * jit/IntrinsicEmitter.cpp:
        * jit/JITInlineCacheGenerator.cpp:
        * jit/JITInlineCacheGenerator.h:
        * jit/JITOperations.cpp:
        * jit/JITPropertyAccess.cpp:
        * jit/JITPropertyAccess32_64.cpp:

2016-04-11  Skachkov Oleksandr  <gskachkov@gmail.com>

        Remove NewArrowFunction from DFG IR
        https://bugs.webkit.org/show_bug.cgi?id=156439

        Reviewed by Saam Barati.

        It seems that NewArrowFunction was left in DFG IR during refactoring by mistake.

        * dfg/DFGAbstractInterpreterInlines.h:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGClobbersExitState.cpp:
        * dfg/DFGDoesGC.cpp:
        * dfg/DFGFixupPhase.cpp:
        * dfg/DFGMayExit.cpp:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToPhantomNewFunction):
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunction):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        * dfg/DFGSpeculativeJIT64.cpp:
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * dfg/DFGStructureRegistrationPhase.cpp:
        * ftl/FTLCapabilities.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):

2016-04-05  Oliver Hunt  <oliver@apple.com>

        Remove compile time define for SEPARATED_HEAP
        https://bugs.webkit.org/show_bug.cgi?id=155508

        Reviewed by Mark Lam.

        Remove the SEPARATED_HEAP compile time flag. The separated
        heap is available, but off by default, on x86_64, ARMv7, and
        ARM64.

        Working through the issues that happened last time essentially
        required implementing the ARMv7 path for the separated heap
        just so I could find all the ways it was going wrong.

        We fixed all the logic by making the branch and jump logic in
        the linker and assemblers take two parameters, the location to
        write to, and the location we'll actually be writing to. We 
        need to do this because it's no longer sufficient to compute
        jumps relative to region the linker is writing to.

        The repatching jump, branch, and call functions only need the
        executable address as the patching is performed directly using
        performJITMemcpy function which works in terms of the executable
        address.

        There is no performance impact on jsc-benchmarks with the separate
        heap either emabled or disabled.

        * Configurations/FeatureDefines.xcconfig:
        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::linkJump):
        (JSC::ARM64Assembler::linkCall):
        (JSC::ARM64Assembler::relinkJump):
        (JSC::ARM64Assembler::relinkCall):
        (JSC::ARM64Assembler::link):
        (JSC::ARM64Assembler::linkJumpOrCall):
        (JSC::ARM64Assembler::linkCompareAndBranch):
        (JSC::ARM64Assembler::linkConditionalBranch):
        (JSC::ARM64Assembler::linkTestAndBranch):
        (JSC::ARM64Assembler::relinkJumpOrCall):
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2):
        (JSC::ARMv7Assembler::revertJumpTo_movT3):
        (JSC::ARMv7Assembler::link):
        (JSC::ARMv7Assembler::linkJump):
        (JSC::ARMv7Assembler::relinkJump):
        (JSC::ARMv7Assembler::repatchCompact):
        (JSC::ARMv7Assembler::replaceWithJump):
        (JSC::ARMv7Assembler::replaceWithLoad):
        (JSC::ARMv7Assembler::replaceWithAddressComputation):
        (JSC::ARMv7Assembler::setInt32):
        (JSC::ARMv7Assembler::setUInt7ForLoad):
        (JSC::ARMv7Assembler::isB):
        (JSC::ARMv7Assembler::isBX):
        (JSC::ARMv7Assembler::isMOV_imm_T3):
        (JSC::ARMv7Assembler::isMOVT):
        (JSC::ARMv7Assembler::isNOP_T1):
        (JSC::ARMv7Assembler::isNOP_T2):
        (JSC::ARMv7Assembler::linkJumpT1):
        (JSC::ARMv7Assembler::linkJumpT2):
        (JSC::ARMv7Assembler::linkJumpT3):
        (JSC::ARMv7Assembler::linkJumpT4):
        (JSC::ARMv7Assembler::linkConditionalJumpT4):
        (JSC::ARMv7Assembler::linkBX):
        (JSC::ARMv7Assembler::linkConditionalBX):
        (JSC::ARMv7Assembler::linkJumpAbsolute):
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::copyCompactAndLinkCode):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::link):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::link):
        * jit/ExecutableAllocator.h:
        (JSC::performJITMemcpy):
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
        (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
        (JSC::FixedVMPoolExecutableAllocator::genericWriteToJITRegion):
        (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): Deleted.
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:

2016-04-10  Filip Pizlo  <fpizlo@apple.com>

        Clean up how we reason about the states of AccessCases
        https://bugs.webkit.org/show_bug.cgi?id=156454

        Reviewed by Mark Lam.
        
        Currently when we add an AccessCase to a PolymorphicAccess stub, we regenerate the stub.
        That means that as we grow a stub to have N cases, we will do O(N^2) generation work. I want
        to explore buffering AccessCases so that we can do O(N) generation work instead. But to
        before I go there, I want to make sure that the statefulness of AccessCase makes sense. So,
        I broke it down into three different states and added assertions about the transitions. I
        also broke out a separate operation called AccessCase::commit(), which is the work that
        cannot be buffered since there cannot be any JS effects between when the AccessCase was
        created and when we do the work in commit().
        
        This opens up a fairly obvious path to buffering AccessCases: add them to the list without
        regenerating. Then when we do eventually trigger regeneration, those cases will get cloned
        and generated automagically. This patch doesn't implement this technique yet, but gives us
        an opportunity to independently test the scaffolding necessary to do it.

        This is perf-neutral on lots of tests.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessGenerationResult::dump):
        (JSC::AccessCase::clone):
        (JSC::AccessCase::commit):
        (JSC::AccessCase::guardedByStructureCheck):
        (JSC::AccessCase::dump):
        (JSC::AccessCase::generateWithGuard):
        (JSC::AccessCase::generate):
        (JSC::AccessCase::generateImpl):
        (JSC::PolymorphicAccess::regenerateWithCases):
        (JSC::PolymorphicAccess::regenerate):
        (WTF::printInternal):
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessCase::type):
        (JSC::AccessCase::state):
        (JSC::AccessCase::offset):
        (JSC::AccessCase::viaProxy):
        (JSC::AccessCase::callLinkInfo):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::addAccessCase):
        * bytecode/Watchpoint.h:
        * dfg/DFGOperations.cpp:
        * jit/Repatch.cpp:
        (JSC::repatchGetByID):
        (JSC::repatchPutByID):
        (JSC::repatchIn):
        * runtime/VM.cpp:
        (JSC::VM::dumpRegExpTrace):
        (JSC::VM::ensureWatchpointSetForImpureProperty):
        (JSC::VM::registerWatchpointForImpureProperty):
        (JSC::VM::addImpureProperty):
        * runtime/VM.h:

2016-04-11  Fujii Hironori  <Hironori.Fujii@jp.sony.com>

        [CMake] Make FOLDER property INHERITED
        https://bugs.webkit.org/show_bug.cgi?id=156460

        Reviewed by Brent Fulgham.

        * CMakeLists.txt:
        * shell/CMakeLists.txt:
        * shell/PlatformWin.cmake:
        Set FOLDER property as a directory property not a target property

2016-04-09  Keith Miller  <keith_miller@apple.com>

        tryGetById should be supported by the DFG/FTL
        https://bugs.webkit.org/show_bug.cgi?id=156378

        Reviewed by Filip Pizlo.

        This patch adds support for tryGetById in the DFG/FTL. It adds a new DFG node
        TryGetById, which acts similarly to the normal GetById DFG node. One key
        difference between GetById and TryGetById is that in the LLInt and Baseline
        we do not profile the result type. This profiling is unnessary for the current
        use case of tryGetById, which is expected to be a strict equality comparision
        against a specific object or undefined. In either case other DFG optimizations
        will make this equally fast with or without the profiling information.

        Additionally, this patch adds new reuse modes for JSValueRegsTemporary that take
        an operand and attempt to reuse the registers for that operand if they are free
        after the current DFG node.

        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleGetById):
        (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/DFGNode.h:
        (JSC::DFG::Node::hasIdentifier):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileTryGetById):
        (JSC::DFG::JSValueRegsTemporary::JSValueRegsTemporary):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::GPRTemporary::operator=):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
        (JSC::FTL::DFG::LowerDFGToB3::getById):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * tests/stress/try-get-by-id.js:
        (tryGetByIdTextStrict):
        (get let):
        (let.get createBuiltin):
        (get throw):
        (getCaller.obj.1.throw.new.Error): Deleted.

2016-04-09  Saam barati  <sbarati@apple.com>

        Allocation sinking SSA Defs are allowed to have replacements
        https://bugs.webkit.org/show_bug.cgi?id=156444

        Reviewed by Filip Pizlo.

        Consider the following program and the annotations that explain why
        the SSA defs we create in allocation sinking can have replacements.

        function foo(a1) {
            let o1 = {x: 20, y: 50};
            let o2 = {y: 40, o1: o1};
            let o3 = {};
        
            // We're Defing a new variable here, call it o3_field.
            // o3_field is defing the value that is the result of 
            // a GetByOffset that gets eliminated through allocation sinking.
            o3.field = o1.y;
        
            dontCSE();
        
            // This control flow is here to not allow the phase to consult
            // its local SSA mapping (which properly handles replacements)
            // for the value of o3_field.
            if (a1) {
                a1 = true; 
            } else {
                a1 = false;
            }
        
            // Here, we ask for the reaching def of o3_field, and assert
            // it doesn't have a replacement. It does have a replacement
            // though. The original Def was the GetByOffset. We replaced
            // that GetByOffset with the value of the o1_y variable.
            let value = o3.field;
            assert(value === 50);
        }

        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * tests/stress/allocation-sinking-defs-may-have-replacements.js: Added.
        (dontCSE):
        (assert):
        (foo):

2016-04-09  Commit Queue  <commit-queue@webkit.org>

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

        Caused many many leaks (Requested by ap on #webkit).

        Reverted changeset:

        "Web Inspector: get rid of InspectorBasicValue and
        InspectorString subclasses"
        https://bugs.webkit.org/show_bug.cgi?id=156407
        http://trac.webkit.org/changeset/199242

2016-04-09  Filip Pizlo  <fpizlo@apple.com>

        Debug JSC test failure: stress/multi-put-by-offset-reallocation-butterfly-cse.js.ftl-no-cjit-small-pool
        https://bugs.webkit.org/show_bug.cgi?id=156406

        Reviewed by Saam Barati.

        The failure was because the GC ran from within the butterfly allocation call in a put_by_id
        transition AccessCase that had to deal with indexing storage. When the GC runs in a call from a stub,
        then we need to be extra careful:

        1) The GC may reset the IC and delete the stub. So, the stub needs to tell the GC that it might be on
           the stack during GC, so that the GC keeps it alive if it's currently running.
        
        2) If the stub uses (dereferences or stores) some object after the call, then we need to ensure that
           the stub routine knows about that object independently of the IC.
        
        In the case of put_by_id transitions that use a helper to allocate the butterfly, we have both
        issues. A long time ago, we had to deal with (2), and we still had code to handle that case, although
        it appears to be dead. This change revives that code and glues it together with PolymorphicAccess.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::alternateBase):
        (JSC::AccessCase::doesCalls):
        (JSC::AccessCase::couldStillSucceed):
        (JSC::AccessCase::generate):
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessCase::customSlotBase):
        (JSC::AccessCase::isGetter):
        (JSC::AccessCase::doesCalls): Deleted.
        * jit/GCAwareJITStubRoutine.cpp:
        (JSC::GCAwareJITStubRoutine::markRequiredObjectsInternal):
        (JSC::MarkingGCAwareJITStubRoutine::MarkingGCAwareJITStubRoutine):
        (JSC::MarkingGCAwareJITStubRoutine::~MarkingGCAwareJITStubRoutine):
        (JSC::MarkingGCAwareJITStubRoutine::markRequiredObjectsInternal):
        (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
        (JSC::createJITStubRoutine):
        (JSC::MarkingGCAwareJITStubRoutineWithOneObject::MarkingGCAwareJITStubRoutineWithOneObject): Deleted.
        (JSC::MarkingGCAwareJITStubRoutineWithOneObject::~MarkingGCAwareJITStubRoutineWithOneObject): Deleted.
        (JSC::MarkingGCAwareJITStubRoutineWithOneObject::markRequiredObjectsInternal): Deleted.
        * jit/GCAwareJITStubRoutine.h:
        (JSC::createJITStubRoutine):

2016-04-08  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: XHRs and Web Worker scripts are not searchable
        https://bugs.webkit.org/show_bug.cgi?id=154214
        <rdar://problem/24643587>

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Page.json:
        Add optional requestId to search results properties and search
        parameters for when the frameId and url are not enough. XHR
        resources, and "Other" resources will use this.

2016-04-08  Guillaume Emont  <guijemont@igalia.com>

        MIPS: support Signed cond in branchTest32()
        https://bugs.webkit.org/show_bug.cgi?id=156260

        This is needed since r197688 makes use of it.

        Reviewed by Mark Lam.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::branchTest32):

2016-04-08  Alex Christensen  <achristensen@webkit.org>

        Progress towards running CMake WebKit2 on Mac
        https://bugs.webkit.org/show_bug.cgi?id=156426

        Reviewed by Tim Horton.

        * PlatformMac.cmake:

2016-04-08  Saam barati  <sbarati@apple.com>

        Debugger may dereference m_currentCallFrame even after the VM has gone idle
        https://bugs.webkit.org/show_bug.cgi?id=156413

        Reviewed by Mark Lam.

        There is a bug where the debugger may dereference its m_currentCallFrame
        pointer after that pointer becomes invalid to read from. This happens like so:

        We may step over an instruction which causes the end of execution for the
        current program. This causes the VM to exit. Then, we perform a GC which
        causes us to collect the global object. The global object being collected
        causes us to detach the debugger. In detaching, we think we still have a 
        valid m_currentCallFrame, we dereference it, and crash. The solution is to
        make sure we're paused when dereferencing this pointer inside ::detach().

        * debugger/Debugger.cpp:
        (JSC::Debugger::detach):

2016-04-08  Brian Burg  <bburg@apple.com>

        Web Inspector: get rid of InspectorBasicValue and InspectorString subclasses
        https://bugs.webkit.org/show_bug.cgi?id=156407
        <rdar://problem/25627659>

        Reviewed by Timothy Hatcher.

        There's no point having these subclasses as they don't save any space.
        Add m_stringValue to the union and merge some implementations of writeJSON.
        Move uses of the subclass to InspectorValue and delete redundant methods.
        Now, most InspectorValue methods are non-virtual so they can be templated.

        * bindings/ScriptValue.cpp:
        (Deprecated::jsToInspectorValue):
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::makeCall):
        Don't used deleted subclasses.

        * inspector/InspectorValues.cpp:
        (Inspector::InspectorValue::null):
        (Inspector::InspectorValue::create):
        (Inspector::InspectorValue::asValue):
        (Inspector::InspectorValue::asBoolean):
        (Inspector::InspectorValue::asDouble):
        (Inspector::InspectorValue::asInteger):
        (Inspector::InspectorValue::asString):
        These only need one implementation now.

        (Inspector::InspectorValue::writeJSON):
        Still a virtual method since Object and Array need their members.

        (Inspector::InspectorObjectBase::InspectorObjectBase):
        (Inspector::InspectorBasicValue::asBoolean): Deleted.
        (Inspector::InspectorBasicValue::asDouble): Deleted.
        (Inspector::InspectorBasicValue::asInteger): Deleted.
        (Inspector::InspectorBasicValue::writeJSON): Deleted.
        (Inspector::InspectorString::asString): Deleted.
        (Inspector::InspectorString::writeJSON): Deleted.
        (Inspector::InspectorString::create): Deleted.
        (Inspector::InspectorBasicValue::create): Deleted.

        * inspector/InspectorValues.h:
        (Inspector::InspectorObjectBase::setBoolean):
        (Inspector::InspectorObjectBase::setInteger):
        (Inspector::InspectorObjectBase::setDouble):
        (Inspector::InspectorObjectBase::setString):
        (Inspector::InspectorArrayBase::pushBoolean):
        (Inspector::InspectorArrayBase::pushInteger):
        (Inspector::InspectorArrayBase::pushDouble):
        (Inspector::InspectorArrayBase::pushString):
        Use new factory methods.

        * replay/EncodedValue.cpp:
        (JSC::ScalarEncodingTraits<bool>::encodeValue):
        (JSC::ScalarEncodingTraits<double>::encodeValue):
        (JSC::ScalarEncodingTraits<float>::encodeValue):
        (JSC::ScalarEncodingTraits<int32_t>::encodeValue):
        (JSC::ScalarEncodingTraits<int64_t>::encodeValue):
        (JSC::ScalarEncodingTraits<uint32_t>::encodeValue):
        (JSC::ScalarEncodingTraits<uint64_t>::encodeValue):
        * replay/EncodedValue.h:
        Use new factory methods.

2016-04-08  Filip Pizlo  <fpizlo@apple.com>

        Add IC support for arguments.length
        https://bugs.webkit.org/show_bug.cgi?id=156389

        Reviewed by Geoffrey Garen.
        
        This adds support for caching accesses to arguments.length for both DirectArguments and
        ScopedArguments. In strict mode, we already cached these accesses since they were just
        normal properties.

        Amazingly, we also already supported caching of overridden arguments.length in both
        DirectArguments and ScopedArguments. This is because when you override, the property gets
        materialized as a normal JS property and the structure is changed.
        
        This patch painstakingly preserves our previous caching of overridden length while
        introducing caching of non-overridden length (i.e. the common case). In fact, we even cache
        the case where it could either be overridden or not, since we just end up with an AccessCase
        for each and they cascade to each other.

        This is a >3x speed-up on microbenchmarks that do arguments.length in a polymorphic context.
        Entirely monomorphic accesses were already handled by the DFG.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
        (JSC::AccessCase::guardedByStructureCheck):
        (JSC::AccessCase::generateWithGuard):
        (JSC::AccessCase::generate):
        (WTF::printInternal):
        * bytecode/PolymorphicAccess.h:
        * jit/ICStats.h:
        * jit/JITOperations.cpp:
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        (JSC::tryCachePutByID):
        (JSC::tryRepatchIn):
        * tests/stress/direct-arguments-override-length-then-access-normal-length.js: Added.
        (args):
        (foo):
        (result.foo):

2016-04-08  Benjamin Poulain  <bpoulain@apple.com>

        UInt32ToNumber should have an Int52 path
        https://bugs.webkit.org/show_bug.cgi?id=125704

        Reviewed by Filip Pizlo.

        When dealing with big numbers, fall back to Int52 instead
        of double when possible.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileUInt32ToNumber):

2016-04-08  Brian Burg  <bburg@apple.com>

        Web Inspector: protocol generator should emit an error when 'type' is used instead of '$ref'
        https://bugs.webkit.org/show_bug.cgi?id=156275
        <rdar://problem/25569331>

        Reviewed by Darin Adler.

        * inspector/protocol/Heap.json: Fix a mistake that's now caught by the protocol generator.

        * inspector/scripts/codegen/models.py:
        (TypeReference.__init__): Check here if type_kind is on a whitelist of primitive types.
        (TypeReference.referenced_name): Update comment.

        Add a new test specifically for the case when the type would otherwise be resolved. Rebaseline.

        * inspector/scripts/tests/expected/fail-on-type-reference-as-primitive-type.json-error: Added.
        * inspector/scripts/tests/expected/fail-on-unknown-type-reference-in-type-declaration.json-error:
        * inspector/scripts/tests/fail-on-type-reference-as-primitive-type.json: Added.

2016-04-07  Joseph Pecoraro  <pecoraro@apple.com>

        Remove ENABLE(ENABLE_ES6_CLASS_SYNTAX) guards
        https://bugs.webkit.org/show_bug.cgi?id=156384

        Reviewed by Ryosuke Niwa.

        * Configurations/FeatureDefines.xcconfig:
        * features.json: Mark as Done.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseExportDeclaration):
        (JSC::Parser<LexerType>::parseStatementListItem):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):

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

        Implementing caching transition puts that need to reallocate with indexing storage
        https://bugs.webkit.org/show_bug.cgi?id=130914

        Reviewed by Saam Barati.

        This enables the IC's put_by_id path to handle reallocating the out-of-line storage even if
        the butterfly has indexing storage. Like the DFG, we do this by calling operations that
        reallocate the butterfly. Those use JSObject API and do all of the nasty work for us, like
        triggering a barrier.

        This does a bunch of refactoring to how PolymorphicAccess makes calls. It's a lot easier to
        do it now because the hard work is hidden under AccessGenerationState methods. This means
        that custom accessors now share logic with put_by_id transitions.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessGenerationState::succeed):
        (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
        (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall):
        (JSC::AccessGenerationState::originalCallSiteIndex):
        (JSC::AccessGenerationState::emitExplicitExceptionHandler):
        (JSC::AccessCase::AccessCase):
        (JSC::AccessCase::transition):
        (JSC::AccessCase::generate):
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessGenerationState::needsToRestoreRegistersIfException):
        (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:

2016-04-07  Joseph Pecoraro  <pecoraro@apple.com>

        Remote Inspector: When disallowing remote inspection on a debuggable, a listing is still sent to debuggers
        https://bugs.webkit.org/show_bug.cgi?id=156380
        <rdar://problem/25323727>

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::updateTarget):
        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
        When a target has been updated and it no longer generates a listing,
        we should remove the old listing as that is now stale and should
        not be sent. Not generating a listing means this target is no
        longer allowed to be debugged.

2016-04-07  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Not necessary to validate webinspectord connection on iOS
        https://bugs.webkit.org/show_bug.cgi?id=156377
        <rdar://problem/25612460>

        Reviewed by Simon Fraser.

        * inspector/remote/RemoteInspectorXPCConnection.h:
        * inspector/remote/RemoteInspectorXPCConnection.mm:
        (Inspector::RemoteInspectorXPCConnection::handleEvent):

2016-04-07  Keith Miller  <keith_miller@apple.com>

        Rename ArrayMode::supportsLength to supportsSelfLength
        https://bugs.webkit.org/show_bug.cgi?id=156374

        Reviewed by Filip Pizlo.

        The name supportsLength is confusing because TypedArray have a
        length function however it is on the prototype and not on the
        instance. supportsSelfLength makes more sense since we use the
        function during fixup to tell if we can intrinsic the length
        property lookup on self accesses.

        * dfg/DFGArrayMode.h:
        (JSC::DFG::ArrayMode::supportsSelfLength):
        (JSC::DFG::ArrayMode::supportsLength): Deleted.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::attemptToMakeGetArrayLength):

2016-04-07  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: ProfileView source links are off by 1 line, worse in pretty printed code
        https://bugs.webkit.org/show_bug.cgi?id=156371

        Reviewed by Timothy Hatcher.

        * inspector/protocol/ScriptProfiler.json:
        Clarify that these locations are 1-based.

2016-04-07  Jon Davis  <jond@apple.com>

        Add Web Animations API to Feature Status Page
        https://bugs.webkit.org/show_bug.cgi?id=156360

        Reviewed by Timothy Hatcher.

        * features.json:

2016-04-07  Saam barati  <sbarati@apple.com>

        Invalid assertion inside DebuggerScope::getOwnPropertySlot
        https://bugs.webkit.org/show_bug.cgi?id=156357

        Reviewed by Keith Miller.

        The Type Profiler might profile JS code that uses DebuggerScope and accesses properties
        on it. Therefore, it may have a DebuggerScope object in its log. Objects in the log
        are subject to having their getOwnPropertySlot method called. Therefore, the DebuggerScope
        might not always be in a valid state when its getOwnPropertySlot method is called.
        Therefore, the assertion invalid.

        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::getOwnPropertySlot):

2016-04-07  Saam barati  <sbarati@apple.com>

        Initial implementation of annex b.3.3 behavior was incorrect
        https://bugs.webkit.org/show_bug.cgi?id=156276

        Reviewed by Keith Miller.

        I almost got annex B.3.3 correct in my first implementation.
        There is a subtlety here I got wrong. We always create a local binding for
        a function at the very beginning of execution of a block scope. So we
        hoist function declarations to their local binding within a given
        block scope. When we actually evaluate the function declaration statement
        itself, we must lookup the binding in the current scope, and bind the
        value to the binding in the "var" scope. We perform the following
        abstract operations when executing a function declaration statement.

        f = lookupBindingInCurrentScope("func")
        store(varScope, "func", f)

        I got this wrong by performing the store to the var binding at the beginning
        of the block scope instead of when we evaluate the function declaration statement.
        This behavior is observable. For example, a program could change the value
        of "func" before the actual function declaration statement executes.
        Consider the following two functions:
        ```
        function foo1() {
            // func === undefined
            {
                // typeof func === "function"
                function func() { } // Executing this statement binds the local "func" binding to the implicit "func" var binding.
                func = 20 // This sets the local "func" binding to 20.
            }
            // typeof func === "function"
        }

        function foo2() {
            // func === undefined
            {
                // typeof func === "function"
                func = 20 // This sets the local "func" binding to 20.
                function func() { } // Executing this statement binds the local "func" binding to the implicit "func" var binding.
            }
            // func === 20
        }
        ```

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
        (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitNodeForLeftHandSide):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FuncDeclNode::emitBytecode):
        * tests/stress/sloppy-mode-function-hoisting.js:
        (test.foo):
        (test):
        (test.):
        (test.bar):
        (test.switch.case.0):
        (test.capFoo1):
        (test.switch.capFoo2):
        (test.outer):
        (foo):

2016-04-07  Alex Christensen  <achristensen@webkit.org>

        Build fix after r199170

        * CMakeLists.txt:

2016-04-07  Keith Miller  <keith_miller@apple.com>

        We should support the ability to do a non-effectful getById
        https://bugs.webkit.org/show_bug.cgi?id=156116

        Reviewed by Benjamin Poulain.

        Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is
        useful because it enables us to take different code paths based on values that we would
        otherwise not be able to have knowledge of. This patch adds this new feature called
        try_get_by_id that will attempt to do as much of a get_by_id as possible without performing
        an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the
        GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and
        undefined if the slot is unset.  If the slot is proxied or any other cases then the result
        is null. In theory, if we ever wanted to check for null we could add a sentinal object to
        the global object that indicates we could not get the result.

        In order to implement this feature we add a new enum GetByIdKind that indicates what to do
        for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the
        get_by_id the same way we would for load and return the value at the appropriate offset.
        Additionally, in order to make sure the we can properly compare the GetterSetter object
        with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the
        GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are
        likely to have little to no impact on memory usage as normal accessors are generally rare.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinExecutableCreator.cpp: Added.
        (JSC::createBuiltinExecutable):
        * builtins/BuiltinExecutableCreator.h: Copied from Source/JavaScriptCore/builtins/BuiltinExecutables.h.
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createDefaultConstructor):
        (JSC::BuiltinExecutables::createBuiltinExecutable):
        (JSC::createBuiltinExecutable):
        (JSC::BuiltinExecutables::createExecutable):
        (JSC::createExecutableInternal): Deleted.
        * builtins/BuiltinExecutables.h:
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::tryGet):
        (JSC::AccessCase::generate):
        (WTF::printInternal):
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessCase::isGet): Deleted.
        (JSC::AccessCase::isPut): Deleted.
        (JSC::AccessCase::isIn): Deleted.
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::reset):
        * bytecode/StructureStubInfo.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitTryGetById):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::getById):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITInlineCacheGenerator.cpp:
        (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
        * jit/JITInlineCacheGenerator.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emit_op_try_get_by_id):
        (JSC::JIT::emitSlow_op_try_get_by_id):
        (JSC::JIT::emit_op_get_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emit_op_try_get_by_id):
        (JSC::JIT::emitSlow_op_try_get_by_id):
        (JSC::JIT::emit_op_get_by_id):
        * jit/Repatch.cpp:
        (JSC::repatchByIdSelfAccess):
        (JSC::appropriateOptimizingGetByIdFunction):
        (JSC::appropriateGenericGetByIdFunction):
        (JSC::tryCacheGetByID):
        (JSC::repatchGetByID):
        (JSC::resetGetByID):
        * jit/Repatch.h:
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionGetGetterSetter):
        (functionCreateBuiltin):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * runtime/GetterSetter.cpp:
        * runtime/GetterSetter.h:
        * runtime/JSType.h:
        * runtime/PropertySlot.cpp:
        (JSC::PropertySlot::getPureResult):
        * runtime/PropertySlot.h:
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        * tests/stress/try-get-by-id.js: Added.
        (tryGetByIdText):
        (getCaller.obj.1.throw.new.Error.let.func):
        (getCaller.obj.1.throw.new.Error):
        (throw.new.Error.get let):
        (throw.new.Error.):
        (throw.new.Error.let.get createBuiltin):
        (get let):
        (let.get createBuiltin):
        (let.func):
        (get let.func):
        (get throw):

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

        Rationalize the makeSpaceForCCall stuff
        https://bugs.webkit.org/show_bug.cgi?id=156352

        Reviewed by Mark Lam.

        I want to add more code to PolymorphicAccess that makes C calls, so that I can finally fix
        https://bugs.webkit.org/show_bug.cgi?id=130914 (allow transition caches to handle indexing
        headers).

        When trying to understand what it takes to make a C call, I came across code that was making
        room on the stack for spilled arguments. This logic was guarded with some complicated
        condition. At first, I tried to just refactor the code so that the same ugly condition
        wouldn't have to be copy-pasted everywhere that we made C calls. But then I started thinking
        about the condition, and realized that it was probably wrong: if the outer PolymorphicAccess
        harness decides to reuse a register for the scratchGPR then the top of the stack will store
        the old value of scratchGPR, but the condition wouldn't necessarily trigger. So if the call
        then overwrote something on the stack, we'd have a bad time.

        Making room on the stack for a call is a cheap operation. It's orders of magnitude cheaper
        than the rest of the call. Therefore, I think that it's best to just unconditionally make
        room on the stack.

        This patch makes us do just that. I also made the relevant helpers not inline, because I
        think that we have too many inline methods in our assemblers. Now it's much easier to make
        C calls from PolymorphicAccess because you just call the AssemblyHelper methods for making
        space. There are no special conditions or anything like that.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generate):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitLoadStructure):
        (JSC::AssemblyHelpers::makeSpaceOnStackForCCall):
        (JSC::AssemblyHelpers::reclaimSpaceOnStackForCCall):
        (JSC::emitRandomThunkImpl):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::makeSpaceOnStackForCCall): Deleted.
        (JSC::AssemblyHelpers::reclaimSpaceOnStackForCCall): Deleted.

2016-04-07  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r199128 and r199141.
        https://bugs.webkit.org/show_bug.cgi?id=156348

        Causes crashes on multiple webpages (Requested by keith_mi_ on
        #webkit).

        Reverted changesets:

        "[ES6] Add support for Symbol.isConcatSpreadable."
        https://bugs.webkit.org/show_bug.cgi?id=155351
        http://trac.webkit.org/changeset/199128

        "Unreviewed, uncomment accidentally commented line in test."
        http://trac.webkit.org/changeset/199141

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

        Rationalize the handling of PutById transitions a bit
        https://bugs.webkit.org/show_bug.cgi?id=156330

        Reviewed by Mark Lam.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generate): Get rid of the specialized slow calls. We can just use the failAndIgnore jump target. We just need to make sure that we don't make observable effects until we're done with all of the fast path checks.
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::addAccessCase): MadeNoChanges indicates that we should keep trying to repatch. Currently PutById transitions might trigger the case that addAccessCase() sees null, if the transition involves an indexing header. Doing repatching in that case is probably not good. But, we should just fix this the right way eventually.

2016-04-07  Per Arne Vollan  <peavo@outlook.com>

        [Win] Fix for JSC stress test failures.
        https://bugs.webkit.org/show_bug.cgi?id=156343

        Reviewed by Filip Pizlo.

        We need to make it clear to MSVC that the method loadPtr(ImplicitAddress address, RegisterID dest)
        should be used, and not loadPtr(const void* address, RegisterID dest).

        * jit/CCallHelpers.cpp:
        (JSC::CCallHelpers::setupShadowChickenPacket):

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

        [JSC] UInt32ToNumber should be NodeMustGenerate
        https://bugs.webkit.org/show_bug.cgi?id=156329

        Reviewed by Filip Pizlo.

        It exits on negative numbers on the integer path.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:

2016-04-04  Geoffrey Garen  <ggaren@apple.com>

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

        "Perf bots are down, so I can't re-land this right now."

        Reverted changeset:

        CopiedBlock should be 16kB
        https://bugs.webkit.org/show_bug.cgi?id=156168
        http://trac.webkit.org/changeset/199016

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

        String.prototype.match() should be calling internal function RegExpCreate.
        https://bugs.webkit.org/show_bug.cgi?id=156318

        Reviewed by Filip Pizlo.

        RegExpCreate is not the same as the RegExp constructor.  The current implementation
        invokes new @RegExp which calls the constructor.  This results in failures in
        es6/Proxy_internal_get_calls_String.prototype.match.js, and
        es6/Proxy_internal_get_calls_String.prototype.search.js due to observable side
        effects.

        This patch fixes this by factoring out the part of the RegExp constructor that
        makes the RegExpCreate function, and changing String's match and search to call
        RegExpCreate instead in accordance with the ES6 spec. 

        * builtins/StringPrototype.js:
        (match):
        (search):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/RegExpConstructor.cpp:
        (JSC::toFlags):
        (JSC::regExpCreate):
        (JSC::constructRegExp):
        (JSC::esSpecRegExpCreate):
        (JSC::constructWithRegExpConstructor):
        * runtime/RegExpConstructor.h:
        (JSC::isRegExp):

2016-04-06  Keith Miller  <keith_miller@apple.com>

        Unreviewed, uncomment accidentally commented line in test.

        * tests/stress/array-concat-spread-object.js:

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

        JSC should have a simple way of gathering IC statistics
        https://bugs.webkit.org/show_bug.cgi?id=156317

        Reviewed by Benjamin Poulain.

        This adds a cheap, runtime-enabled way of gathering statistics about why we take the slow
        paths for inline caches. This is complementary to our existing bytecode profiler. Eventually
        we may want to combine the two things.
        
        This is not a slow-down on anything because we only do extra work on IC slow paths and if
        it's disabled it's just a load-and-branch to skip the stats gathering code.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/ICStats.cpp: Added.
        * jit/ICStats.h: Added.
        * jit/JITOperations.cpp:
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::inherits):
        (JSC::JSValue::classInfoOrNull):
        (JSC::JSValue::toThis):
        * runtime/Options.h:

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

        32-bit JSC stress/multi-put-by-offset-multiple-transitions.js failing
        https://bugs.webkit.org/show_bug.cgi?id=156292

        Reviewed by Benjamin Poulain.

        Make sure that we stash the callsite index before calling operationReallocateStorageAndFinishPut.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generate):

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

        JSC test stress/arrowfunction-lexical-bind-superproperty.js failing
        https://bugs.webkit.org/show_bug.cgi?id=156309

        Reviewed by Saam Barati.

        Just be honest about the fact that the ArgumentCount and Callee parts of inline callframe runtime
        meta-data can be read at any time.
        
        We only have to say this for the inline callframe forms of ArgumentCount and Callee because we don't
        sink any part of the machine prologue. This change just prevents us from sinking the pseudoprologue
        of inlined varargs or closure calls.

        Shockingly, this is not a regression on anything.

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

2016-03-29  Keith Miller  <keith_miller@apple.com>

        [ES6] Add support for Symbol.isConcatSpreadable.
        https://bugs.webkit.org/show_bug.cgi?id=155351

        Reviewed by Saam Barati.

        This patch adds support for Symbol.isConcatSpreadable. In order to do so it was necessary to move the
        Array.prototype.concat function to JS. A number of different optimizations were needed to make such the move to
        a builtin performant. First, four new DFG intrinsics were added.

        1) IsArrayObject (I would have called it IsArray but we use the same name for an IndexingType): an intrinsic of
           the Array.isArray function.
        2) IsJSArray: checks the first child is a JSArray object.
        3) IsArrayConstructor: checks the first child is an instance of ArrayConstructor.
        4) CallObjectConstructor: an intrinsic of the Object constructor.

        IsActualObject, IsJSArray, and CallObjectConstructor can all be converted into constants in the abstract interpreter if
        we are able to prove that the first child is an Array or for ToObject an Object.

        In order to further improve the perfomance we also now cover more indexing types in our fast path memcpy
        code. Before we would only memcpy Arrays if they had the same indexing type and did not have Array storage and
        were not undecided. Now the memcpy code covers the following additional two cases: One array is undecided and
        the other is a non-array storage and the case where one array is Int32 and the other is contiguous (we map this
        into a contiguous array).

        This patch also adds a new fast path for concat with more than one array argument by using memcpy to append
        values onto the result array. This works roughly the same as the two array fast path using the same methodology
        to decide if we can memcpy the other butterfly into the result butterfly.

        Two new debugging tools are also added to the jsc cli. One is a version of the print function with a private
        name so it can be used for debugging builtins. The other is dumpDataLog, which takes a JSValue and runs our
        dataLog function on it.

        Finally, this patch add a new constructor to JSValueRegsTemporary that allows it to reuse the the registers of a
        JSValueOperand if the operand's use count is one.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ArrayPrototype.js:
        (concatSlowPath):
        (concat):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * 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::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::compileIsJSArray):
        (JSC::DFG::SpeculativeJIT::compileIsArrayObject):
        (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor):
        (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
        * dfg/DFGSpeculativeJIT.h:
        (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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::isArray):
        * jit/JITOperations.h:
        * jsc.cpp:
        (WTF::RuntimeArray::createStructure):
        (GlobalObject::finishCreation):
        (functionDebug):
        (functionDataLogValue):
        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
        * runtime/ArrayConstructor.h:
        (JSC::isArrayConstructor):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::arrayProtoPrivateFuncIsJSArray):
        (JSC::moveElements):
        (JSC::arrayProtoPrivateFuncConcatMemcpy):
        (JSC::arrayProtoPrivateFuncAppendMemcpy):
        (JSC::arrayProtoFuncConcat): Deleted.
        * runtime/ArrayPrototype.h:
        (JSC::ArrayPrototype::createStructure):
        * runtime/CommonIdentifiers.h:
        * runtime/Intrinsic.h:
        * runtime/JSArray.cpp:
        (JSC::JSArray::appendMemcpy):
        (JSC::JSArray::fastConcatWith): Deleted.
        * runtime/JSArray.h:
        (JSC::JSArray::createStructure):
        (JSC::JSArray::fastConcatType): Deleted.
        * runtime/JSArrayInlines.h: Added.
        (JSC::JSArray::memCopyWithIndexingType):
        (JSC::JSArray::canFastCopy):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSType.h:
        * runtime/ObjectConstructor.h:
        (JSC::constructObject):
        * tests/es6.yaml:
        * tests/stress/array-concat-spread-object.js: Added.
        (arrayEq):
        * tests/stress/array-concat-spread-proxy-exception-check.js: Added.
        (arrayEq):
        * tests/stress/array-concat-spread-proxy.js: Added.
        (arrayEq):
        * tests/stress/array-concat-with-slow-indexingtypes.js: Added.
        (arrayEq):
        * tests/stress/array-species-config-array-constructor.js:

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

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

        "It didn't fix the timeout" (Requested by saamyjoon on
        #webkit).

        Reverted changeset:

        "jsc-layout-tests.yaml/js/script-tests/regress-141098.js
        failing on Yosemite Debug after r198989"
        https://bugs.webkit.org/show_bug.cgi?id=156187
        http://trac.webkit.org/changeset/199070

2016-04-06  Geoffrey Garen  <ggaren@apple.com>

        Unreviewed, rolling in r199016.
        https://bugs.webkit.org/show_bug.cgi?id=156140

        It might work this time without regression because 16kB aligned requests
        now take the allocation fast path.

        Restored changeset:

        CopiedBlock should be 16kB
        https://bugs.webkit.org/show_bug.cgi?id=156168
        http://trac.webkit.org/changeset/199016

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

        Update es6.yaml to expect es6/Proxy_internal_get_calls_RegExp_constructor.js to pass.
        https://bugs.webkit.org/show_bug.cgi?id=156314

        Reviewed by Saam Barati.

        * tests/es6.yaml:

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

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

        Still breaks internal builds (Requested by keith_miller on
        #webkit).

        Reverted changeset:

        "We should support the ability to do a non-effectful getById"
        https://bugs.webkit.org/show_bug.cgi?id=156116
        http://trac.webkit.org/changeset/199104

2016-04-06  Keith Miller  <keith_miller@apple.com>

        RegExp constructor should use Symbol.match and other properties
        https://bugs.webkit.org/show_bug.cgi?id=155873

        Reviewed by Michael Saboff.

        This patch updates the behavior of the RegExp constructor. Now the constructor
        should get the Symbol.match property and check if it exists to decide if something
        should be constructed like a regexp object.

        * runtime/RegExpConstructor.cpp:
        (JSC::toFlags):
        (JSC::constructRegExp):
        (JSC::constructWithRegExpConstructor):
        (JSC::callRegExpConstructor):
        * runtime/RegExpConstructor.h:
        * tests/stress/regexp-constructor.js: Added.
        (assert):
        (throw.new.Error.get let):
        (throw.new.Error.):
        (throw.new.Error.get re):

2016-04-06  Keith Miller  <keith_miller@apple.com>

        We should support the ability to do a non-effectful getById
        https://bugs.webkit.org/show_bug.cgi?id=156116

        Reviewed by Benjamin Poulain.

        Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is
        useful because it enables us to take different code paths based on values that we would
        otherwise not be able to have knowledge of. This patch adds this new feature called
        try_get_by_id that will attempt to do as much of a get_by_id as possible without performing
        an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the
        GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and
        undefined if the slot is unset.  If the slot is proxied or any other cases then the result
        is null. In theory, if we ever wanted to check for null we could add a sentinal object to
        the global object that indicates we could not get the result.

        In order to implement this feature we add a new enum GetByIdKind that indicates what to do
        for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the
        get_by_id the same way we would for load and return the value at the appropriate offset.
        Additionally, in order to make sure the we can properly compare the GetterSetter object
        with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the
        GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are
        likely to have little to no impact on memory usage as normal accessors are generally rare.

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createDefaultConstructor):
        (JSC::BuiltinExecutables::createBuiltinExecutable):
        (JSC::createBuiltinExecutable):
        (JSC::BuiltinExecutables::createExecutable):
        (JSC::createExecutableInternal): Deleted.
        * builtins/BuiltinExecutables.h:
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::tryGet):
        (JSC::AccessCase::generate):
        (WTF::printInternal):
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessCase::isGet): Deleted.
        (JSC::AccessCase::isPut): Deleted.
        (JSC::AccessCase::isIn): Deleted.
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::reset):
        * bytecode/StructureStubInfo.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitTryGetById):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::getById):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITInlineCacheGenerator.cpp:
        (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
        * jit/JITInlineCacheGenerator.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emit_op_try_get_by_id):
        (JSC::JIT::emitSlow_op_try_get_by_id):
        (JSC::JIT::emit_op_get_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emit_op_try_get_by_id):
        (JSC::JIT::emitSlow_op_try_get_by_id):
        (JSC::JIT::emit_op_get_by_id):
        * jit/Repatch.cpp:
        (JSC::repatchByIdSelfAccess):
        (JSC::appropriateOptimizingGetByIdFunction):
        (JSC::appropriateGenericGetByIdFunction):
        (JSC::tryCacheGetByID):
        (JSC::repatchGetByID):
        (JSC::resetGetByID):
        * jit/Repatch.h:
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionGetGetterSetter):
        (functionCreateBuiltin):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * runtime/GetterSetter.cpp:
        * runtime/GetterSetter.h:
        * runtime/JSType.h:
        * runtime/PropertySlot.cpp:
        (JSC::PropertySlot::getPureResult):
        * runtime/PropertySlot.h:
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        * tests/stress/try-get-by-id.js: Added.
        (tryGetByIdText):
        (getCaller.obj.1.throw.new.Error.let.func):
        (getCaller.obj.1.throw.new.Error):
        (throw.new.Error.get let):
        (throw.new.Error.):
        (throw.new.Error.let.get createBuiltin):
        (get let):
        (let.get createBuiltin):
        (let.func):
        (get let.func):
        (get throw):

2016-04-05  Chris Dumez  <cdumez@apple.com>

        Add support for [EnabledAtRuntime] operations on DOMWindow
        https://bugs.webkit.org/show_bug.cgi?id=156272

        Reviewed by Alex Christensen.

        Add identifier for 'fetch' so it can be used from the generated
        bindings.

        * runtime/CommonIdentifiers.h:

2016-04-05  Alex Christensen  <achristensen@webkit.org>

        Make CMake-generated binaries on Mac able to run
        https://bugs.webkit.org/show_bug.cgi?id=156268

        Reviewed by Daniel Bates.

        * CMakeLists.txt:

2016-04-05  Filip Pizlo  <fpizlo@apple.com>

        Improve some other cases of context-sensitive inlining
        https://bugs.webkit.org/show_bug.cgi?id=156277

        Reviewed by Benjamin Poulain.
        
        This implements some improvements for inlining:

        - We no longer do guarded inlining when the profiling doesn't come from a stub. Doing so would have
          been risky, and according to benchmarks, it wasn't common enough to matter. I think it's better to
          err on the side of not inlining.
        
        - The jneq_ptr pattern for variadic calls no longer breaks the basic block. Not breaking the block
          increases the chances of the parser seeing the callee constant. While inlining doesn't require a
          callee constant, sometimes it makes a difference. Note that we were previously breaking the block
          for no reason at all: if the boundary after jneq_ptr is a jump target from some other jump, then
          the parser will automatically break the block for us. There is no reason to add any block breaking
          ourselves since we implement jneq_ptr by ignoring the affirmative jump destination and inserting a
          check and falling through.
        
        - get_by_id handling now tries to apply some common sense to its status object. In particular, if
          the source is a NewObject and there was no interfering operation that could clobber the structure,
          then we know which case of a polymorphic GetByIdStatus we would take. This arises in some
          constructor patterns.
        
        Long term, we should address all of these cases comprehensively by having a late inliner. The inliner
        being part of the bytecode parser means that there is a lot of complexity in the parser and it
        prevents us from inlining upon learning new information from static analysis. But for now, I think
        it's fine to experiment with one-off hacks, if only to learn what the possibilities are.
        
        This is a 14% speed-up on Octane/raytrace.

        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::dump):
        * bytecode/CallLinkStatus.h:
        (JSC::CallLinkStatus::couldTakeSlowPath):
        (JSC::CallLinkStatus::setCouldTakeSlowPath):
        (JSC::CallLinkStatus::variants):
        (JSC::CallLinkStatus::size):
        (JSC::CallLinkStatus::at):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::makesCalls):
        (JSC::GetByIdStatus::filter):
        (JSC::GetByIdStatus::dump):
        * bytecode/GetByIdStatus.h:
        (JSC::GetByIdStatus::wasSeenInJIT):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::refineStatically):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * runtime/Options.h:

2016-04-05  Saam barati  <sbarati@apple.com>

        JSC SamplingProfiler: Use a thread + sleep loop instead of WTF::WorkQueue for taking samples
        https://bugs.webkit.org/show_bug.cgi?id=154017

        Reviewed by Geoffrey Garen.

        By moving to an explicitly created seperate thread + sample-then-sleep
        loop, we can remove a lot of the crufty code around WorkQueue.
        We're also getting sample rates that are much closer to what we're
        asking the OS for. When the sampling handler was built off of WorkQueue,
        we'd often get sample rates much higher than the 1ms we asked for. On Kraken,
        we would average about 1.7ms sample rates, even though we'd ask for a 1ms rate.
        Now, on Kraken, we're getting about 1.2ms rates. Because we're getting
        higher rates, this patch is a performance regression. It's slower because
        we're sampling more frequently.

        Before this patch, the sampling profiler had the following overhead:
        - 10% on Kraken
        - 12% on octane
        - 15% on AsmBench

        With this patch, the sampling profiler has the following overhead:
        - 16% on Kraken
        - 17% on Octane
        - 30% on AsmBench

        Comparatively, this new patch has the following overhead over the old sampling profiler:
        - 5% on Kraken
        - 3.5% on Octane
        - 13% slower on AsmBench

        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::trackingComplete):
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::SamplingProfiler):
        (JSC::SamplingProfiler::~SamplingProfiler):
        (JSC::SamplingProfiler::createThreadIfNecessary):
        (JSC::SamplingProfiler::timerLoop):
        (JSC::SamplingProfiler::takeSample):
        (JSC::tryGetBytecodeIndex):
        (JSC::SamplingProfiler::shutdown):
        (JSC::SamplingProfiler::start):
        (JSC::SamplingProfiler::pause):
        (JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread):
        (JSC::SamplingProfiler::noticeJSLockAcquisition):
        (JSC::SamplingProfiler::noticeVMEntry):
        (JSC::SamplingProfiler::clearData):
        (JSC::SamplingProfiler::stop): Deleted.
        (JSC::SamplingProfiler::dispatchIfNecessary): Deleted.
        (JSC::SamplingProfiler::dispatchFunction): Deleted.
        * runtime/SamplingProfiler.h:
        (JSC::SamplingProfiler::setTimingInterval):
        (JSC::SamplingProfiler::setStopWatch):
        * runtime/VM.cpp:
        (JSC::VM::VM):

2016-04-05  Commit Queue  <commit-queue@webkit.org>

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

        This change broke internal Mac builds (Requested by ryanhaddad
        on #webkit).

        Reverted changeset:

        "We should support the ability to do a non-effectful getById"
        https://bugs.webkit.org/show_bug.cgi?id=156116
        http://trac.webkit.org/changeset/199073

2016-04-05  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        [Fetch API] Add a runtime flag to fetch API and related constructs
        https://bugs.webkit.org/show_bug.cgi?id=156113
 
        Reviewed by Alex Christensen.

        Add a fetch API runtime flag based on preferences.
        Disable fetch API by default.
 
        * runtime/CommonIdentifiers.h:

2016-04-05  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix cloop some more.

        * runtime/RegExpInlines.h:
        (JSC::RegExp::hasCodeFor):
        (JSC::RegExp::hasMatchOnlyCodeFor):

2016-04-05  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix cloop.

        * jit/CCallHelpers.cpp:

2016-03-18  Filip Pizlo  <fpizlo@apple.com>

        JSC should use a shadow stack version of CHICKEN so that debuggers have the option of retrieving tail-deleted frames
        https://bugs.webkit.org/show_bug.cgi?id=155598

        Reviewed by Saam Barati.
        
        JSC is the first JSVM to have proper tail calls. This means that error.stack and the
        debugger will appear to "delete" strict mode stack frames, if the call that this frame made
        was in tail position. This is exactly what functional programmers expect - they don't want
        the VM to waste resources on tail-deleted frames to ensure that it's legal to loop forever
        using tail calls. It's also something that non-functional programmers fear. It's not clear
        that tail-deleted frames would actually degrade the debugging experience, but the fear is
        real, so it's worthwhile to do something about it.

        It turns out that there is at least one tail call implementation that doesn't suffer from
        this problem. It implements proper tail calls in the sense that you won't run out of memory
        by tail-looping. It also has the power to show you tail-deleted frames in a backtrace, so
        long as you haven't yet run out of memory. It's called CHICKEN Scheme, and it's one of my
        favorite hacks:
        
        http://www.more-magic.net/posts/internals-gc.html

        CHICKEN does many awesome things. The intuition from CHICKEN that we use here is a simple
        one: what if a tail call still kept the tail-deleted frame, and the GC actually deleted that
        frame only once we proved that there was insufficient memory to keep it around.
        
        CHICKEN does this by reshaping the C stack with longjmp/setjmp. We can't do that because we
        can have arbitrary native code, and that native code does not have relocatable stack frames.
        
        But we can do something almost like CHICKEN on a shadow stack. It's a common trick to have a
        VM maintain two stacks - the actual execution stack plus a shadow stack that has some extra
        information. The shadow stack can be reshaped, moved, etc, since the VM tightly controls its
        layout. The main stack can then continue to obey ABI rules.

        This patch implements a mechanism for being able to display stack traces that include
        tail-deleted frames. It uses a shadow stack that behaves like a CHICKEN stack: it has all
        frames all the time, though we will collect the tail-deleted ones if the stack gets too big.
        This new mechanism is called ShadowChicken, obviously: it's CHICKEN on a shadow stack.
        
        ShadowChicken is always on, but individual CodeBlocks may make their own choices about
        whether to opt into it. They will do that at bytecompile time based on the debugger mode on
        their global object.

        When no CodeBlock opts in, there is no overhead, since ShadowChicken ends up doing nothing
        in that case. Well, except when exceptions are thrown. Then it might do some work, but it's
        minor.

        When all CodeBlocks opt in, there is about 6% overhead. That's too much overhead to enable
        this all the time, but it's low enough to justify enabling in the Inspector. It's currently
        enabled on all CodeBlocks only when you use an Option. Otherwise it will auto-enable if the
        debugger is on.

        Note that ShadowChicken attempts to gracefully handle the presence of stack frames that have
        no logging. This is essential since we *can* have debugging enabled in one GlobalObject and
        disabled in another. Also, some frames don't do ShadowChicken because they just haven't been
        hacked to do it yet. Native frames fall into this category, as do the VM entry frames.

        This doesn't yet wire ShadowChicken into DebuggerCallFrame. That will take more work. It
        just makes a ShadowChicken stack walk function available to jsc. It's used from the
        shadow-chicken tests.

        * API/JSContextRef.cpp:
        (BacktraceFunctor::BacktraceFunctor):
        (BacktraceFunctor::operator()):
        (JSContextCreateBacktrace):
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::RecursionCheckFunctor::RecursionCheckFunctor):
        (JSC::RecursionCheckFunctor::operator()):
        (JSC::CodeBlock::noticeIncomingCall):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitEnter):
        (JSC::BytecodeGenerator::emitCallInTailPosition):
        (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
        (JSC::BytecodeGenerator::emitCallVarargs):
        (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
        (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
        (JSC::BytecodeGenerator::emitCallDefineProperty):
        * bytecompiler/BytecodeGenerator.h:
        * debugger/DebuggerCallFrame.cpp:
        (JSC::LineAndColumnFunctor::operator()):
        (JSC::LineAndColumnFunctor::column):
        (JSC::FindCallerMidStackFunctor::FindCallerMidStackFunctor):
        (JSC::FindCallerMidStackFunctor::operator()):
        (JSC::DebuggerCallFrame::DebuggerCallFrame):
        * 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/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.cpp:
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
        (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue):
        (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail):
        (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::setupShadowChickenPacket):
        (JSC::FTL::DFG::LowerDFGToB3::boolify):
        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::visitSamplingProfiler):
        (JSC::Heap::visitShadowChicken):
        (JSC::Heap::traceCodeBlocksAndJITStubRoutines):
        (JSC::Heap::collectImpl):
        * heap/Heap.h:
        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::CreateScriptCallStackFunctor::CreateScriptCallStackFunctor):
        (Inspector::CreateScriptCallStackFunctor::operator()):
        (Inspector::createScriptCallStack):
        * interpreter/CallFrame.h:
        (JSC::ExecState::iterate):
        * interpreter/Interpreter.cpp:
        (JSC::DumpRegisterFunctor::DumpRegisterFunctor):
        (JSC::DumpRegisterFunctor::operator()):
        (JSC::GetStackTraceFunctor::GetStackTraceFunctor):
        (JSC::GetStackTraceFunctor::operator()):
        (JSC::Interpreter::getStackTrace):
        (JSC::GetCatchHandlerFunctor::handler):
        (JSC::GetCatchHandlerFunctor::operator()):
        (JSC::notifyDebuggerOfUnwinding):
        (JSC::UnwindFunctor::UnwindFunctor):
        (JSC::UnwindFunctor::operator()):
        (JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer):
        * interpreter/ShadowChicken.cpp: Added.
        (JSC::ShadowChicken::Packet::dump):
        (JSC::ShadowChicken::Frame::dump):
        (JSC::ShadowChicken::ShadowChicken):
        (JSC::ShadowChicken::~ShadowChicken):
        (JSC::ShadowChicken::log):
        (JSC::ShadowChicken::update):
        (JSC::ShadowChicken::visitChildren):
        (JSC::ShadowChicken::reset):
        (JSC::ShadowChicken::dump):
        (JSC::ShadowChicken::functionsOnStack):
        * interpreter/ShadowChicken.h: Added.
        (JSC::ShadowChicken::Packet::Packet):
        (JSC::ShadowChicken::Packet::tailMarker):
        (JSC::ShadowChicken::Packet::throwMarker):
        (JSC::ShadowChicken::Packet::prologue):
        (JSC::ShadowChicken::Packet::tail):
        (JSC::ShadowChicken::Packet::throwPacket):
        (JSC::ShadowChicken::Packet::operator bool):
        (JSC::ShadowChicken::Packet::isPrologue):
        (JSC::ShadowChicken::Packet::isTail):
        (JSC::ShadowChicken::Packet::isThrow):
        (JSC::ShadowChicken::Frame::Frame):
        (JSC::ShadowChicken::Frame::operator==):
        (JSC::ShadowChicken::Frame::operator!=):
        (JSC::ShadowChicken::log):
        (JSC::ShadowChicken::logSize):
        (JSC::ShadowChicken::addressOfLogCursor):
        (JSC::ShadowChicken::logEnd):
        * interpreter/ShadowChickenInlines.h: Added.
        (JSC::ShadowChicken::iterate):
        * interpreter/StackVisitor.h:
        (JSC::StackVisitor::Frame::callee):
        (JSC::StackVisitor::Frame::codeBlock):
        (JSC::StackVisitor::Frame::bytecodeOffset):
        (JSC::StackVisitor::Frame::inlineCallFrame):
        (JSC::StackVisitor::Frame::isJSFrame):
        (JSC::StackVisitor::Frame::isInlinedFrame):
        (JSC::StackVisitor::visit):
        * jit/CCallHelpers.cpp: Added.
        (JSC::CCallHelpers::logShadowChickenProloguePacket):
        (JSC::CCallHelpers::logShadowChickenTailPacket):
        (JSC::CCallHelpers::setupShadowChickenPacket):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::prepareForTailCallSlow):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_resume):
        (JSC::JIT::emit_op_log_shadow_chicken_prologue):
        (JSC::JIT::emit_op_log_shadow_chicken_tail):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (FunctionJSCStackFunctor::FunctionJSCStackFunctor):
        (FunctionJSCStackFunctor::operator()):
        (functionClearSamplingFlags):
        (functionShadowChickenFunctionsOnStack):
        (functionReadline):
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::llint_throw_stack_overflow_error):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * profiler/ProfileGenerator.cpp:
        (JSC::AddParentForConsoleStartFunctor::foundParent):
        (JSC::AddParentForConsoleStartFunctor::operator()):
        * runtime/Error.cpp:
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor):
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()):
        (JSC::addErrorInfoAndGetBytecodeOffset):
        * runtime/JSFunction.cpp:
        (JSC::RetrieveArgumentsFunctor::result):
        (JSC::RetrieveArgumentsFunctor::operator()):
        (JSC::retrieveArguments):
        (JSC::RetrieveCallerFunctionFunctor::result):
        (JSC::RetrieveCallerFunctionFunctor::operator()):
        (JSC::retrieveCallerFunction):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::GlobalFuncProtoGetterFunctor::result):
        (JSC::GlobalFuncProtoGetterFunctor::operator()):
        (JSC::globalFuncProtoGetter):
        (JSC::GlobalFuncProtoSetterFunctor::allowsAccess):
        (JSC::GlobalFuncProtoSetterFunctor::operator()):
        * runtime/NullSetterFunction.cpp:
        (JSC::GetCallerStrictnessFunctor::GetCallerStrictnessFunctor):
        (JSC::GetCallerStrictnessFunctor::operator()):
        (JSC::GetCallerStrictnessFunctor::callerIsStrict):
        (JSC::callerIsStrict):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructorGetPrototypeOfFunctor::result):
        (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
        (JSC::objectConstructorGetPrototypeOf):
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::SetEnabledProfilerFunctor::operator()):
        * runtime/VM.h:
        (JSC::VM::shouldBuilderPCToCodeOriginMapping):
        (JSC::VM::bytecodeIntrinsicRegistry):
        (JSC::VM::shadowChicken):
        * tests/stress/resources/shadow-chicken-support.js: Added.
        (describeFunction):
        (describeArray):
        (expectStack):
        (initialize):
        * tests/stress/shadow-chicken-disabled.js: Added.
        (test1.foo):
        (test1.bar):
        (test1.baz):
        (test1):
        (test2.foo):
        (test2.bar):
        (test2.baz):
        (test2):
        (test3.foo):
        (test3.bar):
        (test3.baz):
        (test3):
        * tests/stress/shadow-chicken-enabled.js: Added.
        (test1.foo):
        (test1.bar):
        (test1.baz):
        (test1):
        (test2.foo):
        (test2.bar):
        (test2.baz):
        (test2):
        (test3.bob):
        (test3.thingy):
        (test3.foo):
        (test3.bar):
        (test3.baz):
        (test3):
        (test4.bob):
        (test4.thingy):
        (test4.foo):
        (test4.bar):
        (test4.baz):
        (test4):
        (test5.foo):
        (test5):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
        (JSC::CallerFrameJITTypeFunctor::operator()):
        (JSC::CallerFrameJITTypeFunctor::jitType):
        (JSC::functionLLintTrue):
        (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
        (JSC::CellAddressCheckFunctor::operator()):
        (JSC::JSDollarVMPrototype::isValidCell):
        (JSC::JSDollarVMPrototype::isValidCodeBlock):
        (JSC::JSDollarVMPrototype::codeBlockForFrame):
        (JSC::PrintFrameFunctor::PrintFrameFunctor):
        (JSC::PrintFrameFunctor::operator()):
        (JSC::printCallFrame):

2016-03-19  Filip Pizlo  <fpizlo@apple.com>

        DFG and FTL should constant-fold RegExpExec, RegExpTest, and StringReplace
        https://bugs.webkit.org/show_bug.cgi?id=155270

        Reviewed by Saam Barati.

        This enables constant-folding of RegExpExec, RegExpTest, and StringReplace.

        It's now possible to run Yarr on the JIT threads. Since previous work on constant-folding
        strings gave the DFG an API for reasoning about JSString constants in terms of
        JIT-thread-local WTF::Strings, it's now super easy to just pass strings to Yarr and build IR
        based on the results.

        But RegExpExec is hard: the folded version still must allocate a RegExpMatchesArray. We must
        use the same Structure that the code would have used or else we'll pollute the program's
        inline caches. Also, RegExpMatchesArray.h|cpp will allocate the array and its named
        properties in one go - we don't want to lose that optimization. So, this patch enables
        MaterializeNewObject to allocate objects or arrays with any number of indexed or named
        properties. Previously it could only handle objects (but not arrays) and named properties
        (but not indexed ones).

        This also adds a few minor things for setting the RegExpConstructor cached result.

        This is about a 2x speed-up on microbenchmarks when we fold a match success and about a
        8x speed-up when we fold a match failure. It's a 10% speed-up on Octane/regexp.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * 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):
        * dfg/DFGInsertionSet.cpp:
        (JSC::DFG::InsertionSet::insertSlow):
        (JSC::DFG::InsertionSet::execute):
        * dfg/DFGInsertionSet.h:
        (JSC::DFG::InsertionSet::insertCheck):
        * dfg/DFGLazyJSValue.cpp:
        (JSC::DFG::LazyJSValue::tryGetString):
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGNode.h:
        (JSC::DFG::StackAccessData::flushedAt):
        (JSC::DFG::OpInfo::OpInfo): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGObjectMaterializationData.cpp:
        (JSC::DFG::ObjectMaterializationData::dump):
        (JSC::DFG::PhantomPropertyValue::dump): Deleted.
        (JSC::DFG::ObjectMaterializationData::oneWaySimilarityScore): Deleted.
        (JSC::DFG::ObjectMaterializationData::similarityScore): Deleted.
        * dfg/DFGObjectMaterializationData.h:
        (JSC::DFG::PhantomPropertyValue::PhantomPropertyValue): Deleted.
        (JSC::DFG::PhantomPropertyValue::operator==): Deleted.
        * dfg/DFGOpInfo.h: Added.
        (JSC::DFG::OpInfo::OpInfo):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGPromotedHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGPromotedHeapLocation.h:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::~SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
        (JSC::DFG::SpeculativeJIT::emitGetLength):
        (JSC::DFG::SpeculativeJIT::compileLazyJSConstant):
        (JSC::DFG::SpeculativeJIT::compileMaterializeNewObject):
        (JSC::DFG::SpeculativeJIT::compileRecordRegExpCachedResult):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSArray): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::StrengthReductionPhase):
        (JSC::DFG::StrengthReductionPhase::handleNode):
        (JSC::DFG::StrengthReductionPhase::handleCommutativity):
        (JSC::DFG::StrengthReductionPhase::executeInsertionSet):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validate):
        (JSC::DFG::Validate::validateCPS):
        * ftl/FTLAbstractHeapRepository.cpp:
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
        (JSC::FTL::DFG::LowerDFGToB3::compileRecordRegExpCachedResult):
        (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
        (JSC::FTL::DFG::LowerDFGToB3::storageForTransition):
        (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::isNotCellOrMisc):
        (JSC::FTL::DFG::LowerDFGToB3::unboxDouble):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationPopulateObjectInOSR):
        (JSC::FTL::operationNewObjectWithButterfly): Deleted.
        * ftl/FTLOperations.h:
        * inspector/ContentSearchUtilities.cpp:
        * runtime/JSObject.h:
        (JSC::JSObject::createRawObject):
        (JSC::JSFinalObject::create):
        * runtime/RegExp.cpp:
        (JSC::RegExp::compile):
        (JSC::RegExp::match):
        (JSC::RegExp::matchConcurrently):
        (JSC::RegExp::compileMatchOnly):
        (JSC::RegExp::deleteCode):
        * runtime/RegExp.h:
        * runtime/RegExpCachedResult.h:
        (JSC::RegExpCachedResult::offsetOfLastRegExp):
        (JSC::RegExpCachedResult::offsetOfLastInput):
        (JSC::RegExpCachedResult::offsetOfResult):
        (JSC::RegExpCachedResult::offsetOfReified):
        * runtime/RegExpConstructor.h:
        (JSC::RegExpConstructor::offsetOfCachedResult):
        * runtime/RegExpInlines.h:
        (JSC::RegExp::hasCodeFor):
        (JSC::RegExp::compileIfNecessary):
        (JSC::RegExp::matchInline):
        (JSC::RegExp::hasMatchOnlyCodeFor):
        (JSC::RegExp::compileIfNecessaryMatchOnly):
        * runtime/RegExpObjectInlines.h:
        (JSC::RegExpObject::execInline):
        * runtime/StringPrototype.cpp:
        (JSC::substituteBackreferencesSlow):
        (JSC::substituteBackreferencesInline):
        (JSC::substituteBackreferences):
        (JSC::StringRange::StringRange):
        * runtime/StringPrototype.h:
        * runtime/VM.h:
        * tests/stress/simple-regexp-exec-folding-fail.js: Added.
        (foo):
        * tests/stress/simple-regexp-exec-folding.js: Added.
        (foo):
        * tests/stress/simple-regexp-test-folding-fail.js: Added.
        (foo):
        * tests/stress/simple-regexp-test-folding.js: Added.
        (foo):
        * yarr/RegularExpression.cpp:
        * yarr/Yarr.h:
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::interpret):
        (JSC::Yarr::ByteCompiler::ByteCompiler):
        (JSC::Yarr::ByteCompiler::compile):
        (JSC::Yarr::ByteCompiler::checkInput):
        (JSC::Yarr::byteCompile):
        (JSC::Yarr::interpret):
        * yarr/YarrInterpreter.h:
        (JSC::Yarr::BytecodePattern::BytecodePattern):

2016-04-05  Keith Miller  <keith_miller@apple.com>

        We should support the ability to do a non-effectful getById
        https://bugs.webkit.org/show_bug.cgi?id=156116

        Reviewed by Benjamin Poulain.

        Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is
        useful because it enables us to take different code paths based on values that we would
        otherwise not be able to have knowledge of. This patch adds this new feature called
        try_get_by_id that will attempt to do as much of a get_by_id as possible without performing
        an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the
        GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and
        undefined if the slot is unset.  If the slot is proxied or any other cases then the result
        is null. In theory, if we ever wanted to check for null we could add a sentinal object to
        the global object that indicates we could not get the result.

        In order to implement this feature we add a new enum GetByIdKind that indicates what to do
        for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the
        get_by_id the same way we would for load and return the value at the appropriate offset.
        Additionally, in order to make sure the we can properly compare the GetterSetter object
        with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the
        GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are
        likely to have little to no impact on memory usage as normal accessors are generally rare.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createDefaultConstructor):
        (JSC::BuiltinExecutables::createBuiltinExecutable):
        (JSC::createBuiltinExecutable):
        (JSC::BuiltinExecutables::createExecutable):
        (JSC::createExecutableInternal): Deleted.
        * builtins/BuiltinExecutables.h:
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::tryGet):
        (JSC::AccessCase::generate):
        (WTF::printInternal):
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessCase::isGet): Deleted.
        (JSC::AccessCase::isPut): Deleted.
        (JSC::AccessCase::isIn): Deleted.
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::reset):
        * bytecode/StructureStubInfo.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitTryGetById):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::getById):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITInlineCacheGenerator.cpp:
        (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
        * jit/JITInlineCacheGenerator.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emit_op_try_get_by_id):
        (JSC::JIT::emitSlow_op_try_get_by_id):
        (JSC::JIT::emit_op_get_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emit_op_try_get_by_id):
        (JSC::JIT::emitSlow_op_try_get_by_id):
        (JSC::JIT::emit_op_get_by_id):
        * jit/Repatch.cpp:
        (JSC::repatchByIdSelfAccess):
        (JSC::appropriateOptimizingGetByIdFunction):
        (JSC::appropriateGenericGetByIdFunction):
        (JSC::tryCacheGetByID):
        (JSC::repatchGetByID):
        (JSC::resetGetByID):
        * jit/Repatch.h:
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionGetGetterSetter):
        (functionCreateBuiltin):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * runtime/GetterSetter.cpp:
        * runtime/GetterSetter.h:
        * runtime/JSType.h:
        * runtime/PropertySlot.cpp:
        (JSC::PropertySlot::getPureResult):
        * runtime/PropertySlot.h:
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        * tests/stress/try-get-by-id.js: Added.
        (tryGetByIdText):
        (getCaller.obj.1.throw.new.Error.let.func):
        (getCaller.obj.1.throw.new.Error):
        (throw.new.Error.get let):
        (throw.new.Error.):
        (throw.new.Error.let.get createBuiltin):
        (get let):
        (let.get createBuiltin):
        (let.func):
        (get let.func):
        (get throw):

2016-04-05  Saam barati  <sbarati@apple.com>

        jsc-layout-tests.yaml/js/script-tests/regress-141098.js failing on Yosemite Debug after r198989
        https://bugs.webkit.org/show_bug.cgi?id=156187

        Reviewed by Filip Pizlo.

        This is a speculative fix. Lets see if the prevents the timeout.

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

2016-04-04  Filip Pizlo  <fpizlo@apple.com>

        PolymorphicAccess should have a MegamorphicLoad case
        https://bugs.webkit.org/show_bug.cgi?id=156182

        Reviewed by Geoffrey Garen and Keith Miller.

        This introduces a new case to PolymorphicAccess called MegamorphicLoad. This inlines the lookup in
        the PropertyTable. It's cheaper than switching on a huge number of cases and it's cheaper than
        calling into C++ to do the same job - particularly since inlining the lookup into an access means
        that we can precompute the hash code.

        When writing the inline code for the hashtable lookup, I found that our hashing algorithm was not
        optimal. It used a double-hashing method for reducing collision pathologies. This is great for
        improving the performance of some worst-case scenarios. But this misses the point of a hashtable: we
        want to optimize the average-case performance. When optimizing for average-case, we can choose to
        either focus on maximizing the likelihood of the fast case happening, or to minimize the cost of the
        worst-case, or to minimize the cost of the fast case. Even a very basic hashtable will achieve a high
        probability of hitting the fast case. So, doing work to reduce the likelihood of a worst-case
        pathology only makes sense if it also preserves the good performance of the fast case, or reduces the
        likelihood of the worst-case by so much that it's a win for the average case even with a slow-down in
        the fast case.

        I don't believe, based on looking at how the double-hashing is implemented, that it's possible that
        this preserves the good performance of the fast case. It requires at least one more value to be live
        around the loop, and dramatically increases the register pressure at key points inside the loop. The
        biggest offender is the doubleHash() method itself. There is no getting around how bad this is: if
        the compiler live-range-splits that method to death to avoid degrading register pressure elsewhere
        then we will pay a steep price anytime we take the second iteration around the loop; but if the
        compiler doesn't split around the call then the hashtable lookup fast path will be full of spills on
        some architectures (I performed biological register allocation and found that I needed 9 registers
        for complete lookup, while x86-64 has only 6 callee-saves; OTOH ARM64 has 10 callee-saves so it might
        be better off).

        Hence, this patch changes the hashtable lookup to use simple linear probing. This was not a slow-down
        on anything, and it made MegamorphicLoad much more sensible since it is less likely to have to spill.

        There are some other small changes in this patch, like rationalizing the IC's choice between giving
        up after a repatch (i.e. never trying again) and just pretending that nothing happened (so we can
        try to repatch again in the future). It looked like the code in Repatch.cpp was set up to be able to
        choose between those options, but we weren't fully taking advantage of it because the
        regenerateWithCase() method just returned null for any failure, and didn't say whether it was the
        sort of failure that renders the inline cache unrepatchable (like memory allocation failure). Now
        this is all made explicit. I wanted to make sure this change happened in this patch since the
        MegamorphicLoad code automagically generates a MegamorphicLoad case by coalescing other cases. Since
        this is intended to avoid blowing out the cache and making it unrepatchable, I wanted to make sure
        that the rules for giving up were something that made sense to me.
        
        This is a big win on microbenchmarks. It's neutral on traditional JS benchmarks. It's a slight
        speed-up for page loading, because many real websites like to have megamorphic property accesses.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessGenerationResult::dump):
        (JSC::AccessGenerationState::addWatchpoint):
        (JSC::AccessCase::get):
        (JSC::AccessCase::megamorphicLoad):
        (JSC::AccessCase::replace):
        (JSC::AccessCase::guardedByStructureCheck):
        (JSC::AccessCase::couldStillSucceed):
        (JSC::AccessCase::canBeReplacedByMegamorphicLoad):
        (JSC::AccessCase::canReplace):
        (JSC::AccessCase::generateWithGuard):
        (JSC::AccessCase::generate):
        (JSC::PolymorphicAccess::PolymorphicAccess):
        (JSC::PolymorphicAccess::~PolymorphicAccess):
        (JSC::PolymorphicAccess::regenerateWithCases):
        (JSC::PolymorphicAccess::regenerateWithCase):
        (WTF::printInternal):
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessCase::isGet):
        (JSC::AccessCase::isPut):
        (JSC::AccessCase::isIn):
        (JSC::AccessGenerationResult::AccessGenerationResult):
        (JSC::AccessGenerationResult::operator==):
        (JSC::AccessGenerationResult::operator!=):
        (JSC::AccessGenerationResult::operator bool):
        (JSC::AccessGenerationResult::kind):
        (JSC::AccessGenerationResult::code):
        (JSC::AccessGenerationResult::madeNoChanges):
        (JSC::AccessGenerationResult::gaveUp):
        (JSC::AccessGenerationResult::generatedNewCode):
        (JSC::PolymorphicAccess::isEmpty):
        (JSC::AccessGenerationState::AccessGenerationState):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::aboutToDie):
        (JSC::StructureStubInfo::addAccessCase):
        * bytecode/StructureStubInfo.h:
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
        (JSC::AssemblyHelpers::loadProperty):
        (JSC::emitRandomThunkImpl):
        (JSC::AssemblyHelpers::emitRandomThunk):
        (JSC::AssemblyHelpers::emitLoadStructure):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::loadValue):
        (JSC::AssemblyHelpers::moveValueRegs):
        (JSC::AssemblyHelpers::argumentsStart):
        (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
        (JSC::AssemblyHelpers::emitLoadStructure): Deleted.
        * jit/GPRInfo.cpp:
        (JSC::JSValueRegs::dump):
        * jit/GPRInfo.h:
        (JSC::JSValueRegs::uses):
        * jit/Repatch.cpp:
        (JSC::replaceWithJump):
        (JSC::tryCacheGetByID):
        (JSC::tryCachePutByID):
        (JSC::tryRepatchIn):
        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):
        * runtime/Options.h:
        * runtime/PropertyMapHashTable.h:
        (JSC::PropertyTable::begin):
        (JSC::PropertyTable::find):
        (JSC::PropertyTable::get):
        * runtime/Structure.h:

2016-04-05  Antoine Quint  <graouts@apple.com>

        [WebGL2] Turn the ENABLE_WEBGL2 flag on
        https://bugs.webkit.org/show_bug.cgi?id=156061
        <rdar://problem/25463193>

        Reviewed by Alex Christensen.

        * Configurations/FeatureDefines.xcconfig:
        * runtime/CommonIdentifiers.h:

        Define the conditionalized classes WebGL2RenderingContext and WebGLVertexArrayObject. 

2016-04-04  Zan Dobersek  <zdobersek@igalia.com>

        Add missing EABI_32BIT_DUMMY_ARG arguments for some callOperation(J_JITOperation_EGReoJ, ...) overloads
        https://bugs.webkit.org/show_bug.cgi?id=156161

        Reviewed by Yusuke Suzuki.

        r197641 added a couple of callOperation(J_JITOperation_EGReoJ, ...) overloads
        that handle arguments split into the tag and the payload. The two were split
        between the last argument register and the stack on 32-bit ARM EABI systems,
        causing incorrect behavior.

        Adding EABI_32BIT_DUMMY_ARG pushes the tag and payload together onto the
        stack, removing the issue.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):

2016-04-04  Joseph Pecoraro  <pecoraro@apple.com>

        Avoid copying ModuleLoaderObject.js to resources bundle
        https://bugs.webkit.org/show_bug.cgi?id=156188
        <rdar://problem/25534383>

        Reviewed by Alexey Proskuryakov.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2016-04-04  Geoffrey Garen  <ggaren@apple.com>

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

        "Regressed Octane and Kraken on the perf bots."

        Reverted changeset:

        CopiedBlock should be 16kB
        https://bugs.webkit.org/show_bug.cgi?id=156168
        http://trac.webkit.org/changeset/199016

2016-04-04  Benjamin Poulain  <bpoulain@apple.com>

        [JSC][x86] Fix an assertion in MacroAssembler::branch8()
        https://bugs.webkit.org/show_bug.cgi?id=156181

        Reviewed by Geoffrey Garen.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::branch8):
        The test was wrong because valid negative numbers have ones
        in the top bits.

        I replaced the assertion to be explicit about the valid range.

2016-04-04  Chris Dumez  <cdumez@apple.com>

        Regression(r196145): Crash in getOwnPropertyDescriptor on http://www.history.com/shows/vikings
        https://bugs.webkit.org/show_bug.cgi?id=156136
        <rdar://problem/25410767>

        Reviewed by Ryosuke Niwa.

        Add a few more identifiers for using in the generated bindings.

        * runtime/CommonIdentifiers.h:

2016-04-04  Geoffrey Garen  <ggaren@apple.com>

        CopiedBlock should be 16kB
        https://bugs.webkit.org/show_bug.cgi?id=156168

        Reviewed by Mark Lam.

        MarkedBlock is 16kB, and bmalloc's largest fast-path allocation is 16kB,
        and the largest page size on Apple devices is 16kB -- so this change
        should improve sharing and recycling and keep us on the fast path more.

        32kB is also super aggro. At 16kB, we support allocations up to 8kB,
        which covers 99.3% of allocations on facebook.com. The 32kB block size
        only covered an additional 0.2% of allocations.

        * heap/CopiedBlock.h:

2016-04-04  Carlos Garcia Campos  <cgarcia@igalia.com>

        REGRESSION(r198792): [GTK] Inspector crashes in Inspector::Protocol::getEnumConstantValue since r198792
        https://bugs.webkit.org/show_bug.cgi?id=155745
        <rdar://problem/25289456>

        Reviewed by Brian Burg.

        The problem is that we are generating the Inspector::Protocol::getEnumConstantValue() method and the
        enum_constant_values array for every framework that has enum values. So, in case of GTK port we have two
        implementations, one for the inspector in JavaScriptCore and another one for Web Automation in WebKit2, but when
        using the inspector in WebKit2 we always end up using the one in WebKit2. Since the enum_constant_values array
        is smaller in WebKit2 than the one in JavaScriptCore, we crash every time we receive an enum value higher than
        the array size. We need to disambiguate the getEnumConstantValue() generated and used for every framework, so we
        can use a specific namespace for the enum conversion methods.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::breakpointActionTypeForString): Use Inspector::Protocol::InspectorHelpers.
        * inspector/scripts/codegen/cpp_generator.py:
        (CppGenerator.helpers_namespace): Return the namespace name that should be used for the helper methods.
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
        (CppBackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain): Use
        CppGenerator.helpers_namespace() to use the right namespace when using getEnumConstantValue().
        (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command): Ditto.
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
        (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event): Ditto.
        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (CppProtocolTypesHeaderGenerator.generate_output): Move declaration of getEnumConstantValue to a helper function.
        (_generate_enum_constant_value_conversion_methods): Do not emit any code if there aren't enums and ensure all
        conversion methods are declared inside the helpers namespace.
        (_generate_builder_setter_for_member): Use CppGenerator.helpers_namespace() to use the right namespace when
        using getEnumConstantValue().
        (_generate_unchecked_setter_for_member): Ditto.
        (_generate_declarations_for_enum_conversion_methods): Return a list instead of a string so that we can return an
        empty list in case of not emitting any code. The caller will use extend() that has no effect when an empty list
        is passed.
        * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
        (CppProtocolTypesImplementationGenerator.generate_output): Use the new helper function to generate both the enum
        mapping and conversion methods inside the helpers namespace.
        (CppProtocolTypesImplementationGenerator._generate_enum_mapping): Return a list instead of a string so that we
        can return an empty list in case of not emitting any code.
        (CppProtocolTypesImplementationGenerator._generate_enum_mapping_and_conversion_methods): Ensure we only emit
        code when there are enum values, and it's generated inside the helpers namespace.
        * 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:

2016-04-04  Csaba Osztrogonác  <ossy@webkit.org>

        Unreviewed ARM buildfix after r198981.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::roundTowardZeroDouble):

2016-04-03  Saam barati  <sbarati@apple.com>

        Implement Annex B.3.3 function hoisting rules for function code
        https://bugs.webkit.org/show_bug.cgi?id=155672

        Reviewed by Geoffrey Garen.

        The spec states that functions declared inside a function
        inside a block scope are subject to the rules of Annex B.3.3:
        https://tc39.github.io/ecma262/#sec-block-level-function-declarations-web-legacy-compatibility-semantics

        The rule states that functions declared in such blocks should
        be local bindings of the block. If declaring the function's name
        as a "var" in the function would not lead to a syntax error (i.e,
        if we don't have a let/const/class variable with the same name)
        and if we don't have a parameter with the same name, then we
        implictly also declare the funcion name as a "var". When evaluating
        the block statement we bind the hoisted "var" to be the value
        of the local function binding.

        There is one more thing we do for web compatibility. We allow
        function declarations inside if/else statements that aren't
        blocks. For such statements, we transform the code as if the
        function were declared inside a block statement. For example:
        ``` function foo() { if (cond) function baz() { } }```
        is transformed into:
        ``` function foo() { if (cond) { function baz() { } } }```

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
        (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
        * bytecompiler/BytecodeGenerator.h:
        * parser/Nodes.cpp:
        (JSC::ScopeNode::ScopeNode):
        (JSC::ProgramNode::ProgramNode):
        (JSC::ModuleProgramNode::ModuleProgramNode):
        (JSC::EvalNode::EvalNode):
        (JSC::FunctionNode::FunctionNode):
        * parser/Nodes.h:
        (JSC::ScopeNode::hasCapturedVariables):
        (JSC::ScopeNode::captures):
        (JSC::ScopeNode::hasSloppyModeHoistedFunction):
        (JSC::ScopeNode::varDeclarations):
        (JSC::ProgramNode::startColumn):
        (JSC::ProgramNode::endColumn):
        (JSC::EvalNode::startColumn):
        (JSC::EvalNode::endColumn):
        (JSC::ModuleProgramNode::startColumn):
        (JSC::ModuleProgramNode::endColumn):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::didFinishParsing):
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::Parser<LexerType>::parseIfStatement):
        * parser/Parser.h:
        (JSC::Scope::declareVariable):
        (JSC::Scope::declareFunction):
        (JSC::Scope::addSloppyModeHoistableFunctionCandidate):
        (JSC::Scope::appendFunction):
        (JSC::Scope::declareParameter):
        (JSC::Scope::mergeInnerArrowFunctionFeatures):
        (JSC::Scope::getSloppyModeHoistedFunctions):
        (JSC::Scope::getCapturedVars):
        (JSC::ScopeRef::containingScope):
        (JSC::ScopeRef::operator==):
        (JSC::ScopeRef::operator!=):
        (JSC::Parser::declareFunction):
        (JSC::Parser::hasDeclaredVariable):
        (JSC::Parser::isFunctionMetadataNode):
        (JSC::Parser::DepthManager::DepthManager):
        (JSC::Parser<LexerType>::parse):
        * parser/VariableEnvironment.h:
        (JSC::VariableEnvironmentEntry::isImported):
        (JSC::VariableEnvironmentEntry::isImportedNamespace):
        (JSC::VariableEnvironmentEntry::isFunction):
        (JSC::VariableEnvironmentEntry::isParameter):
        (JSC::VariableEnvironmentEntry::isSloppyModeHoistingCandidate):
        (JSC::VariableEnvironmentEntry::setIsCaptured):
        (JSC::VariableEnvironmentEntry::setIsConst):
        (JSC::VariableEnvironmentEntry::setIsImported):
        (JSC::VariableEnvironmentEntry::setIsImportedNamespace):
        (JSC::VariableEnvironmentEntry::setIsFunction):
        (JSC::VariableEnvironmentEntry::setIsParameter):
        (JSC::VariableEnvironmentEntry::setIsSloppyModeHoistingCandidate):
        (JSC::VariableEnvironmentEntry::clearIsVar):
        * runtime/CodeCache.h:
        (JSC::SourceCodeValue::SourceCodeValue):
        * runtime/JSScope.cpp:
        * runtime/JSScope.h:
        * tests/es6.yaml:
        * tests/stress/sloppy-mode-function-hoisting.js: Added.
        (assert):
        (test):
        (falsey):
        (truthy):
        (test.):
        (test.a):
        (test.f):
        (test.let.funcs.f):
        (test.catch.f):
        (test.foo):
        (test.bar):
        (test.switch.case.0):
        (test.else.f):
        (test.b):
        (test.c):
        (test.d):
        (test.e):
        (test.g):
        (test.h):
        (test.i):
        (test.j):
        (test.k):
        (test.l):
        (test.m):
        (test.n):
        (test.o):
        (test.p):
        (test.q):
        (test.r):
        (test.s):
        (test.t):
        (test.u):
        (test.v):
        (test.w):
        (test.x):
        (test.y):
        (test.z):
        (foo):
        (bar):
        (falsey.bar):
        (baz):
        (falsey.baz):

2016-04-03  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, turn ES6 for-in loop test success
        https://bugs.webkit.org/show_bug.cgi?id=155451

        * tests/es6.yaml:

2016-04-03  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Add truncate operation (rounding to zero)
        https://bugs.webkit.org/show_bug.cgi?id=156072

        Reviewed by Saam Barati.

        Add TruncIntrinsic for Math.trunc. DFG handles it as ArithTrunc.
        In DFG, ArithTrunc behaves similar to ArithRound, ArithCeil, and ArithFloor.
        ArithTrunc rounds the value towards zero.

        And we rewrite @toInteger to use @trunc instead of @abs, @floor, negation and branch.
        This is completely the same to what we do in JSValue::toInteger.

        Since DFG recognize it, DFG can convert ArithTrunc to Identity if the given argument is Int32.
        This is useful because almost all the argument is Int32 in @toLength -> @toInteger -> @trunc case.
        In such cases, we can eliminate trunc() call.

        As a bonus, to speed up Math.trunc operation, we use x86 SSE round and frintz in ARM64 for ArithRound.
        In DFG, we emit these instructions. In FTL, we use Patchpoint to emit these instructions to avoid adding a new B3 IR.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::roundTowardZeroDouble):
        (JSC::MacroAssemblerARM64::roundTowardZeroFloat):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::roundTowardZeroDouble):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::roundTowardZeroDouble):
        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::roundTowardZeroDouble):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::roundTowardZeroDouble):
        (JSC::MacroAssemblerX86Common::roundTowardZeroFloat):
        * builtins/GlobalObject.js:
        (toInteger):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * 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):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::arithNodeFlags):
        (JSC::DFG::Node::hasHeapPrediction):
        (JSC::DFG::Node::hasArithRoundingMode):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithRounding):
        * 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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithTrunc):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::doubleTrunc):
        * ftl/FTLOutput.h:
        * jit/ThunkGenerators.cpp:
        (JSC::truncThunkGenerator):
        * jit/ThunkGenerators.h:
        * runtime/CommonIdentifiers.h:
        * runtime/Intrinsic.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/MathObject.cpp:
        (JSC::MathObject::finishCreation):
        * runtime/MathObject.h:
        * runtime/VM.cpp:
        (JSC::thunkGeneratorForIntrinsic):
        * tests/stress/math-rounding-infinity.js:
        (testTrunc):
        * tests/stress/math-rounding-nan.js:
        (testTrunc):
        * tests/stress/math-rounding-negative-zero.js:
        (testTrunc):
        * tests/stress/math-trunc-arith-rounding-mode.js: Added.
        (firstCareAboutZeroSecondDoesNot):
        (firstDoNotCareAboutZeroSecondDoes):
        (warmup):
        (verifyNegativeZeroIsPreserved):
        * tests/stress/math-trunc-basics.js: Added.
        (mathTruncOnIntegers):
        (mathTruncOnDoubles):
        (mathTruncOnBooleans):
        (uselessMathTrunc):
        (mathTruncWithOverflow):
        (mathTruncConsumedAsDouble):
        (mathTruncDoesNotCareAboutMinusZero):
        (mathTruncNoArguments):
        (mathTruncTooManyArguments):
        (testMathTruncOnConstants):
        (mathTruncStructTransition):
        (Math.trunc):
        * tests/stress/math-trunc-should-be-truncate.js: Added.
        (mathTrunc):

2016-04-03  Skachkov Oleksandr  <gskachkov@gmail.com>

        [ES6] Class syntax. Access to new.target inside of the eval should not lead to SyntaxError
        https://bugs.webkit.org/show_bug.cgi?id=155545

        Reviewed by Saam Barati.
       
        Current patch allow to invoke new.target in eval if this eval is executed within function, 
        otherwise this will lead to Syntax error 
   
        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::getSlow):
        * bytecode/ExecutableInfo.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::evalContextType):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::evalContextType):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluate):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::setEvalContextType):
        (JSC::Scope::evalContextType):
        (JSC::parse):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        * runtime/CodeCache.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::ScriptExecutable):
        (JSC::EvalExecutable::create):
        (JSC::EvalExecutable::EvalExecutable):
        (JSC::ProgramExecutable::ProgramExecutable):
        (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
        (JSC::FunctionExecutable::FunctionExecutable):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::evalContextType):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createEvalCodeBlock):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
        * tests/stress/arrowfunction-lexical-bind-newtarget.js:
        * tests/stress/new-target.js:

2016-04-02  Commit Queue  <commit-queue@webkit.org>

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

        "Causes js/regress/array-nonarray-polymorhpic-access.html to
        crash." (Requested by ddkilzer on #webkit).

        Reverted changeset:

        "[JSC] Initialize SSA's live values at tail lazily"
        https://bugs.webkit.org/show_bug.cgi?id=156126
        http://trac.webkit.org/changeset/198976

2016-04-02  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Initialize SSA's live values at tail lazily
        https://bugs.webkit.org/show_bug.cgi?id=156126

        Reviewed by Mark Lam.

        Setting up the clean state early looks harmless but it is
        actually quite expensive.

        The problem is AbstractValue is gigantic, you really want
        to minimize how much you touch that memory.

        By removing the initialization, most blocks only
        get 2 or 3 accesses. Once to setup the value, and a few
        queries for merging the current block with the successors.

        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::endBasicBlock):
        (JSC::DFG::setLiveValues): Deleted.
        (JSC::DFG::InPlaceAbstractState::initialize): Deleted.

2016-04-02  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add an option to avoid disassembling baseline code for the JSC Profiler
        https://bugs.webkit.org/show_bug.cgi?id=156127

        Reviewed by Mark Lam.

        The profiler run out of memory on big programs if you dump
        the baseline disassembly.

        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * runtime/Options.h:

2016-04-02  Dan Bernstein  <mitz@apple.com>

        jsc binary embedded in relocatable JavaScriptCore.framework links against system JavaScriptCore.framework
        https://bugs.webkit.org/show_bug.cgi?id=156134
        <rdar://problem/25443824>

        Reviewed by Mark Lam.

        * Configurations/JSC.xcconfig: Define WK_RELOCATABLE_FRAMEWORKS_LDFLAGS when building
          relocatable frameworks to include a -dyld_env option setting DYLD_FRAMEWORK_PATH to point
          to the directory containing JavaScript.framework, and add
          WK_RELOCATABLE_FRAMEWORKS_LDFLAGS to OTHER_LDFLAGS.

2016-04-01  Benjamin Poulain  <bpoulain@apple.com>

        [JSC][x86] Add the 3 operands form of floating point substraction
        https://bugs.webkit.org/show_bug.cgi?id=156095

        Reviewed by Geoffrey Garen.

        Same old, same old. Add the AVX form of subsd and subss.

        Unfortunately, we cannot benefit from the 3 register form
        in B3 yet because the Air script does not support CPU flags yet.
        That can be fixed later.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::subDouble):
        (JSC::MacroAssemblerX86Common::subFloat):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::vsubsd_rr):
        (JSC::X86Assembler::subsd_mr):
        (JSC::X86Assembler::vsubsd_mr):
        (JSC::X86Assembler::vsubss_rr):
        (JSC::X86Assembler::subss_mr):
        (JSC::X86Assembler::vsubss_mr):
        (JSC::X86Assembler::X86InstructionFormatter::SingleInstructionBufferWriter::memoryModRM):
        * b3/air/AirOpcode.opcodes:

2016-04-01  Alberto Garcia  <berto@igalia.com>

        [JSC] Missing PATH_MAX definition
        https://bugs.webkit.org/show_bug.cgi?id=156102

        Reviewed by Yusuke Suzuki.

        Not all systems define PATH_MAX, so add a fallback value that is
        long enough.

        * jsc.cpp:

2016-03-31  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] CFA's valuesAtHead should be a list, not a map
        https://bugs.webkit.org/show_bug.cgi?id=156087

        Reviewed by Mark Lam.

        One more step toward moving to the Air-style of liveness analysis:

        Make DFG's valuesAtHead a list of Node*-AbstractValue.
        This patch alone is already a speedup because our many CFAs
        spend an unreasonable amount of time updating at block boundaries.

        * dfg/DFGBasicBlock.h:
        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::CFAPhase::performBlockCFA):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::beginBasicBlock):
        (JSC::DFG::setLiveValues):
        (JSC::DFG::InPlaceAbstractState::merge):
        * dfg/DFGNode.h:
        (JSC::DFG::nodeValuePairComparator):
        (JSC::DFG::nodeValuePairListDump):

2016-03-31  Saam barati  <sbarati@apple.com>

        Revert rewrite const as var workaround
        https://bugs.webkit.org/show_bug.cgi?id=155393

        Reviewed by Mark Lam.

        * parser/Parser.h:
        (JSC::Parser::next):
        (JSC::Parser::nextExpectIdentifier):
        * runtime/VM.h:
        (JSC::VM::setShouldRewriteConstAsVar): Deleted.
        (JSC::VM::shouldRewriteConstAsVar): Deleted.

2016-03-31  Saam barati  <sbarati@apple.com>

        [ES6] Disallow var assignments in for-in loops
        https://bugs.webkit.org/show_bug.cgi?id=155451

        Reviewed by Mark Lam.

        We're doing this in its own patch instead of the patch for https://bugs.webkit.org/show_bug.cgi?id=155384
        because last time we made this change it broke some websites. Lets try making
        it again because it's what the ES6 mandates. If it still breaks things we will
        roll it out.

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

2016-03-31  Saam barati  <sbarati@apple.com>

        parsing arrow function expressions slows down the parser by 8% lets recoup some loss
        https://bugs.webkit.org/show_bug.cgi?id=155988

        Reviewed by Benjamin Poulain.

        We used to eagerly check if we're parsing an arrow function.
        We did this inside parseAssignmentExpression(), and it was
        very costly. The reason it was costly is that arrow functions
        might start with an identifier. This means anytime we saw an
        identifier we would have to do a lookahead, and then most likely
        backtrack because more often than not, we wouldn't see "=>"
        as the next token.

        In this patch I implement a new approach. We just parse
        the lhs of an assignment expression eagerly without doing any
        lookahead. Retroactively, if we see that we might have started
        with an arrow function, and we don't have a valid lhs or the
        next token is a "=>", we try to parse as an arrow function.

        Here are a few examples motivating why this is valid:

        `x => x`
        In this example:
        - "x" is a valid arrow function starting point.
        - "x" also happens to be a valid lhs
        - because we see "=>" as the next token, we parse as an arrow function and succeed.

        `(x) => x`
        In this example:
        - "(" is a valid arrow function starting point.
        - "(x)" also happens to be a valid lhs
        - because we see "=>" as the next token, we parse as an arrow function and succeed.

        `({x = 30}) => x;`
        In this example:
        - "(" is a valid arrow function starting point.
        - "({x = 30})" is NOT a valid lhs. Because of this, we try to parse it as an arrow function and succeed.

        There is one interesting implementation detail where we might
        parse something that is both a valid LHS but happens
        to actually be the arrow function parameters. The valid LHS
        parsing might declare such variables as "uses" which would cause 
        weird capture analysis. This patch also introduces a mechanism
        to backtrack on used variable analysis.

        This is a 3.5%-4.5% octane code load speedup.

        * parser/Lexer.h:
        (JSC::Lexer::sawError):
        (JSC::Lexer::setSawError):
        (JSC::Lexer::getErrorMessage):
        (JSC::Lexer::setErrorMessage):
        (JSC::Lexer::sourceURL):
        (JSC::Lexer::sourceMappingURL):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::isArrowFunctionParameters):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::startSwitch):
        (JSC::Scope::declareParameter):
        (JSC::Scope::usedVariablesContains):
        (JSC::Scope::useVariable):
        (JSC::Scope::pushUsedVariableSet):
        (JSC::Scope::currentUsedVariablesSize):
        (JSC::Scope::revertToPreviousUsedVariables):
        (JSC::Scope::setNeedsFullActivation):
        (JSC::Scope::needsFullActivation):
        (JSC::Scope::isArrowFunctionBoundary):
        (JSC::Scope::setInnerArrowFunctionUsesEvalAndUseArgumentsIfNeeded):
        (JSC::Scope::collectFreeVariables):
        (JSC::Scope::fillParametersForSourceProviderCache):
        (JSC::Scope::restoreFromSourceProviderCache):
        (JSC::Scope::setIsModule):

2016-03-31  Yusuke Suzuki  <utatane.tea@gmail.com>

        Fails to build in Linux / PowerPC due to different ucontext_t definition
        https://bugs.webkit.org/show_bug.cgi?id=156015

        Reviewed by Michael Catanzaro.

        PPC does not have mcontext_t in ucontext_t::uc_mcontext.
        So we take the special way to retrieve mcontext_t in PPC.

        * heap/MachineStackMarker.cpp:
        (pthreadSignalHandlerSuspendResume):

2016-03-31  Benjamin Poulain  <benjamin@webkit.org>

        [JSC][x86] Add the indexed forms of floating point addition and multiplication
        https://bugs.webkit.org/show_bug.cgi?id=156058

        Reviewed by Geoffrey Garen.

        B3 supports lowering [base, index] addresses into
        arbitrary instructions but we were not using that feature.

        This patch adds the missing support for the lowering
        of Add and Mul.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::addDouble):
        (JSC::MacroAssemblerX86Common::addFloat):
        (JSC::MacroAssemblerX86Common::mulDouble):
        (JSC::MacroAssemblerX86Common::mulFloat):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::addsd_mr):
        (JSC::X86Assembler::vaddsd_mr):
        (JSC::X86Assembler::addss_mr):
        (JSC::X86Assembler::vaddss_mr):
        (JSC::X86Assembler::mulsd_mr):
        (JSC::X86Assembler::vmulsd_mr):
        (JSC::X86Assembler::mulss_mr):
        (JSC::X86Assembler::vmulss_mr):
        (JSC::X86Assembler::X86InstructionFormatter::SingleInstructionBufferWriter::memoryModRM):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::appendBinOp):
        Unlike the Addr form, we never need to transform a Tmp
        into an Index for spilling.

        Instead of duplicating all the code in MacroAssembler, I can
        just have the lowering phase try using addresses for the first
        argument when possible.

        * b3/air/AirOpcode.opcodes:
        * b3/air/testair.cpp:
        (JSC::B3::Air::testX86VMULSDBaseNeedsRex):
        (JSC::B3::Air::testX86VMULSDIndexNeedsRex):
        (JSC::B3::Air::testX86VMULSDBaseIndexNeedRex):
        (JSC::B3::Air::run):

2016-03-31  Saam barati  <sbarati@apple.com>

        DFG JIT bug in typeof constant folding where the input to typeof is an object or function
        https://bugs.webkit.org/show_bug.cgi?id=156034
        <rdar://problem/25446785>

        Reviewed by Ryosuke Niwa.

        AI would constant fold TypeOf to the string "object" if it saw that
        its input type didn't expand past the types contained in the set 
        "SpecObject - SpecObjectOther". But, SpecObject contains SpecFunction.
        And typeof of a function should return "function". This patch fixes
        this bug by making sure we constant fold to object iff the type
        doesn't expand past the set "SpecObject - SpecObjectOther - SpecFunction".

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * tests/stress/typeof-dfg-function-or-object.js: Added.
        (assert):
        (foo.else.o):
        (foo):

2016-03-31  Mark Lam  <mark.lam@apple.com>

        Gardening: Build and logic fix after r198873.
        https://bugs.webkit.org/show_bug.cgi?id=156043

        Not reviewed.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::addFloat):
        - 2 args were meant to be ordered differently in order to call the other addFloat.
          Instead, there was an infinite recursion bug.  This is now fixed.

2016-03-30  Benjamin Poulain  <benjamin@webkit.org>

        [JSC][x86] Add the 3 operands forms of floating point addition and multiplication
        https://bugs.webkit.org/show_bug.cgi?id=156043

        Reviewed by Geoffrey Garen.

        When they are available, VADD and VMUL are better options to lower
        floating point addition and multiplication.

        In the simple cases when one of the operands is aliased to the destination,
        those forms have the same size or 1 byte shorter depending on the registers.

        In the more advanced cases, we gain nice advantages with the new forms:
        -We can get rid of the MoveDouble in front the instruction when we cannot
         alias.
        -We can disable aliasing entirely in Air. That is useful for latency
         since computing coalescing is not exactly cheap.

        * assembler/MacroAssemblerX86Common.cpp:
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::and32):
        (JSC::MacroAssemblerX86Common::mul32):
        (JSC::MacroAssemblerX86Common::or32):
        (JSC::MacroAssemblerX86Common::xor32):
        (JSC::MacroAssemblerX86Common::branchAdd32):
        The change in B3LowerToAir exposed a bug in the fake 3 operands
        forms of those instructions. If the address is equal to
        the destination, we were nuking the address.

        For example,
            Add32([%r11], %eax, %r11)
        would generate:
            move %eax, %r11
            add32 [%r11], %r11
        which crashes.

        I updated codegen of those cases to support that case through
            load32 [%r11], %r11
            add32 %eax, %r11

        The weird case were all arguments have the same registers
        is handled too.

        (JSC::MacroAssemblerX86Common::addDouble):
        (JSC::MacroAssemblerX86Common::addFloat):
        (JSC::MacroAssemblerX86Common::mulDouble):
        (JSC::MacroAssemblerX86Common::mulFloat):
        (JSC::MacroAssemblerX86Common::supportsFloatingPointRounding):
        (JSC::MacroAssemblerX86Common::supportsAVX):
        (JSC::MacroAssemblerX86Common::updateEax1EcxFlags):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::branchAdd64):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::vaddsd_rr):
        (JSC::X86Assembler::vaddsd_mr):
        (JSC::X86Assembler::vaddss_rr):
        (JSC::X86Assembler::vaddss_mr):
        (JSC::X86Assembler::vmulsd_rr):
        (JSC::X86Assembler::vmulsd_mr):
        (JSC::X86Assembler::vmulss_rr):
        (JSC::X86Assembler::vmulss_mr):
        (JSC::X86Assembler::X86InstructionFormatter::SingleInstructionBufferWriter::memoryModRM):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::appendBinOp):
        Add the 3 operand forms so that we lower Add and Mul
        to the best form directly.

        I will change how we lower the fake 3 operands instructions
        but the codegen should end up the same in most cases.
        The new codegen is the load32 + op above.

        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::shouldTryAliasingDef):
        * b3/air/testair.cpp:
        (JSC::B3::Air::testX86VMULSD):
        (JSC::B3::Air::testX86VMULSDDestRex):
        (JSC::B3::Air::testX86VMULSDOp1DestRex):
        (JSC::B3::Air::testX86VMULSDOp2DestRex):
        (JSC::B3::Air::testX86VMULSDOpsDestRex):
        (JSC::B3::Air::testX86VMULSDAddr):
        (JSC::B3::Air::testX86VMULSDAddrOpRexAddr):
        (JSC::B3::Air::testX86VMULSDDestRexAddr):
        (JSC::B3::Air::testX86VMULSDRegOpDestRexAddr):
        (JSC::B3::Air::testX86VMULSDAddrOpDestRexAddr):
        Make sure we have some coverage for AVX encoding of instructions.

2016-03-30  Saam Barati  <sbarati@apple.com>

        Change some release asserts in CodeBlock linking into debug asserts
        https://bugs.webkit.org/show_bug.cgi?id=155500

        Reviewed by Filip Pizlo.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):

2016-03-30  Joseph Pecoraro  <pecoraro@apple.com>

        Remove unused ScriptProfiler.Samples.totalTime
        https://bugs.webkit.org/show_bug.cgi?id=156002

        Reviewed by Saam Barati.

        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::buildSamples):
        (Inspector::InspectorScriptProfilerAgent::trackingComplete):
        * inspector/protocol/ScriptProfiler.json:
        Remove totalTime.

        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::SamplingProfiler): Deleted.
        * runtime/SamplingProfiler.h:
        (JSC::SamplingProfiler::totalTime): Deleted.
        Remove now unused m_totalTime.

2016-03-30  Michael Saboff  <msaboff@apple.com>

        [ES6] Quantified unicode regular expressions do not work for counts greater than 1
        https://bugs.webkit.org/show_bug.cgi?id=156044

        Reviewed by Mark Lam.

        Fixed incorrect indexing of non-BMP characters in fixed patterns.  The old code
        was indexing by character units, a single JS character, instead of code points
        which is 2 JS characters.

        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::matchDisjunction):

2016-03-30  Mark Lam  <mark.lam@apple.com>

        Make the $vm debugging tools available to builtins as @$vm.
        https://bugs.webkit.org/show_bug.cgi?id=156012

        Reviewed by Saam Barati.

        We also need some debugging tools for builtin development.  The $vm object will
        be made available to builtins as @$vm, which gives us, amongst many goodies,
        @$vm.print() (which prints the toString() values of its args) and
        @$vm.printValue() (which dataLogs its arg as a JSValue).  @$vm will only be
        available if we run with JSC_useDollarVM=true.

        Also changed @$vm.print() to not automatically insert a space between the
        printing of each of its args.  This makes it clearer as to what will be printed
        i.e. it will only print what is passed to it.

        * builtins/BuiltinNames.h:
        (JSC::BuiltinNames::BuiltinNames):
        (JSC::BuiltinNames::dollarVMPublicName):
        (JSC::BuiltinNames::dollarVMPrivateName):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::functionPrint):

2016-03-30  Keith Miller  <keith_miller@apple.com>

        Unreviewed, buildfix.

        * bytecode/BytecodeIntrinsicRegistry.h:

2016-03-30  Keith Miller <keith_miller@apple.com>

        Unreviewed, rollout r198808. The patch causes crashes on 32-bit and appears to be a JSBench regression.

2016-03-30  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Implement String.prototype.repeat in builtins JS
        https://bugs.webkit.org/show_bug.cgi?id=155974

        Reviewed by Darin Adler.

        This patch converts C++ String.prototype.repeat implementation into JS builtins.
        |this| in strict mode is correctly inferred as String[1]. This fact encourages us
        to write PrimitiveTypes.prototype.XXX methods in builtin JS.

        LayoutTests/js/string-repeat.html already covers the tests for this change.

        Note: String.prototype.repeat functionality is similar to Harmony's
        String.prototype.{padStart, padEnd}. It's nice to port them to builtin JS in
        the other patch.

        The existing C++ code has the fast path for singleCharacterString repeating.
        Since this use is important (e.g. generating N length spaces: ' '.repeat(N)),
        we keep this fast path as @repeatCharacter().

        The performance results show that, while the performance of the single character fast path
        is neutral, other string repeating has significant speed up.
        There are two reasons.

        1. Not resolving string rope.

        We added several tests postfixed "not-resolving". In that tests, we do not touch the content
        of the generated string. As a result, the generated rope is not resolved.

        2. O(log N) intermediate JSRopeStrings.

        In the existing C++ implementation, we use JSString::RopeBuilder. We iterate N times and append
        the given string to the builder.
        In this case, the intermediate rope strings generated in JSString::RopeBuilder is O(N).
        In JS builtin implementation, we only iterate log N times. As a result, the number of the
        intermediate rope strings becomes O(log N).

        [1]: http://trac.webkit.org/changeset/195938

        * builtins/StringPrototype.js:
        (repeatSlowPath):
        (repeat):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncRepeatCharacter):
        (JSC::StringPrototype::finishCreation): Deleted.
        (JSC::stringProtoFuncRepeat): Deleted.
        * runtime/StringPrototype.h:
        * tests/stress/string-repeat-edge-cases.js: Added.
        (shouldBe):
        (let.object.toString):
        (valueOf):
        (shouldThrow):

2016-03-30  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Update udis86
        https://bugs.webkit.org/show_bug.cgi?id=156005

        Reviewed by Geoffrey Garen.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * disassembler/udis86/differences.txt:
        * disassembler/udis86/itab.py: Removed.
        * disassembler/udis86/optable.xml:
        * disassembler/udis86/ud_itab.py: Added.
        * disassembler/udis86/ud_opcode.py:
        * disassembler/udis86/ud_optable.py: Removed.
        * disassembler/udis86/udis86.c:
        * disassembler/udis86/udis86_decode.c:
        * disassembler/udis86/udis86_decode.h:
        * disassembler/udis86/udis86_extern.h:
        * disassembler/udis86/udis86_input.c: Removed.
        * disassembler/udis86/udis86_input.h: Removed.
        * disassembler/udis86/udis86_syn-att.c:
        * disassembler/udis86/udis86_syn.h:
        * disassembler/udis86/udis86_types.h:
        * disassembler/udis86/udis86_udint.h:

2016-03-30  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Get rid of operationInitGlobalConst(), it is useless
        https://bugs.webkit.org/show_bug.cgi?id=156010

        Reviewed by Geoffrey Garen.

        * jit/JITOperations.cpp:
        * jit/JITOperations.h:

2016-03-29  Saam barati  <sbarati@apple.com>

        Fix typos in our error messages and remove some trailing periods
        https://bugs.webkit.org/show_bug.cgi?id=155985

        Reviewed by Mark Lam.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * runtime/ArrayConstructor.h:
        (JSC::isArray):
        * runtime/ProxyConstructor.cpp:
        (JSC::makeRevocableProxy):
        (JSC::proxyRevocableConstructorThrowError):
        (JSC::ProxyConstructor::finishCreation):
        (JSC::constructProxyObject):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::finishCreation):
        (JSC::performProxyGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::performPut):
        (JSC::performProxyCall):
        (JSC::performProxyConstruct):
        (JSC::ProxyObject::performDelete):
        (JSC::ProxyObject::performPreventExtensions):
        (JSC::ProxyObject::performIsExtensible):
        (JSC::ProxyObject::performDefineOwnProperty):
        (JSC::ProxyObject::performGetOwnPropertyNames):
        (JSC::ProxyObject::performSetPrototype):
        (JSC::ProxyObject::performGetPrototype):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncStartsWith):
        (JSC::stringProtoFuncEndsWith):
        (JSC::stringProtoFuncIncludes):
        * runtime/Structure.cpp:
        (JSC::Structure::preventExtensionsTransition):
        * tests/stress/proxy-basic.js:
        * tests/stress/proxy-construct.js:
        (throw.new.Error):
        (assert):
        * tests/stress/proxy-define-own-property.js:
        (assert):
        (throw.new.Error):
        (i.catch):
        (assert.set get catch):
        * tests/stress/proxy-delete.js:
        (assert):
        * tests/stress/proxy-get-own-property.js:
        (assert):
        (i.catch):
        (set get let):
        * tests/stress/proxy-get-prototype-of.js:
        (assert):
        (assert.get let):
        (assert.get catch):
        * tests/stress/proxy-has-property.js:
        (assert):
        * tests/stress/proxy-is-array.js:
        (test):
        * tests/stress/proxy-is-extensible.js:
        (assert):
        * tests/stress/proxy-json.js:
        (assert):
        (test):
        * tests/stress/proxy-own-keys.js:
        (assert):
        (i.catch):
        * tests/stress/proxy-prevent-extensions.js:
        (assert):
        * tests/stress/proxy-property-descriptor.js:
        * tests/stress/proxy-revoke.js:
        (assert):
        (throw.new.Error.):
        (throw.new.Error):
        (shouldThrowNullHandler):
        * tests/stress/proxy-set-prototype-of.js:
        (assert.set let):
        (assert.set catch):
        (assert):
        (set catch):
        * tests/stress/proxy-set.js:
        (throw.new.Error.let.handler.set 45):
        (throw.new.Error):
        * tests/stress/proxy-with-private-symbols.js:
        (assert):
        * tests/stress/proxy-with-unbalanced-getter-setter.js:
        (assert):
        * tests/stress/reflect-set-proxy-set.js:
        (throw.new.Error.let.handler.set 45):
        (throw.new.Error):
        * tests/stress/reflect-set-receiver-proxy-set.js:
        (let.handler.set 45):
        (catch):
        * tests/stress/string-prototype-methods-endsWith-startsWith-includes-correctness.js:
        (test):
        (test.get let):

2016-03-29  Keith Miller  <keith_miller@apple.com>

        [ES6] Add support for Symbol.isConcatSpreadable.
        https://bugs.webkit.org/show_bug.cgi?id=155351

        Reviewed by Saam Barati.

        This patch adds support for Symbol.isConcatSpreadable. In order to do so it was necessary to move the
        Array.prototype.concat function to JS. A number of different optimizations were needed to make such the move to
        a builtin performant. First, four new DFG intrinsics were added.

        1) IsArrayObject (I would have called it IsArray but we use the same name for an IndexingType): an intrinsic of
           the Array.isArray function.
        2) IsJSArray: checks the first child is a JSArray object.
        3) IsArrayConstructor: checks the first child is an instance of ArrayConstructor.
        4) CallObjectConstructor: an intrinsic of the Object constructor.

        IsActualObject, IsJSArray, and CallObjectConstructor can all be converted into constants in the abstract interpreter if
        we are able to prove that the first child is an Array or for ToObject an Object.

        In order to further improve the perfomance we also now cover more indexing types in our fast path memcpy
        code. Before we would only memcpy Arrays if they had the same indexing type and did not have Array storage and
        were not undecided. Now the memcpy code covers the following additional two cases: One array is undecided and
        the other is a non-array storage and the case where one array is Int32 and the other is contiguous (we map this
        into a contiguous array).

        This patch also adds a new fast path for concat with more than one array argument by using memcpy to append
        values onto the result array. This works roughly the same as the two array fast path using the same methodology
        to decide if we can memcpy the other butterfly into the result butterfly.

        Two new debugging tools are also added to the jsc cli. One is a version of the print function with a private
        name so it can be used for debugging builtins. The other is dumpDataLog, which takes a JSValue and runs our
        dataLog function on it.

        Finally, this patch add a new constructor to JSValueRegsTemporary that allows it to reuse the the registers of a
        JSValueOperand if the operand's use count is one.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ArrayPrototype.js:
        (concatSlowPath):
        (concat):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * 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::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::compileIsJSArray):
        (JSC::DFG::SpeculativeJIT::compileIsArrayObject):
        (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor):
        (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
        * dfg/DFGSpeculativeJIT.h:
        (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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::isArray):
        * jit/JITOperations.h:
        * jsc.cpp:
        (WTF::RuntimeArray::createStructure):
        (GlobalObject::finishCreation):
        (functionDebug):
        (functionDataLogValue):
        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
        * runtime/ArrayConstructor.h:
        (JSC::isArrayConstructor):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::arrayProtoPrivateFuncIsJSArray):
        (JSC::moveElements):
        (JSC::arrayProtoPrivateFuncConcatMemcpy):
        (JSC::arrayProtoPrivateFuncAppendMemcpy):
        (JSC::arrayProtoFuncConcat): Deleted.
        * runtime/ArrayPrototype.h:
        (JSC::ArrayPrototype::createStructure):
        * runtime/CommonIdentifiers.h:
        * runtime/Intrinsic.h:
        * runtime/JSArray.cpp:
        (JSC::JSArray::appendMemcpy):
        (JSC::JSArray::fastConcatWith): Deleted.
        * runtime/JSArray.h:
        (JSC::JSArray::createStructure):
        (JSC::JSArray::fastConcatType): Deleted.
        * runtime/JSArrayInlines.h: Added.
        (JSC::JSArray::memCopyWithIndexingType):
        (JSC::JSArray::canFastCopy):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSType.h:
        * runtime/ObjectConstructor.h:
        (JSC::constructObject):
        * tests/es6.yaml:
        * tests/stress/array-concat-spread-object.js: Added.
        (arrayEq):
        * tests/stress/array-concat-spread-proxy-exception-check.js: Added.
        (arrayEq):
        * tests/stress/array-concat-spread-proxy.js: Added.
        (arrayEq):
        * tests/stress/array-concat-with-slow-indexingtypes.js: Added.
        (arrayEq):
        * tests/stress/array-species-config-array-constructor.js:

2016-03-29  Saam barati  <sbarati@apple.com>

        We don't properly optimize TDZ checks when we declare a let variable without an initializer
        https://bugs.webkit.org/show_bug.cgi?id=150453

        Reviewed by Mark Lam.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::EmptyLetExpression::emitBytecode):

2016-03-29  Saam barati  <sbarati@apple.com>

        Allow builtin JS functions to be intrinsics
        https://bugs.webkit.org/show_bug.cgi?id=155960

        Reviewed by Mark Lam.

        Builtin functions can now be recognized as intrinsics inside
        the DFG. This gives us the flexibility to either lower a builtin
        as an intrinsic in the DFG or as a normal function call.
        Because we may decide to not lower it as an intrinsic, the DFG
        inliner could still inline the function call.

        You can annotate a builtin function like so to make
        it be recognized as an intrinsic.
        ```
        [intrinsic=FooIntrinsic] function foo() { ... }
        ```
        where FooIntrinsic is an enum value of the Intrinsic enum.

        So in the future if we write RegExp.prototype.test as a builtin, we would do:
        ``` RegExpPrototype.js
        [intrinsic=RegExpTestIntrinsic] function test() { ... }
        ```

        * Scripts/builtins/builtins_generate_combined_implementation.py:
        (BuiltinsCombinedImplementationGenerator.generate_secondary_header_includes):
        * Scripts/builtins/builtins_generate_separate_implementation.py:
        (BuiltinsSeparateImplementationGenerator.generate_secondary_header_includes):
        * Scripts/builtins/builtins_generator.py:
        (BuiltinsGenerator.generate_embedded_code_string_section_for_function):
        * Scripts/builtins/builtins_model.py:
        (BuiltinObject.__init__):
        (BuiltinFunction):
        (BuiltinFunction.__init__):
        (BuiltinFunction.fromString):
        (BuiltinFunction.__str__):
        * Scripts/builtins/builtins_templates.py:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::visitChildren):
        (JSC::UnlinkedFunctionExecutable::link):
        * bytecode/UnlinkedFunctionExecutable.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        * runtime/Executable.cpp:
        (JSC::ExecutableBase::clearCode):
        (JSC::NativeExecutable::destroy):
        (JSC::ScriptExecutable::ScriptExecutable):
        (JSC::EvalExecutable::create):
        (JSC::EvalExecutable::EvalExecutable):
        (JSC::ProgramExecutable::ProgramExecutable):
        (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
        (JSC::FunctionExecutable::FunctionExecutable):
        (JSC::ExecutableBase::intrinsic): Deleted.
        (JSC::NativeExecutable::intrinsic): Deleted.
        * runtime/Executable.h:
        (JSC::ExecutableBase::ExecutableBase):
        (JSC::ExecutableBase::hasJITCodeFor):
        (JSC::ExecutableBase::intrinsic):
        (JSC::ExecutableBase::intrinsicFor):
        (JSC::ScriptExecutable::finishCreation):
        * runtime/Intrinsic.h:

2016-03-29  Joseph Pecoraro  <pecoraro@apple.com>

        JSC::Debugger cleanup after recent changes
        https://bugs.webkit.org/show_bug.cgi?id=155982

        Reviewed by Mark Lam.

        * debugger/Debugger.cpp:
        (JSC::Debugger::Debugger):
        Initialize with breakpoints disabled. Web Inspector always informs
        the backend if it should enable or disable breakpoints on startup.

        (JSC::Debugger::setProfilingClient):
        When using the Sampling profiler we do not need to recompile.

2016-03-29  Saam barati  <sbarati@apple.com>

        "Can not" => "cannot" in String.prototype error messages
        https://bugs.webkit.org/show_bug.cgi?id=155895

        Reviewed by Mark Lam.

        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncStartsWith):
        (JSC::stringProtoFuncEndsWith):
        (JSC::stringProtoFuncIncludes):
        * tests/stress/string-prototype-methods-endsWith-startsWith-includes-correctness.js:
        (test):
        (test.get let):

2016-03-29  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: We should have a way to capture heap snapshots programatically.
        https://bugs.webkit.org/show_bug.cgi?id=154407
        <rdar://problem/24726292>

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Console.json:
        Add a new Console.heapSnapshot event for when a heap snapshot is taken.

        * runtime/ConsolePrototype.cpp:
        (JSC::ConsolePrototype::finishCreation):
        (JSC::consoleProtoFuncProfile):
        (JSC::consoleProtoFuncProfileEnd):
        (JSC::consoleProtoFuncTakeHeapSnapshot):
        * runtime/ConsoleClient.h:
        Add the console.takeHeapSnapshot method and dispatch to the ConsoleClient.

        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::takeHeapSnapshot):
        * inspector/JSGlobalObjectConsoleClient.h:
        Have the InspectorConsoleAgent handle this.

        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::InspectorConsoleAgent):
        (Inspector::InspectorConsoleAgent::takeHeapSnapshot):
        * inspector/agents/InspectorConsoleAgent.h:
        * inspector/agents/JSGlobalObjectConsoleAgent.cpp:
        (Inspector::JSGlobalObjectConsoleAgent::JSGlobalObjectConsoleAgent):
        * inspector/agents/JSGlobalObjectConsoleAgent.h:
        Give the ConsoleAgent a HeapAgent pointer so that it can have the HeapAgent
        perform the snapshot building work like it normally does.

2016-03-29  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION(r192914): 10% regression on Sunspider's date-format-tofte
        https://bugs.webkit.org/show_bug.cgi?id=155559

        Reviewed by Saam Barati.

        The fast path of the eval function is the super hot path in date-format-tofte.
        Any performance regression is not allowed here.
        Before this patch, we allocated SourceCode in the fast path.
        This allocation incurs 10% performance regression.

        This patch removes this allocation in the fast path.
        And change the key of the EvalCodeCache to EvalCodeCache::CacheKey.
        It combines RefPtr<StringImpl> and isArrowFunctionContext.
        Since EvalCodeCache does not cache any eval code evaluated under the strict mode,
        it is unnecessary to include several options (ThisTDZMode, and DerivedContextType) in the cache map's key.
        But isArrowFunctionContext is necessary since the sloppy mode arrow function exists.

        To validate this change, we add a new test that evaluates the same code
        under the non-arrow function context and the arrow function context.

        After introducing CacheKey, we observed 1% regression compared to the RefPtr<StringImpl> keyed case.
        This is because HashMap<RefPtr<T>, ...>::get(T*) is specially optimized; this path is inlined while the normal ::get() is not inlined.
        To avoid this performance regression, we introduce HashMap::fastGet, that aggressively encourages inlining.
        The relationship between fastGet() and get() is similar to fastAdd() and add().
        After applying this change, the evaluation shows no performance regression in comparison with the RefPtr<StringImpl> keyed case.

        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::CacheKey::CacheKey):
        (JSC::EvalCodeCache::CacheKey::hash):
        (JSC::EvalCodeCache::CacheKey::isEmptyValue):
        (JSC::EvalCodeCache::CacheKey::operator==):
        (JSC::EvalCodeCache::CacheKey::isHashTableDeletedValue):
        (JSC::EvalCodeCache::CacheKey::Hash::hash):
        (JSC::EvalCodeCache::CacheKey::Hash::equal):
        (JSC::EvalCodeCache::tryGet):
        (JSC::EvalCodeCache::getSlow):
        (JSC::EvalCodeCache::isCacheable):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * tests/stress/eval-in-arrow-function.js: Added.
        (shouldBe):
        (i):

2016-03-29  Joseph Pecoraro  <pecoraro@apple.com>

        Audit WebCore builtins for user overridable code
        https://bugs.webkit.org/show_bug.cgi?id=155923

        Reviewed by Youenn Fablet.

        * runtime/CommonIdentifiers.h:
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        Expose @Object.@defineProperty to built-ins.

2016-03-28  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] ArithSub should not propagate "UsesAsOther"
        https://bugs.webkit.org/show_bug.cgi?id=155932

        Reviewed by Mark Lam.

        The node ArithSub was backpropagating UsesAsOther.
        This causes any GetByVal on a Double Array to have an extra
        hole check if it flows into an ArithSub.

        The definition of ArithSub (12.8.4.1) has both operands go
        through ToNumber(). ToNumber() on "undefined" always produces
        NaN. It is safe to ignore the NaN marker from hole when
        the DAG flows into ArithSub.

        This patch also adds this change and test coverage to ArithAdd.
        ArithAdd was not a problem in practice because it is only
        generated before Fixup if both operands are known to be numerical.
        The change to ArithAdd is there to protect us of the ArithSub-like
        problems if we ever improve our support of arithmetic operators.

        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * tests/stress/arith-add-on-double-array-with-holes.js: Added.
        (let.testCase.of.testCases.eval.nonObservableHoleOnLhs):
        (let.testCase.of.testCases.observableHoleOnLhs):
        (let.testCase.of.testCases.nonObservableHoleOnRhs):
        (let.testCase.of.testCases.observableHoleOnRhs):
        * tests/stress/arith-sub-on-double-array-with-holes.js: Added.
        (let.testCase.of.testCases.eval.nonObservableHoleOnLhs):
        (let.testCase.of.testCases.observableHoleOnLhs):
        (let.testCase.of.testCases.nonObservableHoleOnRhs):
        (let.testCase.of.testCases.observableHoleOnRhs):
        * tests/stress/value-add-on-double-array-with-holes.js: Added.
        (let.testCase.of.testCases.eval.nonObservableHoleOnLhs):
        (let.testCase.of.testCases.observableHoleOnLhs):
        (let.testCase.of.testCases.nonObservableHoleOnRhs):
        (let.testCase.of.testCases.observableHoleOnRhs):

2016-03-28  Brian Burg  <bburg@apple.com>

        Web Inspector: protocol generator should generate C++ string-to-enum helper functions
        https://bugs.webkit.org/show_bug.cgi?id=155691
        <rdar://problem/25258078>

        Reviewed by Timothy Hatcher.

        There's a lot of code throughout the Inspector agents and automation code
        that needs to convert a raw string into a typed protocol enum. Generate
        some helpers that do this conversion so clients can move over to using it.

        These helpers are necessary for when we eventually switch to calling backend
        dispatcher handlers with typed arguments instead of untyped JSON objects.

        To correctly generate a conversion function for an anonymous enum, the
        generator needs to be able to get the containing object type's declaration.
        Since the model's Type object each have only one instance, there is a
        one-to-one association between type and its declaration.

        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (CppProtocolTypesHeaderGenerator.generate_output):
        (CppProtocolTypesHeaderGenerator._generate_forward_declarations):
        Clean up this method to use methodcaller to sort types by raw name.

        (_generate_declarations_for_enum_conversion_methods):
        (_generate_declarations_for_enum_conversion_methods.return_type_with_export_macro):
        (_generate_declarations_for_enum_conversion_methods.type_member_is_anonymous_enum_type):
        Added. Generates a new section with an unfilled template and specializations of
        the template for every named and anonymous enum in every domain. Guards for
        domains wrap the forward declarations. This is added to the end of the header
        file so that specializations for both types of enums are in the same place.

        * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
        (CppProtocolTypesImplementationGenerator.generate_output):
        (CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain):
        (CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain.type_member_is_anonymous_enum_type):
        (CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain.generate_conversion_method_body):
        Added. Generate a static array of offsets into the enum constant value array.
        Then, loop over this array of offsets and do string comparisons against the
        provided string and enum constant values at the relevant offsets for this enum.

        * inspector/scripts/codegen/generator_templates.py:
        (GeneratorTemplates): Update copyright year in generated files.

        * inspector/scripts/codegen/models.py:
        (AliasedType.__init__):
        (EnumType.__init__):
        (EnumType.enum_values):
        (EnumType.declaration):
        (ArrayType.__init__):
        (ArrayType.declaration):
        (ObjectType.__init__):
        (ObjectType.declaration):
        (Protocol.resolve_types):
        (Protocol.lookup_type_reference):
        Pass the type declaration to Type constructors if available. If not,
        fill in a placeholder name for the type in the constructor instead of caller.

        Rebaseline all the things, mostly for copyright block changes.

        * 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:

2016-03-25  Joseph Pecoraro  <pecoraro@apple.com>

        Misc. JavaScriptCore built-ins cleanups
        https://bugs.webkit.org/show_bug.cgi?id=155920

        Reviewed by Mark Lam.

        * builtins/RegExpPrototype.js:
        (match):
        No need for an else after an if that always returns.

        * builtins/TypedArrayConstructor.js:
        (of):
        Fix error message to use the correct function name.

        (allocateInt8Array):
        (allocateInt16Array):
        (allocateInt32Array):
        (allocateUint32Array):
        (allocateUint16Array):
        (allocateUint8Array):
        (allocateUint8ClampedArray):
        (allocateFloat32Array):
        (allocateFloat64Array):
        Cleanup style to be like all the other code.

        * tests/stress/typedarray-of.js:
        Test the exception message.

2016-03-25  Joseph Pecoraro  <pecoraro@apple.com>

        Date.prototype.toLocaleDateString uses overridable Object.create
        https://bugs.webkit.org/show_bug.cgi?id=155917

        Reviewed by Mark Lam.

        * builtins/DatePrototype.js:
        (toLocaleString.toDateTimeOptionsAnyAll):
        (toLocaleDateString.toDateTimeOptionsDateDate):
        (toLocaleTimeString.toDateTimeOptionsTimeTime):
        Switch from @Object.create to @Object.@create to guarentee we are
        using the built-in create method and not user defined code.

        * runtime/CommonIdentifiers.h:
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        Setup the @create private symbol.

2016-03-25  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Put the x86 Assembler on a binary diet
        https://bugs.webkit.org/show_bug.cgi?id=155683

        Reviewed by Darin Adler.

        The MacroAssemblers are heavily inlined. This is unfortunately
        important for baseline JIT where many branches can be eliminated
        at compile time.

        This inlining causes a lot of binary bloat. The phases
        lowering to ASM are massively large.

        This patch improves the situation a bit for x86 through
        many small improvements:

        -Every instruction starts with ensureSpace(). The slow
         path realloc the buffer.
         From that slow path, only fastRealloc() was a function
         call. What is around does not need to be fast, I moved
         the whole grow() function out of line for those cases.

        -When testing multiple registers for REX requirements,
         we had something like this:
             byteRegRequiresRex(reg) || byteRegRequiresRex(rm)
             regRequiresRex(index) || regRequiresRex(base)
         Those were producing multiple test-and-branch. Those branches
         are effectively random so we don't have to care about individual
         branches being predictable.

         The new code effectively does:
             byteRegRequiresRex(reg | rm)
             regRequiresRex(index | base)

        -Change "ModRmMode" to have the value we can OR directly
         to the generated ModRm.
         This is important because some ModRM code is so large
         that is goes out of line;

        -Finally, a big change on how we write to the AssemblerBuffer.

         Previously, instructions were written byte by byte into
         the assembler buffer of the MacroAssembler.

         The problem with that is the compiler cannot prove that
         the buffer pointer and the AssemblerBuffer are not pointing
         to the same memory.

         Because of that, before any write, all the local register
         were pushed back to the AssemblerBuffer memory, then everything
         was read back after the write to compute the next write.

         I attempted to use the "restrict" keyword and wrapper types
         to help Clang with that but nothing worked.

         The current solution is to keep a local copy of the index
         and the buffer pointer in the scope of each instruction.
         That is done by AssemblerBuffer::LocalWriter.

         Since LocalWriter only exists locally, it stays in
         register and we don't have all the memory churn between
         each byte writing. This also allows clang to combine
         obvious cases since there are no longer observable side
         effects between bytes.

        This patch reduces the binary size by 66k. It is a small
        speed-up on Sunspider.

        * assembler/AssemblerBuffer.h:
        (JSC::AssemblerBuffer::ensureSpace):
        (JSC::AssemblerBuffer::LocalWriter::LocalWriter):
        (JSC::AssemblerBuffer::LocalWriter::~LocalWriter):
        (JSC::AssemblerBuffer::LocalWriter::putByteUnchecked):
        (JSC::AssemblerBuffer::LocalWriter::putShortUnchecked):
        (JSC::AssemblerBuffer::LocalWriter::putIntUnchecked):
        (JSC::AssemblerBuffer::LocalWriter::putInt64Unchecked):
        (JSC::AssemblerBuffer::LocalWriter::putIntegralUnchecked):
        (JSC::AssemblerBuffer::putIntegral):
        (JSC::AssemblerBuffer::outOfLineGrow):
        * assembler/MacroAssemblerX86Common.h:
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::X86InstructionFormatter::byteRegRequiresRex):
        (JSC::X86Assembler::X86InstructionFormatter::regRequiresRex):
        (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::LocalBufferWriter):
        (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::emitRex):
        (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::emitRexW):
        (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::emitRexIf):
        (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::emitRexIfNeeded):
        (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::putModRm):
        (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::putModRmSib):
        (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::registerModRM):
        (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::memoryModRM):
        (JSC::X86Assembler::X86InstructionFormatter::oneByteOp): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::oneByteOp_disp32): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::oneByteOp_disp8): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::twoByteOp): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::threeByteOp): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::oneByteOp64): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::oneByteOp64_disp32): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::oneByteOp64_disp8): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::twoByteOp64): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::oneByteOp8): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::twoByteOp8): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::emitRex): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::emitRexW): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::emitRexIf): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::emitRexIfNeeded): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::putModRm): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::putModRmSib): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::registerModRM): Deleted.
        (JSC::X86Assembler::X86InstructionFormatter::memoryModRM): Deleted.

2016-03-25  Saam barati  <sbarati@apple.com>

        RegExp.prototype.test should be an intrinsic again
        https://bugs.webkit.org/show_bug.cgi?id=155861

        Reviewed by Yusuke Suzuki.

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

2016-03-25  Mark Lam  <mark.lam@apple.com>

        ES6's throwing of TypeErrors on access of RegExp.prototype flag properties breaks websites.
        https://bugs.webkit.org/show_bug.cgi?id=155904

        Reviewed by Geoffrey Garen.

        There exists a JS library XRegExp (see http://xregexp.com) that extends the regexp
        implementation.  XRegExp does feature testing by comparing RegExp.prototype.sticky
        to undefined.  See:

        Example 1. https://github.com/slevithan/xregexp/blob/28a2b033c5951477bed8c7c867ddf7e89c431cd4/tests/perf/index.html
            ...
            } else if (knownVersion[version]) {
                // Hack around ES6 incompatibility in XRegExp versions prior to 3.0.0
                if (parseInt(version, 10) < 3) {
                    delete RegExp.prototype.sticky;
            }
            ...

        Example 2. https://github.com/slevithan/xregexp/blob/d0e665d4068cec4d15919215b098b2373f1f12e9/tests/perf/versions/xregexp-all-v2.0.0.js
            ...
            // Check for flag y support (Firefox 3+)
                hasNativeY = RegExp.prototype.sticky !== undef,
            ...

        The ES6 spec states that we should throw a TypeError here because RegExp.prototype
        is not a RegExp object, and the sticky getter is only allowed to be called on
        RegExp objects.  See https://tc39.github.io/ecma262/2016/#sec-get-regexp.prototype.sticky.
        As a result, websites that uses XRegExp can break (e.g. some Atlassian tools).

        As a workaround, we'll return undefined instead of throwing on access of these
        flag properties that may be used for feature testing.

        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoGetterGlobal):
        (JSC::regExpProtoGetterIgnoreCase):
        (JSC::regExpProtoGetterMultiline):
        (JSC::regExpProtoGetterSticky):
        (JSC::regExpProtoGetterUnicode):

2016-03-25  Caitlin Potter  <caitp@igalia.com>

        [JSC] fix divide-by-zero in String.prototype.padStart/padEnd
        https://bugs.webkit.org/show_bug.cgi?id=155903

        Reviewed by Filip Pizlo.

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

2016-03-25  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] materialize-past-butterfly-allocation.js time out in debug

        * tests/stress/materialize-past-butterfly-allocation.js:
        The test times out on the debug bots. We suspect there is nothing
        wrong, just overkill loops.

2016-03-25  Brian Burg  <bburg@apple.com>

        Web Inspector: protocol generator should prefix C++ filenames with the protocol group
        https://bugs.webkit.org/show_bug.cgi?id=155859
        <rdar://problem/25349859>

        Reviewed by Alex Christensen and Joseph Pecoraro.

        Like for generated Objective-C files, we should use the 'protocol group' name
        as the prefix for generated C++ files so that headers from different protocol
        groups have unambiguous names.

        * inspector/scripts/codegen/cpp_generator.py:
        (CppGenerator):
        (CppGenerator.__init__):
        (CppGenerator.protocol_name):
        Make all C++ code generators extend the CppGenerator python class and use the
        protocol_name() instance method. This matches a recent change to the ObjC generator.

        * inspector/scripts/codegen/cpp_generator_templates.py:
        (CppGeneratorTemplates):
        Drive-by cleanup to use #pragma once instead of header guards.

        * inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
        (CppAlternateBackendDispatcherHeaderGenerator):
        (CppAlternateBackendDispatcherHeaderGenerator.__init__):
        (CppAlternateBackendDispatcherHeaderGenerator.output_filename):
        (CppAlternateBackendDispatcherHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
        (CppBackendDispatcherHeaderGenerator):
        (CppBackendDispatcherHeaderGenerator.__init__):
        (CppBackendDispatcherHeaderGenerator.output_filename):
        (CppBackendDispatcherHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
        (CppBackendDispatcherImplementationGenerator):
        (CppBackendDispatcherImplementationGenerator.__init__):
        (CppBackendDispatcherImplementationGenerator.output_filename):
        (CppBackendDispatcherImplementationGenerator.generate_output):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
        (CppFrontendDispatcherHeaderGenerator):
        (CppFrontendDispatcherHeaderGenerator.__init__):
        (CppFrontendDispatcherHeaderGenerator.output_filename):
        (CppFrontendDispatcherHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
        (CppFrontendDispatcherImplementationGenerator):
        (CppFrontendDispatcherImplementationGenerator.__init__):
        (CppFrontendDispatcherImplementationGenerator.output_filename):
        (CppFrontendDispatcherImplementationGenerator.generate_output):
        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (CppProtocolTypesHeaderGenerator):
        (CppProtocolTypesHeaderGenerator.__init__):
        (CppProtocolTypesHeaderGenerator.output_filename):
        (CppProtocolTypesHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
        (CppProtocolTypesImplementationGenerator):
        (CppProtocolTypesImplementationGenerator.__init__):
        (CppProtocolTypesImplementationGenerator.output_filename):
        (CppProtocolTypesImplementationGenerator.generate_output):
        Use the protocol_name() instance method to compute generated protocol file names.

        * inspector/scripts/codegen/models.py:
        Explicitly set the 'protocol_group' for the Inspector protocol.

        Rebaseline generator test results.

        * 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:

2016-03-25  Keith Miller  <keith_miller@apple.com>

        putByIndexBeyondVectorLengthWithoutAttributes should not crash if it can't ensureLength
        https://bugs.webkit.org/show_bug.cgi?id=155730

        Reviewed by Saam Barati.

        This patch makes ensureLength return a boolean indicating if it was able to set the length.
        ensureLength also no longer sets the butterfly to null if the allocation of the butterfly
        fails. All of ensureLengths callers including putByIndexBeyondVectorLengthWithoutAttributes
        have been adapted to throw an out of memory error if ensureLength fails.

        * runtime/JSArray.cpp:
        (JSC::JSArray::setLength):
        (JSC::JSArray::unshiftCountWithAnyIndexingType):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
        (JSC::JSObject::ensureLengthSlow):
        * runtime/JSObject.h:
        (JSC::JSObject::ensureLength):

2016-03-25  Caitlin Potter  <caitp@igalia.com>

        [JSC] implement String.prototype.padStart() and String.prototype.padEnd() proposal
        https://bugs.webkit.org/show_bug.cgi?id=155795

        Reviewed by Darin Adler.

        Implements ECMAScript proposal http://tc39.github.io/proposal-string-pad-start-end/
        Currently at Stage 3.

        * runtime/JSString.h:
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::repeatCharacter):
        (JSC::repeatStringPattern):
        (JSC::padString):
        (JSC::stringProtoFuncPadEnd):
        (JSC::stringProtoFuncPadStart):
        * tests/es6.yaml:
        * tests/es6/String.prototype_methods_String.prototype.padEnd.js: Added.
        * tests/es6/String.prototype_methods_String.prototype.padStart.js: Added.

2016-03-24  Alex Christensen  <achristensen@webkit.org>

        Fix Mac CMake build.

        * PlatformMac.cmake:
        Link to Security framework.

2016-03-24  Saam barati  <sbarati@apple.com>

        ES6: Implement IsRegExp function and use where needed in String.prototype.* methods
        https://bugs.webkit.org/show_bug.cgi?id=155854

        Reviewed by Mark Lam.

        This patch is a straight forward implementation of IsRegExp
        in the ES6 spec:
        https://tc39.github.io/ecma262/#sec-isregexp
        We now use this IsRegExp function inside String.prototype.(startsWith | endsWith | includes)
        as is dictated by the spec.

        * runtime/RegExpConstructor.h:
        (JSC::RegExpConstructor::recordMatch):
        (JSC::isRegExp):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncStartsWith):
        (JSC::stringProtoFuncEndsWith):
        (JSC::stringProtoFuncIncludes):
        * tests/es6.yaml:
        * tests/es6/well-known_symbols_Symbol.match_String.prototype.endsWith.js: Added.
        (test):
        * tests/es6/well-known_symbols_Symbol.match_String.prototype.includes.js: Added.
        (test):
        * tests/es6/well-known_symbols_Symbol.match_String.prototype.startsWith.js: Added.
        (test):
        * tests/stress/string-prototype-methods-endsWith-startsWith-includes-correctness.js: Added.
        (assert):
        (test):
        (test.get let):
        (get let):

2016-03-24  Saam barati  <sbarati@apple.com>

        Web Inspector: Separate Debugger enable state from the debugger breakpoints enabled state
        https://bugs.webkit.org/show_bug.cgi?id=152193
        <rdar://problem/23867520>

        Reviewed by Joseph Pecoraro.

        When all breakpoints are disabled, we can recompile all JS
        code and remove the necessary debugging code that is emitted.
        This allows for the code that is executing to be almost as fast
        as it is with the debugger completely disabled. This is in preparation for:
        https://bugs.webkit.org/show_bug.cgi?id=155809
        which will introduce a high fidelity profiler. That profiler
        could be built off the principle that breakpoints are disabled
        when we're performing a high fidelity profile. Doing so, for example,
        allows the sampling profiler to better measure the real performance
        of the JS of a particular application.

        * debugger/Debugger.cpp:
        (JSC::Debugger::setBreakpointsActivated):
        (JSC::Debugger::setPauseOnExceptionsState):
        * debugger/Debugger.h:
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        * inspector/JSGlobalObjectScriptDebugServer.cpp:
        (Inspector::JSGlobalObjectScriptDebugServer::attachDebugger):
        (Inspector::JSGlobalObjectScriptDebugServer::detachDebugger):
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::enable):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock):
        (JSC::JSGlobalObject::createModuleProgramCodeBlock):
        (JSC::JSGlobalObject::queueMicrotask):
        (JSC::JSGlobalObject::hasDebugger):
        (JSC::JSGlobalObject::hasInteractiveDebugger):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::runtimeFlags):
        (JSC::JSGlobalObject::hasDebugger): Deleted.

2016-03-24  Michael Saboff  <msaboff@apple.com>

        Create private builtin helper advanceStringIndexUnicode() for use by RegExp builtins
        https://bugs.webkit.org/show_bug.cgi?id=155855

        Reviewed by Mark Lam.

        Moved advanceStringIndexUnicode() as a separate helper.  Added it as a private builtin
        to the GlobalObject like other private builtins.

        * builtins/RegExpPrototype.js:
        (advanceStringIndexUnicode):
        (match):
        (match.advanceStringIndexUnicode): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):

2016-03-24  Michael Saboff  <msaboff@apple.com>

        [ES6] Add Proxy based tests for RegExp.prototype[@@match]
        https://bugs.webkit.org/show_bug.cgi?id=155807

        Reviewed by Saam Barati.

        Added new test that uses Proxy to verify RegExp.prototype[@@match] processing
        conforms to the ES6 standard

        Modified builtin RegExp.prototype[@@match] to be ES6 spec conformant.

        Updated es6.yaml as Proxy_internal_get_calls_RegExp.prototype[Symbol.match].js now passes.

        * builtins/RegExpPrototype.js:
        (match):
        * tests/es6.yaml: Updated.
        * tests/stress/regexp-match-proxy.js: Added.
        (assert):
        (let.getProxyNullExec.new.Proxy):
        (let.getSetProxyNullExec.new.Proxy):
        (get resetTracking):
        (let.getSetProxyMatches_s.new.Proxy):
        (set get getSetProxyNullExec):
        (let.getSetProxyMatches_tx_Greedy.new.Proxy):
        (set get getSetProxyMatches_s):
        (let.getSetProxyMatchesUnicode_digit_nonGreedy.new.Proxy):
        (set get getSetProxyMatches_tx_Greedy):

2016-03-24  Michael Saboff  <msaboff@apple.com>

        [ES6] Greedy unicode RegExp's don't properly backtrack past non BMP characters
        https://bugs.webkit.org/show_bug.cgi?id=155829

        Reviewed by Saam Barati.

        When we backup when matching part of a unicode pattern, we can't just backup one character.
        Instead we need to save our start position before trying to match a character and
        restore the position if the match fails.  This was done in other places, but wasn't
        done for all greedy types.

        Fixed matchGlobal() to properly handle advancing past non BMP characters.

        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::matchGlobal):
        * runtime/RegExpObjectInlines.h:
        (JSC::RegExpObject::advanceStringUnicode):
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::matchCharacterClass):
        (JSC::Yarr::Interpreter::matchDisjunction):

2016-03-24  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] In some cases, the integer range optimization phase never converges
        https://bugs.webkit.org/show_bug.cgi?id=155828
        rdar://problem/25155460

        Reviewed by Filip Pizlo.

        In certain conditions, the integer range optimization phase continuously
        changes the representation of the same truth, preventing it from
        converging to a stable state.

        The bug starts by having the same ground truth incomming into a block
        in different valid forms. For example, you can have x < 42 coming as:
            1) x < 42
            2) x < 41 + 1
            3) x < 43 - 1

        Having those 3 alone coming from predecessors would be okay, we would
        just accumulate them. The problem is when you have a combination
        of rule that filter out the previously obtained truth, then add a new
        form of the same truth.

        Let's use the test case as an example. We have two incoming blocks:
            Block #1:
              -i < 42
              -i != 41
            Block #2:
              -i < 41
              -i == 42 - 42 (i == 0 refining the rule above).

        Let say that our conditions at head are now [i < 41, i < 42 - 1].

        If we merge block #2:
              -i < 42 and i < 41      -> i < 42
              -i < 42 and i < 42 - 1  -> i < 42
              -i != 41 and i < 41     -> i < 41
              -i != 41 and i < 42 - 1 -> nothing

        The new head is: [i < 41, i < 42]

        If we merge block #1:
              -i < 41 and i < 41       -> i < 41
              -i < 41 and i < 42       -> i < 42
              -i == 42 - 42 and i < 41 -> (i < 41 and i < 42 - 1)
              -i == 42 - 42 and i < 42 -> i < 42

        After filter, we are back to [i < 41, i < 42 - 1].

        There are several variations of this idea where the same truth
        rotate different forms with each merge().

        One possible solution is to make filter() more aggressive
        to avoid the better form occuring at merge(). I'll probably
        do that at some point but that seems fragile since the same
        problem could reappear if merge() is later improved.

        For this patch, I went with a more generic solution after
        merge(): if the generated form is equivalent to one that
        previously existed at head, pick the existing form.

        In the previous example, what happens is we only have
        either [i < 41] or [i < 42 - 1] but never both simultaneously.

        * dfg/DFGIntegerRangeOptimizationPhase.cpp:
        * tests/stress/integer-range-optimization-constant-representation-1.js: Added.
        * tests/stress/integer-range-optimization-constant-representation-2.js: Added.
        Two variation. One timeout in release because of the additional flags.
        The other is gets more type of run but only assert in debug.

2016-03-23  Commit Queue  <commit-queue@webkit.org>

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

        "It broke debugging in the web inspector" (Requested by
        saamyjoon on #webkit).

        Reverted changeset:

        "We should not disable inlining when the debugger is enabled"
        https://bugs.webkit.org/show_bug.cgi?id=155741
        http://trac.webkit.org/changeset/198582

2016-03-23  Michael Saboff  <msaboff@apple.com>

        JavaScriptCore ArrayPrototype::join shouldn't cache butterfly when it makes effectful calls
        https://bugs.webkit.org/show_bug.cgi?id=155776

        Reviewed by Saam Barati.

        Array.join ends up calling toString, possibly on some object.  Since these calls
        could be effectful and could change the array itself, we can't hold the butterfly
        pointer while making effectful calls.  Changed the code to fall back to the general
        case when an effectful toString() call might be made.

        * runtime/ArrayPrototype.cpp:
        (JSC::join):
        * runtime/JSStringJoiner.h:
        (JSC::JSStringJoiner::appendWithoutSideEffects): New helper that doesn't make effectful
        toString() calls.
        (JSC::JSStringJoiner::append): Built upon appendWithoutSideEffects.

2016-03-23  Keith Miller  <keith_miller@apple.com>

        Array.prototype native functions' species constructors should work with proxies
        https://bugs.webkit.org/show_bug.cgi?id=155798

        Reviewed by Mark Lam.

        Before native the species constructors were checking if the this value was a JSArray.
        Instead they should look check that the this value returns true on Array.isArray.

        * runtime/ArrayPrototype.cpp:
        (JSC::speciesConstructArray):
        * tests/es6.yaml:
        * tests/stress/proxy-array-prototype-methods.js:

2016-03-23  Saam barati  <sbarati@apple.com>

        We should not disable inlining when the debugger is enabled
        https://bugs.webkit.org/show_bug.cgi?id=155741

        Reviewed by Oliver Hunt.

        We can enable inlining when the debugger is enabled as long
        as we make sure we still jettison the proper CodeBlocks when
        a breakpoint is set. This means that for any optimized CodeBlock,
        we must ask if any of its inlinees contain the breakpoint that
        is being set. If any inlinees do contain the breakpoint, we must
        jettison the machine code block that they are a part of.

        * debugger/Debugger.cpp:
        (JSC::Debugger::toggleBreakpoint):
        (JSC::Debugger::applyBreakpoints):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::ByteCodeParser):
        (JSC::DFG::ByteCodeParser::setLocal):
        (JSC::DFG::ByteCodeParser::flush):
        (JSC::DFG::ByteCodeParser::flushForTerminal):
        (JSC::DFG::ByteCodeParser::inliningCost):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::~Graph):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::hasDebuggerEnabled): Deleted.
        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):

2016-03-23  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Allow undefined/null for Symbol.search and Symbol.match
        https://bugs.webkit.org/show_bug.cgi?id=155785

        Reviewed by Saam Barati.

        Undefined and null for Symbol.search and Symbol.match properties of the given RegExp (like) object are allowed.
        When they are specified, we go to the fallback path; creating the RegExp with the given object and matching.

        * builtins/StringPrototype.js:
        (match):
        (search):
        * tests/stress/string-symbol-customization.js: Added.
        (shouldBe):
        (shouldThrow):

2016-03-22  Caitlin Potter  <caitp@igalia.com>

        [JSC] correctly handle indexed properties in Object.getOwnPropertyDescriptors
        https://bugs.webkit.org/show_bug.cgi?id=155563

        Reviewed by Saam Barati.

        * runtime/JSObject.h:
        (JSC::JSObject::putOwnDataPropertyMayBeIndex):
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetOwnPropertyDescriptors):

2016-03-22  Saam Barati  <sbarati@apple.com>

        We should FTL compile code when the debugger is enabled
        https://bugs.webkit.org/show_bug.cgi?id=155740

        Reviewed by Oliver Hunt.

        There was no fundamental reason why we didn't support debugging
        with the FTL. It looks like this was just an oversight. We had
        a Breakpoint node in the DFG that amounted to a nop. By removing
        this node, we now support debugging in the FTL. Anytime a breakpoint
        is set, we will jettison any DFG/FTL CodeBlocks that contain the breakpoint
        that was set.

        * 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/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):

2016-03-22  Keith Miller  <keith_miller@apple.com>

        REGRESSION(r197543): Use-after-free on storage/indexeddb/transaction-abort-private.html
        https://bugs.webkit.org/show_bug.cgi?id=155067

        Reviewed by Filip Pizlo.

        GCIncommingRefCountedSets need to be finalized before we start
        destructing members of the Heap object. Previously, we would
        clear all our ArrayBuffer objects when the GCIncommingRefCountedSet
        holding them was destroyed. However, ArrayBuffers have a weak
        reference to their wrappers. When we would attempt to destroy the
        ArrayBuffer object we would end up accessing the WeakImpl for
        the weak reference, which had already been freed as we destroyed
        our weak block. The solution to this is to move the old
        GCIncommingRefCountedSet destructor functionality to a new
        function lastChanceToFinalize. This function is called when
        we finalize our other objects on Heap destruction.

        * heap/GCIncomingRefCountedSet.h:
        * heap/GCIncomingRefCountedSetInlines.h:
        (JSC::GCIncomingRefCountedSet<T>::lastChanceToFinalize):
        (JSC::GCIncomingRefCountedSet<T>::~GCIncomingRefCountedSet): Deleted.
        * heap/Heap.cpp:
        (JSC::Heap::lastChanceToFinalize):

2016-03-22  Per Arne Vollan  <peavo@outlook.com>

        [Win] [64-bit] Remove MSVC 2013 FMA3 Bug Workaround
        https://bugs.webkit.org/show_bug.cgi?id=141499

        Reviewed by Brent Fulgham.

        As we have moved on to VS2015, this workaround is no longer needed.

        * API/tests/testapi.c:
        (main):
        * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp:
        (wWinMain):
        * jsc.cpp:
        (main):
        * testRegExp.cpp:
        (main):

2016-03-22  Michael Saboff  <msaboff@apple.com>

        [ES6] Implement RegExp.prototype[@@match]
        https://bugs.webkit.org/show_bug.cgi?id=155711

        Reviewed by Filip Pizlo.

        Implemented ES6 spec for String.prototype.match and RegExp.prototype[@@match].
        Implemented both as builtins, with String.prototype.match calling 
        RegExp.prototype[@@match].

        For performance reasons, RegExp.prototype[@@match] has a C++ fast path when
        RegExp.prototype.exec has not been overridden.  This fast path,
        RegExpObject::matchGlobal, was taken from the prior StringPrototype::match.
        It only handles global matches.

        Added new test, stress/regexp-match.js.

        Updated various tests for changes exception string and now passing ES6 behavior.

        * CMakeLists.txt: 
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        Added builtins/RegExpPrototype.js and eliminated RegExpPrototype.lut.h.

        * builtins/RegExpPrototype.js: Added.
        (match.advanceStringIndexUnicode): Helper.
        (match): Implements RegExp.prototype[@@match].
        * builtins/StringPrototype.js:
        (match): Implements String.prototype.match.

        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        (JSC::BytecodeIntrinsicRegistry::lookup):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * runtime/CommonIdentifiers.h:
        Added Symbol.match and builtins @match and @exec.

        * runtime/RegExpObject.cpp:
        * runtime/RegExpObject.h:
        * runtime/RegExpObjectInlines.h:
        (JSC::RegExpObject::matchGlobal): Added.
        (JSC::RegExpObject::advanceStringUnicode): Added helper.

        * runtime/RegExpPrototype.cpp:
        * runtime/RegExpPrototype.h:
        (JSC::RegExpPrototype::RegExpPrototype):
        (JSC::RegExpPrototype::finishCreation):
        (JSC::RegExpPrototype::visitChildren):
        (JSC::regExpProtoFuncMatchPrivate):
        (JSC::RegExpPrototype::getOwnPropertySlot): Deleted.
        (JSC::RegExpPrototype::create):
        Restructured to create properties explicitly due to having two names for native regExpProtoFuncExec.

        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        Made match a builtin.
        Removed unused declaration of stringProtoFuncSearch() since it was made a builtin.

        * tests/es6.yaml:
        * tests/stress/regexp-match.js: Added.
        (shouldBe):
        (shouldThrow):
        (errorKey.toString):
        (primitive.of.primitives.shouldThrow):
        (testRegExpMatch):
        (testMatch):
        (testBoth):
        (alwaysUnmatch):

2016-03-22  Caitlin Potter  <caitp@igalia.com>

        [JSC] allow duplicate property names returned from Proxy ownKeys() trap
        https://bugs.webkit.org/show_bug.cgi?id=155560

        Reviewed by Darin Adler.

        Specification allows duplicate property names to be reported by the
        Proxy ownKeys() trap --- and this is observable in any API which
        operates on the returned list, such as Object.keys(),
        Object.getOwnPropertyNames(), Object.getOwnPropertySymbols(), or
        Object.getOwnPropertyDescriptors().

        * runtime/PropertyNameArray.h:
        (JSC::PropertyNameArray::addUnchecked):
        (JSC::PropertyNameArray::add):
        (JSC::PropertyNameArray::addKnownUnique): Deleted.
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performGetOwnPropertyNames):
        * runtime/Structure.cpp:
        (JSC::Structure::getPropertyNamesFromStructure):

2016-03-21  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Clean up Math.floor thunk and use SSE round instruction
        https://bugs.webkit.org/show_bug.cgi?id=155705

        Reviewed by Geoffrey Garen.

        SSE now allow us to use round instruction to implement Math.floor.
        MacroAssembler's floorDouble is now only used in ARM64, but it can be allowed in x86 SSE.

        * jit/ThunkGenerators.cpp:
        (JSC::floorThunkGenerator):

2016-03-21  Konstantin Tokarev  <annulen@yandex.ru>

        Fixed compilation with GCC 4.8.
        https://bugs.webkit.org/show_bug.cgi?id=155698

        Reviewed by Alexey Proskuryakov.

        GCC 4.8 does not allow aggregate initialization for type with deleted
        constructor, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52707.

        * dfg/DFGCSEPhase.cpp: Added ctor for ImpureDataSlot.

2016-03-21  Joonghun Park  <jh718.park@samsung.com>

        [JSC] Add ArrayBuffer::tryCreate and change the callsites where it is needed
        https://bugs.webkit.org/show_bug.cgi?id=155328

        Reviewed by Darin Adler.

        * API/JSTypedArray.cpp:
        (JSObjectMakeTypedArray):
        (JSObjectMakeArrayBufferWithBytesNoCopy):
        * runtime/ArrayBuffer.h:
        (JSC::ArrayBuffer::create):
        (JSC::ArrayBuffer::tryCreate):
        (JSC::ArrayBuffer::createUninitialized):
        (JSC::ArrayBuffer::tryCreateUninitialized):
        (JSC::ArrayBuffer::createInternal):
        * runtime/GenericTypedArrayViewInlines.h:
        (JSC::GenericTypedArrayView<Adaptor>::create):
        (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::constructArrayBuffer):

2016-03-20  Dan Bernstein  <mitz@apple.com>

        [Mac] Determine TARGET_MAC_OS_X_VERSION_MAJOR from MACOSX_DEPLOYMENT_TARGET rather than from MAC_OS_X_VERSION_MAJOR
        https://bugs.webkit.org/show_bug.cgi?id=155707
        <rdar://problem/24980691>

        Reviewed by Darin Adler.

        * Configurations/Base.xcconfig: Set TARGET_MAC_OS_X_VERSION_MAJOR based on the last
          component of MACOSX_DEPLOYMENT_TARGET.
        * Configurations/DebugRelease.xcconfig: For engineering builds, preserve the behavior of
          TARGET_MAC_OS_X_VERSION_MAJOR being the host’s OS version.

2016-03-20  Michael Saboff  <msaboff@apple.com>

        Crash in stress/regexp-matches-array-slow-put.js due to stomping on memory when having bad time
        https://bugs.webkit.org/show_bug.cgi?id=155679

        Reviewed by Saam Barati.

        Allocate out of line storage based on what the structure says it needs
        in JSArray::tryCreateUninitialized.

        * runtime/JSArray.h:
        (JSC::JSArray::tryCreateUninitialized):

2016-03-20  Joseph Pecoraro  <pecoraro@apple.com>

        Crash on DFG::WorkList thread in JSC::Heap::isCollecting for destroyed Web Worker
        https://bugs.webkit.org/show_bug.cgi?id=155678
        <rdar://problem/25251439>

        Reviewed by Filip Pizlo.

        This fixes a crash that we saw with GuardMalloc. If the Plan was
        Cancelled it may not be safe to access the VM. If the Plan was
        cancelled we are just going to bail anyways, so keep the ASSERT but
        short-circuit if the plan was Cancelled.

        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::runThread):

2016-03-20  Dan Bernstein  <mitz@apple.com>

        Update build settings

        Rubber-stamped by Andy Estes.

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

2016-03-19  Skachkov Oleksandr  <gskachkov@gmail.com>

        [ES6] Arrow function syntax. Update syntax error text 'super is only valid inside functions' to more suitable
        https://bugs.webkit.org/show_bug.cgi?id=155491

        Reviewed by Saam Barati.

        Current message 'super is only valid inside of funcitons' is not correct 
        after patch for https://bugs.webkit.org/show_bug.cgi?id=153864 because 
        it is allow to use 'super' in eval. Current patch replace old message by
        'Super is only valid inside functions or 'eval' inside a function' and 
        fix tests that rely on this message.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseMemberExpression):
        * tests/stress/generator-with-super.js:
        (shouldThrow):
        * tests/stress/modules-syntax-error.js:
        * tests/stress/super-in-lexical-scope.js:
        * tests/stress/tagged-templates-syntax.js:

2016-03-19  Mark Lam  <mark.lam@apple.com>

        ES6 spec requires that ErrorPrototype not be an Error object.
        https://bugs.webkit.org/show_bug.cgi?id=155680

        Reviewed by Michael Saboff.

        The ES6 spec states that Error.prototype should not be an instance of Error:
        https://tc39.github.io/ecma262/#sec-properties-of-the-error-prototype-object

        "The Error prototype object is an ordinary object. It is not an Error instance
        and does not have an [[ErrorData]] internal slot."

        This patch changes ErrorPrototype to conform to the above specification.

        * runtime/ErrorConstructor.cpp:
        (JSC::ErrorConstructor::finishCreation):
        * runtime/ErrorPrototype.cpp:
        (JSC::ErrorPrototype::ErrorPrototype):
        (JSC::ErrorPrototype::finishCreation):
        (JSC::ErrorPrototype::getOwnPropertySlot):
        * runtime/ErrorPrototype.h:
        (JSC::ErrorPrototype::create):

        * runtime/NativeErrorConstructor.cpp:
        (JSC::NativeErrorConstructor::finishCreation):
        * runtime/NativeErrorPrototype.cpp:
        (JSC::NativeErrorPrototype::NativeErrorPrototype):
        (JSC::NativeErrorPrototype::finishCreation):
        * runtime/NativeErrorPrototype.h:
        (JSC::NativeErrorPrototype::create):
        - updated to no longer need a JSGlobalObject argument.

        * tests/es6/miscellaneous_built-in_prototypes_are_not_instances.js:
        - updated to match the kangax version of this test.

2016-03-18  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Limit DFG's Validate symbols to its compilation unit
        https://bugs.webkit.org/show_bug.cgi?id=155670

        Reviewed by Filip Pizlo.

        * dfg/DFGValidate.cpp:

2016-03-18  Mark Lam  <mark.lam@apple.com>

        ES6 spec requires that RegExpPrototype not be a RegExp object.
        https://bugs.webkit.org/show_bug.cgi?id=155654

        Reviewed by Filip Pizlo.

        The ES6 spec states that RegExp.prototype should not be an instance of RegExp:
        https://tc39.github.io/ecma262/#sec-properties-of-the-regexp-prototype-object

        "The RegExp prototype object is an ordinary object. It is not a RegExp instance
        and does not have a [[RegExpMatcher]] internal slot or any of the other internal
        slots of RegExp instance objects."

        This patch changes RegExpPrototype to conform to the above specifications.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::RegExpConstructor):
        (JSC::RegExpConstructor::finishCreation):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::RegExpPrototype):
        (JSC::RegExpPrototype::finishCreation):
        (JSC::RegExpPrototype::getOwnPropertySlot):
        (JSC::RegExpPrototype::visitChildren):
        (JSC::regExpProtoFuncTest):
        * runtime/RegExpPrototype.h:
        (JSC::RegExpPrototype::create):
        (JSC::RegExpPrototype::createStructure):
        (JSC::RegExpPrototype::emptyRegExp):

        * tests/es6.yaml:
        - This patch makes the es6/miscellaneous_built-in_prototypes_are_not_instances.js
          test now pass.  However, the kangax version of this test still fails because
          it also checks Error objects (which will be fixed in a subsequent patch).

        * tests/mozilla/ecma_2/shell.js:
        (stringify):
        (test):
        (getFailedCases):
        (err):
        * tests/stress/static-getter-in-names.js:
        (shouldBe):

2016-03-18  Keith Miller  <keith_miller@apple.com>

        DataView should use an accessor for its length and buffer properties
        https://bugs.webkit.org/show_bug.cgi?id=155625

        Reviewed by Michael Saboff.

        The DataView object should use an accessor on DataView.prototype for its
        byteLength, byteOffset, and buffer properties. This patch also, moves the
        buffer property off the TypedArray object itself and onto the prototype
        along with the other accessors. Since the .buffer property is no longer on
        the object, JSArrayBufferView no longer needs to intercept accesses to
        properties. Finally, this patch also fixes the length property on all the
        existing DataView.prototype functions.

        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::getOwnPropertySlot): Deleted.
        (JSC::JSArrayBufferView::put): Deleted.
        (JSC::JSArrayBufferView::defineOwnProperty): Deleted.
        (JSC::JSArrayBufferView::deleteProperty): Deleted.
        (JSC::JSArrayBufferView::getOwnNonIndexPropertyNames): Deleted.
        * runtime/JSArrayBufferView.h:
        (JSC::JSArrayBufferView::jsBuffer):
        * runtime/JSDataViewPrototype.cpp:
        (JSC::dataViewProtoGetterBuffer):
        (JSC::dataViewProtoGetterByteLength):
        (JSC::dataViewProtoGetterByteOffset):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoGetterFuncBuffer):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewProtoGetterFuncBuffer):
        (JSC::JSTypedArrayViewPrototype::finishCreation):

2016-03-18  Csaba Osztrogonác  <ossy@webkit.org>

        Unreviewed speculative cloop buildfix after r198364.

        * bytecode/SuperSampler.cpp:

2016-03-17  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Make CSE's ImpureData faster when dealing with large blocks
        https://bugs.webkit.org/show_bug.cgi?id=155594

        Reviewed by Filip Pizlo.

        In some tests with large blocks, the time spent in DFG's LocalCSE
        can be over 10% of the total compile time.
        In those cases, LocalCSE is completely dominated by handling large
        blocks.

        This patch addresses the most obvious hot spots ImpureData's handling.

        Initially, most of the time was going into HashTable::rehash().
        The reason is the buckets are <HeapLocation, LazyNode> gigantic.
        The hash table would easily get into several kilobytes and the CPU
        was spending more time dealing with memory than anything.

        To solve that, I moved the pairs lazily to the heap. The table itself
        just contains the unique_ptr to those values. This makes the table
        reasonably small and the alloc/dealloc are paid for by the fast rehash().

        Once addImpure() was better, the next big bottleneck was clobber().
        For each clobber(), we need to go over the entire map and test each value.
        That loop was where most of the time was going.

        Most calls to clobber() come from two kinds: SideState and Stack.

        SideState is easy: it is never def'ed so we can always skip it.

        Stack is disjoint from Heap too so we can also put it separately.

        Splitting the map into 2 helped reduce the overhead. The maps are:
        -Stack
        -Heap

        Having Stack alone was not enough for many blocks. In some cases,
        you have a ton of SetLocal/GetLocal and having Stack separately
        makes no difference.

        To solve that, I split Stack in two: a map addressed by AbstractHeap
        + unique HeapLocation and a fallback map for everything else.
        Since most Stack are not TOP and are unique per AbstractHeap,
        I get O(1) clobber in most cases.

        I could achieve the same result with a custom hash structure.
        I don't think it is worth the effort, in most cases, m_fallbackStackMap
        has a size of zero or one.

        This patch introduces a lot of coupling between CSE and AbstractHeap.
        To reduce the risk of bugs, the old map is still maintained in debug
        and each step checks that the results are the same as the new implementation.

        A new validation step also verify the strong assumptions made by CSE:
        -SideState and World are never def().
        -We never write HEAP TOP, we only write specific heap location.

        * dfg/DFGCSEPhase.cpp:
        * dfg/DFGHeapLocation.h:
        * dfg/DFGLazyNode.h:
        (JSC::DFG::LazyNode::hash):

2016-03-17  Saam barati  <sbarati@apple.com>

        Implement SmallPtrSet and integrate it into the Parser
        https://bugs.webkit.org/show_bug.cgi?id=155552

        Reviewed by Filip Pizlo.

        Using SmallPtrSet instead of HashSet really helps speed
        up the parser. What saves us most is not needing to always
        malloc/free memory in the HashSet.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::startSwitch):
        (JSC::Scope::endSwitch):
        (JSC::Scope::startLoop):
        (JSC::Scope::hasDeclaredParameter):
        (JSC::Scope::declareWrite):
        (JSC::Scope::declareParameter):
        (JSC::Scope::usedVariablesContains):
        (JSC::Scope::useVariable):
        (JSC::Scope::collectFreeVariables):
        (JSC::Scope::getCapturedVars):
        (JSC::Scope::isValidStrictMode):
        (JSC::Scope::shadowsArguments):
        (JSC::Scope::copyCapturedVariablesToVector):
        (JSC::Scope::setIsModule):
        (JSC::Parser::pushScope):
        (JSC::Scope::getUsedVariables): Deleted.

2016-03-17  Brian Burg  <bburg@apple.com>

        Web Inspector: protocol generator shouldn't generate enums for parameters with non-anonymous enum types
        https://bugs.webkit.org/show_bug.cgi?id=155610
        <rdar://problem/25229878>

        Reviewed by Joseph Pecoraro.

        If a command parameter has an anonymous enum type, the backend dispatcher generator
        makes a C++ enum for the parameter. However, if the parameter references a named enum
        type specified in a domain's 'type' section, then there's no need to generate an enum.

        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
        (CppBackendDispatcherHeaderGenerator._generate_handler_declaration_for_command):
        Add a missing check for the is_anonymous flag. Type references to named enums are resolved
        to the underlying aliased EnumType instead of an AliasedType, so we have to check the flag.

        Rebaseline tests.

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

2016-03-17  Filip Pizlo  <fpizlo@apple.com>

        Replace all of the various non-working and non-compiling sampling profiler hacks with a single super hack
        https://bugs.webkit.org/show_bug.cgi?id=155561

        Reviewed by Saam Barati.

        A VM needs some internal profiling hacks in addition to the profiler(s) that the user sees, because
        you can squeeze out more fidelity if you're willing to make some kind of deal with the devil. Prior
        to this change JSC had a bunch of these:

        - CodeBlock sampling profiler
        - Bytecode sampling profiler
        - Sampling flags
        - Sampling regions
        - Some other stuff

        I tried using these recently. They didn't even build. Initially I fixed that, but then I found that
        these profilers had some serious bugs that made them report bogus results - like underreporting the
        time spent in regions of code by more than 2x.

        Part of the problem here is that a profiler loses fidelity as it gains power. The more general it
        tries to be, the more code gets executed on the hot path for the profiler, which increasingly
        perturbs the results. I believe that's the reason for the underreporting - code ran sufficiently
        slower, and in a sufficiently different way when profiling, that the results were just wrong.

        This change attacks this problem directly by replacing all of the diverse profiling hacks with just
        one, which I call the SuperSampler. It consists of exactly one counter. When enabled, the sampler
        will periodically print (via dataLog()) the percentage of samples that saw a non-zero count. Because
        it's so simple, it gives better accuracy. This comes about in two ways:

        - It runs at a lower rate. That's fine since it's only checking one flag. You don't need a high rate
          for just one flag.
        
        - The fact that there is only *one* flag means that the user must choose a hypothesis about what is
          slow. This turns the problem of profiling into a hypothesis testing problem, which is an inherently
          less flaky kind of experiment to run.
        
        The SuperSampler is enabled with a runtime flag rather than a compile-time flag, so it's much less
        likely to break. That also means that you can enable it without rebuilding the universe. The old
        samplers all had ENABLE flags in Platform.h, which was rather unfortunate for compile times.

        SuperSampler supports both JIT and C++ users. C++ users should use SuperSamplerScope. The default
        idiom is to create one and pass "true" to it. You can disable a scope by passing "false" instead.
        This patch puts a bunch of scopes in places I care about. I think it's probably OK if people check in
        these deactivated scopes. That makes it convenient to retest things we've tested previously.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/SamplingTool.cpp: Removed.
        * bytecode/SamplingTool.h: Removed.
        * bytecode/SuperSampler.cpp: Added.
        (JSC::initializeSuperSampler):
        (JSC::printSuperSamplerState):
        * bytecode/SuperSampler.h: Added.
        (JSC::SuperSamplerScope::SuperSamplerScope):
        (JSC::SuperSamplerScope::~SuperSamplerScope):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        * bytecompiler/NodesCodegen.cpp:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::forAllValues):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::clobberStructures):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        (JSC::DFG::performArgumentsElimination):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::performBackwardsPropagation):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::parse):
        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::performCFA):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::performCFGSimplification):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlocks):
        (JSC::DFG::CPSRethreadingPhase::propagatePhis):
        (JSC::DFG::performCPSRethreading):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::performLocalCSE):
        (JSC::DFG::performGlobalCSE):
        * dfg/DFGCleanUpPhase.cpp:
        (JSC::DFG::performCleanUp):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::performConstantFolding):
        * dfg/DFGConstantHoistingPhase.cpp:
        (JSC::DFG::performConstantHoisting):
        * dfg/DFGCriticalEdgeBreakingPhase.cpp:
        (JSC::DFG::performCriticalEdgeBreaking):
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::performDCE):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::performFixup):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dethread):
        * dfg/DFGIntegerCheckCombiningPhase.cpp:
        (JSC::DFG::performIntegerCheckCombining):
        * dfg/DFGIntegerRangeOptimizationPhase.cpp:
        (JSC::DFG::performIntegerRangeOptimization):
        * dfg/DFGInvalidationPointInjectionPhase.cpp:
        (JSC::DFG::performInvalidationPointInjection):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::performLICM):
        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
        (JSC::DFG::performLiveCatchVariablePreservationPhase):
        * dfg/DFGLivenessAnalysisPhase.cpp:
        (JSC::DFG::performLivenessAnalysis):
        * dfg/DFGLoopPreHeaderCreationPhase.cpp:
        (JSC::DFG::performLoopPreHeaderCreation):
        * dfg/DFGMaximalFlushInsertionPhase.cpp:
        (JSC::DFG::performMaximalFlushInsertion):
        * dfg/DFGMovHintRemovalPhase.cpp:
        (JSC::DFG::performMovHintRemoval):
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::performOSRAvailabilityAnalysis):
        * dfg/DFGOSREntrypointCreationPhase.cpp:
        (JSC::DFG::performOSREntrypointCreation):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::performObjectAllocationSinking):
        * dfg/DFGOperations.cpp:
        * dfg/DFGPhantomInsertionPhase.cpp:
        (JSC::DFG::performPhantomInsertion):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):
        * dfg/DFGPredictionInjectionPhase.cpp:
        (JSC::DFG::performPredictionInjection):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::performPredictionPropagation):
        * dfg/DFGPutStackSinkingPhase.cpp:
        (JSC::DFG::performPutStackSinking):
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::performSSAConversion):
        * dfg/DFGSSALoweringPhase.cpp:
        (JSC::DFG::performSSALowering):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::performStackLayout):
        * dfg/DFGStaticExecutionCountEstimationPhase.cpp:
        (JSC::DFG::performStaticExecutionCountEstimation):
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        (JSC::DFG::performFastStoreBarrierInsertion):
        (JSC::DFG::performGlobalStoreBarrierInsertion):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::performStrengthReduction):
        * dfg/DFGStructureAbstractValue.cpp:
        (JSC::DFG::StructureAbstractValue::assertIsRegistered):
        (JSC::DFG::StructureAbstractValue::clobber):
        (JSC::DFG::StructureAbstractValue::observeTransition):
        (JSC::DFG::StructureAbstractValue::observeTransitions):
        (JSC::DFG::StructureAbstractValue::add):
        (JSC::DFG::StructureAbstractValue::merge):
        (JSC::DFG::StructureAbstractValue::mergeSlow):
        (JSC::DFG::StructureAbstractValue::mergeNotTop):
        (JSC::DFG::StructureAbstractValue::filter):
        (JSC::DFG::StructureAbstractValue::filterSlow):
        (JSC::DFG::StructureAbstractValue::contains):
        (JSC::DFG::StructureAbstractValue::isSubsetOf):
        (JSC::DFG::StructureAbstractValue::isSupersetOf):
        (JSC::DFG::StructureAbstractValue::overlaps):
        (JSC::DFG::StructureAbstractValue::equalsSlow):
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::performStructureRegistration):
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::performTierUpCheckInjection):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::performTypeCheckHoisting):
        * dfg/DFGUnificationPhase.cpp:
        (JSC::DFG::performUnification):
        * dfg/DFGVarargsForwardingPhase.cpp:
        (JSC::DFG::performVarargsForwarding):
        * dfg/DFGVirtualRegisterAllocationPhase.cpp:
        (JSC::DFG::performVirtualRegisterAllocation):
        * dfg/DFGWatchpointCollectionPhase.cpp:
        (JSC::DFG::performWatchpointCollection):
        * dynbench.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileRegExpExec):
        (JSC::FTL::DFG::LowerDFGToB3::compileRegExpTest):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetRegExpObjectLastIndex):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileFTLOSRExit):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::store):
        (JSC::FTL::Output::absolute):
        (JSC::FTL::Output::incrementSuperSamplerCount):
        (JSC::FTL::Output::decrementSuperSamplerCount):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::baseIndex):
        (JSC::FTL::Output::load8SignExt32):
        (JSC::FTL::Output::load8ZeroExt32):
        (JSC::FTL::Output::anchor):
        (JSC::FTL::Output::absolute): Deleted.
        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::collectAndSweep):
        (JSC::Heap::collectImpl):
        (JSC::Heap::zombifyDeadObjects):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::specializedSweep):
        * interpreter/Interpreter.cpp:
        (JSC::setupVarargsFrameAndSetThis):
        (JSC::Interpreter::Interpreter):
        (JSC::Interpreter::initialize):
        (JSC::checkedReturn):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::debug):
        (JSC::SamplingScope::SamplingScope): Deleted.
        (JSC::SamplingScope::~SamplingScope): Deleted.
        (JSC::Interpreter::enableSampler): Deleted.
        (JSC::Interpreter::dumpSampleData): Deleted.
        (JSC::Interpreter::startSampling): Deleted.
        (JSC::Interpreter::stopSampling): Deleted.
        * interpreter/Interpreter.h:
        (JSC::Interpreter::isCallBytecode):
        (JSC::Interpreter::sampler): Deleted.
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::branchIfNotFastTypedArray):
        (JSC::AssemblyHelpers::incrementSuperSamplerCount):
        (JSC::AssemblyHelpers::decrementSuperSamplerCount):
        (JSC::AssemblyHelpers::purifyNaN):
        * jit/AssemblyHelpers.h:
        * jit/JIT.cpp:
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        * jit/JITArithmetic32_64.cpp:
        * jit/JITCall.cpp:
        * jit/JITCall32_64.cpp:
        * jit/JITOperations.cpp:
        * jit/JITPropertyAccess.cpp:
        * jit/JITPropertyAccess32_64.cpp:
        * jsc.cpp:
        (runWithScripts):
        (jscmain):
        * parser/Nodes.cpp:
        * parser/Parser.h:
        (JSC::parse):
        * runtime/Executable.h:
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/Options.h:
        * runtime/RegExpCachedResult.h:
        * runtime/RegExpMatchesArray.h:
        (JSC::createRegExpMatchesArray):
        * runtime/StringPrototype.cpp:
        (JSC::removeUsingRegExpSearch):
        (JSC::stringProtoFuncSubstring):
        * runtime/VM.cpp:
        (JSC::VM::resetDateCache):
        (JSC::VM::whenIdle):
        (JSC::VM::deleteAllCode):
        (JSC::VM::addSourceProviderCache):
        (JSC::VM::startSampling): Deleted.
        (JSC::VM::stopSampling): Deleted.
        (JSC::VM::dumpSampleData): Deleted.
        * runtime/VM.h:
        (JSC::VM::regExpCache):
        * testRegExp.cpp:
        (runFromFiles):
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::interpret):

2016-03-17  Saam barati  <sbarati@apple.com>

        [ES6] Make GetProperty(.) inside ArrayPrototype.cpp spec compatible.
        https://bugs.webkit.org/show_bug.cgi?id=155575

        Reviewed by Filip Pizlo and Mark Lam.

        This patch makes various Array.prototype.(shift | unshift | splice)
        spec compliant. Before, they were performing Get and HasProperty as one 
        operation. Instead, they need to be performed as two distinct operations
        when it would be observable.

        * runtime/ArrayPrototype.cpp:
        (JSC::getProperty):
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::PropertySlot):
        (JSC::PropertySlot::isCacheableValue):
        (JSC::PropertySlot::isCacheableGetter):
        (JSC::PropertySlot::isCacheableCustom):
        (JSC::PropertySlot::setIsTaintedByProxy):
        (JSC::PropertySlot::isTaintedByProxy):
        (JSC::PropertySlot::internalMethodType):
        (JSC::PropertySlot::getValue):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        * tests/es6.yaml:
        * tests/stress/proxy-array-prototype-methods.js: Added.
        (assert):
        (test):
        (shallowEq):

2016-03-17  Mark Lam  <mark.lam@apple.com>

        Make FunctionMode an enum class.
        https://bugs.webkit.org/show_bug.cgi?id=155587

        Reviewed by Saam Barati.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * parser/NodeConstructors.h:
        (JSC::BaseFuncExprNode::BaseFuncExprNode):
        (JSC::FuncExprNode::FuncExprNode):
        (JSC::FuncDeclNode::FuncDeclNode):
        (JSC::ArrowFuncExprNode::ArrowFuncExprNode):
        (JSC::MethodDefinitionNode::MethodDefinitionNode):
        * parser/ParserModes.h:
        (JSC::functionNameIsInScope):

2016-03-17  Michael Saboff  <msaboff@apple.com>

        [ES6] Getters and Setters should be prefixed appropriately
        https://bugs.webkit.org/show_bug.cgi?id=155593

        Reviewed by Mark Lam.

        Changed the putDirectNativeIntrinsicGetter() to prepend "get " to the funtion name.

        Updated places that had their own macro or hand constructed a getter function to use
        the JSC_NATIVE_GETTER macro which will properly append "get ".

        Prepended "get " and "set " to the __proto__ accessor created on the Object prototype.

        When we create the Symbol.species getter, added an explicit function name of "get [Symbol.species]".

        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        (Inspector::jsInjectedScriptHostPrototypeAttributeEvaluate):
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluate):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putDirectNativeIntrinsicGetter):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        (JSC::MapPrototype::getOwnPropertySlot):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        (JSC::SetPrototype::getOwnPropertySlot):
        * tests/stress/accessors-get-set-prefix.js: Added.
        (tryGetOwnPropertyDescriptorGetName):

2016-03-16  Mark Lam  <mark.lam@apple.com>

        Method names should not appear in the lexical scope of the method's body.
        https://bugs.webkit.org/show_bug.cgi?id=155568

        Reviewed by Saam Barati.

        Consider this scenario:

            var f = "foo";
            var result = ({
                f() {
                    return f; // f should be the string "foo", not this method f.
                }
            }).f();
            result === "foo"; // Should be true.

        The reason this is not current working is because the parser does not yet
        distinguish between FunctionExpressions and MethodDefinitions.  The ES6 spec
        explicitly distinguishes between the 2, and we should do the same.
        
        This patch changes all methods (and getters and setters which are also methods)
        to have a FunctionMode of MethodDefinition (instead of FunctionExpression).
        functionNameIsInScope() is responsible for determining whether a function's name
        should be in its scope or not.  It already returns false for any function
        whose FunctionMode is not FunctionExpression.  Giving methods the MethodDefinition
        FunctionMode gets us the correct behavior ES6 expects.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
        (JSC::BytecodeGenerator::emitNewMethodDefinition):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrowFuncExprNode::emitBytecode):
        (JSC::MethodDefinitionNode::emitBytecode):
        (JSC::YieldExprNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFunctionExpr):
        (JSC::ASTBuilder::createMethodDefinition):
        (JSC::ASTBuilder::createFunctionMetadata):
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createArguments):
        * parser/NodeConstructors.h:
        (JSC::FunctionParameters::FunctionParameters):
        (JSC::BaseFuncExprNode::BaseFuncExprNode):
        (JSC::FuncExprNode::FuncExprNode):
        (JSC::FuncDeclNode::FuncDeclNode):
        (JSC::ArrowFuncExprNode::ArrowFuncExprNode):
        (JSC::MethodDefinitionNode::MethodDefinitionNode):
        (JSC::YieldExprNode::YieldExprNode):
        * parser/Nodes.h:
        (JSC::BaseFuncExprNode::metadata):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        * parser/ParserModes.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createFunctionExpr):
        (JSC::SyntaxChecker::createFunctionMetadata):
        (JSC::SyntaxChecker::createArrowFunctionExpr):
        (JSC::SyntaxChecker::createMethodDefinition):
        (JSC::SyntaxChecker::setFunctionNameStart):
        (JSC::SyntaxChecker::createArguments):
        * tests/es6.yaml:

2016-03-17  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION(r197380): Build fails with new GCC and Clang
        https://bugs.webkit.org/show_bug.cgi?id=155044

        Reviewed by Michael Catanzaro.

        In C++, std math functions ceil and floor are overloaded for double and float.
        Without explicit cast or function pointer assignment, compilers cannot
        determine which function address is used in the given context.

        * b3/B3LowerMacrosAfterOptimizations.cpp:

2016-03-17  Skachkov Oleksandr  <gskachkov@gmail.com>

        Invoking super()/super inside of the eval should not lead to SyntaxError
        https://bugs.webkit.org/show_bug.cgi?id=153864

        Reviewed by Saam Barati.

        Added support of the invoking super/super() inside of the eval within class.
        Also support cases when eval is invoked in constructor, class method directly 
        or via arrow function. Access to the new.target in eval is not part of this patch
        and will be implemented in https://bugs.webkit.org/show_bug.cgi?id=155545

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::isThisUsedInInnerArrowFunction):
        (JSC::BytecodeGenerator::isNewTargetUsedInInnerArrowFunction):
        (JSC::BytecodeGenerator::isSuperUsedInInnerArrowFunction):
        (JSC::BytecodeGenerator::isSuperCallUsedInInnerArrowFunction):
        (JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::isEvalContext):
        (JSC::Scope::setIsEvalContext):
        (JSC::parse):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        * tests/stress/arrowfunction-lexical-bind-supercall-4.js:
        * tests/stress/arrowfunction-lexical-bind-superproperty.js:
        * tests/stress/class-syntax-super-in-eval.js: Added.
        * tests/stress/generator-with-super.js:

2016-03-15  Filip Pizlo  <fpizlo@apple.com>

        ASSERTION FAILED: !edge->isPhantomAllocation() in regress/script-tests/sink-huge-activation.js.ftl-eager in debug mode
        https://bugs.webkit.org/show_bug.cgi?id=153805

        Reviewed by Mark Lam.

        The object allocation sinking phase uses InferredValue::isStillValid() in the opposite
        way from most clients: it will do an *extra* optimization if it returns false. The
        phase will first compute sink candidates and then it will compute materialization
        points. If something is a sink candidate then it is not a materialization point. A
        NewFunction node may appear as not being a sink candidate during the first pass, so it's
        not added to the set of things that will turn into PhantomNewFunction. But on the second
        pass where we add materializations, we check isStillValid() again. Now this may become
        false, so that second pass thinks that NewFunction is a sink candidate (even though it's
        not in the sink candidates set) and so is not a materialization point.

        This manifests as the NewFunction referring to a PhantomCreateActivation or whatever.

        The solution is to have the phase cache results of calls to isStillValid(). It's OK if
        we just remember the result of the first call and assume that it's not a sink candidate.
        That's the worst that can happen.

        No new tests since this is a super hard race and sink-huge-activation seemed to already
        be catching it.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:

2016-03-16  Saam Barati  <sbarati@apple.com>

        [ES6] Make Array.prototype.reverse spec compatible.
        https://bugs.webkit.org/show_bug.cgi?id=155528

        Reviewed by Michael Saboff.

        This patch make Array.prototype.reverse spec compatible.
        Before, we weren't performing a HasProperty of each index
        before performing a Get on that index.  We now do that on
        the slow path.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncReverse):
        * tests/stress/array-reverse-proxy.js: Added.
        (assert):
        (test):
        (shallowCopy):
        (shallowEqual):
        (let.handler.get getSet):
        (test.let.handler.get getSet):

2016-03-16  Chris Dumez  <cdumez@apple.com>

        Unreviewed, rolling out r198235, r198240, r198241, and
        r198252.

        Causing crashes on ARM

        Reverted changesets:

        "Remove compile time define for SEPARATED_HEAP"
        https://bugs.webkit.org/show_bug.cgi?id=155508
        http://trac.webkit.org/changeset/198235

        "Gardening: build fix after r198235."
        http://trac.webkit.org/changeset/198240

        "Build fix."
        http://trac.webkit.org/changeset/198241

        "Rename performJITMemcpy to something more inline with our
        normal webkit function names"
        https://bugs.webkit.org/show_bug.cgi?id=155525
        http://trac.webkit.org/changeset/198252

2016-03-16  Brian Burg <bburg@apple.com>

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

        This change is unnecessary, clients can instead compile the
        file with ARC enabled (Requested by brrian on #webkit).

        Reverted changeset:

        "REGRESSION(r198077): generated Objective-C protocol object
        getters leak their wrappers"
        https://bugs.webkit.org/show_bug.cgi?id=155523
        http://trac.webkit.org/changeset/198257

2016-03-16  Mark Lam  <mark.lam@apple.com>

        Add support for setting Function.name from computed properties.
        https://bugs.webkit.org/show_bug.cgi?id=155437

        Reviewed by Filip Pizlo.

        In JS code, we can have initialization of computed properties with function and
        class objects e.g.

            var o = {
                [x]: function() {},
                [y]: class {}
            }

        The ES6 spec states that the function and class in the example above (being
        anonymous) should take on the value of x and y respectively as their names:

            o[x].name; // should be the "stringified" value of x.
            o[y].name; // should be the "stringified" value of y.

        To achieve this, we will now inject an op_set_function_name bytecode at property
        initialization sites if:

        1. the property assigned value is a function or class, and
        2. the function and class is anonymous, and
        3. if property assigned value is a class, it doesn't have a static method
           that is statically named "name".

        The op_set_function_name will result in JSFunction::setFunctionName() being
        called on the target function / class before it is assigned to the property.
        JSFunction::setFunctionName() will take care of:

        1. computing the name to use from the value of the computed property name
           e.g. x and y in the example above.

           If the computed property name is not a symbol, then the function / class name
           should be the toString() value of that computed property name.

           If the computed property name is a symbol, then ...
           a. if the Symbol has a defined description (e.g. Symbol("foo")), then the
              function / class name should be "[<symbol description>]" e.g. "[foo]".
           b. if the Symbol has an undefined description (e.g. Symbol()), then the
              function / class name should be "".

           Note: Symbol("") is not the same as Symbol().  The former has a defined
           descriptor "", and hence, yields a function / class name of "[]".  The latter
           yields a function / class name of "".

        2. reifying the lazy name property with this function / class name.

        op_set_function_name is named after the SetFunctionName internal function
        in the ES6 spec that performs the above operation.

        It is behaviorally correct to use op_set_function_name at every property
        initialization site with computed property names.  However, we choose to not
        emit the op_set_function_name bytecode when we already know that it will do
        nothing i.e. when the target function / class is proven to already have a name or
        name property.  This is done as an optimization to avoid unnecessary calls to
        JSFunction::setFunctionName().

        Note: we could further check if the class has a static method with a computed
        name that is a constant string "name" and elide op_set_function_name there too.
        However, we don't bother because this should be rare.  JSFunction::setFunctionName()
        will still do the right thing.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitNewFunction):
        (JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded):
        (JSC::BytecodeGenerator::emitCall):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode):
        (JSC::PropertyListNode::emitPutConstantProperty):
        * 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/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunction):
        (JSC::DFG::SpeculativeJIT::compileSetFunctionName):
        (JSC::DFG::SpeculativeJIT::compileForwardVarargs):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
        (JSC::FTL::DFG::LowerDFGToB3::compileSetFunctionName):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_to_primitive):
        (JSC::JIT::emit_op_set_function_name):
        (JSC::JIT::emit_op_strcat):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emitSlow_op_to_primitive):
        (JSC::JIT::emit_op_set_function_name):
        (JSC::JIT::emit_op_strcat):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::handleHostCall):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/Nodes.cpp:
        (JSC::FunctionNode::finishParsing):
        (JSC::PropertyListNode::hasStaticallyNamedProperty):
        (JSC::VariableEnvironmentNode::VariableEnvironmentNode):
        * parser/Nodes.h:
        * runtime/JSFunction.cpp:
        (JSC::getCalculatedDisplayName):
        (JSC::JSFunction::setFunctionName):
        (JSC::JSFunction::reifyLength):
        (JSC::JSFunction::reifyName):
        * runtime/JSFunction.h:
        * tests/es6.yaml:
        * tests/stress/computed-function-names.js: Added.
        (toKeyString):
        (toFuncName):
        (shouldBe):
        (return.propKey):

2016-03-16  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Reflect.set with receiver
        https://bugs.webkit.org/show_bug.cgi?id=155294

        Reviewed by Saam Barati.

        This patch introduces the receiver parameter support for Reflect.set.
        Reflect.set can alter the receiver with arbitrary values.
        Each property descriptor uses the receiver in [[Set]].

        1) In the accessor descriptor case, the receiver is used as |this| value for setter calls.
        2) In the data descriptor case, the actual property will be set onto the receiver objects.

        The current put operation does not support the receiver that is different from the base object.
        In particular, (2) case is not supported.
        The naive implementation adds one more [[GetOwnProperty]] for the receiver per [[Set]] (9.1.9.1-4-c [1]), and it is unacceptable.
        To keep the fast path efficiently, we fall back to the slow but generic implementation (ordinarySetSlow)
        only when the receiver is altered.

        We need not to change any JIT part, because the JS code cannot alter the receiver without Reflect.set.
        The property accesses generated by the JIT code always have the receiver that is the same to the base object.
        ProxyObject can alter the receiver, but this situation has no problem because ProxyObject disables Inline Caching.
        NOTE: Generating Inline Caching for JSProxy (that is used for the Window proxy) is already disabled before this change.

        [1]: https://tc39.github.io/ecma262/#sec-ordinaryset

        * jsc.cpp:
        (functionCreateProxy):
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::put):
        * runtime/JSArray.cpp:
        (JSC::JSArray::put):
        * runtime/JSArrayBuffer.cpp:
        (JSC::JSArrayBuffer::put):
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::put):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::isThisValueAltered):
        * runtime/JSDataView.cpp:
        (JSC::JSDataView::put):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::put):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::put):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::put):
        * runtime/JSObject.cpp:
        (JSC::ordinarySetSlow):
        (JSC::JSObject::putInlineSlow):
        * runtime/JSObject.h:
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::putInline):
        * runtime/JSProxy.h:
        (JSC::JSProxy::createStructure):
        * runtime/Lookup.h:
        (JSC::putEntry):
        * runtime/PropertySlot.h:
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::put):
        * runtime/PutPropertySlot.h:
        (JSC::PutPropertySlot::PutPropertySlot):
        (JSC::PutPropertySlot::isCacheablePut):
        (JSC::PutPropertySlot::isCacheableSetter):
        (JSC::PutPropertySlot::isCacheableCustom):
        (JSC::PutPropertySlot::isCustomAccessor):
        (JSC::PutPropertySlot::disableCaching):
        (JSC::PutPropertySlot::isCacheable):
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectSet):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::put):
        (JSC::reject): Deleted.
        * runtime/StringObject.cpp:
        (JSC::StringObject::put):
        * tests/es6.yaml:
        * tests/stress/ordinary-set-exceptions.js: Added.
        (shouldBe):
        (shouldThrow):
        (shouldThrow.set get var):
        * tests/stress/proxy-set.js:
        * tests/stress/reflect-set-proxy-set.js: Copied from Source/JavaScriptCore/tests/stress/proxy-set.js.
        (shouldBe):
        (unreachable):
        (assert):
        (throw.new.Error.let.handler.set 45):
        (throw.new.Error):
        (let.target.set x):
        (let.target.get x):
        (set let):
        * tests/stress/reflect-set-receiver-proxy-set.js: Added.
        (shouldBe):
        (unreachable):
        (assert):
        (let.handler.set 45):
        (catch):
        (let.target.set x):
        (let.target.get x):
        (set let):
        * tests/stress/reflect-set-with-global-proxy.js: Added.
        (shouldBe):
        (unreachable):
        (get shouldBe):
        (set shouldBe):
        (set test1):
        (set test2):
        (set test3):
        * tests/stress/reflect-set.js:
        (shouldThrow):
        (unreachable):
        (get shouldBe):
        (set shouldBe):
        (receiverTestIndexed):
        (set get Uint8Array):
        (receiverCase): Deleted.
        (proxyCase): Deleted.
        (stringObjectCase.set get shouldBe): Deleted.
        (regExpLastIndex): Deleted.

2016-03-15  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove hint from SlowCaseEntry
        https://bugs.webkit.org/show_bug.cgi?id=155530

        Reviewed by Alex Christensen.

        * jit/JIT.h:
        (JSC::SlowCaseEntry::SlowCaseEntry):

2016-03-15  Brian Burg  <bburg@apple.com>

        REGRESSION(r198077): generated Objective-C protocol object getters leak their wrappers
        https://bugs.webkit.org/show_bug.cgi?id=155523
        <rdar://problem/25181764>

        Reviewed by Joseph Pecoraro.

        Since the code may not be compiled with ARC, autorelease the returned wrapper.

        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator.protocol_to_objc_expression_for_member):
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:

2016-03-15  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Help clang generate better code on arrayProtoFuncToString()
        https://bugs.webkit.org/show_bug.cgi?id=155512

        Reviewed by Mark Lam.

        3d-raytrace hits Array.toString() hard with small arrays.
        Half of the time is going into overhead around the StringJoiner.
        This patch makes the function shorter and the layout better.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncToString):
        Add "UNLIKELY" on rare cases. Clang pushes that code to the tail.

        Factor the code of jsMakeNontrivialString() so that the operation
        is not duplicated in the function.

        * runtime/JSStringBuilder.h:
        (JSC::jsMakeNontrivialString):
        jsNontrivialString() supports r-value reference.
        Move the result string into jsNontrivialString(), this removes
        the deref+destructor from the function.

        * runtime/JSStringJoiner.cpp:
        (JSC::JSStringJoiner::~JSStringJoiner):
        The destructor is pretty large. No point in inlining it.

        (JSC::joinStrings):
        * runtime/JSStringJoiner.h:
        (JSC::JSStringJoiner::JSStringJoiner):
        (JSC::JSStringJoiner::append):
        The calls were duplicated. That's unnecessary.

        * runtime/NumericStrings.h:
        (JSC::NumericStrings::add):
        Return a reference in all cases.
        This removes a deref+destructor.

2016-03-15  Joseph Pecoraro  <pecoraro@apple.com>

        Remove stale ArrayPrototype declarations
        https://bugs.webkit.org/show_bug.cgi?id=155520

        Reviewed by Mark Lam.

        * runtime/ArrayPrototype.cpp:
        The implementations went away when the methods were moved to builtins
        but the declarations were left behind.

2016-03-15  Oliver Hunt  <oliver@apple.com>

        Rename performJITMemcpy to something more inline with our normal webkit function names
        https://bugs.webkit.org/show_bug.cgi?id=155525

        Reviewed by Saam Barati.

        Simple bulk search/replace with a better name.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::fillNops):
        (JSC::ARM64Assembler::replaceWithJump):
        (JSC::ARM64Assembler::replaceWithLoad):
        (JSC::ARM64Assembler::replaceWithAddressComputation):
        (JSC::ARM64Assembler::setPointer):
        (JSC::ARM64Assembler::repatchInt32):
        (JSC::ARM64Assembler::repatchCompact):
        (JSC::ARM64Assembler::linkJumpOrCall):
        (JSC::ARM64Assembler::linkCompareAndBranch):
        (JSC::ARM64Assembler::linkConditionalBranch):
        (JSC::ARM64Assembler::linkTestAndBranch):
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::copyCompactAndLinkCode):
        * jit/ExecutableAllocator.h:
        (JSC::writeToExecutableRegion):
        (JSC::performJITMemcpy): Deleted.

2016-03-15  Oliver Hunt  <oliver@apple.com>

        Build fix.

        * jit/ExecutableAllocatorFixedVMPool.cpp:

2016-03-15  Mark Lam  <mark.lam@apple.com>

        Gardening: build fix after r198235.

        Not Reviewed.

        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):

2016-03-15  Oliver Hunt  <oliver@apple.com>

        Remove compile time define for SEPARATED_HEAP
        https://bugs.webkit.org/show_bug.cgi?id=155508

        Reviewed by Mark Lam.

        This removes the compile time define for the SEPARATED_HEAP
        feature, and moves to a default-off runtime preference.

        This happily also removes the need for world rebuilds while
        bringing it up on different platforms.

        * Configurations/FeatureDefines.xcconfig:
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::copyCompactAndLinkCode):
        * jit/ExecutableAllocator.h:
        (JSC::performJITMemcpy):
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
        (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
        (JSC::FixedVMPoolExecutableAllocator::genericWriteToJITRegion):
        (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): Deleted.
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:

2016-03-15  Commit Queue  <commit-queue@webkit.org>

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

        "Lets do this patch at a later time" (Requested by saamyjoon
        on #webkit).

        Reverted changeset:

        "[ES6] Disallow var assignments in for-in loops"
        https://bugs.webkit.org/show_bug.cgi?id=155451
        http://trac.webkit.org/changeset/198148

2016-03-15  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION: ASSERTION FAILED: !m_lastActiveBlock on js/function-apply.html
        https://bugs.webkit.org/show_bug.cgi?id=155411
        <rdar://problem/25134537>

        Reviewed by Mark Lam.

        * heap/Heap.cpp:
        (JSC::Heap::collectImpl):
        (JSC::Heap::didFinishCollection):
        During collection allocators are stop/reset. The HeapProfiler tasks
        were using HeapIterationScope (to satisfy MarkedSpace forEachCell API
        contracts) which was doing its own stop/resume of allocators. Doing a
        stop/resume in between the normal stop/reset of collection is unexpected.

        Move this to didFinishCollection, alongside other heap iterations
        like zombies and immortal objects. Putting this after those tasks
        also means the heap snapshots will respect the zombies/immortal options
        when deciding if the cell is alive or not.

2016-03-15  Saam Barati  <sbarati@apple.com>

        We should have different JSTypes for JSGlobalLexicalEnvironment and JSLexicalEnvironment and JSModuleEnvironment
        https://bugs.webkit.org/show_bug.cgi?id=152406

        Reviewed by Mark Lam.

        This makes testing for a JSGlobalLexicalEnvironment faster
        because we can just check the Cell's type instead of using
        jsDynamicCast. I also changed code that does jsDynamicCast<JSGlobalObject*>
        instead of isGlobalObject().

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
        (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
        * runtime/JSGlobalLexicalEnvironment.h:
        (JSC::JSGlobalLexicalEnvironment::createStructure):
        * runtime/JSLexicalEnvironment.h:
        (JSC::JSLexicalEnvironment::createStructure):
        (JSC::JSLexicalEnvironment::JSLexicalEnvironment):
        * runtime/JSModuleEnvironment.h:
        (JSC::JSModuleEnvironment::createStructure):
        (JSC::JSModuleEnvironment::offsetOfModuleRecord):
        * runtime/JSObject.h:
        (JSC::JSObject::isGlobalObject):
        (JSC::JSObject::isJSLexicalEnvironment):
        (JSC::JSObject::isGlobalLexicalEnvironment):
        (JSC::JSObject::isErrorInstance):
        * runtime/JSScope.cpp:
        (JSC::abstractAccess):
        (JSC::isUnscopable):
        (JSC::JSScope::resolve):
        (JSC::JSScope::collectVariablesUnderTDZ):
        (JSC::JSScope::isVarScope):
        (JSC::JSScope::isLexicalScope):
        (JSC::JSScope::isModuleScope):
        (JSC::JSScope::isCatchScope):
        (JSC::JSScope::isFunctionNameScopeObject):
        (JSC::JSScope::isNestedLexicalScope):
        (JSC::JSScope::constantScopeForCodeBlock):
        (JSC::isScopeType): Deleted.
        (JSC::JSScope::isGlobalLexicalEnvironment): Deleted.
        * runtime/JSScope.h:
        * runtime/JSType.h:

2016-03-15  Filip Pizlo  <fpizlo@apple.com>

        Remove the Baker barrier from JSC
        https://bugs.webkit.org/show_bug.cgi?id=155479

        Reviewed by Saam Barati.

        It's been a while since I added a Baker barrier, but I never followed it up with an actual
        concurrent GC. While thinking about the GC, I became convinced that the right path forward
        is to do a non-copying concurrent GC. That is, remove the copied space and just use the
        marked space. The downside of using marked space cannot be more than the overhead of the
        Baker barrier, so concurrent non-copying GC is definitely better than copying
        non-concurrent GC. I also suspect that just plain non-copying non-concurrent GC is going to
        be fine also, so the path forward will probably be to first just remove CopiedSpace.

        Anyway, for now this patch just removes the Baker barrier. It was a cute implementation but
        it just cost performance and I don't think we'll ever use it.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generate):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGCopyBarrierOptimizationPhase.cpp: Removed.
        * dfg/DFGCopyBarrierOptimizationPhase.h: Removed.
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
        (JSC::DFG::SpeculativeJIT::compileGetButterfly):
        * 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):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetButterfly):
        (JSC::FTL::DFG::LowerDFGToB3::compileConstantStoragePointer):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname):
        (JSC::FTL::DFG::LowerDFGToB3::storageForTransition):
        (JSC::FTL::DFG::LowerDFGToB3::getById):
        (JSC::FTL::DFG::LowerDFGToB3::isFastTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetButterflyReadOnly): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::loadButterflyWithBarrier): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::loadVectorWithBarrier): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::copyBarrier): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::isInToSpace): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::loadButterflyReadOnly): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::loadVectorReadOnly): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::removeSpaceBits): Deleted.
        * heap/CopyBarrier.h:
        (JSC::CopyBarrierBase::CopyBarrierBase):
        (JSC::CopyBarrierBase::operator bool):
        (JSC::CopyBarrierBase::get):
        (JSC::CopyBarrierBase::clear):
        (JSC::CopyBarrierBase::setWithoutBarrier):
        (JSC::CopyBarrier::CopyBarrier):
        (JSC::CopyBarrier::get):
        (JSC::CopyBarrier::set):
        (JSC::CopyBarrier::setWithoutBarrier):
        (JSC::CopyBarrierBase::operator!): Deleted.
        (JSC::CopyBarrierBase::getWithoutBarrier): Deleted.
        (JSC::CopyBarrierBase::getPredicated): Deleted.
        (JSC::CopyBarrierBase::copyState): Deleted.
        (JSC::CopyBarrierBase::setCopyState): Deleted.
        (JSC::CopyBarrierBase::weakCASWithoutBarrier): Deleted.
        (JSC::CopyBarrier::getWithoutBarrier): Deleted.
        (JSC::CopyBarrier::getPredicated): Deleted.
        (JSC::CopyBarrier::weakCASWithoutBarrier): Deleted.
        * heap/Heap.cpp:
        (JSC::Heap::addToRememberedSet):
        (JSC::Heap::collectAndSweep):
        (JSC::Heap::copyBarrier): Deleted.
        * heap/Heap.h:
        (JSC::Heap::writeBarrierBuffer):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::branchIfNotFastTypedArray):
        (JSC::AssemblyHelpers::purifyNaN):
        (JSC::AssemblyHelpers::loadTypedArrayVector): Deleted.
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchStructure):
        (JSC::AssemblyHelpers::addressForByteOffset):
        (JSC::AssemblyHelpers::branchIfToSpace): Deleted.
        (JSC::AssemblyHelpers::branchIfNotToSpace): Deleted.
        (JSC::AssemblyHelpers::removeSpaceBits): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompile):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitSlow_op_has_indexed_property):
        (JSC::JIT::emit_op_get_direct_pname):
        (JSC::JIT::emitSlow_op_get_direct_pname):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_get_direct_pname):
        (JSC::JIT::emitSlow_op_get_direct_pname):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitDoubleLoad):
        (JSC::JIT::emitContiguousLoad):
        (JSC::JIT::emitArrayStorageLoad):
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        (JSC::JIT::emitSlow_op_put_by_val):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitSlow_op_put_to_scope):
        (JSC::JIT::emitIntTypedArrayGetByVal):
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/DirectArguments.cpp:
        (JSC::DirectArguments::visitChildren):
        (JSC::DirectArguments::copyBackingStore):
        (JSC::DirectArguments::overrideArgument):
        (JSC::DirectArguments::copyToArguments):
        * runtime/DirectArguments.h:
        (JSC::DirectArguments::canAccessIndexQuickly):
        (JSC::DirectArguments::canAccessArgumentIndexQuicklyInDFG):
        * runtime/JSArray.cpp:
        (JSC::JSArray::setLength):
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::fastSlice):
        (JSC::JSArray::fastConcatWith):
        (JSC::JSArray::shiftCountWithArrayStorage):
        (JSC::JSArray::shiftCountWithAnyIndexingType):
        (JSC::JSArray::unshiftCountWithAnyIndexingType):
        (JSC::JSArray::fillArgList):
        (JSC::JSArray::copyToArguments):
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::finalize):
        * runtime/JSArrayBufferView.h:
        (JSC::JSArrayBufferView::isNeutered):
        (JSC::JSArrayBufferView::vector):
        (JSC::JSArrayBufferView::length):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
        (JSC::JSGenericTypedArrayView<Adaptor>::copyBackingStore):
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitChildren):
        (JSC::JSObject::copyBackingStore):
        (JSC::JSObject::heapSnapshot):
        (JSC::JSObject::getOwnPropertySlotByIndex):
        (JSC::JSObject::putByIndex):
        (JSC::JSObject::enterDictionaryIndexingMode):
        (JSC::JSObject::createInitialIndexedStorage):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::convertUndecidedToInt32):
        (JSC::JSObject::convertUndecidedToDouble):
        (JSC::JSObject::convertUndecidedToContiguous):
        (JSC::JSObject::constructConvertedArrayStorageWithoutCopyingElements):
        (JSC::JSObject::convertUndecidedToArrayStorage):
        (JSC::JSObject::convertInt32ToDouble):
        (JSC::JSObject::convertInt32ToContiguous):
        (JSC::JSObject::convertInt32ToArrayStorage):
        (JSC::JSObject::convertDoubleToContiguous):
        (JSC::JSObject::convertDoubleToArrayStorage):
        (JSC::JSObject::convertContiguousToArrayStorage):
        (JSC::JSObject::setIndexQuicklyToUndecided):
        (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode):
        (JSC::JSObject::deletePropertyByIndex):
        (JSC::JSObject::getOwnPropertyNames):
        (JSC::JSObject::putIndexedDescriptor):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
        (JSC::JSObject::putDirectIndexBeyondVectorLength):
        (JSC::JSObject::getNewVectorLength):
        (JSC::JSObject::ensureLengthSlow):
        (JSC::JSObject::reallocateAndShrinkButterfly):
        (JSC::JSObject::growOutOfLineStorage):
        (JSC::getBoundSlotBaseFunctionForGetterSetter):
        (JSC::JSObject::getEnumerableLength):
        * runtime/JSObject.h:
        (JSC::JSObject::getArrayLength):
        (JSC::JSObject::getVectorLength):
        (JSC::JSObject::canGetIndexQuickly):
        (JSC::JSObject::getIndexQuickly):
        (JSC::JSObject::tryGetIndexQuickly):
        (JSC::JSObject::canSetIndexQuickly):
        (JSC::JSObject::canSetIndexQuicklyForPutDirect):
        (JSC::JSObject::setIndexQuickly):
        (JSC::JSObject::initializeIndex):
        (JSC::JSObject::hasSparseMap):
        (JSC::JSObject::inSparseIndexingMode):
        (JSC::JSObject::inlineStorage):
        (JSC::JSObject::butterfly):
        (JSC::JSObject::outOfLineStorage):
        (JSC::JSObject::locationForOffset):
        (JSC::JSObject::ensureInt32):
        (JSC::JSObject::ensureDouble):
        (JSC::JSObject::ensureContiguous):
        (JSC::JSObject::ensureArrayStorage):
        (JSC::JSObject::arrayStorage):
        (JSC::JSObject::arrayStorageOrNull):
        (JSC::JSObject::ensureLength):
        (JSC::JSObject::putDirectWithoutTransition):
        * runtime/MapData.h:
        (JSC::JSIterator>::IteratorData::next):
        (JSC::JSIterator>::IteratorData::refreshCursor):
        * runtime/MapDataInlines.h:
        (JSC::JSIterator>::find):
        (JSC::JSIterator>::add):
        (JSC::JSIterator>::remove):
        (JSC::JSIterator>::replaceAndPackBackingStore):
        (JSC::JSIterator>::replaceBackingStore):
        (JSC::JSIterator>::ensureSpaceForAppend):
        (JSC::JSIterator>::visitChildren):
        (JSC::JSIterator>::copyBackingStore):
        * runtime/Options.h:

2016-03-15  Saam barati  <sbarati@apple.com>

        Destructuring parameters are evaluated in the wrong scope
        https://bugs.webkit.org/show_bug.cgi?id=155454

        Reviewed by Geoffrey Garen.

        This patch makes our engine compatible with how parameter
        lists are evaluated in ES6. A parameter list that contains
        a rest parameter, any destructuring patterns, or default parameter values, 
        is classified as being non-simple. Non-simple parameter lists
        must get their own scope to live in, and the variables in the
        scope are under TDZ. This means that functions evaluated in the
        parameter list don't have access to variables inside the function
        body. Also, non-simple parameter lists get the strict-mode arguments object.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::~BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        * bytecompiler/BytecodeGenerator.h:
        * parser/Nodes.h:
        (JSC::FunctionParameters::size):
        (JSC::FunctionParameters::at):
        (JSC::FunctionParameters::append):
        (JSC::FunctionParameters::hasDefaultParameterValues): Deleted.
        * tests/es6.yaml:
        * tests/stress/parameter-scoping.js: Added.
        (assert):
        (test):
        (test.foo):
        (test.):

2016-03-14  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Don't reference the properties of @Reflect directly
        https://bugs.webkit.org/show_bug.cgi?id=155436

        Reviewed by Geoffrey Garen.

        Reflect.ownKeys and Reflect.getOwnPropertyDescriptor can be altered with the user-crafted values.
        Instead of referencing them directly, let's reference them through private names.

        * builtins/ObjectConstructor.js:
        (assign):
        * runtime/CommonIdentifiers.h:
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation): Deleted.
        * runtime/ReflectObject.cpp:
        (JSC::ReflectObject::finishCreation):
        * tests/stress/object-assign-correctness.js:
        (runTests.):
        (runTests.get let):
        (Reflect.ownKeys):
        (Reflect.getOwnPropertyDescriptor):
        (test.let.handler.switch.case.string_appeared_here.return.get enumerable): Deleted.
        (test.let.handler.getOwnPropertyDescriptor): Deleted.
        (test.let.handler.ownKeys): Deleted.
        (test.let.handler.get getProps): Deleted.
        (test.let.handler): Deleted.
        (test): Deleted.

2016-03-14  Daniel Bates  <dabates@apple.com>

        Web Inspector: Display Content Security Policy hash in details sidebar for script and style elements
        https://bugs.webkit.org/show_bug.cgi?id=155466
        <rdar://problem/25152480>

        Reviewed by Joseph Pecoraro and Timothy Hatcher.

        Add property contentSecurityPolicyHash to store the CSP hash for an HTML style element or an
        applicable HTML script element.

        * inspector/protocol/DOM.json:

2016-03-14  Joonghun Park  <jh718.park@samsung.com>

        Purge PassRefPtr from ArrayBuffer, ArchiveResource, Pasteboard, LegacyWebArchive and DataObjectGtk
        https://bugs.webkit.org/show_bug.cgi?id=150497

        Reviewed by Darin Adler.

        * runtime/ArrayBuffer.h:
        (JSC::ArrayBuffer::create):
        (JSC::ArrayBuffer::createAdopted):
        (JSC::ArrayBuffer::createFromBytes):
        (JSC::ArrayBuffer::createUninitialized):
        (JSC::ArrayBuffer::slice):
        (JSC::ArrayBuffer::sliceImpl):

2016-03-14  Benjamin Poulain  <bpoulain@apple.com>

        Andy VanWagoner no longer has time to own Intl

        * features.json:
        Andy is busy with other things.

        Andy, thanks for your amazing work on Intl and your dedication
        to making things right.

2016-03-14  Julien Brianceau  <jbriance@cisco.com>

        [mips] Fix unaligned access in LLINT.
        https://bugs.webkit.org/show_bug.cgi?id=153228

        Address loads used with btbxx opcodes were wrongly converted to lw
        instruction instead of lbu, leading to unaligned access on mips
        platforms. This is not a bug as it's silently fixed up by kernel,
        but it's more efficient to avoid unaligned accesses for mips.

        Reviewed by Geoffrey Garen.

        * offlineasm/mips.rb:

2016-03-14  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(r194394): >2x slow-down on CDjs
        https://bugs.webkit.org/show_bug.cgi?id=155471

        Unreviewed (rollout).

        This revision changes localeCompare() so that it's *much* slower than before. It's
        understandable that sometimes things will get a tiny bit slower when implementing new
        language features, but more than 2x regression on a major benchmark is not OK.

        This rolls out that change. We can reland it once we think about how to do it in a
        performant way.

        * builtins/StringPrototype.js:
        (search):
        (localeCompare): Deleted.
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):

2016-03-14  Mark Lam  <mark.lam@apple.com>

        Need to distinguish between Symbol() and Symbol("").
        https://bugs.webkit.org/show_bug.cgi?id=155438

        Reviewed by Saam Barati.

        * runtime/PrivateName.h:
        (JSC::PrivateName::PrivateName):

2016-03-14  Oliver Hunt  <oliver@apple.com>

        Temporarily disable the separated heap.
        https://bugs.webkit.org/show_bug.cgi?id=155472

        Reviewed by Geoffrey Garen.

        Temporarily disable this.

        * Configurations/FeatureDefines.xcconfig:

2016-03-14  Joseph Pecoraro  <pecoraro@apple.com>

        Reduce generated JSON HeapSnapshot size
        https://bugs.webkit.org/show_bug.cgi?id=155460

        Reviewed by Geoffrey Garen.

        Adjust the HeapSnapshot JSON to better reduce its size.
        Changes include:

          - avoid inner array groups and instead just have a large array for
            nodes/edges. This removes lots of small array allocations.
          - eliminate duplicate edges
          - avoid duplicating edge names by including them in their own table;
          - now both the nodes and edges lists hold only integers

        * heap/HeapSnapshotBuilder.cpp:
        (JSC::HeapSnapshotBuilder::json):
        Add some more documentation for the slightly modified format.
        While generating, clear data structures as early as possible.

        * heap/HeapSnapshotBuilder.h:
        (JSC::HeapSnapshotEdge::HeapSnapshotEdge):
        During JSON building, the edge's cell pointers are converted to the
        identifier they point to. This avoids having to re-lookup the identifier.

        * tests/heapProfiler/driver/driver.js:
        (CheapHeapSnapshotEdge):
        (CheapHeapSnapshot):
        (CheapHeapSnapshot.prototype.edgeNameFromTableIndex):
        (HeapSnapshot):
        Update test driver for slightly different snapshot format.

2016-03-14  Keith Miller  <keith_miller@apple.com>

        We should be able to eliminate cloned arguments objects that use the length property
        https://bugs.webkit.org/show_bug.cgi?id=155391

        Reviewed by Geoffrey Garen.

        Previously if a programmer tried to use arguments.length in a strict function we would not eliminate the
        arguments object. We were unable to eliminate the arguments object because the user would get a cloned arguments
        object, which does not special case the length property. Thus, in order to get arguments elimination for cloned
        we need to add a special case. There are two things that need to happen for the elimination to succeed.

        First, we need to eliminate the CheckStructure blocking the GetByOffset for the length property. In order to
        eliminate the check structure we need to prove to the Abstract Interpreter that this structure check is
        unnesssary. This didn't occur before for two reasons: 1) CreateClonedArguments did not set the structure it
        produced. 2) Even if CreateClonedArguments provided the global object's cloned arguments structure we would
        transition the new argements object when we added the length property during construction. To fix the second
        problem we now pre-assign a slot on clonedArgumentsStructure for the length property. Additionally, in order to
        prevent future transitions of the structure we need to choose an indexing type for the structure. Since, not
        eliminating the arguments object is so expensive we choose to have all cloned arguments start with continuous
        indexing type, this avoids transitioning when otherwise we would not have to. In the future we should be smarter
        about choosing the indexing type but since its relatively rare to have a arguments object escape we don't worry
        about this for now.

        Additionally, this patch renames all former references of outOfBandArguments to clonedArguments and adds
        extra instrumentation to DFGArgumentsEliminationPhase.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::clonedArgumentsThatWereNotCreated):
        (JSC::ValueRecovery::outOfBandArgumentsThatWereNotCreated): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::tryToSetConstantRecovery):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateClonedArguments):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_create_cloned_arguments):
        (JSC::JIT::emit_op_create_out_of_band_arguments): Deleted.
        * llint/LowLevelInterpreter.asm:
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::ClonedArguments):
        (JSC::ClonedArguments::createEmpty):
        (JSC::ClonedArguments::createWithInlineFrame):
        (JSC::ClonedArguments::createByCopyingFrom):
        (JSC::ClonedArguments::createStructure):
        * runtime/ClonedArguments.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::clonedArgumentsStructure):
        (JSC::JSGlobalObject::outOfBandArgumentsStructure): Deleted.

2016-03-14  Saam barati  <sbarati@apple.com>

        [ES6] Make JSON.stringify ES6 compatible
        https://bugs.webkit.org/show_bug.cgi?id=155448

        Reviewed by Sam Weinig and Mark Lam.

        We weren't following the spec with respect to the "toJSON" property
        of the thing being stringified. We were perform hasProperty(.)
        on "toJSON" instead of get(.). This patch changes it our
        implementation to perform get(value, "toJSON").

        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::isFunction):
        (JSC::JSValue::isCallable):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::toJSON):
        (JSC::Stringifier::toJSONImpl):
        (JSC::Stringifier::appendStringifiedValue):
        * tests/es6.yaml:
        * tests/stress/proxy-json.js:
        (test):
        (test.let.handler.get assert):
        (test.let.handler):

2016-03-14  Saam barati  <sbarati@apple.com>

        [ES6] Disallow var assignments in for-in loops
        https://bugs.webkit.org/show_bug.cgi?id=155451

        Reviewed by Mark Lam.

        We're doing this in its own patch instead of the patch for https://bugs.webkit.org/show_bug.cgi?id=155384
        because last time we made this change it broke some websites. Lets try making
        it again because it's what the ES6 mandates. If it still breaks things we will
        roll it out.

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

2016-03-14  Saam barati  <sbarati@apple.com>

        assignments in for-in/for-of header not allowed
        https://bugs.webkit.org/show_bug.cgi?id=155384

        Reviewed by Darin Adler.

        This patch prevents assignments to the loop variable
        in for in/of loops in all but one situation. The following
        syntax is still allowed even though the spec prevents it:
        ```
        for (var i = X in blah) ;
        ```
        If the loop contains let/const, destructuring, or is a for-of
        loop, we always throw a syntax error if there is an assignment.
        We can do this with full backwards compatibility.
        We only allow the above type of for-in loops because Oliver told
        me that when he tried to make such programs illegal he ran
        into real websites breaking.

        This patch also removed the !::CreatesAST compile-time branch when checking
        assignments to new.target. This was a dangerous thing for me
        to introduce into our parser. There are times where ::CreatesAST
        is true but we also want to check for syntax errors. For example,
        when parsing the top-level AST of a program. Though this check
        was technically correct, it's dangerous to have. It was correct
        because we would always be reparsing the new.target assignment
        because new.target is only allowed inside a function. That made it
        so that (!::CreatesAST <=> we care about new.target assignment syntax errors).
        But, (!::CreatesAST <=> we care about syntax error X) is not true in general.
        I think it's safer to remove such code.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createNewTargetExpr):
        (JSC::ASTBuilder::isNewTarget):
        (JSC::ASTBuilder::createResolve):
        * parser/Nodes.h:
        (JSC::ExpressionNode::isBoolean):
        (JSC::ExpressionNode::isSpreadExpression):
        (JSC::ExpressionNode::isSuperNode):
        (JSC::ExpressionNode::isNewTarget):
        (JSC::ExpressionNode::isBytecodeIntrinsicNode):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseForStatement):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseUnaryExpression):

2016-03-13  Joseph Pecoraro  <pecoraro@apple.com>

        Remove ENABLE(ES6_TEMPLATE_LITERAL_SYNTAX) guards
        https://bugs.webkit.org/show_bug.cgi?id=155417

        Reviewed by Yusuke Suzuki.

        * Configurations/FeatureDefines.xcconfig:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parsePrimaryExpression): Deleted.
        (JSC::Parser<LexerType>::parseMemberExpression): Deleted.

2016-03-13  Konstantin Tokarev  <annulen@yandex.ru>

        Added new port JSCOnly.
        https://bugs.webkit.org/show_bug.cgi?id=154512

        Reviewed by Michael Catanzaro.

        This port allows to build JavaScriptCore engine with minimal
        dependencies.

        * PlatformJSCOnly.cmake: Added.

2016-03-12  Mark Lam  <mark.lam@apple.com>

        http://kangax.github.io/compat-table/esnext/ crashes reliably.
        https://bugs.webkit.org/show_bug.cgi?id=155404

        Reviewed by Yusuke Suzuki.

        constructObjectFromPropertyDescriptor() was incorrectly assuming that either
        both getter and setter will be set or unset.  It did not consider that only one
        of the getter or setter may be set.  This patch fixes that.

        * runtime/ObjectConstructor.h:
        (JSC::constructObjectFromPropertyDescriptor):
        * tests/stress/proxy-with-unbalanced-getter-setter.js: Added.
        (assert):
        (let.handler.defineProperty):
        (i.):
        (i.assert):
        (i.get assert):
        (set assert):

2016-03-12  Brian Burg  <bburg@apple.com>

        When generating Objective-C protocol types, getters for objects need to synthesize a new object instance
        https://bugs.webkit.org/show_bug.cgi?id=155389
        <rdar://problem/25125821>

        Reviewed by Timothy Hatcher.

        Currently, in object property getters for Objective-C protocol types, we use
        a C-style cast of the member's RWIProtocolJSONObject * to the type of the property.
        However, at runtime the class of `self` is going to be RWIProtocolJSONObject *,
        not MemberType *, so any subsequent calls to MemberType properties on the return value
        will fail as the selectors will not be recognized.

        Instead of doing a C-style pointer cast, we need to create a new MemberType object
        that's backed by the InspectorObject retrieved from the parent object by key.
        This requires a new initWithJSONObject initializer for each object protocol type.

        * inspector/scripts/codegen/generate_objc_header.py:
        (ObjCHeaderGenerator._generate_type_interface): Add new declaration.

        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator.generate_type_implementation):
        (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_json_object): Added.
        Forward through to the super class initializer who assigns the underlying InspectorObject.

        (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members):
        Drive-by cleanup to use the more compact [super init] form.

        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator.protocol_to_objc_expression_for_member):
        For property getters of objects, use initWithJSONObject: rather than a C-style cast.

        Rebaseline relevant test results.

        * 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/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:

2016-03-12  Konstantin Tokarev  <annulen@yandex.ru>

        Removed variable names from default constructor declarations.
        https://bugs.webkit.org/show_bug.cgi?id=155397

        Reviewed by Mark Lam.

        They carry no information and generate unused variable warning with GCC
        4.8 in a lot of source files.

        * parser/VariableEnvironment.h:

2016-03-12  Myles C. Maxfield  <mmaxfield@apple.com>

        Delete dead SVG Font code
        https://bugs.webkit.org/show_bug.cgi?id=154718

        Reviewed by Antti Koivisto.

        * Configurations/FeatureDefines.xcconfig:

2016-03-11  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove a few jumps from DFG
        https://bugs.webkit.org/show_bug.cgi?id=155347

        Reviewed by Mark Lam.

        Usually, setting ValueTrue or ValueFalse is set
        by Compare+Or. There are 3 places in DFG with branches instead.

        This patch changes them to the usual pattern.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):

2016-03-11  Saam barati  <sbarati@apple.com>

        [ES6] Make Object.assign spec compliant
        https://bugs.webkit.org/show_bug.cgi?id=155375

        Reviewed by Michael Saboff.

        This is a straight forward implementation of Object.assign
        in the spec.
        https://tc39.github.io/ecma262/#sec-object.assign
        Before, weren't performing all of the specified operations.
        Now, we are.

        * builtins/ObjectConstructor.js:
        (assign):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * tests/es6.yaml:

2016-03-11  Mark Lam  <mark.lam@apple.com>

        Implement Function.name and Function#toString for ES6 class.
        https://bugs.webkit.org/show_bug.cgi?id=155336

        Reviewed by Geoffrey Garen.

        The only thing that the ES6 spec says about toString with regards to class
        objects is:

        "The string representation must have the syntax of a FunctionDeclaration,
        FunctionExpression, GeneratorDeclaration, GeneratorExpression, ClassDeclaration,
        ClassExpression, ArrowFunction, MethodDefinition, or GeneratorMethod depending
        upon the actual characteristics of the object."

        Previously, invoking toString() on a class object will return the function
        source string of the class' constructor function.  This does not conform to the
        spec in that the toString string for a class does not have the syntax of a
        ClassDeclaration or ClassExpression.

        This is now fixed by doing the following:

        1. Added "m_classSource" to FunctionExecutable (and correspondingly to
           UnlinkedFunctionExecutable, FunctionMetadataNode, and ClassExprNode).
           m_classSource is the SourceCode for the code range "class ... { ... }".

           Since the class constructor function is the in memory representation of the
           class object, only class constructor functions will have its m_classSource
           set.  m_classSource will be "null" (by default) for all other functions.
           This is how we know if a FunctionExecutable is for a class.

           Note: FunctionExecutable does not have its own m_classSource.  It always gets
           it from its UnlinkedFunctionExecutable.  This is ok to do because our CodeCache
           currently does not cache UnlinkedFunctionExecutables for class constructors.

        2. The ClassExprNode now tracks the SourceCode range for the class expression.
           This is used to set m_classSource in the UnlinkedFunctionExecutable at
           bytecode generation time, and the FunctionExecutable later at bytecode
           linking time.

        3. Function.prototype.toString() now checks if the function is for a class.
           If so, it returns the string for the class source instead of just the
           function source for the class constructor.

           Note: the class source is static from the time the class was parsed.  This
           can introduces some weirdness at runtime.  Consider the following:

               var v1 = class {}
               v1.toString(); // yields "class {}".

               class c2 extends v1 {}

               c2.__proto__ === v1; // yields true i.e. c2 extends v1.
               c2.toString(); // yields "class c2 extends v1 {}" which is fine.

               v1 = {}; // point v1 to something else now.

               c2.__proto__ === v1; // now yields false i.e. c2 no longer extends v1.
                                    // c2 actually extends the class that v1 used to
                                    // point to, but ...
               c2.toString(); // still yields "class c2 extends v1 {}" which is no longer true.

           It is unclear how we can best implement toString() to avoid this issue.
           The above behavior is how Chrome (Version 51.0.2671.0 canary (64-bit))
           currently implements toString() of a class, and we do the same in this patch.
           In Firefox (45.0), toString() of a class will yield the function source of it
           constructor function, which is not better.

        In this patch, we also added ES6 compliance for Function.name on class objects:

        4. The ClassExprNode now has a m_ecmaName string for tracking the inferred
           name of a class according to the ES6 spec.  The ASTBuilder now mirrors its
           handling of FuncExprNodes to ClassExprNodes in setting the nodes' m_ecmaName
           where relevant.

           The m_ecmaName is later used to set the m_ecmaName of the FunctionExecutable
           of the class constructor, which in turn is used to populate the initial value
           of the Function.name property.

        5. Also renamed some variable names (/m_metadata/metadata/) to be consistent with
           webkit naming convention.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
        (JSC::BytecodeGenerator::emitNewDefaultConstructor):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ClassExprNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createAssignResolve):
        (JSC::ASTBuilder::createYield):
        (JSC::ASTBuilder::createClassExpr):
        (JSC::ASTBuilder::createFunctionExpr):
        (JSC::ASTBuilder::createProperty):
        (JSC::ASTBuilder::makeAssignNode):
        * parser/NodeConstructors.h:
        (JSC::FunctionParameters::FunctionParameters):
        (JSC::BaseFuncExprNode::BaseFuncExprNode):
        (JSC::FuncExprNode::FuncExprNode):
        (JSC::FuncDeclNode::FuncDeclNode):
        (JSC::ArrowFuncExprNode::ArrowFuncExprNode):
        (JSC::ClassDeclNode::ClassDeclNode):
        (JSC::ClassExprNode::ClassExprNode):
        * parser/Nodes.h:
        (JSC::ExpressionNode::isDestructuringNode):
        (JSC::ExpressionNode::isFuncExprNode):
        (JSC::ExpressionNode::isArrowFuncExprNode):
        (JSC::ExpressionNode::isClassExprNode):
        (JSC::ExpressionNode::isCommaNode):
        (JSC::ExpressionNode::isSimpleArray):
        (JSC::ExpressionNode::isAdd):
        * parser/Parser.cpp:
        (JSC::stringForFunctionMode):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseClass):
        * parser/ParserFunctionInfo.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createEmptyLetExpression):
        (JSC::SyntaxChecker::createYield):
        (JSC::SyntaxChecker::createClassExpr):
        (JSC::SyntaxChecker::createFunctionExpr):
        (JSC::SyntaxChecker::createFunctionMetadata):
        (JSC::SyntaxChecker::createArrowFunctionExpr):
        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::FunctionExecutable):
        (JSC::FunctionExecutable::finishCreation):
        * runtime/Executable.h:
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):
        * tests/es6.yaml:

2016-03-11  Commit Queue  <commit-queue@webkit.org>

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

        Broke several ARM tests (Requested by msaboff on #webkit).

        Reverted changeset:

        "[JSC] Add register reuse for ArithAdd of an Int32 and
        constant in DFG"
        https://bugs.webkit.org/show_bug.cgi?id=155164
        http://trac.webkit.org/changeset/197994

2016-03-11  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement Reflect.set without receiver support
        https://bugs.webkit.org/show_bug.cgi?id=155024

        Reviewed by Geoffrey Garen.

        This patch implements Reflect.set.
        The challenge in this patch is Reflect.set requires boolean result of [[Set]],
        this is not propagated in the previous JSC put implementation.

        This patch changes the put and putByIndex signature from `void put(...)` and `void putByIndex(...)` to `bool put(...)` and `bool putByIndex(...)`,
        more consistent style to the ECMA262 spec's [[Set]].

        This patch modifies so many part of WebKit. But almost all the changes are mechanical ones.

        Currently, this patch does not support receiver modification support.
        This will be supported in the subsequent patch[1].

        [1]: https://bugs.webkit.org/show_bug.cgi?id=155294

        * API/JSCallbackObject.h:
        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::put):
        (JSC::JSCallbackObject<Parent>::putByIndex):
        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::put):
        * debugger/DebuggerScope.h:
        * jsc.cpp:
        (WTF::RuntimeArray::put):
        * runtime/ClassInfo.h:
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::put):
        * runtime/ClonedArguments.h:
        * runtime/CustomGetterSetter.cpp:
        (JSC::callCustomSetter):
        * runtime/CustomGetterSetter.h:
        * runtime/GenericArguments.h:
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::put):
        (JSC::GenericArguments<Type>::putByIndex):
        * runtime/GetterSetter.cpp:
        (JSC::callSetter):
        * runtime/GetterSetter.h:
        * runtime/JSArray.cpp:
        (JSC::JSArray::defineOwnProperty):
        (JSC::JSArray::put):
        (JSC::JSArray::push):
        * runtime/JSArray.h:
        * runtime/JSArrayBuffer.cpp:
        (JSC::JSArrayBuffer::put):
        * runtime/JSArrayBuffer.h:
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::put):
        * runtime/JSArrayBufferView.h:
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        (JSC::JSValue::putToPrimitiveByIndex):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::put):
        (JSC::JSValue::putInline):
        (JSC::JSValue::putByIndex):
        * runtime/JSCell.cpp:
        (JSC::JSCell::put):
        (JSC::JSCell::putByIndex):
        * runtime/JSCell.h:
        * runtime/JSDataView.cpp:
        (JSC::JSDataView::put):
        * runtime/JSDataView.h:
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::put):
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSFunction.h:
        * runtime/JSGenericTypedArrayView.h:
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::put):
        (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
        * runtime/JSGlobalLexicalEnvironment.cpp:
        (JSC::JSGlobalLexicalEnvironment::put):
        * runtime/JSGlobalLexicalEnvironment.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::put):
        * runtime/JSGlobalObject.h:
        * runtime/JSLexicalEnvironment.cpp:
        (JSC::JSLexicalEnvironment::put):
        * runtime/JSLexicalEnvironment.h:
        * runtime/JSModuleEnvironment.cpp:
        (JSC::JSModuleEnvironment::put):
        * runtime/JSModuleEnvironment.h:
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::put):
        (JSC::JSModuleNamespaceObject::putByIndex):
        * runtime/JSModuleNamespaceObject.h:
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::instantiateDeclarations):
        * runtime/JSObject.cpp:
        (JSC::JSObject::put):
        (JSC::JSObject::putInlineSlow):
        (JSC::JSObject::putByIndex):
        (JSC::JSObject::putGetter):
        (JSC::JSObject::putSetter):
        (JSC::JSObject::putDirectAccessor):
        (JSC::JSObject::putDirectCustomAccessor):
        (JSC::JSObject::putDirectNonIndexAccessor):
        (JSC::JSObject::putIndexedDescriptor):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
        (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
        (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
        (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
        (JSC::JSObject::putByIndexBeyondVectorLength):
        (JSC::JSObject::putDirectNativeIntrinsicGetter):
        (JSC::JSObject::putDirectNativeFunction):
        (JSC::JSObject::putDirectMayBeIndex):
        (JSC::validateAndApplyPropertyDescriptor):
        * runtime/JSObject.h:
        (JSC::JSObject::putByIndexInline):
        (JSC::JSObject::putDirect):
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::putInline):
        * runtime/JSProxy.cpp:
        (JSC::JSProxy::put):
        (JSC::JSProxy::putByIndex):
        * runtime/JSProxy.h:
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTablePut):
        (JSC::symbolTablePutTouchWatchpointSet):
        (JSC::symbolTablePutInvalidateWatchpointSet):
        (JSC::symbolTablePutWithAttributesTouchWatchpointSet):
        * runtime/Lookup.h:
        (JSC::putEntry):
        (JSC::lookupPut):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performPut):
        (JSC::ProxyObject::put):
        (JSC::ProxyObject::putByIndexCommon):
        (JSC::ProxyObject::putByIndex):
        * runtime/ProxyObject.h:
        * runtime/PutPropertySlot.h:
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectSet):
        * runtime/RegExpConstructor.cpp:
        (JSC::setRegExpConstructorInput):
        (JSC::setRegExpConstructorMultiline):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::defineOwnProperty):
        (JSC::regExpObjectSetLastIndexStrict):
        (JSC::regExpObjectSetLastIndexNonStrict):
        (JSC::RegExpObject::put):
        * runtime/RegExpObject.h:
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::putEntry):
        (JSC::SparseArrayEntry::put):
        * runtime/SparseArrayValueMap.h:
        * runtime/StringObject.cpp:
        (JSC::StringObject::put):
        (JSC::StringObject::putByIndex):
        * runtime/StringObject.h:
        * tests/es6.yaml:
        * tests/modules/namespace.js:
        * tests/stress/reflect-set.js: Added.
        (shouldBe):
        (shouldThrow):
        (receiverCase.object2.set Cocoa):
        (receiverCase):
        (proxyCase):
        (objectCase.set get shouldBe):
        (objectCase.get shouldBe):
        (arrayCase.set get shouldBe):
        (arrayCase.get shouldBe):
        (arrayBufferCase.set get shouldBe):
        (arrayBufferCase.get shouldBe):
        (set get shouldBe):
        (get shouldBe):
        (argumentCase.test1):
        (argumentCase.test2):
        (argumentCase.test3):
        (argumentCase.test4.set get shouldBe):
        (argumentCase.test5.get shouldBe):
        (argumentStrictCase.test1):
        (argumentStrictCase.test2):
        (argumentStrictCase.test3):
        (argumentStrictCase.test4.set get shouldBe):
        (argumentStrictCase.test5.get shouldBe):
        (stringObjectCase.set get shouldBe):
        (stringObjectCase.get shouldBe):
        (customSetter.test1):
        (customSetter.test2):
        (customSetter.test3):
        (customSetter):
        (regExpLastIndex):
        (functionCase.func):

2016-03-10  Brian Burg  <bburg@apple.com>

        Web Inspector: generated initWithPayload: protocol object initializers should recursively decode array and object members
        https://bugs.webkit.org/show_bug.cgi?id=155337
        <rdar://problem/25098357>

        Reviewed by Timothy Hatcher.

        In cases where an object member is itself an object or array, we were
        not calling initWithPayload: on the object member itself. So, this caused
        a runtime error when constructing the outer object because the generated
        code casted the NSDictionary/NSArray into the member's protocol object type.

        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator.payload_to_objc_expression_for_member):
        Do a straightforward call to initWithPayload: for objects. For arrays,
        call a templated helper function which does the same thing. The helper
        is used to make this array decoding fit into a single generated expression.

        Rebaseline relevant test results.

        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:

2016-03-10  Keith Miller  <keith_miller@apple.com>

        Unreviewed, fix Changelog. git merged poorly.

2016-03-10  Keith Miller  <keith_miller@apple.com>

        Unreviewed, fix testapi.

        * API/tests/TypedArrayCTest.cpp:
        (testAccess):
        (testConstructors):
        (forEachTypedArrayType):
        (testTypedArrayCAPI):

2016-03-10  Saam barati  <sbarati@apple.com>

        [ES6] Make RegExp.prototype.toString spec compliant
        https://bugs.webkit.org/show_bug.cgi?id=155341

        Reviewed by Filip Pizlo.

        Before we were directly calling into the flagsString
        function. Instead, we must get the "flags" property
        of the thisObject. This will usually call into the flags
        getter, but not always. Specifically, you can you a Proxy
        to observe this behavior.

        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncToString):
        (JSC::regExpProtoGetterGlobal):
        * tests/es6.yaml:
        * tests/es6/Proxy_internal_get_calls_RegExp.prototype.toString.js: Added.
        (test.get var):
        (test.):
        * tests/stress/regexp-prototype-tostring.js: Added.
        (assert):
        (test):
        (test.get var):
        (test.):
        (let.handler.get switch):
        (let.handler):
        (get test):
        (test.get RegExp):

2016-03-10  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add register reuse for ArithAdd of an Int32 and constant in DFG
        https://bugs.webkit.org/show_bug.cgi?id=155164

        Reviewed by Geoffrey Garen.

        Every "inc" in loop was looking like this:
            move rX, rY
            inc rY
            jo 0x230f4a200580

        This patch add register Reuse to that case to remove
        the extra "move".

        * dfg/DFGOSRExit.h:
        (JSC::DFG::SpeculationRecovery::SpeculationRecovery):
        (JSC::DFG::SpeculationRecovery::immediate):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithAdd):
        * tests/stress/arith-add-with-constant-overflow.js: Added.
        (opaqueAdd):

2016-03-10  Keith Miller  <keith_miller@apple.com>

        Unreviewed, build fix for r197983, hopefully.

        * API/WebKitAvailability.h:

2016-03-10  Keith Miller  <keith_miller@apple.com>

        Typed Arrays have no public facing API
        https://bugs.webkit.org/show_bug.cgi?id=120112

        Reviewed by Geoffrey Garen.

        This patch adds a new C-API (an Obj-C API will follow in the future) for Typed Arrays. The API has two sets of
        functions. One for Typed Arrays and another for Array Buffers. This API is intended to reflect the use of Typed
        Array objects in JS code. There is a method for each of the core TypedArray and Array Buffer methods.
        Originally, we were planning on using a separate non-JS object as the backing store instead of a JS Array Buffer
        but we decide to defer that idea since there was no good CF/NS API that met all the constraints we needed
        (Discussed further below). We also wanted to want until Shared Array Buffers had reached a more finished state
        to see what impact they might have on an API.

        The API has the following Typed Array construction methods:
        1) Create with length (the backing buffer is zero initialized). -- JSObjectMakeTypedArray
        2) Create with an existing pointer and a destructor. -- JSObjectMakeTypedArrayFromBytesNoCopy
        3) Create with an Array Buffer object. -- JSObjectMakeTypedArrayFromArrayBuffer
        4) Create with an Array Buffer object with a given offset and length. -- JSObjectMakeTypedArrayFromArrayBufferWithOffset

        The API has the following functions on Typed Array JSObjectRefs:
        5) Get access to a temporary void* of the backing store's data. -- JSObjectGetTypedArrayBytesPtr
        6) Get the length of a Typed Array object (returns 0 if it is not a Typed Array object). -- JSObjectGetTypedArrayLength
        7) Get the byte length of a Typed Array object (returns 0 if it is not a Typed Array object). -- JSObjectGetTypedArrayByteLength
        8) Get the byte offset of a Typed Array object (returns 0 if it is not a Typed Array object). -- JSObjectGetTypedArrayByteOffset
        9) Get a Typed Array object's Array Buffer  backing store. -- JSObjectGetTypedArrayBuffer

        The API has the following Array Buffer construction method:
        10) Create with an existing pointer and a destructor. -- JSObjectMakeArrayBufferWithBytesNoCopy

        The API has the following functions on Array Buffer JSObjectRefs:
        11) Get access to a temporary void* of the backing store's data. -- JSObjectGetArrayBufferBytesPtr
        12) Get the byte length of an Array Buffer object (returns 0 if it is not an Array Buffer object). -- JSObjectGetArrayBufferByteLength

        The API adds the following new typedefs and enumerations:
        13) A typedef representing the function pointer type used to deallocate byte pointers provided to constructors. -- JSTypedArrayByesDeallocator
        14) An enumeration indicating the Typed Array API type of a JSValueRef. -- JSTypedArrayType

        Finally, The API has the following function to get Typed Array Types:
        15)  Get the Typed Array type of a JS value. -- JSValueGetTypedArrayType

        There are a couple of things to note about these functions. Calling JSObjectGetTypedArrayBytesPtr (5) or
        JSObjectGetArrayBufferBytesPtr (12) will pin and lock the ArrayBuffer's data for the remaining lifetime of that
        ArrayBuffer. This is because, currently, we do not have finalizers for our Array Buffers or Typed Arrays with a
        backing ArrayBuffer and adding one would likely incur a non-trivial cost to GC. Also, we do not have a direct
        way to make a Typed Array from a pointer with an offset as we do not expect using offsets to be a common use
        case of the API.

        While it would have been nice to integrate our backing store with CFData or one of its subclasses, it is not
        possible to force a CFData/CFMutableData to be both writable and have a fixed size/backing store pointer.
        NSData is not writable and CFMutableData can have a fixed pointer if it is allocated with a non-zero capacity
        but there is no way for us to force an existing CFMutableData into this state.

        * API/APIUtils.h: Copied from Source/JavaScriptCore/runtime/ArrayBuffer.cpp.
        (handleExceptionIfNeeded):
        (setException):
        * API/JSBase.h:
        * API/JSObjectRef.cpp:
        (handleExceptionIfNeeded): Deleted.
        * API/JSTypedArray.cpp: Added.
        (toJSTypedArrayType):
        (toTypedArrayType):
        (createTypedArray):
        (JSValueGetTypedArrayType):
        (JSObjectMakeTypedArray):
        (JSObjectMakeTypedArrayWithBytesNoCopy):
        (JSObjectMakeTypedArrayWithArrayBuffer):
        (JSObjectMakeTypedArrayWithArrayBufferAndOffset):
        (JSObjectGetTypedArrayBytesPtr):
        (JSObjectGetTypedArrayLength):
        (JSObjectGetTypedArrayByteLength):
        (JSObjectGetTypedArrayByteOffset):
        (JSObjectGetTypedArrayBuffer):
        (JSObjectMakeArrayBufferWithBytesNoCopy):
        (JSObjectGetArrayBufferBytesPtr):
        (JSObjectGetArrayBufferByteLength):
        * API/JSTypedArray.h: Added.
        * API/JSValueRef.cpp:
        (handleExceptionIfNeeded): Deleted.
        * API/JSValueRef.h:
        * API/JavaScript.h:
        * API/WebKitAvailability.h:
        * API/tests/TypedArrayCTest.cpp: Added.
        (id):
        (freePtr):
        (assertEqualsAsNumber):
        (testAccess):
        (testConstructors):
        (forEachTypedArrayType):
        (testTypedArrayCAPI):
        * API/tests/TypedArrayCTest.h: Added.
        * API/tests/testapi.c:
        (main):
        * CMakeLists.txt:
        * ForwardingHeaders/JavaScriptCore/JSTypedArray.h: Added.
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * PlatformEfl.cmake:
        * PlatformGTK.cmake:
        * runtime/ArrayBuffer.cpp:
        (JSC::ArrayBuffer::transfer):
        * runtime/ArrayBuffer.h:
        (JSC::arrayBufferDestructorNull):
        (JSC::arrayBufferDestructorDefault):
        (JSC::ArrayBufferContents::ArrayBufferContents):
        (JSC::ArrayBufferContents::transfer):
        (JSC::ArrayBuffer::createAdopted):
        (JSC::ArrayBuffer::createFromBytes):
        (JSC::ArrayBuffer::ArrayBuffer):
        (JSC::ArrayBuffer::pinAndLock):
        (JSC::ArrayBufferContents::tryAllocate):
        (JSC::ArrayBufferContents::~ArrayBufferContents):
        * shell/PlatformWin.cmake:

2016-03-10  Saam barati  <sbarati@apple.com>

        [ES6] Instanceof isn't spec compliant when the RHS is a Proxy with a target that is a function
        https://bugs.webkit.org/show_bug.cgi?id=155329

        Reviewed by Mark Lam.

        We use type info flags on the structure to dictate whether or not 
        the RHS of an instanceof is a valid RHS (i.e, a function). The solution
        to make Proxy a valid RHS when the Proxy's target is callable is to have
        two different structures for ProxyObject: one for a non-callable target 
        and one for a callable target.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::moduleRecordStructure):
        (JSC::JSGlobalObject::moduleNamespaceObjectStructure):
        (JSC::JSGlobalObject::proxyObjectStructure):
        (JSC::JSGlobalObject::callableProxyObjectStructure):
        (JSC::JSGlobalObject::proxyRevokeStructure):
        (JSC::JSGlobalObject::wasmModuleStructure):
        * runtime/ProxyConstructor.cpp:
        (JSC::makeRevocableProxy):
        (JSC::constructProxyObject):
        (JSC::ProxyConstructor::getConstructData):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::ProxyObject):
        (JSC::ProxyObject::structureForTarget):
        (JSC::ProxyObject::finishCreation):
        * runtime/ProxyObject.h:
        (JSC::ProxyObject::create):
        (JSC::ProxyObject::createStructure):
        * tests/es6.yaml:
        * tests/stress/proxy-instanceof.js: Added.
        (assert):
        (test):
        (C):
        (test.let.handler.get if):
        (test.let.handler):

2016-03-10  Michael Saboff  <msaboff@apple.com>

        [ES6] RegExp sticky flag should be ignored in String.match when global flag is given
        https://bugs.webkit.org/show_bug.cgi?id=155332

        Reviewed by Saam Barati.

        Removed logic from stringProtoFuncMatch that handles the case where both global and sticky flags are set.

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

2016-03-10  Michael Saboff  <msaboff@apple.com>

        [ES6] Allow RegExp constructor to take pattern from an existing RegExp with new flags
        https://bugs.webkit.org/show_bug.cgi?id=155315

        Reviewed by Saam Barati.

        Changed to comply with section 21.2.3.1, step 5.  Eliminated syntax error.

        In the process, change to get the VM at the top of the function.

        Updated tests accordingly.

        * runtime/RegExpConstructor.cpp:
        (JSC::constructRegExp):
        * tests/es6.yaml: Changed miscellaneous_RegExp_constructor_can_alter_flags.js to normal.
        * tests/mozilla/mozilla-tests.yaml: Disabled ecma_3/RegExp/15.10.4.1-5-n.js as it checks
        for the old behavior of throwing a syntax error.

2016-03-10  Saam barati  <sbarati@apple.com>

        [ES6] Make ToPropertyDescriptor spec compliant
        https://bugs.webkit.org/show_bug.cgi?id=155313

        Reviewed by Mark Lam.

        We were performing HasProperty(.) and Get(.) in the same operation.
        This isn't valid according to the spec and it's user observable
        behavior with Proxy. This patch fixes ToPropertyDescriptor to use
        two distinct operations for HasProperty(.) and Get(.).

        * runtime/ObjectConstructor.cpp:
        (JSC::ownEnumerablePropertyKeys):
        (JSC::toPropertyDescriptor):
        * tests/es6.yaml:
        * tests/stress/to-property-key-correctness.js: Added.
        (assert):
        (test):
        (test.let.handler.has):
        (arrayEq):
        (let.handler.has):
        (let.target):
        (set get let):

2016-03-10  Brian Burg  <bburg@apple.com>

        Web Inspector: report the underlying parser error message when JSON parsing fails
        https://bugs.webkit.org/show_bug.cgi?id=155303
        <rdar://problem/25088939>

        Reviewed by Timothy Hatcher.

        * inspector/scripts/generate-inspector-protocol-bindings.py:
        (generate_from_specification.load_specification):
        Stringize the underlying error so we can see what it says.

2016-03-09  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: JavaScript Heap Allocations Timeline
        https://bugs.webkit.org/show_bug.cgi?id=155287
        <rdar://problem/25078088>

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype._describe):
        (InjectedScript.prototype._nodeDescription):
        Provide the nicer node preview more often.

2016-03-10  Saam barati  <sbarati@apple.com>

        Assignment to new.target should be an early error
        https://bugs.webkit.org/show_bug.cgi?id=151148

        Reviewed by Mark Lam.

        This patch makes it so that any form of assignment to new.target
        is an early syntax error.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createNewTargetExpr):
        (JSC::ASTBuilder::isNewTarget):
        (JSC::ASTBuilder::createResolve):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseUnaryExpression):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createThisExpr):
        (JSC::SyntaxChecker::createSuperExpr):
        (JSC::SyntaxChecker::createNewTargetExpr):
        (JSC::SyntaxChecker::isNewTarget):
        (JSC::SyntaxChecker::createResolve):
        (JSC::SyntaxChecker::createObjectLiteral):
        * tests/es6.yaml:
        * tests/stress/new-target-syntax-errors.js: Added.
        (shouldBeSyntaxError):
        (shouldNotBeSyntaxError):
        * tests/stress/new-target.js:
        (Constructor):
        (doWeirdThings):
        (noAssign): Deleted.
        (catch): Deleted.

2016-03-08  Skachkov Oleksandr  <gskachkov@gmail.com>

        How we load new.target in arrow functions is broken
        https://bugs.webkit.org/show_bug.cgi?id=155153

        Reviewed by Saam Barati.

        Fixed not correct approach of caching new.target. In current patch was added code feature
        flag that shows that current function is using new.target, when generating byte code an arrow 
        function we are loading new.target value to its register from arrow function lexical environment. 

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::newTarget):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createNewTargetExpr):
        (JSC::ASTBuilder::usesNewTarget):
        * parser/Nodes.h:
        (JSC::ScopeNode::usesNewTarget):
        * parser/ParserModes.h:
        * tests/stress/arrowfunction-lexical-bind-newtarget.js:

2016-03-09  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Get a RemoteObject or ObjectPreview from HeapSnapshot Object Identifier
        https://bugs.webkit.org/show_bug.cgi?id=155264
        <rdar://problem/25070716>

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScript.h:
        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::functionDetails):
        (Inspector::InjectedScript::previewValue):
        New InjectedScript methods for building Debugger.FunctionDetails
        or Runtime.ObjectPreview protocol objects from a JSValue.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype.previewValue):
        (InjectedScript.prototype.functionDetails):
        (InjectedScript.prototype.getFunctionDetails):
        (InjectedScript.RemoteObject.prototype._isPreviewableObjectInternal):
        (InjectedScript.RemoteObject.prototype._createObjectPreviewForValue): Deleted.
        (InjectedScript.RemoteObject.prototype._appendEntryPreviews): Deleted.
        Share code around creating function details or object preview objects.

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::nodeForHeapObjectIdentifier):
        (Inspector::InspectorHeapAgent::getPreview):
        (Inspector::InspectorHeapAgent::getRemoteObject):
        * inspector/agents/InspectorHeapAgent.h:
        * inspector/protocol/Heap.json:
        New protocol methods that go from heap object identifier to a
        remote object or some kind of preview.

        * inspector/scripts/codegen/generator.py:
        Allow runtime casts for ObjectPreview.

2016-03-09  Andy VanWagoner  <thetalecrafter@gmail.com>

        [INTL] Intl Constructors not web compatible with Object.create usage
        https://bugs.webkit.org/show_bug.cgi?id=153679

        Reviewed by Darin Adler.

        Add workaround for initializing NumberFormat and DateTimeFormat objects
        using Object.create followed by constructor.call. This is necessary for
        backwards compatibility with libraries relying on v1 behavior of Intl
        constructors.

        Collator does not get the workaround, since polyfills do not include it,
        and there are not any known instances of v2 incompatible libraries.

        The workaround involves checking for an object that inherits from the
        *Format constructor, but was not actually initialized with that type. A
        substitute instance is created and attached to the object using a private
        name. The prototype functions then check for the private property to use
        in place of the original object.

        Since this behavior is not part of the v2 spec, it should be removed as
        soon as the incompatible behavior is no longer in common use.

        * runtime/CommonIdentifiers.h:
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::callIntlDateTimeFormat):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::callIntlNumberFormat):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):

2016-03-09  Saam barati  <sbarati@apple.com>

        Add proper JSON.stringify support for Proxy when the target is an array
        https://bugs.webkit.org/show_bug.cgi?id=155180

        Reviewed by Darin Adler.

        This patch makes the following type of program true:
        `JSON.stringify(new Proxy([25], {})) === "[25]"`

        We need to change the JSON stringifier to use the IsArray test
        in section 7.2.2 of ES6 spec instead of the JSC inherits(JSArray::info())
        test.

        This patch also adds tests for general JSON.stringify support
        of Proxy.

        * runtime/ArrayConstructor.cpp:
        (JSC::arrayConstructorIsArray):
        (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
        * runtime/ArrayConstructor.h:
        (JSC::isArray):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Holder::object):
        (JSC::Stringifier::appendStringifiedValue):
        (JSC::Stringifier::startNewLine):
        (JSC::Stringifier::Holder::Holder):
        * tests/es6.yaml:
        * tests/stress/proxy-json.js: Added.
        (assert):
        (test):

2016-03-09  Saam Barati  <sbarati@apple.com>

        ES6: Implement lexical scoping for function definitions in strict mode
        https://bugs.webkit.org/show_bug.cgi?id=152844

        Reviewed by Geoffrey Garen.

        This patch implements block scoping for function definitions
        in strict mode. The implementation works as follows:
        
        - If we're in sloppy mode, function declarations work exactly
          as they did before this patch. I.e, function declarations are hoisted
          and declared like "var" variables.
        
        - If you're in strict mode and at the top of a function scope or program
          scope, function declarations still work like they used to. They are defined
          like "var" variables. This is necessary for backwards compatibility
          because ES5 strict mode allowed duplicate function declarations at the
          top-most scope of a program/function.
        
        - If you're in strict mode and inside a block statement or a switch statement,
          function declarations are now block scoped. All function declarations within
          a block are hoisted to the beginning of the block. They are not hoisted out of the 
          block like they are in sloppy mode. This allows for the following types of
          programs:
          ```
          function foo() {
              function bar() { return 20; }
              {
                  function bar() { return 30; }
                  bar(); // 30
              }
              bar(); // 20
          }
          ```

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::instantiateLexicalVariables):
        (JSC::BytecodeGenerator::emitPrefillStackTDZVariables):
        (JSC::BytecodeGenerator::pushLexicalScope):
        (JSC::BytecodeGenerator::pushLexicalScopeInternal):
        (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
        (JSC::BytecodeGenerator::popLexicalScope):
        (JSC::BytecodeGenerator::liftTDZCheckIfPossible):
        (JSC::BytecodeGenerator::pushTDZVariables):
        (JSC::BytecodeGenerator::getVariablesUnderTDZ):
        (JSC::BytecodeGenerator::emitNewRegExp):
        (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
        (JSC::BytecodeGenerator::emitNewFunctionExpression):
        (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
        * bytecompiler/BytecodeGenerator.h:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createSourceElements):
        (JSC::ASTBuilder::features):
        (JSC::ASTBuilder::numConstants):
        (JSC::ASTBuilder::createFuncDeclStatement):
        (JSC::ASTBuilder::createClassDeclStatement):
        (JSC::ASTBuilder::createBlockStatement):
        (JSC::ASTBuilder::createTryStatement):
        (JSC::ASTBuilder::createSwitchStatement):
        (JSC::ASTBuilder::Scope::Scope):
        (JSC::ASTBuilder::funcDeclarations): Deleted.
        * parser/NodeConstructors.h:
        (JSC::CaseBlockNode::CaseBlockNode):
        (JSC::SwitchNode::SwitchNode):
        (JSC::BlockNode::BlockNode):
        * parser/Nodes.cpp:
        (JSC::ScopeNode::ScopeNode):
        (JSC::ScopeNode::singleStatement):
        (JSC::ProgramNode::ProgramNode):
        (JSC::ModuleProgramNode::ModuleProgramNode):
        (JSC::EvalNode::EvalNode):
        (JSC::FunctionNode::FunctionNode):
        (JSC::VariableEnvironmentNode::VariableEnvironmentNode):
        * parser/Nodes.h:
        (JSC::VariableEnvironmentNode::VariableEnvironmentNode):
        (JSC::VariableEnvironmentNode::lexicalVariables):
        (JSC::VariableEnvironmentNode::functionStack):
        (JSC::ScopeNode::captures):
        (JSC::ScopeNode::varDeclarations):
        (JSC::ScopeNode::neededConstants):
        (JSC::ProgramNode::startColumn):
        (JSC::ProgramNode::endColumn):
        (JSC::EvalNode::startColumn):
        (JSC::EvalNode::endColumn):
        (JSC::ModuleProgramNode::startColumn):
        (JSC::ModuleProgramNode::endColumn):
        (JSC::ScopeNode::functionStack): Deleted.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::didFinishParsing):
        (JSC::Parser<LexerType>::parseStatementListItem):
        (JSC::Parser<LexerType>::parseSwitchStatement):
        (JSC::Parser<LexerType>::parseBlockStatement):
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::getMetadata):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        * parser/Parser.h:
        (JSC::Scope::declareVariable):
        (JSC::Scope::declareFunction):
        (JSC::Scope::appendFunction):
        (JSC::Scope::takeFunctionDeclarations):
        (JSC::Scope::declareLexicalVariable):
        (JSC::Parser::currentVariableScope):
        (JSC::Parser::currentLexicalDeclarationScope):
        (JSC::Parser::currentFunctionScope):
        (JSC::Parser::pushScope):
        (JSC::Parser::popScopeInternal):
        (JSC::Parser::declareVariable):
        (JSC::Parser::declareFunction):
        (JSC::Parser::hasDeclaredVariable):
        (JSC::Parser::isFunctionMetadataNode):
        (JSC::Parser<LexerType>::parse):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createFuncDeclStatement):
        (JSC::SyntaxChecker::createClassDeclStatement):
        (JSC::SyntaxChecker::createBlockStatement):
        (JSC::SyntaxChecker::createExprStatement):
        (JSC::SyntaxChecker::createIfStatement):
        (JSC::SyntaxChecker::createContinueStatement):
        (JSC::SyntaxChecker::createTryStatement):
        (JSC::SyntaxChecker::createSwitchStatement):
        (JSC::SyntaxChecker::createWhileStatement):
        (JSC::SyntaxChecker::createWithStatement):
        (JSC::SyntaxChecker::createDoWhileStatement):
        * parser/VariableEnvironment.h:
        (JSC::VariableEnvironmentEntry::isExported):
        (JSC::VariableEnvironmentEntry::isImported):
        (JSC::VariableEnvironmentEntry::isImportedNamespace):
        (JSC::VariableEnvironmentEntry::isFunction):
        (JSC::VariableEnvironmentEntry::setIsCaptured):
        (JSC::VariableEnvironmentEntry::setIsConst):
        (JSC::VariableEnvironmentEntry::setIsExported):
        (JSC::VariableEnvironmentEntry::setIsImported):
        (JSC::VariableEnvironmentEntry::setIsImportedNamespace):
        (JSC::VariableEnvironmentEntry::setIsFunction):
        (JSC::VariableEnvironmentEntry::clearIsVar):
        (JSC::VariableEnvironment::VariableEnvironment):
        (JSC::VariableEnvironment::begin):
        (JSC::VariableEnvironment::end):
        * tests/es6.yaml:
        * tests/stress/block-scoped-function-declarations.js: Added.
        (assert):
        (test):
        (f.foo.bar):
        (f.foo.):
        (f.foo):
        (f):
        (assert.foo.):
        (assert.foo):
        (assert.foo.foo):
        (assert.foo.bar):
        (assert.foo.switch.case.1):
        (assert.foo.switch.case.2):
        (assert.foo.switch.foo):
        (assert.foo.switch.bar):

2016-03-09  Saam barati  <sbarati@apple.com>

        Array.isArray support for Proxy
        https://bugs.webkit.org/show_bug.cgi?id=155179

        Reviewed by Mark Lam.

        This patch implements Array.isArray to be compliant
        with the ES6 spec. Specifically, it needs to interface
        properly with Proxy arguments.
        https://tc39.github.io/ecma262/#sec-isarray

        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::getCallData):
        (JSC::arrayConstructorIsArray):
        (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
        * runtime/ArrayPrototype.cpp:
        (JSC::speciesConstructArray):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::revoke):
        (JSC::ProxyObject::isRevoked):
        (JSC::ProxyObject::visitChildren):
        * runtime/ProxyObject.h:
        (JSC::ProxyObject::target):
        (JSC::ProxyObject::handler):
        * tests/es6.yaml:
        * tests/stress/proxy-is-array.js: Added.
        (assert):
        (test):

2016-03-09  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Fix the ARM64 MacroAssembler after r197816
        https://bugs.webkit.org/show_bug.cgi?id=155268

        Reviewed by Mark Lam.

        The patch tries to generate instructions that do not exist,
        causing quite fun stuff at runtime.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::load8):
        (JSC::MacroAssemblerARM64::store16):
        (JSC::MacroAssemblerARM64::store8):

2016-03-09  Commit Queue  <commit-queue@webkit.org>

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

        "Crashes some JSC tests" (Requested by mlam on #webkit).

        Reverted changeset:

        "Add dumping of function expression names in CodeBlock
        bytecode dump."
        https://bugs.webkit.org/show_bug.cgi?id=155248
        http://trac.webkit.org/changeset/197873

2016-03-09  Oliver Hunt  <oliver@apple.com>

        Fix old iOS

        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):

2016-03-09  Oliver Hunt  <oliver@apple.com>

        Wincairo buildfix
        https://bugs.webkit.org/show_bug.cgi?id=155245

        Reviewed by Mark Lam.

        Fix up exports for a few symbols

        * jit/ExecutableAllocator.h:
        * jit/ExecutableAllocatorFixedVMPool.cpp:

2016-03-09  Mark Lam  <mark.lam@apple.com>

        Add dumping of function expression names in CodeBlock bytecode dump.
        https://bugs.webkit.org/show_bug.cgi?id=155248

        Reviewed by Filip Pizlo.

        Because ...
        [  19] new_func_exp      loc5, loc3, f0:foo

        ... is more informative than
        [  19] new_func_exp      loc5, loc3, f0

        Anonymous functions will be dumped as <anon>.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpFunctionExpr):
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/CodeBlock.h:

2016-03-09  Michael Saboff  <msaboff@apple.com>

        [ES6] Implement RegExp sticky flag and related functionality
        https://bugs.webkit.org/show_bug.cgi?id=155177

        Reviewed by Saam Barati.

        Implemented the ES6 RegExp sticky functionality.

        There are two main behavior changes when the sticky flag is specified.
        1) Matching starts at lastIndex and lastIndex is updated after the match.
        2) The regular expression is only matched from the start position in the string.
        See ES6 section 21.2.5.2.2 for details.

        Changed both the Yarr interpreter and jit to not loop to the next character for sticky RegExp's.
        Updated RegExp exec and match, and stringProtoFuncMatch to handle lastIndex changes.

        Restructured the way flags are passed to and through YarrPatterns to use RegExpFlags instead of
        individual bools.

        Updated tests for 'y' flag and new behavior.

        * bytecode/CodeBlock.cpp:
        (JSC::regexpToSourceString):
        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::findMagicComment):
        * runtime/CommonIdentifiers.h:
        * runtime/RegExp.cpp:
        (JSC::regExpFlags):
        (JSC::RegExpFunctionalTestCollector::outputOneTest):
        (JSC::RegExp::finishCreation):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/RegExp.h:
        * runtime/RegExpKey.h:
        * runtime/RegExpObjectInlines.h:
        (JSC::RegExpObject::execInline):
        (JSC::RegExpObject::matchInline):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncCompile):
        (JSC::flagsString):
        (JSC::regExpProtoGetterMultiline):
        (JSC::regExpProtoGetterSticky):
        (JSC::regExpProtoGetterUnicode):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncMatch):
        * tests/es6.yaml:
        * tests/stress/static-getter-in-names.js:
        (shouldBe):
        * yarr/RegularExpression.cpp:
        (JSC::Yarr::RegularExpression::Private::compile):
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::tryConsumeBackReference):
        (JSC::Yarr::Interpreter::matchAssertionBOL):
        (JSC::Yarr::Interpreter::matchAssertionEOL):
        (JSC::Yarr::Interpreter::matchAssertionWordBoundary):
        (JSC::Yarr::Interpreter::matchDotStarEnclosure):
        (JSC::Yarr::Interpreter::matchDisjunction):
        (JSC::Yarr::Interpreter::Interpreter):
        (JSC::Yarr::ByteCompiler::atomPatternCharacter):
        * yarr/YarrInterpreter.h:
        (JSC::Yarr::BytecodePattern::BytecodePattern):
        (JSC::Yarr::BytecodePattern::estimatedSizeInBytes):
        (JSC::Yarr::BytecodePattern::ignoreCase):
        (JSC::Yarr::BytecodePattern::multiline):
        (JSC::Yarr::BytecodePattern::sticky):
        (JSC::Yarr::BytecodePattern::unicode):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::matchCharacterClass):
        (JSC::Yarr::YarrGenerator::jumpIfCharNotEquals):
        (JSC::Yarr::YarrGenerator::generateAssertionBOL):
        (JSC::Yarr::YarrGenerator::generateAssertionEOL):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed):
        (JSC::Yarr::YarrGenerator::generateDotStarEnclosure):
        (JSC::Yarr::YarrGenerator::backtrack):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
        (JSC::Yarr::YarrPatternConstructor::atomPatternCharacter):
        (JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets):
        (JSC::Yarr::YarrPatternConstructor::optimizeBOL):
        (JSC::Yarr::YarrPattern::compile):
        (JSC::Yarr::YarrPattern::YarrPattern):
        * yarr/YarrPattern.h:
        (JSC::Yarr::YarrPattern::reset):
        (JSC::Yarr::YarrPattern::nonwordcharCharacterClass):
        (JSC::Yarr::YarrPattern::ignoreCase):
        (JSC::Yarr::YarrPattern::multiline):
        (JSC::Yarr::YarrPattern::sticky):
        (JSC::Yarr::YarrPattern::unicode):

2016-03-09  Mark Lam  <mark.lam@apple.com>

        FunctionExecutable::ecmaName() should not be based on inferredName().
        https://bugs.webkit.org/show_bug.cgi?id=155203

        Reviewed by Michael Saboff.

        The ES6 rules for how a function name should be inferred closely matches JSC's
        implementation with one exception:
            var o = {}
            o.foo = function() {}

        JSC's inferredName for o.foo would be "foo".
        ES6 specifies that o.foo.name is "".

        The fix is to add a distinct FunctionExecutable::ecmaName() which applies the ES6
        rules for inferring the initial value of Function.name.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createAssignResolve):
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createProperty):
        (JSC::ASTBuilder::makeAssignNode):
        * parser/Nodes.h:
        * runtime/Executable.h:
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::reifyName):
        * tests/es6.yaml:

2016-03-09  Michael Saboff  <msaboff@apple.com>

        Harden JSC Root element functions from bad values
        https://bugs.webkit.org/show_bug.cgi?id=155234

        Reviewed by Saam Barati.

        Changed jsCast() to jsDynamicCast() in Root related function to protect against being
        called with non-Root arguments.

        * jsc.cpp:
        (functionCreateElement):
        (functionGetElement):
        (functionSetElementRoot):

2016-03-09  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Pick how to OSR Enter to FTL at runtime instead of compile time
        https://bugs.webkit.org/show_bug.cgi?id=155217

        Reviewed by Filip Pizlo.

        This patch addresses 2 types of problems with tiering up to FTL
        with OSR Entry in a loop:
        -When there are nested loops, it is generally valuable to enter
         an outer loop rather than an inner loop.
        -When tiering up at a point that cannot OSR Enter, we are at
         the mercy of the outer loop frequency to compile the right
         entry point.

        The first case is significant in the test "gaussian-blur".
        That test has 4 nested loops. When we have an OSR Entry,
        the analysis phases have to be pesimistic where we enter:
        we do not really know what constraint can be proven from
        the DFG code that was running.

        In "gaussian-blur", integer-range analysis removes pretty
        much all overflow checks in the inner loops of where we entered.
        The more outside we enter, the better code we generate.

        Since we spend the most iterations in the inner loop, we naturally
        tend to OSR Enter into the 2 most inner loops, making the most
        pessimistic assumptions.

        To avoid such problems, I changed how we decide where to OSR Enter.
        Previously, the last CheckTierUpAndOSREnter to cross the threshold
        was where we take the entry point for FTL.

        What happens now is that the entry point is not decied when
        compiling the CheckTierUp variants. Instead, all the information
        we need is gathered during compilation and keept on the JITCode
        to be used at runtime.

        When we try to tier up and decide to OSR Enter, we use the information
        we have to pick a good outer loop for OSR Entry.

        Now the problem is outer loop do not CheckTierUpAndOSREnter often,
        wasting several miliseconds before entering the newly compiled FTL code.

        To solve that, every CheckTierUpAndOSREnter has its own trigger that
        bypass the counter. When the FTL Code is compiled, the trigger is set
        and we enter through the right CheckTierUpAndOSREnter immediately.

        ---

        This new mechanism also solves a problem of ai-astar.
        When we try to tier up in ai-astar, we had nothing to compile until
        the outer loop is reached.

        To make sure we reached the CheckTierUpAndOSREnter in a reasonable time,
        we had CheckTierUpWithNestedTriggerAndOSREnter with a special trigger.

        With the new mechanism, we can do much better:
        -When we keep hitting CheckTierUpInLoop, we now have all the information
         we need to already start compiling the outer loop.
         Instead of waiting for the outer loop to be reached a few times, we compile
         it as soon as the inner loop is hammering CheckTierUpInLoop.
        -With the new triggers, the very next time we hit the outer loop, we OSR Enter.

        This allow us to compile what we need sooner and enter sooner.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize): Deleted.
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC): Deleted.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): Deleted.
        * dfg/DFGJITCode.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::JITCompiler):
        (JSC::DFG::JITCompiler::compileEntryExecutionFlag):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPlan.h:
        (JSC::DFG::Plan::canTierUpAndOSREnter):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate): Deleted.
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute): Deleted.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Deleted.
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        (JSC::DFG::TierUpCheckInjectionPhase::buildNaturalLoopToLoopHintMap):
        (JSC::DFG::TierUpCheckInjectionPhase::findLoopsContainingLoopHintWithoutOSREnter): Deleted.
        * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
        (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
        * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:

2016-03-08  Filip Pizlo  <fpizlo@apple.com>

        DFG should be able to constant-fold strings
        https://bugs.webkit.org/show_bug.cgi?id=155200

        Reviewed by Geoffrey Garen.

        This adds constant-folding of string1 + string2 and string.length. The actual folding
        rule is easy, but there are some gotchas.

        The problem is that the DFG cannot allocate new JSString objects until we are on the
        main thread. So, DFG IR must have a node for a JSValue string constant that hasn't been
        created yet - i.e. it doesn't have any concrete JSValue bits yet.

        We have the ability to speak of such things, using LazyJSValue. But that's a class, not
        a node type. This patch now adds a node type, LazyJSConstant, which is a Node that holds
        a LazyJSValue.

        This puts us in a weird situation: AI uses JSValue to represent constants. It would take
        a lot of work to change it to use LazyJSValue. So, this implements the constant folding
        in StrengthReductionPhase. I created a bug and put a FIXME about moving these rules into
        AI.

        OTOH, our experience in B3 shows that constant folding in strength reduction is quite
        nice. It would totally make sense to have strength reduction have constant folding rules
        that mirror the rules in AI, or to factor out the AI constant folding rules, the same
        way that B3 factors out those rules into Value methods.

        Another issue is how to represent the cumulative result of possibly many foldings. I
        initially considered adding LazyJSValue kinds that represented concatenation. Folding
        the concatenation to a constant meand that this constant was actually a LazyJSValue that
        represented the concatenation of two other things. But this would get super messy if we
        wanted to fold an operation that uses the results of another folded operation.

        So, the JIT thread folds string operations by creating a WTF::String that contains the
        result. The DFG::Graph holds a +1 on the underlying StringImpl, so we can pass the
        StringImpl* around without reference counting. The LazyJSValue now has a special kind
        that means: we created this StringImpl* on the JIT thread, and once the JIT is done, we
        will relinquish ownership of it. LazyJSValue has some magic to emit code for these
        to-be-created-JSStrings while also transferring ownership of the StringImpl from the JIT
        thread to the main thread and registering the JSString with the GC.

        This just implements folding for concatenation and GetArrayLength. It's just a proof of
        concept for evil things I want to do later.

        This change is a 2.5x speed-up on the string concatenation microbenchmarks I added in
        this patch.

        * 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/DFGFrozenValue.cpp:
        (JSC::DFG::FrozenValue::emptySingleton):
        (JSC::DFG::FrozenValue::tryGetString):
        (JSC::DFG::FrozenValue::dumpInContext):
        * dfg/DFGFrozenValue.h:
        (JSC::DFG::FrozenValue::strength):
        * dfg/DFGGraph.h:
        * dfg/DFGLazyJSValue.cpp:
        (JSC::DFG::LazyJSValue::newString):
        (JSC::DFG::LazyJSValue::getValue):
        (JSC::DFG::equalToStringImpl):
        (JSC::DFG::LazyJSValue::tryGetStringImpl):
        (JSC::DFG::LazyJSValue::tryGetString):
        (JSC::DFG::LazyJSValue::strictEqual):
        (JSC::DFG::LazyJSValue::switchLookupValue):
        (JSC::DFG::LazyJSValue::emit):
        (JSC::DFG::LazyJSValue::dumpInContext):
        * dfg/DFGLazyJSValue.h:
        (JSC::DFG::LazyJSValue::LazyJSValue):
        (JSC::DFG::LazyJSValue::knownStringImpl):
        (JSC::DFG::LazyJSValue::kind):
        (JSC::DFG::LazyJSValue::tryGetValue):
        (JSC::DFG::LazyJSValue::character):
        (JSC::DFG::LazyJSValue::stringImpl):
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::convertToIdentityOn):
        (JSC::DFG::Node::convertToLazyJSConstant):
        (JSC::DFG::Node::convertToPutHint):
        (JSC::DFG::Node::convertToPutClosureVarHint):
        (JSC::DFG::Node::tryGetString):
        (JSC::DFG::Node::promotedLocationDescriptor):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToConstant):
        (JSC::DFG::Node::convertToConstantStoragePointer):
        (JSC::DFG::Node::castConstant):
        (JSC::DFG::Node::hasLazyJSValue):
        (JSC::DFG::Node::lazyJSValue):
        (JSC::DFG::Node::initializationValueForActivation):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileSetRegExpObjectLastIndex):
        (JSC::DFG::SpeculativeJIT::compileLazyJSConstant):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileInt52Constant):
        (JSC::FTL::DFG::LowerDFGToB3::compileLazyJSConstant):
        (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep):

2016-03-08  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Memory Timeline should show MemoryPressure events
        https://bugs.webkit.org/show_bug.cgi?id=155158
        <rdar://problem/25026610>

        Reviewed by Brian Burg.

        * inspector/protocol/Memory.json:

2016-03-08  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Add Heap domain start/stop tracking commands
        https://bugs.webkit.org/show_bug.cgi?id=155190

        Reviewed by Brian Burg.

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::willDestroyFrontendAndBackend):
        (Inspector::InspectorHeapAgent::startTracking):
        (Inspector::InspectorHeapAgent::stopTracking):
        * inspector/agents/InspectorHeapAgent.h:
        * inspector/protocol/Heap.json:

2016-03-08  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Add a way to create a Heap Snapshot
        https://bugs.webkit.org/show_bug.cgi?id=155188

        Reviewed by Brian Burg.

        * inspector/agents/InspectorHeapAgent.h:
        * inspector/protocol/Heap.json:
        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::snapshot):
        Take a heap snapshot and return the JSON string result.

        * inspector/protocol/Debugger.json:
        Remove unused optional inferredName. Our displayName would be inferred.

2016-03-08  Oliver Hunt  <oliver@apple.com>

        Fix ios bot build.

        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):

2016-03-08  Mark Lam  <mark.lam@apple.com>

        Implement Function.name support for getters/setters and inferring name of function properties.
        https://bugs.webkit.org/show_bug.cgi?id=154865

        Rubber-stamped by Joseph Pecoraro.

        Follow up to the fix for this bug: adding a few small clean-ups for issues Joe
        pointed out in the bug.

        * runtime/JSBoundSlotBaseFunction.cpp:
        (JSC::JSBoundSlotBaseFunction::create):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitiveByIndex):

2016-03-08  Oliver Hunt  <oliver@apple.com>

        Start moving to separated writable and executable mappings in the JIT
        https://bugs.webkit.org/show_bug.cgi?id=155178

        Reviewed by Fil Pizlo.

        Start moving to a separate writable and executable heap for the various
        JITs.

        As part of our work to harden the JIT against various attacks, we're
        moving away from our current RWX heap and on to using separate RW and X
        mappings. This means that simply leaking the location of the executable
        mapping is not sufficient to compromise JSC, so we can continue to
        use direct executable pointers in our GC objects (which we need for
        performance), but keep the writable pointer in only a single location
        so that we are less likely to leak the address. To further obscure the
        address of the writable region we place it in an execute only region
        of memory so that it is not possible to read the location from 
        anywhere. That means an attacker must have at least partial control
        of PC (to call jitMemCopy) before they can start to attack the JIT.

        This work is initially ARM64 only, as we use as the jitMemCopy is
        currently specific to that platform's calling conventions and layout.
        We're just landing it in the current form so that we can at least
        ensure it doesn't regress.

        * Configurations/FeatureDefines.xcconfig:
        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::ldp):
        (JSC::ARM64Assembler::ldnp):
        (JSC::ARM64Assembler::fillNops):
        (JSC::ARM64Assembler::stp):
        (JSC::ARM64Assembler::stnp):
        (JSC::ARM64Assembler::replaceWithJump):
        (JSC::ARM64Assembler::replaceWithLoad):
        (JSC::ARM64Assembler::replaceWithAddressComputation):
        (JSC::ARM64Assembler::setPointer):
        (JSC::ARM64Assembler::repatchInt32):
        (JSC::ARM64Assembler::repatchCompact):
        (JSC::ARM64Assembler::linkJumpOrCall):
        (JSC::ARM64Assembler::linkCompareAndBranch):
        (JSC::ARM64Assembler::linkConditionalBranch):
        (JSC::ARM64Assembler::linkTestAndBranch):
        (JSC::ARM64Assembler::loadStoreRegisterPairOffset):
        (JSC::ARM64Assembler::loadStoreRegisterPairNonTemporal):
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::copyCompactAndLinkCode):
        (JSC::LinkBuffer::allocate):
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::LinkBuffer):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::sub64):
        (JSC::MacroAssemblerARM64::load64):
        (JSC::MacroAssemblerARM64::loadPair64):
        (JSC::MacroAssemblerARM64::loadPair64WithNonTemporalAccess):
        (JSC::MacroAssemblerARM64::load8):
        (JSC::MacroAssemblerARM64::store64):
        (JSC::MacroAssemblerARM64::storePair64):
        (JSC::MacroAssemblerARM64::storePair64WithNonTemporalAccess):
        (JSC::MacroAssemblerARM64::store8):
        (JSC::MacroAssemblerARM64::branchAdd64):
        (JSC::MacroAssemblerARM64::branchSub64):
        * jit/ExecutableAllocator.h:
        (JSC::performJITMemcpy):
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
        (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
        (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:

2016-03-08  Mark Lam  <mark.lam@apple.com>

        Implement Function.name support for getters/setters and inferring name of function properties.
        https://bugs.webkit.org/show_bug.cgi?id=154865

        Reviewed by Geoffrey Garen.

        1. toString() no longer uses the value of Function.name as the name of the
           function in the returned string, because ...

            i. Function.name is supposed to be configurable.  Hence, it can be made
               writable and can be set to any JSValue, or deleted.
           ii. Function.prototype.toString() is supposed to produce a string that can be
               eval'ed.  Hence, for JS functions, the function name in the produced
               string must be a legal function name (and not some arbitrary value set in
               Function.name).  For example, while a number is a legal value for
               Function.name, it is not legal as the function name in the toString()
               string.

           Instead, we'll always use the original name from the JS source that the
           function was parsed from.

        2. JSFunction::name() now always return the original name, not the value of
           the Function.name property.  As a result, it also no longer needs an
           ExecState* arg.

           If the original name is an empty string, JSFunction::name() will use the
           inferred name.

        3. For JS functions, the original name can be attained from their
           FunctionExecutable object.

           For host/native functions (which do not have a FunctionExecutable), we get the
           "original" name from its NativeExecutable.

        4. The m_hostFunctionStubMap now keys its NativeExecutable pointers using the
           original name, in addition to the native function and constructor pointers.

           This is needed because we want a different NativeExecutable for functions with
           a different name (to satisfy (3) above).

        5. Changed JSBoundFunction to store the name of its bound function in its
           NativeExecutable.  This will later be used to generate the toString() string.
           It's Function.name value is eagerly initialized at construction time.

        6. Function.name for getters/setters are now prefixed with "get"/"set".
           This was done both for the JSBoundSlotBaseFunctions and JS definable get/set
           functions.

        7. Added InternalFunction::m_originalName so that we can use it to generate the
           toString() string.  We're storing it as a JSString instead of a WTF::String
           only because we want InternalFunction to be continue to be trivially
           destructible.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::functionDetails):
        * jit/JITThunks.cpp:
        (JSC::JITThunks::finalize):
        (JSC::JITThunks::hostFunctionStub):
        * jit/JITThunks.h:
        * runtime/Executable.h:
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::finishCreation):
        (JSC::InternalFunction::visitChildren):
        (JSC::InternalFunction::name):
        (JSC::InternalFunction::displayName):
        * runtime/InternalFunction.h:
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::create):
        (JSC::JSBoundFunction::visitChildren):
        (JSC::JSBoundFunction::toStringName): Deleted.
        * runtime/JSBoundFunction.h:
        (JSC::JSBoundFunction::boundThis):
        (JSC::JSBoundFunction::boundArgs):
        (JSC::JSBoundFunction::createStructure):
        * runtime/JSBoundSlotBaseFunction.cpp:
        (JSC::boundSlotBaseFunctionCall):
        (JSC::JSBoundSlotBaseFunction::create):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::initializeRareData):
        (JSC::JSFunction::name):
        (JSC::JSFunction::displayName):
        (JSC::JSFunction::calculatedDisplayName):
        (JSC::JSFunction::reifyName):
        * runtime/JSFunction.h:
        * tests/es6.yaml:

2016-03-08  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r197793 and r197799.
        https://bugs.webkit.org/show_bug.cgi?id=155195

        something weird happened while landing this and everything
        broke (Requested by olliej on #webkit).

        Reverted changesets:

        "Start moving to separated writable and executable mappings in
        the JIT"
        https://bugs.webkit.org/show_bug.cgi?id=155178
        http://trac.webkit.org/changeset/197793

        "arm64 build fix after r197793."
        http://trac.webkit.org/changeset/197799

2016-03-08  Alex Christensen  <achristensen@webkit.org>

        arm64 build fix after r197793.

        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
        (JSC::FixedVMPoolExecutableAllocator::initializeBulletproofJIT):
        (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
        Use consistent ENABLE macro.  It looks like it was partially renamed.

2016-03-08  Filip Pizlo  <fpizlo@apple.com>

        Regexp matching should incur less call overhead
        https://bugs.webkit.org/show_bug.cgi?id=155181

        Reviewed by Geoffrey Garen.

        Previously we had DFG/FTL code call into the DFGOperation, which then called in to
        RegExpObject, which then called into createRegExpMatchesArray, which then called into
        RegExp, which then called the code generated by Yarr.

        Now we have DFG/FTL code call into the DFGOperation, which does all of the things and calls
        into code generated by Yarr.

        This is another tiny Octane/regexp speed-up.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGOperations.cpp:
        * runtime/RegExp.cpp:
        (JSC::regExpFlags):
        (JSC::RegExp::compile):
        (JSC::RegExp::match):
        (JSC::RegExp::compileMatchOnly):
        (JSC::RegExp::deleteCode):
        (JSC::RegExpFunctionalTestCollector::clearRegExp): Deleted.
        (JSC::RegExp::compileIfNecessary): Deleted.
        (JSC::RegExp::compileIfNecessaryMatchOnly): Deleted.
        * runtime/RegExp.h:
        * runtime/RegExpInlines.h: Added.
        (JSC::RegExpFunctionalTestCollector::clearRegExp):
        (JSC::RegExp::compileIfNecessary):
        (JSC::RegExp::matchInline):
        (JSC::RegExp::compileIfNecessaryMatchOnly):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::createEmptyRegExpMatchesArray):
        (JSC::createStructureImpl):
        (JSC::tryCreateUninitializedRegExpMatchesArray): Deleted.
        (JSC::createRegExpMatchesArray): Deleted.
        * runtime/RegExpMatchesArray.h:
        (JSC::tryCreateUninitializedRegExpMatchesArray):
        (JSC::createRegExpMatchesArray):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::put):
        (JSC::RegExpObject::exec):
        (JSC::RegExpObject::match):
        (JSC::getLastIndexAsUnsigned): Deleted.
        * runtime/RegExpObject.h:
        (JSC::RegExpObject::getLastIndex):
        (JSC::RegExpObject::test):
        (JSC::RegExpObject::testInline):
        * runtime/RegExpObjectInlines.h: Added.
        (JSC::getRegExpObjectLastIndexAsUnsigned):
        (JSC::RegExpObject::execInline):
        (JSC::RegExpObject::matchInline):

2016-03-08  Mark Lam  <mark.lam@apple.com>

        synthesizePrototype() and friends need to be followed by exception checks (or equivalent).
        https://bugs.webkit.org/show_bug.cgi?id=155169

        Reviewed by Geoffrey Garen.

        With the exception checks, we may end up throwing new exceptions over an existing
        one that has been thrown but not handled yet, thereby obscuring it.  It may also
        mean that the VM will continue running on potentially unstable state, which may
        have undesirable consequences.

        I first observed this in some failed assertion while running tests on a patch for
        https://bugs.webkit.org/show_bug.cgi?id=154865.

        Performance is neutral with this patch (tested on x86_64).

        1. Deleted JSNotAnObject, and removed all uses of it.

        2. Added exception checks, when needed, following calls to synthesizePrototype()
           and JSValue::toObject().

           The cases that do not need an exception check are the ones that already ensures
           that JSValue::toObject() is only called on a value that is convertible to an
           object.  In those cases, I added an assertion that no exception was thrown
           after the call.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::createScriptCallStackFromException):
        * interpreter/Interpreter.cpp:
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncJoin):
        (JSC::arrayProtoFuncConcat):
        (JSC::arrayProtoFuncPop):
        (JSC::arrayProtoFuncPush):
        (JSC::arrayProtoFuncReverse):
        (JSC::arrayProtoFuncShift):
        (JSC::arrayProtoFuncSlice):
        (JSC::arrayProtoFuncSplice):
        (JSC::arrayProtoFuncUnShift):
        (JSC::arrayProtoFuncIndexOf):
        (JSC::arrayProtoFuncLastIndexOf):
        (JSC::arrayProtoFuncValues):
        (JSC::arrayProtoFuncEntries):
        (JSC::arrayProtoFuncKeys):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/ExceptionHelpers.cpp:
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::toObjectSlowCase):
        (JSC::JSValue::toThisSlowCase):
        (JSC::JSValue::synthesizePrototype):
        (JSC::JSValue::putToPrimitive):
        (JSC::JSValue::putToPrimitiveByIndex):
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::getPropertySlot):
        (JSC::JSValue::get):
        * runtime/JSFunction.cpp:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoGetter):
        * runtime/JSNotAnObject.cpp: Removed.
        * runtime/JSNotAnObject.h: Removed.
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorDefineProperties):
        (JSC::objectConstructorCreate):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncValueOf):
        (JSC::objectProtoFuncHasOwnProperty):
        (JSC::objectProtoFuncIsPrototypeOf):
        (JSC::objectProtoFuncToString):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2016-03-08  Oliver Hunt  <oliver@apple.com>

        Start moving to separated writable and executable mappings in the JIT
        https://bugs.webkit.org/show_bug.cgi?id=155178

        Reviewed by Filip Pizlo.

        Start moving to a separate writable and executable heap for the various
        JITs.

        As part of our work to harden the JIT against various attacks, we're
        moving away from our current RWX heap and on to using separate RW and X
        mappings. This means that simply leaking the location of the executable
        mapping is not sufficient to compromise JSC, so we can continue to
        use direct executable pointers in our GC objects (which we need for
        performance), but keep the writable pointer in only a single location
        so that we are less likely to leak the address. To further obscure the
        address of the writable region we place it in an execute only region
        of memory so that it is not possible to read the location from 
        anywhere. That means an attacker must have at least partial control
        of PC (to call jitMemCopy) before they can start to attack the JIT.

        This work is initially ARM64 only, as we use as the jitMemCopy is
        currently specific to that platform's calling conventions and layout.
        We're just landing it in the current form so that we can at least
        ensure it doesn't regress.

        * Configurations/FeatureDefines.xcconfig:
        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::ldp):
        (JSC::ARM64Assembler::ldnp):
        (JSC::ARM64Assembler::fillNops):
        (JSC::ARM64Assembler::stp):
        (JSC::ARM64Assembler::stnp):
        (JSC::ARM64Assembler::replaceWithJump):
        (JSC::ARM64Assembler::replaceWithLoad):
        (JSC::ARM64Assembler::replaceWithAddressComputation):
        (JSC::ARM64Assembler::setPointer):
        (JSC::ARM64Assembler::repatchInt32):
        (JSC::ARM64Assembler::repatchCompact):
        (JSC::ARM64Assembler::linkJumpOrCall):
        (JSC::ARM64Assembler::linkCompareAndBranch):
        (JSC::ARM64Assembler::linkConditionalBranch):
        (JSC::ARM64Assembler::linkTestAndBranch):
        (JSC::ARM64Assembler::loadStoreRegisterPairOffset):
        (JSC::ARM64Assembler::loadStoreRegisterPairNonTemporal):
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::copyCompactAndLinkCode):
        (JSC::LinkBuffer::allocate):
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::LinkBuffer):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::sub64):
        (JSC::MacroAssemblerARM64::load64):
        (JSC::MacroAssemblerARM64::loadPair64):
        (JSC::MacroAssemblerARM64::loadPair64WithNonTemporalAccess):
        (JSC::MacroAssemblerARM64::load8):
        (JSC::MacroAssemblerARM64::store64):
        (JSC::MacroAssemblerARM64::storePair64):
        (JSC::MacroAssemblerARM64::storePair64WithNonTemporalAccess):
        (JSC::MacroAssemblerARM64::store8):
        (JSC::MacroAssemblerARM64::branchAdd64):
        (JSC::MacroAssemblerARM64::branchSub64):
        * jit/ExecutableAllocator.h:
        (JSC::performJITMemcpy):
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
        (JSC::FixedVMPoolExecutableAllocator::initializeBulletproofJIT):
        (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:

2016-03-08  Michael Saboff  <msaboff@apple.com>

        [ES6] Regular Expression canonicalization tables for Unicode need to be updated to use Unicode CaseFolding.txt
        https://bugs.webkit.org/show_bug.cgi?id=155114

        Reviewed by Darin Adler.

        Extracted out the Unicode canonicalization table creation from
        YarrCanonicalizeUnicode.js into a new Python script, generateYarrCanonicalizeUnicode.
        That script generates the Unicode tables as the file YarrCanonicalizeUnicode.cpp in
        DerivedSources/JavaScriptCore.

        Updated the processing of ignore case to make the ASCII short cuts dependent on whether
        or not we are a Unicode pattern.

        Renamed yarr/YarrCanonicalizeUnicode.{cpp,js} back to their prior names,
        YarrCanonicalizeUCS2.{cpp,js}.
        Renamed yarr/YarrCanonicalizeUnicode.h to YarrCanonicalize.h as it declares both the
        legacy UCS2 and Unicode tables.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * generateYarrCanonicalizeUnicode: Added.
        * ucd: Added.
        * ucd/CaseFolding.txt: Added.  The current verion, 8.0, of the Unicode CaseFolding table.
        * yarr/YarrCanonicalizeUCS2.cpp: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUnicode.cpp.
        * yarr/YarrCanonicalize.h: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUnicode.h.
        * yarr/YarrCanonicalizeUCS2.js: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUnicode.js.
        (printHeader):
        * yarr/YarrCanonicalizeUnicode.cpp: Removed.
        * yarr/YarrCanonicalizeUnicode.h: Removed.
        * yarr/YarrCanonicalizeUnicode.js: Removed.
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::tryConsumeBackReference):
        * yarr/YarrJIT.cpp:
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::CharacterClassConstructor::putChar):

2016-03-08  Andreas Kling  <akling@apple.com>

        WeakBlock::visit() should check for a WeakHandleOwner before consulting mark bits.
        <https://webkit.org/b/155154>

        Reviewed by Darin Adler.

        Reorder the checks in WeakBlock::visit() so we don't look at the mark bits in MarkedBlock
        unless the current WeakImpl has a WeakHandleOwner we need to consult.

        I was originally hoping to make an optimization that could skip over entire WeakBlocks
        if they didn't have a single WeakHandleOwner, but it turns out that scenario is not as
        common as I suspected.

        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::visit):

2016-03-07  Saam barati  <sbarati@apple.com>

        [ES6] Implement revocable proxies
        https://bugs.webkit.org/show_bug.cgi?id=154321

        Reviewed by Mark Lam.

        This patch is a straight forward implementation of Proxy.revocable
        with respect to section 26.2.2.1 of the ECMAScript spec.
        https://tc39.github.io/ecma262/#sec-proxy.revocable

        This patch also fixes a bug in Proxy where we
        were incorrectly caching "in", i.e, `"x" in proxy`.
        We should never blatantly cache this because caching is observable
        behavior by users of the language. We could come up with
        a smarter caching scheme that caches only if the Proxy's
        handler doesn't have a "has" property, i.e, we don't have
        to call out to JS code. But for now, it's easiest to disable
        caching.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::moduleRecordStructure):
        (JSC::JSGlobalObject::moduleNamespaceObjectStructure):
        (JSC::JSGlobalObject::proxyObjectStructure):
        (JSC::JSGlobalObject::proxyRevokeStructure):
        (JSC::JSGlobalObject::wasmModuleStructure):
        * runtime/ProxyConstructor.cpp:
        (JSC::ProxyConstructor::create):
        (JSC::ProxyConstructor::ProxyConstructor):
        (JSC::makeRevocableProxy):
        (JSC::proxyRevocableConstructorThrowError):
        (JSC::ProxyConstructor::finishCreation):
        (JSC::constructProxyObject):
        * runtime/ProxyConstructor.h:
        (JSC::ProxyConstructor::createStructure):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::finishCreation):
        (JSC::performProxyGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::performPut):
        (JSC::performProxyCall):
        (JSC::performProxyConstruct):
        (JSC::ProxyObject::performDelete):
        (JSC::ProxyObject::performPreventExtensions):
        (JSC::ProxyObject::performIsExtensible):
        (JSC::ProxyObject::performDefineOwnProperty):
        (JSC::ProxyObject::performGetOwnPropertyNames):
        (JSC::ProxyObject::performSetPrototype):
        (JSC::ProxyObject::performGetPrototype):
        (JSC::ProxyObject::getPrototype):
        (JSC::ProxyObject::revoke):
        (JSC::ProxyObject::visitChildren):
        * runtime/ProxyObject.h:
        (JSC::ProxyObject::create):
        * runtime/ProxyRevoke.cpp: Added.
        (JSC::ProxyRevoke::create):
        (JSC::ProxyRevoke::ProxyRevoke):
        (JSC::ProxyRevoke::finishCreation):
        (JSC::performProxyRevoke):
        (JSC::ProxyRevoke::getCallData):
        (JSC::ProxyRevoke::visitChildren):
        * runtime/ProxyRevoke.h: Added.
        (JSC::ProxyRevoke::createStructure):
        (JSC::ProxyRevoke::proxy):
        (JSC::ProxyRevoke::setProxyToNull):
        * tests/stress/proxy-has-property.js:
        (assert):
        (assert.let.handler.has):
        (assert.let.foo):
        * tests/stress/proxy-revoke.js: Added.
        (assert):
        (throw.new.Error.):
        (throw.new.Error):
        (callAllHandlers):
        (shouldThrowNullHandler):
        (allHandlersShouldThrow):
        (i.let.trap.of.traps.trap.string_appeared_here.func):
        (i.let.trap.of.traps.else.func):
        (i.Proxy.revocable):

2016-03-07  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the ARM build after r197687
        https://bugs.webkit.org/show_bug.cgi?id=155128

        Reviewed by Saam Barati.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::moveZeroToDouble):

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

        Reduce the number of instructions needed to record the last regexp result
        https://bugs.webkit.org/show_bug.cgi?id=155161

        Reviewed by Sam Weinig.

        This tightens up RegExpCachedResult::record(). My profiling shows that we spend just
        over 1% of the time in Octane/regexp in this function. This function had two obvious
        redundancies:

        1) It executed the write barrier on owner twice. It only needs to execute it once. Since
           the same RegExpConstructor is likely to be used many times, it makes sense to do the
           barrier without looking at the 'to' objects at all. In steady state, this means that
           the RegExpConstructor will simply be OldGrey so this one barrier will always skip the
           slow path.

        2) It cleared some fields that didn't need to be cleared, since we can just use
           m_reified to indicate that the fields are not meaningful anymore.

        This is meant to be a microscopic regexp speed-up.

        * runtime/RegExpCachedResult.cpp:
        (JSC::RegExpCachedResult::visitChildren):
        (JSC::RegExpCachedResult::lastResult):
        * runtime/RegExpCachedResult.h:
        (JSC::RegExpCachedResult::record):

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

        createRegExpMatchesArray should allocate substrings more quickly
        https://bugs.webkit.org/show_bug.cgi?id=155160

        Reviewed by Sam Weinig.

        This was calling a version of jsSubstring() that isn't inlineable because it was doing a lot
        of checks in finishCreation(). In particular, it was checking that the base string is not
        itself a substring and that it's been resolved. We don't need those checks here, since the
        string must have been resolved prior to regexp processing.

        This patch is also smart about whether to do checks for the empty and full substrings. In
        the matches array loop, these checks are super unlikely to be profitable, so we just
        unconditionally allocate the substring.

        This removes those checks and makes the allocation inlineable. It looks like a 1% speed-up
        on Octane/regexp.

        * runtime/JSString.h:
        (JSC::jsSubstring):
        (JSC::jsSubstringOfResolved):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::createRegExpMatchesArray):

2016-03-07  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Small clean up of how we use SSA's valuesAtHead
        https://bugs.webkit.org/show_bug.cgi?id=155152

        Reviewed by Filip Pizlo.

        liveAtHead and valuesAtHead contain the same nodes,
        we do not need the extra look up.

        This also opens the way to use the same kind of liveness
        analysis as Air (where live values at head do not use a set).

        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::beginBasicBlock):
        (JSC::DFG::InPlaceAbstractState::merge):

2016-03-07  Brian Burg  <bburg@apple.com>

        Web Inspector: the protocol generator should generate factory method stubs for protocol types
        https://bugs.webkit.org/show_bug.cgi?id=155103
        <rdar://problem/25002772>

        Reviewed by Timothy Hatcher.

        Generate stubs with unique names so that parsing methods can be used
        reflectively at runtime, based on the protocol version that's loaded.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/scripts/codegen/__init__.py:
        * inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
        Added. For each type in a domain, add a method of the form
        -[ProtocolTypeConversions _parseXXX:fromPayload]. This is in a category
        method, and the selector is only ever looked up at runtime.

        (ObjCProtocolTypeConversionsHeaderGenerator.generate_output):
        * inspector/scripts/generate-inspector-protocol-bindings.py:
        (generate_from_specification):

        Rebaseline test results with new generator output.

        * 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:

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

        RegExp.prototype.exec() should call into Yarr at most once
        https://bugs.webkit.org/show_bug.cgi?id=155139

        Reviewed by Saam Barati.

        For apparently no good reason, RegExp.prototype.match() was calling into Yarr twice, almost
        as if it was hoping that the non-matching case was so common that it was best to have the
        matching case do the work all over again.

        This is a 4% speed-up on Octane/regexp. It's also a matter of common sense: we should not be
        in the business of presuming whether someone's match will succeed or fail. The increased
        cost of running Yarr twice is so much larger than whatever savings we were getting from
        running a match-only regexp that this is just not a good overall deal for the engine.

        Also, it's interesting that we are seeing a 4% speed-up on regexp despite the fact that a
        majority (almost a supermajority, I think) of calls into RegExp.prototype.match() are failed
        matches. So, this change is a 4% speed-up despite being a slow down on the common case. That
        tells you just how bad the old behavior was on the uncommon case.

        * runtime/MatchResult.h:
        (MatchResult::MatchResult):
        (MatchResult::failed):
        (MatchResult::operator bool):
        * runtime/RegExpCachedResult.cpp:
        (JSC::RegExpCachedResult::lastResult):
        * runtime/RegExpConstructor.h:
        (JSC::RegExpConstructor::setMultiline):
        (JSC::RegExpConstructor::multiline):
        (JSC::RegExpConstructor::performMatch):
        (JSC::RegExpConstructor::recordMatch):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::createRegExpMatchesArray):
        (JSC::createEmptyRegExpMatchesArray):
        (JSC::createStructureImpl):
        * runtime/RegExpMatchesArray.h:
        (JSC::createRegExpMatchesArray):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::put):
        (JSC::getLastIndexAsUnsigned):
        (JSC::RegExpObject::exec):
        (JSC::RegExpObject::match):
        * runtime/RegExpObject.h:
        (JSC::RegExpObject::getLastIndex):
        (JSC::RegExpObject::test):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncMatch):

2016-03-07  Joseph Pecoraro  <pecoraro@apple.com>

        Heap Snapshot should include different Edge types and data (Property, Index, Variable)
        https://bugs.webkit.org/show_bug.cgi?id=154937

        Reviewed by Geoffrey Garen.

        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::appendHidden):
        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::appendHidden):
        (JSC::SlotVisitor::appendValuesHidden):
        Add new visit methods to visit a reference without snapshotting the edge.

        * heap/Heap.cpp:
        (JSC::AddExtraHeapSnapshotEdges::AddExtraHeapSnapshotEdges):
        (JSC::AddExtraHeapSnapshotEdges::operator()):
        (JSC::Heap::addHeapSnapshotEdges):
        (JSC::Heap::removeDeadHeapSnapshotNodes):
        (JSC::Heap::collectImpl):
        * heap/Heap.h:
        After marking, visit the live cells for a chance to record extra
        heap snapshotting information about the cell.

        * heap/HeapSnapshotBuilder.cpp:
        (JSC::HeapSnapshotBuilder::appendNode):
        (JSC::HeapSnapshotBuilder::appendEdge):
        (JSC::HeapSnapshotBuilder::appendPropertyNameEdge):
        (JSC::HeapSnapshotBuilder::appendVariableNameEdge):
        (JSC::HeapSnapshotBuilder::appendIndexEdge):
        (JSC::HeapSnapshotBuilder::json):
        * heap/HeapSnapshotBuilder.h:
        (JSC::HeapSnapshotEdge::HeapSnapshotEdge):
        Construct edges with extra data.

        * runtime/ClassInfo.h:
        * runtime/JSCell.cpp:
        (JSC::JSCell::heapSnapshot):
        * runtime/JSCell.h:
        Add a new method to provide cells with an opportunity to provide
        extra heap snapshotting information.

        * runtime/JSObject.cpp:
        (JSC::JSObject::visitButterfly):
        (JSC::JSObject::visitChildren):
        (JSC::JSObject::heapSnapshot):
        (JSC::JSFinalObject::visitChildren):
        * runtime/JSObject.h:
        Capture object property names and index names when heap snapshotting.
        Do not include them as internal edges in normal visitChildren.

        * runtime/JSEnvironmentRecord.cpp:
        (JSC::JSEnvironmentRecord::visitChildren):
        (JSC::JSEnvironmentRecord::heapSnapshot):
        * runtime/JSEnvironmentRecord.h:
        * runtime/JSSegmentedVariableObject.cpp:
        (JSC::JSSegmentedVariableObject::visitChildren):
        (JSC::JSSegmentedVariableObject::heapSnapshot):
        * runtime/JSSegmentedVariableObject.h:
        Capture scope variable names when heap snapshotting.

        * runtime/Structure.cpp:
        (JSC::Structure::visitChildren):
        * runtime/Structure.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::propertyTable):
        When performing a heap snapshotting collection, don't clear the
        property table so that accessing the table during this GC is okay.

        * tests/heapProfiler/driver/driver.js:
        * tests/heapProfiler/property-edge-types.js: Added.
        * tests/heapProfiler/variable-edge-types.js: Added.
        Tests covering the different edge types and data we capture.

2016-03-07  Saam barati  <sbarati@apple.com>

        [ES6] Implement Proxy.[[GetPrototypeOf]]
        https://bugs.webkit.org/show_bug.cgi?id=155099

        Reviewed by Mark Lam.

        This patch is a straight forward implementation of Proxy.[[GetPrototypeOf]]
        with respect to section 9.5.1 of the ECMAScript spec.
        https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-getprototypeof

        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::setPrototype):
        (JSC::ProxyObject::performGetPrototype):
        (JSC::ProxyObject::getPrototype):
        (JSC::ProxyObject::visitChildren):
        * runtime/ProxyObject.h:
        * tests/es6.yaml:
        * tests/stress/proxy-get-prototype-of.js: Added.
        (assert):
        (throw.new.Error.let.handler.get getPrototypeOf):
        (throw.new.Error.get let):
        (throw.new.Error.get catch):
        (throw.new.Error):
        (assert.let.handler.getPrototypeOf):
        (assert.get let):
        (assert.get catch):
        (assert.):
        (let.handler.getPrototypeOf):
        (get let):
        (let.handler.has):

2016-03-07  Brian Burg  <bburg@apple.com>

        Web Inspector: rename generated *EnumConversionHelpers.h to *TypeConversions.h
        https://bugs.webkit.org/show_bug.cgi?id=155121
        <rdar://problem/25010391>

        Reviewed by Timothy Hatcher.

        Split out this renaming from the work to generate factory method stubs for types.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/scripts/codegen/__init__.py:
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
        (ObjCConfigurationImplementationGenerator.generate_output):
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator.generate_output):
        * inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objc_conversion_helpers.py.
        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator.generate_output):
        * inspector/scripts/codegen/objc_generator_templates.py:
        * inspector/scripts/generate-inspector-protocol-bindings.py:
        (generate_from_specification):

        Rebaseline tests after changing generator order.

        * 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:

2016-03-07  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Improve and64() and or64() with immediate on x86
        https://bugs.webkit.org/show_bug.cgi?id=155104

        Reviewed by Geoffrey Garen.

        GetButterflyReadOnly was doing:
            movq 0x8(%rbx), %r9
            movq $0xfffffffffffffffc, %r11
            andq %r11, %r9
        There is no need for the move to load the immediate,
        andq sign extend its immediate.

        With this patch, we have:
            movq 0x8(%rbx), %r9
            andq $0xfffffffffffffffc, %r9

        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::and64):
        (JSC::MacroAssemblerX86_64::or64):

2016-03-07  Brian Burg  <bburg@apple.com>

        Web Inspector: It should be possible to initialize generated ObjC protocol types from an NSDictionary payload
        https://bugs.webkit.org/show_bug.cgi?id=155102
        <rdar://problem/25002015>

        Reviewed by Timothy Hatcher.

        In Objective-C code, we sometimes prefer to parse JSON using Cocoa rather
        than the InspectorValue classes. Support initializing protocol objects
        directly from an NSDictionary payload. This delegates validation of values to
        the setter methods that already exist on the protocol object classes.

        * inspector/scripts/codegen/generate_objc_header.py:
        (ObjCHeaderGenerator._generate_type_interface):
        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator.generate_type_implementation):
        (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_payload):
        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator.payload_to_objc_expression_for_member):
        Add a new helper method to generate an expression to unpack the value
        from an NSDictionary. If it's not a primitive, the setter performs
        validation of the value's kind using -[NSObject isKindOfClass:].

        Rebaseline relevant tests.

        * 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/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:

2016-03-07  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Simplify the overflow check of ArithAbs
        https://bugs.webkit.org/show_bug.cgi?id=155063

        Reviewed by Geoffrey Garen.

        The only integer that overflow abs(int32) is INT_MIN.
        For some reason, our code testing for that case
        was checking the top bit of the result specifically.

        The code required a large immediate on x86 and an extra
        register on ARM64.

        This patch turns the overflow check into a branch on
        the sign of the result.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArithAbs):
        * jit/ThunkGenerators.cpp:
        (JSC::absThunkGenerator):
        * tests/stress/arith-abs-overflow.js: Added.
        (opaqueAbs):

2016-03-07  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Improve how DFG zero Floating Point registers
        https://bugs.webkit.org/show_bug.cgi?id=155096

        Reviewed by Geoffrey Garen.

        DFG had a weird way of zeroing a FPR:
            -zero a GP.
            -move that to a FP.

        Filip added moveZeroToDouble() for B3. This patch
        uses that in the lower tiers.

        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::moveZeroToDouble):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
        * jit/ThunkGenerators.cpp:
        (JSC::floorThunkGenerator):
        (JSC::roundThunkGenerator):

2016-03-07  Andreas Kling  <akling@apple.com>

        REGRESSION (r197303): Web Inspector crashes web process when inspecting an element on TOT
        <https://webkit.org/b/154812>

        Reviewed by Geoffrey Garen.

        Guard against null pointer dereference for UnlinkedCodeBlocks that don't have any control flow
        profiling data.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::hasOpProfileControlFlowBytecodeOffsets):

2016-03-07  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Remove a useless "Move" from baseline-JIT op_mul's fast path
        https://bugs.webkit.org/show_bug.cgi?id=155071

        Reviewed by Geoffrey Garen.

        We do not need to multiply to a scratch and then move the result
        to the destination. We can just multiply to the destination.

        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_mul):
        * jit/JITMulGenerator.cpp:
        (JSC::JITMulGenerator::generateFastPath):

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

        [JSC] StringObject.{put, defineOwnProperty} should realize indexed properties
        https://bugs.webkit.org/show_bug.cgi?id=155089

        Reviewed by Geoffrey Garen.

        Through implementing Reflect.set[1], we found StringObject does not obey the spec.
        StringObject::put should call putByIndex if the given propertyName is index.
        And StringObject::defineOwnProperty should recognize indexed properties since
        JSObject::defineOwnIndexedProperty is specialized to JSObject layout.
        Before calling JSObject::defineOwnProperty,
        StringObject should handle its special indexed own properties.
        It is responsibility of StringObject::defineOwnProperty.

        And the logic is cleaned up by using validateAndApplyPropertyDescriptor.

        [1]: https://bugs.webkit.org/show_bug.cgi?id=155024

        * runtime/StringObject.cpp:
        (JSC::StringObject::put):
        (JSC::StringObject::putByIndex):
        (JSC::isStringOwnProperty):
        (JSC::StringObject::defineOwnProperty):
        (JSC::StringObject::deleteProperty):
        * tests/stress/string-object-define-own-property.js: Added.
        (shouldBe):
        (shouldThrow):
        * tests/stress/string-object-put-by-index.js: Added.
        (shouldBe):
        (shouldThrow):
        (testSloppy):
        (testStrict):

2016-03-06  Brian Burg  <bburg@apple.com>

        Web Inspector: the protocol generator should have separate prefix options for Objective-C classes and filenames
        https://bugs.webkit.org/show_bug.cgi?id=155101
        <rdar://problem/25000053>

        Reviewed by Timothy Hatcher.

        It should be possible to generate Objective-C protocol types without prefixing all class names.
        The prefixes are only necessary when the generated files are part of a framework, but this isn't
        how the generated Objective-C frontend files are used.

        Add a separate framework setting and switch over code to use the 'protocol_group' in filenames,
        and the 'objc_prefix' for Objective-C enum and class prefixes.

        No tests need to be rebaselined because tests always set the protocol_group and objc_prefix
        to the same value.

        * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
        (ObjCBackendDispatcherHeaderGenerator.output_filename):
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
        (ObjCConfigurationImplementationGenerator.output_filename):
        (ObjCConfigurationImplementationGenerator.generate_output):
        * inspector/scripts/codegen/generate_objc_configuration_header.py:
        (ObjCConfigurationHeaderGenerator.output_filename):
        (ObjCConfigurationHeaderGenerator.generate_output):
        (ObjCConfigurationHeaderGenerator._generate_configuration_interface_for_domains):
        * inspector/scripts/codegen/generate_objc_configuration_implementation.py:
        (ObjCBackendDispatcherImplementationGenerator.output_filename):
        (ObjCBackendDispatcherImplementationGenerator.generate_output):
        (ObjCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains):
        * inspector/scripts/codegen/generate_objc_conversion_helpers.py:
        (ObjCConversionHelpersGenerator.output_filename):
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator.output_filename):
        (ObjCFrontendDispatcherImplementationGenerator.generate_output):
        * inspector/scripts/codegen/generate_objc_header.py:
        (ObjCHeaderGenerator.output_filename):
        * inspector/scripts/codegen/generate_objc_internal_header.py:
        (ObjCInternalHeaderGenerator.output_filename):
        (ObjCInternalHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator.output_filename):
        (ObjCProtocolTypesImplementationGenerator.generate_output):
        * inspector/scripts/codegen/models.py:
        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator):
        (ObjCGenerator.protocol_name):
        (ObjCGenerator.objc_prefix):

2016-03-06  Brian Burg  <bburg@apple.com>

        Unreviewed, rebaseline inspector protocol generator tests after r197563.

        * 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/generate-domains-with-feature-guards.json-result:

2016-03-06  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Improve DFG's Int32 ArithMul if one operand is a constant
        https://bugs.webkit.org/show_bug.cgi?id=155066

        Reviewed by Filip Pizlo.

        When multiplying an integer by a constant, DFG was doing quite
        a bit worse than baseline JIT.
        We were loading the constant into a register, doing the multiply,
        the checking the result and both operands for negative zero.

        This patch changes:
        -Use the multiply-by-immediate form on x86.
        -Do as few checks as possible to detect negative-zero.

        In most cases, this reduce the negative-zero checks
        to zero or one TEST+JUMP.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::mul32):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithMul):

2016-03-06  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Remove a superfluous Move in front of every double unboxing
        https://bugs.webkit.org/show_bug.cgi?id=155064

        Reviewed by Saam Barati.

        Double unboxing was always doing:
            Move source, scratch
            Add64 tag, scratch
            IntToDouble scratch, fp

        We do not need to "Move" to copy the source.
        Both x86 and ARM64 have an efficient 3 operands Add instruction.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        (JSC::DFG::SpeculativeJIT::compileDoubleRep):
        (JSC::DFG::SpeculativeJIT::speculateRealNumber):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::unboxDouble):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::unboxDoubleWithoutAssertions):
        (JSC::AssemblyHelpers::unboxDouble):
        (JSC::AssemblyHelpers::unboxDoubleNonDestructive):

2016-03-06  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Use 3 operands Add in more places
        https://bugs.webkit.org/show_bug.cgi?id=155082

        Reviewed by Filip Pizlo.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::addPtr):
        (JSC::MacroAssembler::add32):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::add32):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithAdd):
        The case with child1 constant is useless.
        The canonical form will have the constant as child2.

        Also add register reuse for the fast-add.
        Registers are a scarce resource on x86.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::prepareForTailCallSlow):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::generate):

2016-03-06  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Improve codegen of Compare and Test
        https://bugs.webkit.org/show_bug.cgi?id=155055

        Reviewed by Filip Pizlo.

        This patch introduces a few improvements on how we lower
        Compare and Test with immediates:
            -Add certain Immediate forms of ARM64.
            -Use CBZ/CBNZ when possible on ARM64.
            -When possible, convert a CMP into a TST
             On some hardware, we can issue more TST simultaneously.

             On x86, any TST+Jump is candidate for macro-fusion.
             They are also smaller.
             (sections 3.4.2.2 and 3.5.1.9)
            -Do not load the mask immediate of a TST
             if it only contains ones (mostly useful for ARM64
             since that would not have been a valid immediate).

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::compare32):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::moveConditionallyAfterFloatingPointCompare):
        (JSC::MacroAssemblerARM64::moveDoubleConditionallyAfterFloatingPointCompare):
        This is somewhat unrelated but I found that out while working
        on moveDoubleConditionallyTest32:
            If "thenCase" and "dest" are assigned the same register
            by the allocator, then the first (f)fcsel would override
            the "thenCase" and the second fcsel would always be "elseCase".

        This is covered by testb3 but was only uncovered
        after recent "Move" removals in lowering.

        (JSC::MacroAssemblerARM64::moveConditionally32):
        (JSC::MacroAssemblerARM64::moveConditionally64):
        (JSC::MacroAssemblerARM64::moveConditionallyTest32):
        (JSC::MacroAssemblerARM64::moveDoubleConditionally32):
        (JSC::MacroAssemblerARM64::moveDoubleConditionally64):
        (JSC::MacroAssemblerARM64::moveDoubleConditionallyTest32):
        (JSC::MacroAssemblerARM64::branch32):
        (JSC::MacroAssemblerARM64::branch64):
        (JSC::MacroAssemblerARM64::branchTest32):
        (JSC::MacroAssemblerARM64::test32):
        The version taking an immediate was guarded by
        (cond == Zero) || (cond == NonZero). That is overzealous,
        and only needed for CBZ/CBNZ.

        (JSC::MacroAssemblerARM64::branchTest64):
        (JSC::MacroAssemblerARM64::compare32):
        (JSC::MacroAssemblerARM64::compare64):
        (JSC::MacroAssemblerARM64::commuteCompareToZeroIntoTest):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::moveConditionally32):
        (JSC::MacroAssemblerX86Common::moveConditionallyTest32):
        (JSC::MacroAssemblerX86Common::branch32):
        (JSC::MacroAssemblerX86Common::test32):
        (JSC::MacroAssemblerX86Common::branchTest32):
        (JSC::MacroAssemblerX86Common::compare32):
        (JSC::MacroAssemblerX86Common::commuteCompareToZeroIntoTest):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::compare64):
        (JSC::MacroAssemblerX86_64::branch64):
        (JSC::MacroAssemblerX86_64::moveConditionally64):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createGenericCompare):
        Unfortunately this cannot be abstracted by the MacroAssembler.
        Those immediates are not valid, we have to pick the better
        for right away.

        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::int64Operands):
        (JSC::B3::modelCompare):
        (JSC::B3::testCompareImpl):
        (JSC::B3::testCompare):
        (JSC::B3::b3Pow):
        (JSC::B3::testPowDoubleByIntegerLoop):
        Some versions of pow(double, int) do not return
        the exact same bits as our integer loop.
        Added a new version to have the same behavior
        as the B3 loop.

        (JSC::B3::run):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePeepHoleBooleanBranch):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileInt32Compare):
        Comparing to an immediate is super common. Do not waste
        a register for that!

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

        Unreviewed, fix build. This was a messed up merge.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):

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

        DFG should know how to speculate StringOrOther
        https://bugs.webkit.org/show_bug.cgi?id=155094

        Reviewed by Saam Barati.

        Any code that processes the regexp matches array was previously doing a relatively expensive
        Branch(Untyped:). This introduces a new use kind called StringOrOther, which is perfect for
        code that loops over the matches array and branches on the entries being non-empty.

        To do this, I needed to introduce code into the FTL that creates new blocks. We still had that
        awful FTL_NEW_BLOCK idiom since the only way to debug LLVM IR was to ascribe names to basic
        blocks. B3 IR is inherently more debuggable since unlike LLVM, B3 knows how to always respect
        code origin, and it knows how to print the code origin nicely in the dumps. So, rather than
        continue using FTL_NEW_BLOCK(m_out, ("things")), I replaced all of that stuff with
        m_out.newBlock(). It's much nicer that way.

        This is a tiny speed-up on Octane/regexp at best. I was hoping for more. Oh well.

        * bytecode/SpeculatedType.h:
        (JSC::isStringSpeculation):
        (JSC::isStringOrOtherSpeculation):
        (JSC::isSymbolSpeculation):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::shouldSpeculateString):
        (JSC::DFG::Node::shouldSpeculateStringOrOther):
        (JSC::DFG::Node::shouldSpeculateStringObject):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::operator()):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileStringZeroLength):
        (JSC::DFG::SpeculativeJIT::compileLogicalNotStringOrOther):
        (JSC::DFG::SpeculativeJIT::emitStringBranch):
        (JSC::DFG::SpeculativeJIT::emitStringOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::compileConstantStoragePointer):
        (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
        (JSC::DFG::SpeculativeJIT::speculateString):
        (JSC::DFG::SpeculativeJIT::speculateStringOrOther):
        (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage):
        (JSC::DFG::SpeculativeJIT::speculate):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep):
        (JSC::FTL::DFG::LowerDFGToB3::compileBooleanToNumber):
        (JSC::FTL::DFG::LowerDFGToB3::compileToThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithDiv):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithMod):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithMinOrMax):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithPow):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckStructure):
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayPop):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileCopyRest):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetRestLength):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::compileToPrimitive):
        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
        (JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileNotifyWrite):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileSwitch):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsString):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsObjectOrNull):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction):
        (JSC::FTL::DFG::LowerDFGToB3::compileTypeOf):
        (JSC::FTL::DFG::LowerDFGToB3::compileOverridesHasInstance):
        (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
        (JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):
        (JSC::FTL::DFG::LowerDFGToB3::compileHasStructureProperty):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorStructurePname):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorGenericPname):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckWatchdogTimer):
        (JSC::FTL::DFG::LowerDFGToB3::checkStructure):
        (JSC::FTL::DFG::LowerDFGToB3::numberOrNotCellToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::checkInferredType):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
        (JSC::FTL::DFG::LowerDFGToB3::loadVectorWithBarrier):
        (JSC::FTL::DFG::LowerDFGToB3::copyBarrier):
        (JSC::FTL::DFG::LowerDFGToB3::loadVectorReadOnly):
        (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject):
        (JSC::FTL::DFG::LowerDFGToB3::nonSpeculativeCompare):
        (JSC::FTL::DFG::LowerDFGToB3::stringsEqual):
        (JSC::FTL::DFG::LowerDFGToB3::allocateCell):
        (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateBasicStorageAndGetEnd):
        (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::boolify):
        (JSC::FTL::DFG::LowerDFGToB3::equalNullOrUndefined):
        (JSC::FTL::DFG::LowerDFGToB3::contiguousPutByValOutOfBounds):
        (JSC::FTL::DFG::LowerDFGToB3::switchString):
        (JSC::FTL::DFG::LowerDFGToB3::switchStringRecurse):
        (JSC::FTL::DFG::LowerDFGToB3::buildTypeOf):
        (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::strictInt52ToJSValue):
        (JSC::FTL::DFG::LowerDFGToB3::jsValueToStrictInt52):
        (JSC::FTL::DFG::LowerDFGToB3::convertDoubleToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::speculate):
        (JSC::FTL::DFG::LowerDFGToB3::speculateCellOrOther):
        (JSC::FTL::DFG::LowerDFGToB3::speculateObjectOrOther):
        (JSC::FTL::DFG::LowerDFGToB3::speculateString):
        (JSC::FTL::DFG::LowerDFGToB3::speculateStringOrOther):
        (JSC::FTL::DFG::LowerDFGToB3::speculateStringIdent):
        (JSC::FTL::DFG::LowerDFGToB3::speculateStringOrStringObject):
        (JSC::FTL::DFG::LowerDFGToB3::speculateRealNumber):
        (JSC::FTL::DFG::LowerDFGToB3::speculateNotStringVar):
        (JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
        (JSC::FTL::DFG::LowerDFGToB3::callCheck):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::initialize):
        (JSC::FTL::Output::newBlock):
        (JSC::FTL::Output::check):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::setFrequency):
        (JSC::FTL::Output::insertNewBlocksBefore):

2016-03-06  Saam Barati  <sbarati@apple.com>

        [[GetPrototypeOf]] should be a fully virtual method in the method table
        https://bugs.webkit.org/show_bug.cgi?id=155002

        Reviewed by Filip Pizlo.

        This patch makes us more consistent with how the ES6 specification models the
        [[GetPrototypeOf]] trap. Moving this method into ClassInfo::methodTable 
        is a prerequisite for implementing Proxy.[[GetPrototypeOf]]. This patch
        still allows directly accessing the prototype for situations where this
        is the desired behavior. This is equivalent to getting the internal
        [[Prototype]] field as described in the specification. 

        * API/JSObjectRef.cpp:
        (JSObjectGetPrototype):
        (JSObjectSetPrototype):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
        (JSC::DFG::SpeculativeJIT::compileCheckTypeInfoFlags):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
        (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOfCustom):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jsc.cpp:
        (functionCreateProxy):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ArrayPrototype.cpp:
        (JSC::speciesConstructArray):
        * runtime/ClassInfo.h:
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncBind):
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorPrototypeGetterCompare):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        * runtime/JSBoundFunction.cpp:
        (JSC::hasInstanceBoundFunction):
        (JSC::getBoundFunctionStructure):
        (JSC::JSBoundFunction::create):
        * runtime/JSBoundFunction.h:
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        * runtime/JSCell.cpp:
        (JSC::JSCell::setPrototype):
        (JSC::JSCell::getPrototype):
        * runtime/JSCell.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::hasLegacyProfiler):
        (JSC::lastInPrototypeChain):
        (JSC::JSGlobalObject::objectPrototypeIsSane):
        (JSC::JSGlobalObject::arrayPrototypeChainIsSane):
        (JSC::JSGlobalObject::stringPrototypeChainIsSane):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::finishCreation):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::GlobalFuncProtoGetterFunctor::GlobalFuncProtoGetterFunctor):
        (JSC::GlobalFuncProtoGetterFunctor::operator()):
        (JSC::globalFuncProtoGetter):
        * runtime/JSLexicalEnvironment.cpp:
        (JSC::JSLexicalEnvironment::getOwnPropertySlot):
        * runtime/JSObject.cpp:
        (JSC::JSObject::calculatedClassName):
        (JSC::JSObject::putInlineSlow):
        (JSC::JSObject::setPrototypeWithCycleCheck):
        (JSC::JSObject::setPrototype):
        (JSC::JSObject::getPrototype):
        (JSC::JSObject::defaultHasInstance):
        (JSC::objectPrivateFuncInstanceOf):
        (JSC::JSObject::getPropertyNames):
        (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
        (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
        (JSC::JSObject::getGenericPropertyNames):
        * runtime/JSObject.h:
        (JSC::JSObject::finishCreation):
        (JSC::JSObject::JSObject):
        (JSC::JSObject::getPrototypeDirect):
        (JSC::JSObject::getPrototype):
        (JSC::JSObject::getOwnNonIndexPropertySlot):
        (JSC::JSObject::getPropertySlot):
        (JSC::JSObject::getNonIndexPropertySlot):
        (JSC::JSObject::prototype): Deleted.
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::canPerformFastPutInline):
        * runtime/JSProxy.cpp:
        (JSC::JSProxy::setTarget):
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::constructTypedArrayView):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructorGetPrototypeOfFunctor::ObjectConstructorGetPrototypeOfFunctor):
        (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
        (JSC::objectConstructorGetPrototypeOf):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncIsPrototypeOf):
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performSetPrototype):
        * runtime/StructureInlines.h:
        (JSC::Structure::isValid):
        * tests/stress/proxy-has-property.js:
        (assert.let.h1.has):
        (assert.let.h2.has):
        (assert):

2016-03-06  Commit Queue  <commit-queue@webkit.org>

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

        "Doesn't build properly when building entire webkit"
        (Requested by saamyjoon on #webkit).

        Reverted changeset:

        "[[GetPrototypeOf]] should be a fully virtual method in the
        method table"
        https://bugs.webkit.org/show_bug.cgi?id=155002
        http://trac.webkit.org/changeset/197645

2016-03-06  Saam barati  <sbarati@apple.com>

        [[GetPrototypeOf]] should be a fully virtual method in the method table
        https://bugs.webkit.org/show_bug.cgi?id=155002

        Reviewed by Filip Pizlo.

        This patch makes us more consistent with how the ES6 specification models the
        [[GetPrototypeOf]] trap. Moving this method into ClassInfo::methodTable 
        is a prerequisite for implementing Proxy.[[GetPrototypeOf]]. This patch
        still allows directly accessing the prototype for situations where this
        is the desired behavior. This is equivalent to getting the internal
        [[Prototype]] field as described in the specification. 

        * API/JSObjectRef.cpp:
        (JSObjectGetPrototype):
        (JSObjectSetPrototype):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
        (JSC::DFG::SpeculativeJIT::compileCheckTypeInfoFlags):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
        (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOfCustom):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jsc.cpp:
        (functionCreateProxy):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ArrayPrototype.cpp:
        (JSC::speciesConstructArray):
        * runtime/ClassInfo.h:
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncBind):
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorPrototypeGetterCompare):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        * runtime/JSBoundFunction.cpp:
        (JSC::hasInstanceBoundFunction):
        (JSC::getBoundFunctionStructure):
        (JSC::JSBoundFunction::create):
        * runtime/JSBoundFunction.h:
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        * runtime/JSCell.cpp:
        (JSC::JSCell::setPrototype):
        (JSC::JSCell::getPrototype):
        * runtime/JSCell.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::hasLegacyProfiler):
        (JSC::lastInPrototypeChain):
        (JSC::JSGlobalObject::objectPrototypeIsSane):
        (JSC::JSGlobalObject::arrayPrototypeChainIsSane):
        (JSC::JSGlobalObject::stringPrototypeChainIsSane):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::finishCreation):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::GlobalFuncProtoGetterFunctor::GlobalFuncProtoGetterFunctor):
        (JSC::GlobalFuncProtoGetterFunctor::operator()):
        (JSC::globalFuncProtoGetter):
        * runtime/JSLexicalEnvironment.cpp:
        (JSC::JSLexicalEnvironment::getOwnPropertySlot):
        * runtime/JSObject.cpp:
        (JSC::JSObject::calculatedClassName):
        (JSC::JSObject::putInlineSlow):
        (JSC::JSObject::setPrototypeWithCycleCheck):
        (JSC::JSObject::setPrototype):
        (JSC::JSObject::getPrototype):
        (JSC::JSObject::defaultHasInstance):
        (JSC::objectPrivateFuncInstanceOf):
        (JSC::JSObject::getPropertyNames):
        (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
        (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
        (JSC::JSObject::getGenericPropertyNames):
        * runtime/JSObject.h:
        (JSC::JSObject::finishCreation):
        (JSC::JSObject::JSObject):
        (JSC::JSObject::getPrototypeDirect):
        (JSC::JSObject::getPrototype):
        (JSC::JSObject::getOwnNonIndexPropertySlot):
        (JSC::JSObject::getPropertySlot):
        (JSC::JSObject::getNonIndexPropertySlot):
        (JSC::JSObject::prototype): Deleted.
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::canPerformFastPutInline):
        * runtime/JSProxy.cpp:
        (JSC::JSProxy::setTarget):
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::constructTypedArrayView):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructorGetPrototypeOfFunctor::ObjectConstructorGetPrototypeOfFunctor):
        (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
        (JSC::objectConstructorGetPrototypeOf):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncIsPrototypeOf):
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performSetPrototype):
        * runtime/StructureInlines.h:
        (JSC::Structure::isValid):
        * tests/stress/proxy-has-property.js:
        (assert.let.h1.has):
        (assert.let.h2.has):
        (assert):

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

        RegExpMatchesArray doesn't know how to have a bad time
        https://bugs.webkit.org/show_bug.cgi?id=155069

        Reviewed by Yusuke Suzuki.

        In trunk if we are having a bad time, the regexp matches array is still allocated with a
        non-slow-put indexing shape, which makes it have the wrong behavior on indexed setters on
        the prototype chain.

        Getting this to work right requires introducing bad time code paths into the regexp matches
        array. It also requires something more drastic: making this code not play games with the
        global object. The code that creates the matches array needs to have the actual global
        object of the regexp native function that it's logically created by.

        This is totally different from how we've handled global objects in the past because it means
        that the global object is not a constant. Normally we can make it a constant because a
        script executable will know its global object. But with native functions, it's the function
        instance that knows the global object - not the native executable. When we inline a native
        intrinsic, we are guaranteed to know the native executable but we're not guaranteed to know
        the functon instance. This means that the global object may be a variable that gets computed
        by looking at the instance at run-time. So, the RegExpExec/RegExpTest nodes in DFG IR now
        take a global object child. That also meant adding a new node type, GetGlobalObject, which
        does the thing to the callee that CallFrame::lexicalGlobalObject() would have done.
        Eventually, we'll probably have to make other native intrinsics also use GetGlobalObject. It
        turns out that this really isn't so bad because usually it's constant-folded anyway, since
        although the intrinsic code supports executable-based inlining (which leaves the callee
        instance as an unknown), it happens rarely for intrinsics. So, conveying the global object
        via a child isn't any worse than conveying it via meta-data, and it's probably better than
        telling the inliner not to do executable-based inlining of native intrinsics. That would
        have been a confusing special-case.

        This is perf-neutral on my machines but it fixes a bug and it unlocks some interesting
        possibilities. For example, RegExpExec can now make a firm promise about the type of array
        it's creating.

        This also contains some other changes:
        
        - We are now using Structure::addPropertyTransition() in a lot of places even though it was
          meant to be an internal method with a quirky contract - for example if only works if you
          know that there is not existing transition. This relaxes this constraint.
        
        - Restores the use of "*" for heap references in JSString.h. It's very unusual to have heap
          references pointed at with "&", since we don't currently do that anywhere. The fact that
          it was using the wrong reference type also meant that the code couldn't elegantly make use
          of some our GC pointer helpers like jsCast<>.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::handleMinMax):
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * 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::compileSkipScope):
        (JSC::DFG::SpeculativeJIT::compileGetGlobalObject):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        * dfg/DFGSpeculativeJIT.h:
        (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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileSkipScope):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetGlobalObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetClosureVar):
        (JSC::FTL::DFG::LowerDFGToB3::compileRegExpExec):
        (JSC::FTL::DFG::LowerDFGToB3::compileRegExpTest):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
        * jit/JITOperations.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::haveABadTime):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        * runtime/JSObject.h:
        (JSC::JSObject::putDirectInternal):
        * runtime/JSString.h:
        (JSC::jsString):
        (JSC::jsSubstring):
        * runtime/RegExpCachedResult.cpp:
        (JSC::RegExpCachedResult::lastResult):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::tryCreateUninitializedRegExpMatchesArray):
        (JSC::createRegExpMatchesArray):
        (JSC::createStructureImpl):
        (JSC::createRegExpMatchesArrayStructure):
        (JSC::createRegExpMatchesArraySlowPutStructure):
        * runtime/RegExpMatchesArray.h:
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::put):
        (JSC::RegExpObject::exec):
        (JSC::RegExpObject::match):
        * runtime/RegExpObject.h:
        (JSC::RegExpObject::getLastIndex):
        (JSC::RegExpObject::test):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncTest):
        (JSC::regExpProtoFuncExec):
        (JSC::regExpProtoFuncCompile):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncMatch):
        * runtime/Structure.cpp:
        (JSC::Structure::suggestedArrayStorageTransition):
        (JSC::Structure::addPropertyTransition):
        (JSC::Structure::addNewPropertyTransition):
        * runtime/Structure.h:
        * tests/stress/regexp-matches-array-bad-time.js: Added.
        * tests/stress/regexp-matches-array-slow-put.js: Added.

2016-03-06  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] RegExp#lastIndex should handle writable attribute when defining in defineOwnProperty path
        https://bugs.webkit.org/show_bug.cgi?id=155093

        Reviewed by Filip Pizlo.

        Before this patch, `setLastIndex(ExecState* exec, size_t lastIndex)` always overwrites the existing value
        regardless of writable attribute.
        And when defining RegExp#lastIndex in defineOwnProperty, we need to define the value first
        before making the attribute readonly. After changing the writable attribute, we cannot define the value.

        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::defineOwnProperty):
        * runtime/RegExpObject.h:
        (JSC::RegExpObject::setLastIndex):
        * tests/stress/regexp-last-index-writable.js: Added.
        (shouldBe):
        (shouldThrow):
        (regExpLastIndex):

2016-03-05  Filip Pizlo  <fpizlo@apple.com>

        The most aggressive form of RegExpTest/RegExpExec should speculate more aggressively than just cell
        https://bugs.webkit.org/show_bug.cgi?id=154900

        Reviewed by Saam Barati.

        These old operations used to speculate cell. That's what they did when they were first
        introduced. That was probably about as good as they could do back then because we didn't have
        very powerful checks. Now we have powerful checks, so we can do this right.

        The most profitable thing to check is that child1 is a RegExpObject and child2 is a JSString.
        Sometimes though, we will not know what child2 is even though we know that child1 is a
        RegExpObject. So, this patch means that RegExpExec/RegExpTest have the following overloads:

            RegExpExec(RegExpObject:, String:)
            RegExpExec(RegExpObject:, Untyped:)
            RegExpExec(Untyped:, Untyped:)

        This shaves off some type checks in Octane/regexp. It also cleans up some problems in our
        modeling of the effectfulness of these operations.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileRegExpExec):
        (JSC::FTL::DFG::LowerDFGToB3::compileRegExpTest):
        * jit/JITOperations.h:

2016-03-05  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Support Reflect.construct
        https://bugs.webkit.org/show_bug.cgi?id=147330

        Reviewed by Saam Barati.

        Based on Saam's r196868, this patch adds support for Reflect.construct.
        This patch implements OrdinaryCreateFromConstructor[1] for fallback cases.
        This path is rarely taken. For example,

            Reflect.construct(function () { }, [], Map);

        In this case, the `new.target` becomes `Map`.
        So we should create an object that `__proto__` is `Map.prototype`.

        And to allow forward declaration (and encouraging strong type checking), we change
        ConstructType, CallType to C++11 enum class.

        [1]: http://ecma-international.org/ecma-262/6.0/#sec-ordinarycreatefromconstructor

        * API/JSCallbackConstructor.cpp:
        (JSC::JSCallbackConstructor::getConstructData):
        * API/JSCallbackFunction.cpp:
        (JSC::JSCallbackFunction::getCallData):
        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::getConstructData):
        (JSC::JSCallbackObject<Parent>::getCallData):
        * API/JSObjectRef.cpp:
        (JSObjectIsFunction):
        (JSObjectCallAsFunction):
        (JSObjectIsConstructor):
        (JSObjectCallAsConstructor):
        * API/ObjCCallbackFunction.mm:
        (JSC::ObjCCallbackFunction::getCallData):
        (JSC::ObjCCallbackFunction::getConstructData):
        * bindings/ScriptFunctionCall.cpp:
        (Deprecated::ScriptFunctionCall::call):
        * bindings/ScriptValue.cpp:
        (Deprecated::ScriptValue::isFunction):
        * builtins/ReflectObject.js:
        * dfg/DFGOperations.cpp:
        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::createInjectedScript):
        * interpreter/Interpreter.cpp:
        (JSC::sizeOfVarargs):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::handleHostCall):
        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::getConstructData):
        (JSC::ArrayConstructor::getCallData):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncToString):
        (JSC::arrayProtoFuncToLocaleString):
        (JSC::getLength): Deleted.
        * runtime/BooleanConstructor.cpp:
        (JSC::BooleanConstructor::getConstructData):
        (JSC::BooleanConstructor::getCallData):
        * runtime/CallData.cpp:
        (JSC::call):
        * runtime/CallData.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/ConstructData.cpp:
        (JSC::construct):
        * runtime/ConstructData.h:
        * runtime/DateConstructor.cpp:
        (JSC::DateConstructor::getConstructData):
        (JSC::DateConstructor::getCallData):
        * runtime/DatePrototype.cpp:
        (JSC::dateProtoFuncToJSON):
        * runtime/Error.h:
        (JSC::StrictModeTypeErrorFunction::getConstructData):
        (JSC::StrictModeTypeErrorFunction::getCallData):
        * runtime/ErrorConstructor.cpp:
        (JSC::ErrorConstructor::getConstructData):
        (JSC::ErrorConstructor::getCallData):
        * runtime/ExceptionHelpers.cpp:
        (JSC::errorDescriptionForValue):
        * runtime/FunctionConstructor.cpp:
        (JSC::FunctionConstructor::getConstructData):
        (JSC::FunctionConstructor::getCallData):
        * runtime/FunctionPrototype.cpp:
        (JSC::FunctionPrototype::getCallData):
        (JSC::functionProtoFuncToString):
        (JSC::functionProtoFuncBind):
        * runtime/GeneratorFunctionConstructor.cpp:
        (JSC::GeneratorFunctionConstructor::getCallData):
        (JSC::GeneratorFunctionConstructor::getConstructData):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::getCallData):
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::IntlCollatorConstructor::getConstructData):
        (JSC::IntlCollatorConstructor::getCallData):
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::IntlDateTimeFormatConstructor::getConstructData):
        (JSC::IntlDateTimeFormatConstructor::getCallData):
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::IntlNumberFormatConstructor::getConstructData):
        (JSC::IntlNumberFormatConstructor::getCallData):
        * runtime/IteratorOperations.cpp:
        (JSC::iteratorNext):
        (JSC::iteratorClose):
        * runtime/JSArray.h:
        (JSC::getLength):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::JSArrayBufferConstructor::getConstructData):
        (JSC::JSArrayBufferConstructor::getCallData):
        * runtime/JSBoundFunction.cpp:
        (JSC::boundFunctionCall):
        (JSC::boundFunctionConstruct):
        (JSC::JSBoundFunction::create):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::isFunction):
        (JSC::JSValue::isConstructor):
        * runtime/JSCell.cpp:
        (JSC::JSCell::getCallData):
        (JSC::JSCell::getConstructData):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getCallData):
        (JSC::JSFunction::getConstructData):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewWithArguments):
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::getConstructData):
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::getCallData):
        * runtime/JSInternalPromise.cpp:
        (JSC::JSInternalPromise::then):
        * runtime/JSInternalPromiseConstructor.cpp:
        (JSC::JSInternalPromiseConstructor::getConstructData):
        (JSC::JSInternalPromiseConstructor::getCallData):
        * runtime/JSJob.cpp:
        (JSC::JSJobMicrotask::run):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Stringifier):
        (JSC::Stringifier::toJSONImpl):
        (JSC::Stringifier::appendStringifiedValue):
        (JSC::JSONProtoFuncParse):
        * runtime/JSObject.cpp:
        (JSC::callToPrimitiveFunction):
        (JSC::JSObject::hasInstance):
        (JSC::JSObject::getMethod):
        * runtime/JSObject.h:
        (JSC::getCallData):
        (JSC::getConstructData):
        * runtime/JSPromise.cpp:
        (JSC::JSPromise::initialize):
        * runtime/JSPromiseConstructor.cpp:
        (JSC::JSPromiseConstructor::getConstructData):
        (JSC::JSPromiseConstructor::getCallData):
        * runtime/JSPromiseDeferred.cpp:
        (JSC::newPromiseCapability):
        (JSC::callFunction):
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::constructTypedArrayView):
        (JSC::JSTypedArrayViewConstructor::getConstructData):
        (JSC::JSTypedArrayViewConstructor::getCallData):
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        (JSC::MapConstructor::getConstructData):
        (JSC::MapConstructor::getCallData):
        * runtime/ModuleLoaderObject.cpp:
        (JSC::ModuleLoaderObject::provide):
        (JSC::ModuleLoaderObject::loadAndEvaluateModule):
        (JSC::ModuleLoaderObject::loadModule):
        (JSC::ModuleLoaderObject::linkAndEvaluateModule):
        * runtime/NativeErrorConstructor.cpp:
        (JSC::NativeErrorConstructor::getConstructData):
        (JSC::NativeErrorConstructor::getCallData):
        * runtime/NullGetterFunction.cpp:
        (JSC::NullGetterFunction::getCallData):
        (JSC::NullGetterFunction::getConstructData):
        * runtime/NullSetterFunction.cpp:
        (JSC::NullSetterFunction::getCallData):
        (JSC::NullSetterFunction::getConstructData):
        * runtime/NumberConstructor.cpp:
        (JSC::NumberConstructor::getConstructData):
        (JSC::NumberConstructor::getCallData):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::getConstructData):
        (JSC::ObjectConstructor::getCallData):
        (JSC::toPropertyDescriptor):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncDefineGetter):
        (JSC::objectProtoFuncDefineSetter):
        (JSC::objectProtoFuncToLocaleString):
        * runtime/Operations.cpp:
        (JSC::jsTypeStringForValue):
        (JSC::jsIsObjectTypeOrNull):
        (JSC::jsIsFunctionType):
        * runtime/ProxyConstructor.cpp:
        (JSC::ProxyConstructor::getConstructData):
        (JSC::ProxyConstructor::getCallData):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::finishCreation):
        (JSC::performProxyCall):
        (JSC::ProxyObject::getCallData):
        (JSC::performProxyConstruct):
        (JSC::ProxyObject::getConstructData):
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectConstruct):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::getConstructData):
        (JSC::RegExpConstructor::getCallData):
        * runtime/RuntimeType.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):
        (JSC::SetConstructor::getConstructData):
        (JSC::SetConstructor::getCallData):
        * runtime/StringConstructor.cpp:
        (JSC::StringConstructor::getConstructData):
        (JSC::StringConstructor::getCallData):
        * runtime/StringPrototype.cpp:
        (JSC::replaceUsingRegExpSearch):
        (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
        (JSC::operationStringProtoFuncReplaceRegExpString):
        (JSC::replaceUsingStringSearch):
        * runtime/SymbolConstructor.cpp:
        (JSC::SymbolConstructor::getConstructData):
        (JSC::SymbolConstructor::getCallData):
        * runtime/WeakMapConstructor.cpp:
        (JSC::constructWeakMap):
        (JSC::WeakMapConstructor::getConstructData):
        (JSC::WeakMapConstructor::getCallData):
        * runtime/WeakSetConstructor.cpp:
        (JSC::constructWeakSet):
        (JSC::WeakSetConstructor::getConstructData):
        (JSC::WeakSetConstructor::getCallData):
        * tests/es6.yaml:
        * tests/stress/reflect-construct.js: Added.
        (shouldBe):
        (shouldThrow):
        (shouldThrow.array.get length):
        (shouldThrow.array.get 0):
        (array.get length):
        (array.get 0):
        (shouldBe.Reflect.construct):
        (shouldBe.Reflect.construct.Hello):
        (3.shouldBe.Reflect.construct.Hello):
        (3.newTarget):
        (0.shouldBe.Reflect.construct):
        (shouldBe.A):
        (shouldBe.B):
        (nativeConstructorTest.DerivedMap):
        (nativeConstructorTest.FailedMap):
        (set noInline):

2016-03-04  Andreas Kling  <akling@apple.com>

        [iOS] Throw away compiled RegExp code when navigating to a new page.
        <https://webkit.org/b/155015>

        Reviewed by Anders Carlsson.

        Add a mechanism to have the VM discard all RegExp bytecode and JIT code.

        * runtime/VM.cpp:
        (JSC::VM::deleteAllRegExpCode):
        * runtime/VM.h:

2016-03-04  David Kilzer  <ddkilzer@apple.com>

        REGRESSION (r197531): JavaScriptCore ASan build fails due to weak external symbol
        <http://webkit.org/b/155033>
        <rdar://problem/24979661>

        Reviewed by Alexey Proskuryakov.

        * runtime/JSObject.cpp:
        (JSC::JSObject::ordinaryToPrimitive): Don't mark this method
        inline since it's also used in DatePrototype.cpp, and is
        declared as a public class method.
        * runtime/JSObject.h:
        (JSC::JSObject::ordinaryToPrimitive): Don't export this method
        since it is not used outside of JavaScriptCore.

2016-03-04  Alex Christensen  <achristensen@webkit.org>

        Remove vcxproj build system
        https://bugs.webkit.org/show_bug.cgi?id=154388

        Rubber-stamped by Brent Fulgham.

        * JavaScriptCore.vcxproj/JavaScriptCore.sln: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCore.submit.sln: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreCF.props: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreCFLite.props: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreDLL.cpp: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreDebug.props: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreDebugCFLite.props: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj.filters: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedCommon.props: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedDebug.props: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedProduction.props: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedRelease.props: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCorePostBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCorePreBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCorePreLink.cmd: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreProduction.props: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreRelease.props: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreReleaseCFLite.props: Removed.
        * JavaScriptCore.vcxproj/build-generated-files.pl: Removed.
        * JavaScriptCore.vcxproj/copy-files.cmd: Removed.

2016-03-04  Chris Dumez  <cdumez@apple.com>

        Location.reload should not be writable
        https://bugs.webkit.org/show_bug.cgi?id=154989

        Reviewed by Gavin Barraclough.

        After r196770, operations marked as [Unforgeable] in the IDL (such as
        Location.reload) are correctly reported as not writable by
        Object.getOwnPropertyDescriptor(). Trying to set such property in JS
        is correctly ignored (or throws in strict mode) if the object has
        previously been reified. However, due to a bug in putEntry(), it was
        still possible to override the property if the object was not reified
        yet. This patch fixes the issue by checking in putEntry() that entries
        that are functions are not ReadOnly before calling putDirect().

        * runtime/Lookup.h:
        (JSC::putEntry):

2016-03-04  Skachkov Oleksandr  <gskachkov@gmail.com>

        [ES6] Arrow function syntax. Lexical bind "super" inside of the arrow function in generator.
        https://bugs.webkit.org/show_bug.cgi?id=152575

        Reviewed by Yusuke Suzuki.

        Added support of the 'SuperProperty' in arrow function within of the generator 
        method of class. Before patch parser  did not recognize that current arrow function 
        is declated inside of the generator and raise SyntaxError.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::isGeneratorBoundary):
        (JSC::Scope::setIsFunction):
        (JSC::Scope::setIsGenerator):
        (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope):
        * tests/stress/arrowfunction-lexical-bind-superproperty.js:

2016-03-03  Filip Pizlo  <fpizlo@apple.com>

        DFG/FTL should inline accesses to RegExpObject::m_lastIndex
        https://bugs.webkit.org/show_bug.cgi?id=155003

        Reviewed by Benjamin Poulain.

        The Octane/regexp benchmark sets RegExps' lastIndex a lot. I could imagine this being
        something that people want to do. Right now, I'm not convinced that making the RegExp object
        be more plain-JS would be a good idea considering that pretty much all uses of it will
        require some special compiler magic. Also, it's good that this patch teaches the compiler
        how to reason about lastIndex since some of my other plans for regexp involve having the
        compiler treat more regexp stuff as intrinsic.

        This is a smaller Octane/regexp speed-up than I hoped - maybe around 1%. It's an enormous
        speed-up on the microbenchmarks attached to this patch.

        * dfg/DFGAbstractHeap.h:
        * 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/DFGHeapLocation.h:
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePutAccessorByVal):
        (JSC::DFG::SpeculativeJIT::compileGetRegExpObjectLastIndex):
        (JSC::DFG::SpeculativeJIT::compileSetRegExpObjectLastIndex):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * ftl/FTLAbstractHeapRepository.cpp:
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetRegExpObjectLastIndex):
        (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
        (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
        (JSC::FTL::DFG::LowerDFGToB3::lowObject):
        (JSC::FTL::DFG::LowerDFGToB3::lowRegExpObject):
        (JSC::FTL::DFG::LowerDFGToB3::lowString):
        * runtime/RegExpObject.h:
        (JSC::RegExpObject::createStructure):
        (JSC::RegExpObject::offsetOfLastIndex):

2016-03-03  Chris Dumez  <cdumez@apple.com>

        Regression(r196770): Unable to use HipChat Mac app
        https://bugs.webkit.org/show_bug.cgi?id=154999
        <rdar://problem/24931959>

        Reviewed by Darin Adler.

        Add a setter to PutPropertySlot to override the 'isStrictMode' flag.

        * runtime/PutPropertySlot.h:
        (JSC::PutPropertySlot::setStrictMode):

2016-03-03  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add support for MADD, MSUB and MNEG to Air
        https://bugs.webkit.org/show_bug.cgi?id=154997

        Reviewed by Filip Pizlo.

        ARM64 can do an Add/Sub in the Multiply units.
        LLVM was doing so but we lost that when switching to B3.

        This patch adds those instructions in Air.

        There are more ALUs than multiply units, thus we are more
        likely to successfully schedule a Multiply+Add than 2 Multiply.
        I am conservative and only emit a multiply-add if the value
        can be interned. As far as I can tell from what is generated
        by LLVM, that backend had the same rule.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::multiplyAdd32):
        (JSC::MacroAssemblerARM64::multiplySub32):
        (JSC::MacroAssemblerARM64::multiplyNeg32):
        (JSC::MacroAssemblerARM64::multiplyAdd64):
        (JSC::MacroAssemblerARM64::multiplySub64):
        (JSC::MacroAssemblerARM64::multiplyNeg64):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::populateWithInterestingValues):
        (JSC::B3::floatingPointOperands):
        (JSC::B3::int64Operands):
        (JSC::B3::int32Operands):
        (JSC::B3::testMulAddArgsLeft):
        (JSC::B3::testMulAddArgsRight):
        (JSC::B3::testMulAddArgsLeft32):
        (JSC::B3::testMulAddArgsRight32):
        (JSC::B3::testMulSubArgsLeft):
        (JSC::B3::testMulSubArgsRight):
        (JSC::B3::testMulSubArgsLeft32):
        (JSC::B3::testMulSubArgsRight32):
        (JSC::B3::testMulNegArgs):
        (JSC::B3::testMulNegArgs32):
        (JSC::B3::run):

2016-03-03  Saam Barati  <sbarati@apple.com>

        [ES6] Implement Proxy.[[SetPrototypeOf]]
        https://bugs.webkit.org/show_bug.cgi?id=154931

        Reviewed by Ryosuke Niwa.

        This patch is a straight forward implementation of Proxy.[[SetPrototypeOf]]
        with respect to section 9.5.2 of the ECMAScript spec.
        https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-setprototypeof-v

        * runtime/JSObject.cpp:
        (JSC::JSObject::putInlineSlow):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::put):
        (JSC::ProxyObject::getGenericPropertyNames):
        (JSC::ProxyObject::performSetPrototype):
        (JSC::ProxyObject::setPrototype):
        (JSC::ProxyObject::visitChildren):
        * runtime/ProxyObject.h:
        * tests/es6.yaml:
        * tests/stress/proxy-set-prototype-of.js: Added.
        (assert):
        (throw.new.Error.let.handler.get setPrototypeOf):
        (throw.new.Error.set let):
        (throw.new.Error.set catch):
        (throw.new.Error):
        (assert.let.handler.setPrototypeOf):
        (assert.set let):
        (assert.set catch):
        (let.handler.setPrototypeOf):
        (set let):
        (set catch):

2016-03-03  Keith Miller  <keith_miller@apple.com>

        JSArrayBuffers should be collected less aggressively
        https://bugs.webkit.org/show_bug.cgi?id=154982

        Reviewed by Geoffrey Garen.

        We are currently too aggressive in our collection of ArrayBuffer wrappers.
        There are three cases where we need to avoid collecting ArrayBuffer wrappers.
        1. If the wrapper has custom properties.
        2. If the wrapper is a subclass of ArrayBuffer.
        3. If the wrapper is in a WeakMap/WeakSet.

        Currently, we only pass the first case in WebCore and none in the jsc CLI.
        This patch removes some optimizations that cause us to collect when we
        should not. Namely, always skipping the object unless it has custom
        properties. Additionally, in the case of subclassing, we also need a way
        for custom JSArrayBuffer objects to register themselves as the wrapper for
        an ArrayBuffer class.

        Finally, this patch fixes an issue where views would not mark their ArrayBuffer
        as an opaque root. This patch also moves an associated ASSERT that the
        ArrayBuffer held by a view is not null in JSGenericTypedArrayView::visitChildren
        into JSArrayBufferView::visitChildren, where we add the opaque root.

        * runtime/JSArrayBuffer.cpp:
        (JSC::JSArrayBuffer::finishCreation):
        (JSC::JSArrayBuffer::create):
        (JSC::JSArrayBuffer::createWithoutWrapping):
        * runtime/JSArrayBuffer.h:
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::visitChildren):
        * runtime/JSArrayBufferView.h:
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): Deleted.
        * runtime/SimpleTypedArrayController.cpp:
        (JSC::SimpleTypedArrayController::toJS):
        (JSC::SimpleTypedArrayController::registerWrapper):
        (JSC::SimpleTypedArrayController::JSArrayBufferOwner::isReachableFromOpaqueRoots):
        (JSC::SimpleTypedArrayController::JSArrayBufferOwner::finalize):
        * runtime/SimpleTypedArrayController.h:
        * runtime/TypedArrayController.h:

2016-03-03  Filip Pizlo  <fpizlo@apple.com>

        Octane/regexp's Exec function should benefit from array length accessor inlining
        https://bugs.webkit.org/show_bug.cgi?id=154994

        Reviewed by Benjamin Poulain.

        It does:

            var thingy = blahbitty.blah;
            if (thingy)
                foo = thingy.length;

        So, 'thingy' is SpecArray | SpecOther, which prevents the array length accessor inlining from
        kicking in. Our strategy for this elsewhere in the DFG is to allow a one-time speculation that
        we won't see SpecOther, since *usually* we see SpecOther mixed with other stuff in cases like
        this where there is some null check guarding the code.

        This gives another slight speed-up on Octane/regexp.

        * bytecode/SpeculatedType.h:
        (JSC::isCellSpeculation):
        (JSC::isCellOrOtherSpeculation):
        (JSC::isNotCellSpeculation):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::shouldSpeculateCell):
        (JSC::DFG::Node::shouldSpeculateCellOrOther):
        (JSC::DFG::Node::shouldSpeculateNotCell):

2016-03-03  Saam Barati  <sbarati@apple.com>

        Add Proxy tests for exceptions that depend on an object being non-extensible and having configurable properties
        https://bugs.webkit.org/show_bug.cgi?id=154745

        Reviewed by Geoffrey Garen.

        This patch is mostly an implementation of Proxy.[[OwnPropertyKeys]] 
        with respect to section 9.5.11 of the ECMAScript spec.
        https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-ownpropertykeys

        This patch also changes call sites of getOwnPropertyNames and
        getPropertyNames to expect that an exception can be thrown.

        * dfg/DFGOperations.cpp:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::iteratorEntries):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * runtime/IntlObject.cpp:
        (JSC::supportedLocales):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::get):
        (JSC::JSValue::put):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Holder::appendNextProperty):
        (JSC::Walker::walk):
        * runtime/JSObject.cpp:
        (JSC::JSObject::getPropertyNames):
        (JSC::JSObject::getGenericPropertyNames):
        * runtime/JSObject.h:
        (JSC::makeIdentifier):
        (JSC::createListFromArrayLike):
        * runtime/JSPropertyNameEnumerator.h:
        (JSC::propertyNameEnumerator):
        * runtime/JSPropertyNameIterator.cpp:
        (JSC::JSPropertyNameIterator::create):
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/ObjectConstructor.cpp:
        (JSC::defineProperties):
        (JSC::objectConstructorSeal):
        (JSC::objectConstructorFreeze):
        (JSC::objectConstructorIsSealed):
        (JSC::objectConstructorIsFrozen):
        (JSC::ownPropertyKeys):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::getOwnPropertySlotByIndex):
        (JSC::ProxyObject::deleteProperty):
        (JSC::ProxyObject::deletePropertyByIndex):
        (JSC::ProxyObject::defineOwnProperty):
        (JSC::ProxyObject::performGetOwnPropertyNames):
        (JSC::ProxyObject::getOwnPropertyNames):
        (JSC::ProxyObject::getOwnNonIndexPropertyNames):
        (JSC::ProxyObject::getStructurePropertyNames):
        (JSC::ProxyObject::getGenericPropertyNames):
        (JSC::ProxyObject::visitChildren):
        * runtime/ProxyObject.h:
        (JSC::ProxyObject::create):
        (JSC::ProxyObject::createStructure):
        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        (JSC::Structure::add):
        (JSC::Structure::getPropertyNamesFromStructure):
        (JSC::Structure::checkConsistency):
        (JSC::Structure::canCachePropertyNameEnumerator):
        (JSC::Structure::canAccessPropertiesQuicklyForEnumeration):
        (JSC::Structure::canAccessPropertiesQuickly): Deleted.
        * runtime/Structure.h:
        * runtime/WeakMapConstructor.cpp:
        (JSC::constructWeakMap):
        * tests/es6.yaml:
        * tests/stress/proxy-own-keys.js: Added.
        (assert):
        (throw.new.Error.let.handler.ownKeys):
        (throw.new.Error):
        (assert.let.handler.get ownKeys):
        (assert.let.handler.ownKeys):
        (let.handler.ownKeys):
        (i.catch):
        (shallowEq):
        (let.handler.getOwnPropertyDescriptor):
        (i.set assert):
        (set add):
        (set assert):
        (set if):

2016-03-03  Keith Miller  <keith_miller@apple.com>

        Array prototype JS builtins should support Symbol.species
        https://bugs.webkit.org/show_bug.cgi?id=154710

        Reviewed by Geoffrey Garen.

        Add support for Symbol.species in the Array.prototype JS
        builtin functions.

        * builtins/ArrayPrototype.js:
        (filter):
        (map):
        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
        * runtime/ArrayConstructor.h:
        (JSC::ArrayConstructor::create):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * tests/stress/array-species-functions.js:
        (id):

2016-03-03  Michael Saboff  <msaboff@apple.com>

        [ES6] Make Unicode RegExp pattern parsing conform to the spec
        https://bugs.webkit.org/show_bug.cgi?id=154988

        Reviewed by Benjamin Poulain.

        Updated RegExp pattern processing with 'u' (Unicode) flag to conform to the
        spec (https://tc39.github.io/ecma262/2016/#sec-patterns).  In the spec, the
        grammar is annotated with [U] annotations.  Productions that are prefixed with
        [+U] are only available with the Unicode flags while productions prefixed with
        [~U] are only available without the Unicode flag.
        
        Added flags argument to Yarr::checkSyntax() so we can catch Unicode flag related
        parsing errors at syntax checking time.  Restricted what escapes are available for
        non Unicode patterns.  Most of this is defined in the IdentityEscape rule in the
        pattern grammar.

        Added \- as a CharacterClass only escape in Unicode patterns.

        Updated the tests for these changes.

        Made changes suggested in https://bugs.webkit.org/show_bug.cgi?id=154842#c22 after
        change set r197426 was landed.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createRegExp):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createRegExp):
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::InputStream::readChecked):
        (JSC::Yarr::Interpreter::InputStream::readSurrogatePairChecked):
        (JSC::Yarr::Interpreter::InputStream::reread):
        (JSC::Yarr::Interpreter::InputStream::uncheckInput):
        (JSC::Yarr::Interpreter::InputStream::atStart):
        (JSC::Yarr::Interpreter::InputStream::atEnd):
        (JSC::Yarr::Interpreter::testCharacterClass):
        (JSC::Yarr::Interpreter::backtrackPatternCharacter):
        (JSC::Yarr::Interpreter::matchDisjunction):
        (JSC::Yarr::ByteCompiler::atomPatternCharacter):
        * yarr/YarrParser.h:
        (JSC::Yarr::Parser::Parser):
        (JSC::Yarr::Parser::isIdentityEscapeAnError):
        (JSC::Yarr::Parser::parseEscape):
        (JSC::Yarr::Parser::parse):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::CharacterClassConstructor::putChar):
        (JSC::Yarr::CharacterClassConstructor::putRange):
        (JSC::Yarr::CharacterClassConstructor::addSorted):
        (JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets):
        * yarr/YarrSyntaxChecker.cpp:
        (JSC::Yarr::SyntaxChecker::disjunction):
        (JSC::Yarr::checkSyntax):
        * yarr/YarrSyntaxChecker.h:

2016-03-03  Saam barati  <sbarati@apple.com>

        [ES6] Implement Proxy.[[DefineOwnProperty]]
        https://bugs.webkit.org/show_bug.cgi?id=154759

        Reviewed by Geoffrey Garen and Mark Lam.

        This patch is a straight forward implementation of Proxy.[[DefineOwnProperty]]
        with respect to section 9.5.6 of the ECMAScript spec.
        https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-defineownproperty-p-desc

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetOwnPropertyDescriptor):
        (JSC::objectConstructorGetOwnPropertyDescriptors):
        * runtime/ObjectConstructor.h:
        (JSC::constructEmptyObject):
        (JSC::constructObjectFromPropertyDescriptor):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::isExtensible):
        (JSC::ProxyObject::performDefineOwnProperty):
        (JSC::ProxyObject::defineOwnProperty):
        (JSC::ProxyObject::visitChildren):
        * runtime/ProxyObject.h:
        * tests/es6.yaml:
        * tests/stress/proxy-define-own-property.js: Added.
        (assert):
        (throw.new.Error):
        (assert.let.handler.get defineProperty):
        (assert.let.handler.defineProperty):
        (let.handler.defineProperty):
        (i.catch):
        (assert.try.):
        (assert.set get catch):
        (assert.let.setter):
        (assert.let.getter):
        (assert.set get let.handler.defineProperty):
        (assert.set get let):
        (assert.):

2016-03-03  Keith Miller  <keith_miller@apple.com>

        [ES6] Add support for Symbol.toPrimitive
        https://bugs.webkit.org/show_bug.cgi?id=154877

        Reviewed by Saam Barati.

        This patch adds suport for Symbol.toPrimitive. Since we don't currently
        generate snippits for one side of a binary operation we only need to change
        the JSObject::ToPrimitive function and update some optimizations in the DFG
        that need to know how conversions to primitive values should work. As of
        ES6, the date prototype is also no longer special cased in the ToPrimitive
        operation. Instead, Date.prototype has a Symbol.species function that
        replicates the old behavior.

        * bytecode/ObjectPropertyConditionSet.cpp:
        (JSC::generateConditionsForPropertyMissConcurrently):
        * bytecode/ObjectPropertyConditionSet.h:
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::watchConditions):
        (JSC::DFG::Graph::canOptimizeStringObjectAccess):
        * dfg/DFGGraph.h:
        * runtime/CommonIdentifiers.h:
        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::finishCreation):
        (JSC::dateProtoFuncToPrimitiveSymbol):
        * runtime/Error.cpp:
        (JSC::throwTypeError):
        * runtime/Error.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::toPreferredPrimitiveType):
        * runtime/JSObject.cpp:
        (JSC::callToPrimitiveFunction):
        (JSC::JSObject::ordinaryToPrimitive):
        (JSC::JSObject::defaultValue):
        (JSC::JSObject::toPrimitive):
        (JSC::JSObject::getPrimitiveNumber):
        (JSC::callDefaultValueFunction): Deleted.
        (JSC::throwTypeError): Deleted.
        * runtime/JSObject.h:
        (JSC::JSObject::toPrimitive): Deleted.
        * runtime/SmallStrings.h:
        * runtime/SymbolPrototype.cpp:
        (JSC::SymbolPrototype::finishCreation):
        * runtime/SymbolPrototype.h:
        (JSC::SymbolPrototype::create):
        * tests/es6.yaml:
        * tests/stress/date-symbol-toprimitive.js: Added.
        * tests/stress/ropes-symbol-toprimitive.js: Added.
        (ropify):
        (String.prototype.Symbol.toPrimitive):
        * tests/stress/symbol-toprimitive.js: Added.
        (foo.Symbol.toPrimitive):
        (catch):

2016-03-03  Filip Pizlo  <fpizlo@apple.com>

        DFG should be able to compile StringReplace
        https://bugs.webkit.org/show_bug.cgi?id=154979

        Reviewed by Benjamin Poulain.

        Adds support for StringReplace to the DFG tier. This is a 3% speed-up on Octane/regexp.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculateFinalObject):
        (JSC::DFG::SpeculativeJIT::speculateRegExpObject):
        (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JITOperations.h:

2016-03-03  Saam barati  <sbarati@apple.com>

        [[SetPrototypeOf]] isn't properly implemented everywhere
        https://bugs.webkit.org/show_bug.cgi?id=154943

        Reviewed by Benjamin Poulain.

        We were copy-pasting implememntation bits that belong in OrdinarySetPrototypeOf 
        in a few different places that call O.[[SetPrototypeOf]](v)
        rather than having those bits in OrdinarySetPrototypeOf itself.
        We need to put those copy-pasted bits into OrdinarySetPrototypeOf
        and not the call sites of O.[[SetPrototypeOf]](v) because
        O.[[SetPrototypeOf]](v) won't always call into OrdinarySetPrototypeOf.
        This is needed for correctness because this behavior is now observable
        with the ES6 Proxy object.

        * runtime/ClassInfo.h:
        * runtime/JSCell.cpp:
        (JSC::JSCell::isExtensible):
        (JSC::JSCell::setPrototype):
        * runtime/JSCell.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoSetter):
        * runtime/JSObject.cpp:
        (JSC::JSObject::setPrototypeDirect):
        (JSC::JSObject::setPrototypeWithCycleCheck):
        (JSC::JSObject::setPrototype):
        (JSC::JSObject::allowsAccessFrom):
        * runtime/JSObject.h:
        (JSC::JSObject::mayInterceptIndexedAccesses):
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorSetPrototypeOf):
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectSetPrototypeOf):

2016-03-03  Alex Christensen  <achristensen@webkit.org>

        Fix Windows build after r197489.

        * jsc.cpp:

2016-03-02  Filip Pizlo  <fpizlo@apple.com>

        RegExpExec/RegExpTest should not unconditionally speculate cell
        https://bugs.webkit.org/show_bug.cgi?id=154901

        Reviewed by Benjamin Poulain.

        This is a three part change. It all started with a simple goal: end the rage-recompiles in
        Octane/regexp by enabling the DFG and FTL to do untyped RegExpExec/RegExpTest. This keeps us
        in the optimized code when you do a regexp match on a number, for example.

        While implementing this, I realized that DFGOperations.cpp was bad at exception checking. When
        it did check for exceptions, it used exec->hadException() instead of vm.exception(). So I
        fixed that. I also made sure that the regexp operations checked for exception after doing
        toString().

        Unfortunately, the introduction of untyped RegExpExec/RegExpTest caused a regression on
        Octane/regexp. This was because we were simultaneously scheduling replacement and OSR compiles
        of some large functions with the FTL JIT. The OSR compiles were not useful. This was a
        regression from the previous changes to make OSR compiles happen sooner. The problem is that
        this change also removed the throttling of OSR compiles even in those cases where we suspect
        that replacement is more likely. This patch reintroduces that throttling, but only in the
        replacement path.

        This change ends up being neutral overall.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileRegExpExec):
        (JSC::FTL::DFG::LowerDFGToB3::compileRegExpTest):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
        * tests/stress/regexp-exec-effect-after-exception.js: Added.

2016-03-02  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] JSCell_freeListNext and JSCell_structureID are considered not overlapping
        https://bugs.webkit.org/show_bug.cgi?id=154947

        Reviewed by Filip Pizlo.

        This bug was discovered while testing https://bugs.webkit.org/show_bug.cgi?id=154894.

        The problem was that JSCell_freeListNext and JSCell_structureID were
        considered as disjoint. When reordering instructions, the scheduler
        could move the write of the StructureID first to reduce dependencies.
        This would erase half of JSCell_freeListNext before we get a chance
        to load the value.

        This patch changes the hierarchy to make sure nothing is written
        until JSCell_freeListNext is processed.

        All credits for this patch go to Filip.

        * ftl/FTLAbstractHeapRepository.cpp:
        (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
        * ftl/FTLAbstractHeapRepository.h:

2016-03-02  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Improve Select of Doubles based on Double condition
        https://bugs.webkit.org/show_bug.cgi?id=154572

        Reviewed by Filip Pizlo.

        Octane has a bunch of Select on Double based on comparing Doubles.
        A few nodes generate that: ValueRep, Min, Max, etc.

        On ARM64, we can improve our code a lot. ARM can do a select
        based on flags with the FCSEL instruction.

        On x86, this patch adds aggressive aliasing for moveDoubleConditionallyXXX.
        This has obviously a much more limited impact.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::moveDoubleConditionally32): Deleted.
        (JSC::MacroAssembler::moveDoubleConditionally64): Deleted.
        (JSC::MacroAssembler::moveDoubleConditionallyTest32): Deleted.
        (JSC::MacroAssembler::moveDoubleConditionallyTest64): Deleted.
        (JSC::MacroAssembler::moveDoubleConditionallyDouble): Deleted.
        (JSC::MacroAssembler::moveDoubleConditionallyFloat): Deleted.
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::moveDoubleConditionallyAfterFloatingPointCompare):
        (JSC::MacroAssemblerARM64::moveDoubleConditionallyDouble):
        (JSC::MacroAssemblerARM64::moveDoubleConditionallyFloat):
        (JSC::MacroAssemblerARM64::moveConditionally32):
        (JSC::MacroAssemblerARM64::moveDoubleConditionally32):
        (JSC::MacroAssemblerARM64::moveDoubleConditionally64):
        (JSC::MacroAssemblerARM64::moveDoubleConditionallyTest32):
        (JSC::MacroAssemblerARM64::moveDoubleConditionallyTest64):
        (JSC::MacroAssemblerARM64::branch64):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::moveConditionally32):
        (JSC::MacroAssemblerX86Common::moveDoubleConditionally32):
        (JSC::MacroAssemblerX86Common::moveDoubleConditionallyTest32):
        (JSC::MacroAssemblerX86Common::moveDoubleConditionallyDouble):
        (JSC::MacroAssemblerX86Common::moveDoubleConditionallyFloat):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::moveDoubleConditionally64):
        (JSC::MacroAssemblerX86_64::moveDoubleConditionallyTest64):
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::shouldTryAliasingDef):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::populateWithInterestingValues):
        (JSC::B3::floatingPointOperands):
        (JSC::B3::int64Operands):
        (JSC::B3::int32Operands):
        (JSC::B3::testSelectCompareFloat):
        (JSC::B3::testSelectCompareFloatToDouble):
        (JSC::B3::testSelectDoubleCompareDouble):
        (JSC::B3::testSelectDoubleCompareDoubleWithAliasing):
        (JSC::B3::testSelectFloatCompareFloat):
        (JSC::B3::testSelectFloatCompareFloatWithAliasing):
        (JSC::B3::run):

2016-03-02  Joseph Pecoraro  <pecoraro@apple.com>

        Add ability to generate a Heap Snapshot
        https://bugs.webkit.org/show_bug.cgi?id=154847

        Reviewed by Mark Lam.

        This adds HeapSnapshot, HeapSnapshotBuilder, and HeapProfiler.

        HeapProfiler hangs off of the VM and holds the list of snapshots.
        I expect to add other HeapProfiling features, such as allocation
        tracking, to the profiler.

        HeapSnapshot contains a collection of live cells and their identifiers.
        It can point to a previous HeapSnapshot, to ensure that a cell that
        already received an identifier maintains the same identifier across
        multiple snapshots. When a snapshotted cell gets garbage collected,
        the cell will be swept from the HeapSnapshot at the end of collection
        to ensure the list contains only live cells.

        When building a HeapSnapshot nodes are added in increasing node
        identifier order. When done building, the list of nodes is complete
        and the snapshot is finalized. At this point the nodes are sorted
        by JSCell* address to allow for quick lookup of a JSCell*.

        HeapSnapshotBuilder is where snapshotting begins. The builder
        will initiate a specialized heap snapshotting garbage collection.
        During this collection the builder will be notified of all marked
        (live) cells, and connections between cells, as seen by SlotVisitors.
        The builder can reference the previous, readonly, HeapSnapshots to
        avoid creating new nodes for cells that have already been snapshotted.
        When it is determined that we are visiting a live cell for the first
        time, we give the cell a unique identifier and add it to the the
        snapshot we are building.

        Since edge data is costly, and of little long term utility, this
        data is only held by the builder for serialization, and not stored
        long term with the HeapSnapshot node data.

        The goals of HeapSnapshotting at this time are:
        - minimal impact on performance when not profiling the heap
        - unique identifier for cells, so they may be identified across multiple snapshots
        - nodes and edges to be able to construct a graph of which nodes reference/retain which other nodes
        - node data - identifier, type (class name), size
        - edge data - from cell, to cell, type / data (to come in a follow-up patch)

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        Add new files to the build.

        * heap/Heap.cpp:
        (JSC::Heap::isHeapSnapshotting):
        (JSC::RemoveDeadHeapSnapshotNodes::RemoveDeadHeapSnapshotNodes):
        (JSC::RemoveDeadHeapSnapshotNodes::operator()):
        (JSC::Heap::removeDeadHeapSnapshotNodes):
        (JSC::Heap::collectImpl):
        After every collection, sweep dead cells from in memory snapshots.

        * runtime/VM.cpp:
        (JSC::VM::ensureHeapProfiler):
        * runtime/VM.h:
        (JSC::VM::heapProfiler):
        * heap/Heap.h:
        * heap/HeapProfiler.cpp: Added.
        (JSC::HeapProfiler::HeapProfiler):
        (JSC::HeapProfiler::~HeapProfiler):
        (JSC::HeapProfiler::mostRecentSnapshot):
        (JSC::HeapProfiler::appendSnapshot):
        (JSC::HeapProfiler::clearSnapshots):
        (JSC::HeapProfiler::setActiveSnapshotBuilder):
        * heap/HeapProfiler.h: Added.
        (JSC::HeapProfiler::vm):
        (JSC::HeapProfiler::activeSnapshotBuilder):
        VM and Heap can look at the profiler to determine if we are building a
        snapshot, or the "head" snapshot to use for sweeping.

        * heap/HeapSnapshot.cpp: Added.
        (JSC::HeapSnapshot::HeapSnapshot):
        (JSC::HeapSnapshot::~HeapSnapshot):
        (JSC::HeapSnapshot::appendNode):
        Add a node to the unfinalized list of new cells.

        (JSC::HeapSnapshot::sweepCell):
        (JSC::HeapSnapshot::shrinkToFit):
        Collect a list of cells for sweeping and then remove them all at once
        in shrinkToFit. This is done to avoid thrashing of individual removes
        that could cause many overlapping moves within the Vector.

        (JSC::HeapSnapshot::finalize):
        Sort the list, and also cache the bounding start/stop identifiers.
        No other snapshot can contain an identifier in this range, so it will
        improve lookup of a node from an identifier.

        (JSC::HeapSnapshot::nodeForCell):
        (JSC::HeapSnapshot::nodeForObjectIdentifier):
        Search helpers.

        * heap/HeapSnapshotBuilder.h: Added.
        (JSC::HeapSnapshotNode::HeapSnapshotNode):
        (JSC::HeapSnapshotEdge::HeapSnapshotEdge):
        Node and Edge struct types the builder creates.

        * heap/HeapSnapshotBuilder.cpp: Added.
        (JSC::HeapSnapshotBuilder::getNextObjectIdentifier):
        (JSC::HeapSnapshotBuilder::HeapSnapshotBuilder):
        (JSC::HeapSnapshotBuilder::~HeapSnapshotBuilder):
        (JSC::HeapSnapshotBuilder::buildSnapshot):
        (JSC::HeapSnapshotBuilder::appendNode):
        (JSC::HeapSnapshotBuilder::appendEdge):
        When building the snapshot, generating the next identifier, and
        appending to any of the lists must be guarded by a lock because
        SlotVisitors running in parallel may be accessing the builder.

        (JSC::HeapSnapshotBuilder::hasExistingNodeForCell):
        Looking up if a node already exists in a previous snapshot can be
        done without a lock because at this point the data is readonly.

        (JSC::edgeTypeToNumber):
        (JSC::edgeTypeToString):
        (JSC::HeapSnapshotBuilder::json):
        JSON serialization of a heap snapshot contains node and edge data.

        * heap/SlotVisitor.h:
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::didStartMarking):
        (JSC::SlotVisitor::reset):
        Set/clear the active snapshot builder to know if this will be a
        snapshotting GC or not.

        (JSC::SlotVisitor::append):
        (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
        Inform the builder of a new node or edge.

        (JSC::SlotVisitor::visitChildren):
        Remember the current cell we are visiting so that if we need to
        inform the builder of edges we know the "from" cell.

        * jsc.cpp:
        (SimpleObject::SimpleObject):
        (SimpleObject::create):
        (SimpleObject::finishCreation):
        (SimpleObject::visitChildren):
        (SimpleObject::createStructure):
        (SimpleObject::hiddenValue):
        (SimpleObject::setHiddenValue):
        Create a new class "SimpleObject" that can be used by heap snapshotting
        tests. It is easy to filter for this new class name and test internal
        edge relationships created by garbage collection visiting the cell.

        (functionCreateSimpleObject):
        (functionGetHiddenValue):
        (functionSetHiddenValue):
        Expose methods to create and interact with a SimpleObject.

        (functionGenerateHeapSnapshot):
        Expose methods to create a heap snapshot. This currently automatically
        turns the serialized string into a JSON object. That may change.

        * tests/heapProfiler.yaml: Added.
        * tests/heapProfiler/basic-edges.js: Added.
        (excludeStructure):
        * tests/heapProfiler/basic-nodes.js: Added.
        (hasDifferentSizeNodes):
        (hasAllInternalNodes):
        Add tests for basic node and edge data.

        * tests/heapProfiler/driver/driver.js: Added.
        (assert):
        (CheapHeapSnapshotNode):
        (CheapHeapSnapshotEdge):
        (CheapHeapSnapshotEdge.prototype.get from):
        (CheapHeapSnapshotEdge.prototype.get to):
        (CheapHeapSnapshot):
        (CheapHeapSnapshot.prototype.get nodes):
        (CheapHeapSnapshot.prototype.get edges):
        (CheapHeapSnapshot.prototype.nodeWithIdentifier):
        (CheapHeapSnapshot.prototype.nodesWithClassName):
        (CheapHeapSnapshot.prototype.classNameFromTableIndex):
        (CheapHeapSnapshot.prototype.edgeTypeFromTableIndex):
        (createCheapHeapSnapshot):
        (HeapSnapshotNode):
        (HeapSnapshotEdge):
        (HeapSnapshot):
        (HeapSnapshot.prototype.nodesWithClassName):
        (createHeapSnapshot):
        Add two HeapSnapshot representations.
        CheapHeapSnapshot creates two lists of node and edge data that
        lazily creates objects as needed.
        HeapSnapshot creates an object for each node and edge. This
        is wasteful but easier to use.

2016-03-02  Filip Pizlo  <fpizlo@apple.com>

        RegExpPrototype should check for exceptions after calling toString and doing so should not be expensive
        https://bugs.webkit.org/show_bug.cgi?id=154927

        Reviewed by Saam Barati.

        While working on regexp optimizations, I found that RegExpPrototype calls toString(), an
        effectful operation that could do anything, without then checking for hadException().

        So I added a call to hadException().

        But that regressed Octane/regexp by 5%!  That's a lot!  It turns out that
        exec->hadException() is soooper slow. So, I made it cheaper to check for exceptions from
        toString(): there is now a variant called toStringFast() that returns null iff it throws an
        exception.

        This allowed me to add the exception check without regressing perf.

        Note that toString() must retain its old behavior of returning an empty string on exception.
        There is just too much code that relies on that behavior.

        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::isValidCallee):
        (JSC::JSValue::toStringSlowCase):
        (JSC::JSValue::toWTFStringSlowCase):
        * runtime/JSCJSValue.h:
        (JSC::JSValue::asValue):
        * runtime/JSString.h:
        (JSC::JSValue::toString):
        (JSC::JSValue::toStringFast):
        (JSC::JSValue::toWTFString):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncTest):
        (JSC::regExpProtoFuncExec):
        (JSC::regExpProtoFuncCompile):

2016-03-02  Saam barati  <sbarati@apple.com>

        clean up JSObject::isExtensibleInline and JSObject::setPrototypeOfInline, and rename setPrototypeOf to setPrototype
        https://bugs.webkit.org/show_bug.cgi?id=154942

        Reviewed by Benjamin Poulain.

        These don't need to be inlined in the way they are.
        Doing dynamic dispatch is ok performance wise until
        we have evidence stating otherwise.

        * API/JSObjectRef.cpp:
        (JSObjectSetPrototype):
        (JSObjectHasProperty):
        * runtime/ClassInfo.h:
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::constructIntlCollator):
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::constructIntlDateTimeFormat):
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::constructIntlNumberFormat):
        * runtime/JSCell.cpp:
        (JSC::JSCell::isExtensible):
        (JSC::JSCell::setPrototype):
        (JSC::JSCell::setPrototypeOf): Deleted.
        * runtime/JSCell.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoSetter):
        * runtime/JSObject.cpp:
        (JSC::JSObject::setPrototypeWithCycleCheck):
        (JSC::JSObject::setPrototype):
        (JSC::JSObject::allowsAccessFrom):
        (JSC::JSObject::isExtensible):
        (JSC::JSObject::reifyAllStaticProperties):
        (JSC::JSObject::defineOwnNonIndexProperty):
        (JSC::JSObject::setPrototypeOf): Deleted.
        * runtime/JSObject.h:
        (JSC::JSObject::mayInterceptIndexedAccesses):
        (JSC::JSObject::indexingShouldBeSparse):
        (JSC::JSObject::setPrototypeOfInline): Deleted.
        (JSC::JSObject::isExtensibleInline): Deleted.
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorSetPrototypeOf):
        (JSC::objectConstructorIsSealed):
        (JSC::objectConstructorIsFrozen):
        (JSC::objectConstructorIsExtensible):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::performPreventExtensions):
        (JSC::ProxyObject::performIsExtensible):
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectIsExtensible):
        (JSC::reflectObjectSetPrototypeOf):
        * runtime/StringObject.cpp:
        (JSC::StringObject::defineOwnProperty):

2016-03-02  Konstantin Tokarev  <annulen@yandex.ru>

        [cmake] Moved PRE/POST_BUILD_COMMAND to WEBKIT_FRAMEWORK.
        https://bugs.webkit.org/show_bug.cgi?id=154651

        Reviewed by Alex Christensen.

        * CMakeLists.txt: Moved shared code to WEBKIT_FRAMEWORK macro.

2016-03-02  Saam barati  <sbarati@apple.com>

        [[SetPrototypeOf]] should be a fully virtual method in ClassInfo::methodTable
        https://bugs.webkit.org/show_bug.cgi?id=154897

        Reviewed by Filip Pizlo.

        This patch makes us more consistent with how the ES6 specification models the
        [[SetPrototypeOf]] trap. Moving this method into ClassInfo::methodTable 
        is a prerequisite for implementing Proxy.[[SetPrototypeOf]]. This patch
        still allows directly setting the prototype for situations where this
        is the desired behavior. This is equivalent to setting the internal
        [[Prototype]] field as described in the specification. 

        * API/JSClassRef.cpp:
        (OpaqueJSClass::prototype):
        * API/JSObjectRef.cpp:
        (JSObjectMake):
        (JSObjectSetPrototype):
        (JSObjectHasProperty):
        * API/JSWrapperMap.mm:
        (makeWrapper):
        * runtime/ClassInfo.h:
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::constructIntlCollator):
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::constructIntlDateTimeFormat):
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::constructIntlNumberFormat):
        * runtime/JSCell.cpp:
        (JSC::JSCell::isExtensible):
        (JSC::JSCell::setPrototypeOf):
        * runtime/JSCell.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::resetPrototype):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoSetter):
        * runtime/JSObject.cpp:
        (JSC::JSObject::switchToSlowPutArrayStorage):
        (JSC::JSObject::setPrototypeDirect):
        (JSC::JSObject::setPrototypeWithCycleCheck):
        (JSC::JSObject::setPrototypeOf):
        (JSC::JSObject::allowsAccessFrom):
        (JSC::JSObject::setPrototype): Deleted.
        * runtime/JSObject.h:
        (JSC::JSObject::setPrototypeOfInline):
        (JSC::JSObject::mayInterceptIndexedAccesses):
        * runtime/JSProxy.cpp:
        (JSC::JSProxy::setTarget):
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorSetPrototypeOf):
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectSetPrototypeOf):

2016-03-02  Saam barati  <sbarati@apple.com>

        SIGSEGV in Proxy [[Get]] and [[Set]] recursion
        https://bugs.webkit.org/show_bug.cgi?id=154854

        Reviewed by Yusuke Suzuki.

        We need to be aware of the possibility that the VM
        may recurse and that we can stack overflow.

        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performPut):
        * tests/stress/proxy-get-and-set-recursion-stack-overflow.js: Added.
        (assert):
        (testStackOverflowGet):
        (testStackOverflowIndexedGet):
        (testStackOverflowSet):
        (testStackOverflowIndexedSet):

2016-03-02  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Use a Move without REX byte when possible
        https://bugs.webkit.org/show_bug.cgi?id=154801

        Reviewed by Alex Christensen.

        Filip wrote an optimization in the register allocator
        to use 32bit "Move" when we don't care about the top bytes.

        When I moved the commutative ops to the fake 3 operands instruction
        I largely destroyed this since all the "Moves" became full register.

        In this patch, I switch back to 32bit "Moves" for 32bit operations.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::and32):
        (JSC::MacroAssemblerX86Common::lshift32):
        (JSC::MacroAssemblerX86Common::mul32):
        (JSC::MacroAssemblerX86Common::or32):
        (JSC::MacroAssemblerX86Common::rshift32):
        (JSC::MacroAssemblerX86Common::urshift32):
        (JSC::MacroAssemblerX86Common::xor32):
        (JSC::MacroAssemblerX86Common::branchAdd32):
        (JSC::MacroAssemblerX86Common::branchMul32):
        (JSC::MacroAssemblerX86Common::branchSub32):
        (JSC::MacroAssemblerX86Common::move32IfNeeded):

2016-03-01  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Simplify ArithMod(ArithMod(x, const1), const2) if const2 >= const1
        https://bugs.webkit.org/show_bug.cgi?id=154904

        Reviewed by Saam Barati.

        The ASM test "ubench" has a "x % 10 % 255".
        The second modulo should be eliminated.

        This is a 15% improvement on ASMJS' ubench.

        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * tests/stress/arith-modulo-twice.js: Added.
        (opaqueModuloSmaller):
        (opaqueModuloEqual):
        (opaqueModuloLarger):
        (opaqueModuloSmallerNeg):
        (opaqueModuloEqualNeg):
        (opaqueModuloLargerNeg):
        (opaqueExpectedOther):

2016-03-01  Ryosuke Niwa  <rniwa@webkit.org>

        Unreviewed. Update the status of Proxy objects to "In Development".

        * features.json:

2016-03-01  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r197226 and r197256.
        https://bugs.webkit.org/show_bug.cgi?id=154910

        Caused crashes on Mac 32-bit and on ARM (Requested by ap on
        #webkit).

        Reverted changesets:

        "Remove the on demand executable allocator"
        https://bugs.webkit.org/show_bug.cgi?id=154749
        http://trac.webkit.org/changeset/197226

        "CLoop build fix."
        http://trac.webkit.org/changeset/197256

2016-03-01  Joseph Pecoraro  <pecoraro@apple.com>

        Simplify some StringBuilder appends
        https://bugs.webkit.org/show_bug.cgi?id=154902

        Reviewed by Mark Lam.

        * runtime/ExceptionHelpers.cpp:
        (JSC::notAFunctionSourceAppender):
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::stackTracesAsJSON):
        Use StringBuilder::append(char) instead of append(char*) where possible.

2016-03-01  Keith Miller  <keith_miller@apple.com>

        Promise.prototype.then should use Symbol.species to construct the return Promise
        https://bugs.webkit.org/show_bug.cgi?id=154862

        Reviewed by Saam Barati.

        * builtins/PromisePrototype.js:
        * tests/stress/promise-species-functions.js: Added.
        (Symbol.species):
        (id):
        (funcThrows):
        (makeC):
        (test.species):
        (test.speciesThrows):
        (test):

2016-03-01  Michael Saboff  <msaboff@apple.com>

        [ES6] Add support for Unicode regular expressions
        https://bugs.webkit.org/show_bug.cgi?id=154842

        Reviewed by Filip Pizlo.

        Added processing of Unicode regular expressions to the Yarr interpreter.

        Changed parsing of regular expression patterns and PatternTerms to process characters as
        UChar32 in the Yarr code.  The parser converts matched surrogate pairs into the appropriate
        Unicode character when the expression is parsed.  When matching a unicode expression and
        reading source characters, we convert proper surrogate pair into a Unicode character and
        advance the source cursor, "pos", one more position.  The exception to this is when we
        know when generating a fixed character atom that we need to match a unicode character
        that doesn't fit in 16 bits.  The code calls this an extendedUnicodeCharacter and has a
        helper to determine this.

        Added 'u' flag and 'unicode' identifier to regular expression classes.  Added an "isUnicode"
        parameter to YarrPattern pattern() and internal users of that function.

        Updated the generation of the canonicalization tables to include a new set a tables that
        follow the ES 6.0, 21.2.2.8.2 Step 2.  Renamed the YarrCanonicalizeUCS2.* files to
        YarrCanonicalizeUnicode.*. 

        Added a new Layout/js test that tests the added functionality.  Updated other tests that
        have minor es6 unicode checks and look for valid flags.

        Ran the ChakraCore Unicode regular expression tests as well.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:

        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::findMagicComment):
        * yarr/RegularExpression.cpp:
        (JSC::Yarr::RegularExpression::Private::compile):
        Updated use of pattern().

        * runtime/CommonIdentifiers.h:
        * runtime/RegExp.cpp:
        (JSC::regExpFlags):
        (JSC::RegExpFunctionalTestCollector::outputOneTest):
        (JSC::RegExp::finishCreation):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/RegExp.h:
        * runtime/RegExpKey.h:
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncCompile):
        (JSC::flagsString):
        (JSC::regExpProtoGetterMultiline):
        (JSC::regExpProtoGetterUnicode):
        (JSC::regExpProtoGetterFlags):
        Updated for new 'y' (unicode) flag.  Add check to use the interpreter for unicode regular expressions.

        * tests/es6.yaml:
        * tests/stress/static-getter-in-names.js:
        Updated tests for new flag and for passing the minimal es6 regular expression processing.

        * yarr/Yarr.h: Updated the size of information now kept for backtracking.

        * yarr/YarrCanonicalizeUCS2.cpp: Removed.
        * yarr/YarrCanonicalizeUCS2.h: Removed.
        * yarr/YarrCanonicalizeUCS2.js: Removed.
        * yarr/YarrCanonicalizeUnicode.cpp: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUCS2.cpp.
        * yarr/YarrCanonicalizeUnicode.h: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUCS2.h.
        (JSC::Yarr::canonicalCharacterSetInfo):
        (JSC::Yarr::canonicalRangeInfoFor):
        (JSC::Yarr::getCanonicalPair):
        (JSC::Yarr::isCanonicallyUnique):
        (JSC::Yarr::areCanonicallyEquivalent):
        (JSC::Yarr::rangeInfoFor): Deleted.
        * yarr/YarrCanonicalizeUnicode.js: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUCS2.js.
        (printHeader):
        (printFooter):
        (hex):
        (canonicalize):
        (canonicalizeUnicode):
        (createUCS2CanonicalGroups):
        (createUnicodeCanonicalGroups):
        (cu.in.groupedCanonically.characters.sort): Deleted.
        (cu.in.groupedCanonically.else): Deleted.
        Refactored to output two sets of tables, one for UCS2 and one for Unicode.  The UCS2 tables follow
        the legacy canonicalization rules now specified in ES 6.0, 21.2.2.8.2 Step 3.  The new Unicode
        tables follow the rules specified in ES 6.0, 21.2.2.8.2 Step 2.  Eliminated the unused Latin1 tables.

        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::InputStream::InputStream):
        (JSC::Yarr::Interpreter::InputStream::readChecked):
        (JSC::Yarr::Interpreter::InputStream::readSurrogatePairChecked):
        (JSC::Yarr::Interpreter::InputStream::reread):
        (JSC::Yarr::Interpreter::InputStream::prev):
        (JSC::Yarr::Interpreter::testCharacterClass):
        (JSC::Yarr::Interpreter::checkCharacter):
        (JSC::Yarr::Interpreter::checkSurrogatePair):
        (JSC::Yarr::Interpreter::checkCasedCharacter):
        (JSC::Yarr::Interpreter::tryConsumeBackReference):
        (JSC::Yarr::Interpreter::backtrackPatternCharacter):
        (JSC::Yarr::Interpreter::matchCharacterClass):
        (JSC::Yarr::Interpreter::backtrackCharacterClass):
        (JSC::Yarr::Interpreter::matchParenthesesTerminalEnd):
        (JSC::Yarr::Interpreter::matchDisjunction):
        (JSC::Yarr::Interpreter::Interpreter):
        (JSC::Yarr::ByteCompiler::assertionWordBoundary):
        (JSC::Yarr::ByteCompiler::atomPatternCharacter):
        * yarr/YarrInterpreter.h:
        (JSC::Yarr::ByteTerm::ByteTerm):
        (JSC::Yarr::BytecodePattern::BytecodePattern):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::optimizeAlternative):
        (JSC::Yarr::YarrGenerator::matchCharacterClassRange):
        (JSC::Yarr::YarrGenerator::matchCharacterClass):
        (JSC::Yarr::YarrGenerator::notAtEndOfInput):
        (JSC::Yarr::YarrGenerator::jumpIfCharNotEquals):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterGreedy):
        (JSC::Yarr::YarrGenerator::backtrackPatternCharacterNonGreedy):
        * yarr/YarrParser.h:
        (JSC::Yarr::Parser::CharacterClassParserDelegate::atomPatternCharacter):
        (JSC::Yarr::Parser::Parser):
        (JSC::Yarr::Parser::parseEscape):
        (JSC::Yarr::Parser::consumePossibleSurrogatePair):
        (JSC::Yarr::Parser::parseCharacterClass):
        (JSC::Yarr::Parser::parseTokens):
        (JSC::Yarr::Parser::parse):
        (JSC::Yarr::Parser::atEndOfPattern):
        (JSC::Yarr::Parser::patternRemaining):
        (JSC::Yarr::Parser::peek):
        (JSC::Yarr::parse):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::CharacterClassConstructor::CharacterClassConstructor):
        (JSC::Yarr::CharacterClassConstructor::append):
        (JSC::Yarr::CharacterClassConstructor::putChar):
        (JSC::Yarr::CharacterClassConstructor::putUnicodeIgnoreCase):
        (JSC::Yarr::CharacterClassConstructor::putRange):
        (JSC::Yarr::CharacterClassConstructor::charClass):
        (JSC::Yarr::CharacterClassConstructor::addSorted):
        (JSC::Yarr::CharacterClassConstructor::addSortedRange):
        (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
        (JSC::Yarr::YarrPatternConstructor::assertionWordBoundary):
        (JSC::Yarr::YarrPatternConstructor::atomPatternCharacter):
        (JSC::Yarr::YarrPatternConstructor::atomCharacterClassBegin):
        (JSC::Yarr::YarrPatternConstructor::atomCharacterClassAtom):
        (JSC::Yarr::YarrPatternConstructor::atomCharacterClassRange):
        (JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets):
        (JSC::Yarr::YarrPattern::compile):
        (JSC::Yarr::YarrPattern::YarrPattern):
        * yarr/YarrPattern.h:
        (JSC::Yarr::CharacterRange::CharacterRange):
        (JSC::Yarr::CharacterClass::CharacterClass):
        (JSC::Yarr::PatternTerm::PatternTerm):
        (JSC::Yarr::YarrPattern::reset):
        * yarr/YarrSyntaxChecker.cpp:
        (JSC::Yarr::SyntaxChecker::assertionBOL):
        (JSC::Yarr::SyntaxChecker::assertionEOL):
        (JSC::Yarr::SyntaxChecker::assertionWordBoundary):
        (JSC::Yarr::SyntaxChecker::atomPatternCharacter):
        (JSC::Yarr::SyntaxChecker::atomBuiltInCharacterClass):
        (JSC::Yarr::SyntaxChecker::atomCharacterClassBegin):
        (JSC::Yarr::SyntaxChecker::atomCharacterClassAtom):
        (JSC::Yarr::checkSyntax):

2016-03-01  Saam barati  <sbarati@apple.com>

        Remove FIXMEs and add valid test cases after necessary patch has landed.

        Rubber stamped by Mark Lam.

        * tests/stress/proxy-prevent-extensions.js:
        (assert.Object.isSealed):
        (assert):

2016-03-01  Saam barati  <sbarati@apple.com>

        [ES6] Implement Proxy.[[IsExtensible]]
        https://bugs.webkit.org/show_bug.cgi?id=154872

        Reviewed by Oliver Hunt.

        This patch is a direct implementation of Proxy.[[IsExtensible]] with respect to section 9.5.3
        of the ECMAScript 6 spec.
        https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-isextensible

        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::preventExtensions):
        (JSC::ProxyObject::performIsExtensible):
        (JSC::ProxyObject::isExtensible):
        (JSC::ProxyObject::visitChildren):
        * runtime/ProxyObject.h:
        * tests/es6.yaml:
        * tests/stress/proxy-is-extensible.js: Added.
        (assert):
        (throw.new.Error.let.handler.get isExtensible):
        (throw.new.Error):
        (assert.let.handler.isExtensible):
        (assert.):
        (let.handler.isExtensible):

2016-03-01  Saam barati  <sbarati@apple.com>

        [ES6] Implement Proxy.[[PreventExtensions]]
        https://bugs.webkit.org/show_bug.cgi?id=154873

        Reviewed by Oliver Hunt.

        This patch is a direct implementation of Proxy.[[PreventExtensions]] with respect to section 9.5.4
        of the ECMAScript 6 spec.
        https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-preventextensions

        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::deletePropertyByIndex):
        (JSC::ProxyObject::performPreventExtensions):
        (JSC::ProxyObject::preventExtensions):
        (JSC::ProxyObject::visitChildren):
        * runtime/ProxyObject.h:
        * tests/es6.yaml:
        * tests/stress/proxy-prevent-extensions.js: Added.
        (assert):
        (throw.new.Error.let.handler.get preventExtensions):
        (throw.new.Error):
        (assert.let.handler.preventExtensions):
        (assert.):
        (let.handler.preventExtensions):
        (assert.Object.isSealed.let.handler.preventExtensions):
        (assert.Object.isSealed):

2016-03-01  Filip Pizlo  <fpizlo@apple.com>

        FTL should simplify StringReplace with an empty replacement string
        https://bugs.webkit.org/show_bug.cgi?id=154871

        Reviewed by Michael Saboff.

        This is a simple and hugely profitable change. If we do a string.replace(/things/, ""), then
        this calls directly into StringPrototype's replace-with-empty-string logic instead of going
        through stuff that does checks before reaching that same conclusion.

        This speeds up Octane/regexp by about 6-10%. It also speeds up the attached microbenchmark by
        about 7%.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
        * runtime/StringPrototype.cpp:
        (JSC::jsSpliceSubstringsWithSeparators):
        (JSC::removeUsingRegExpSearch):
        (JSC::replaceUsingRegExpSearch):
        (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
        (JSC::operationStringProtoFuncReplaceRegExpString):
        * runtime/StringPrototype.h:

2016-03-01  Alex Christensen  <achristensen@webkit.org>

        Reduce size of internal windows build output
        https://bugs.webkit.org/show_bug.cgi?id=154763

        Reviewed by Brent Fulgham.

        * JavaScriptCore.vcxproj/JavaScriptCore.proj:

2016-03-01  Saam barati  <sbarati@apple.com>

        [[IsExtensible]] should be a virtual method in the method table
        https://bugs.webkit.org/show_bug.cgi?id=154799

        Reviewed by Mark Lam.

        This patch makes us more consistent with how the ES6 specification models the
        [[IsExtensible]] trap. Moving this method into ClassInfo::methodTable 
        is a prerequisite for implementing Proxy.[[IsExtensible]].

        * runtime/ClassInfo.h:
        * runtime/JSCell.cpp:
        (JSC::JSCell::preventExtensions):
        (JSC::JSCell::isExtensible):
        * runtime/JSCell.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoSetter):
        * runtime/JSObject.cpp:
        (JSC::JSObject::preventExtensions):
        (JSC::JSObject::isExtensible):
        (JSC::JSObject::reifyAllStaticProperties):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
        (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
        (JSC::JSObject::defineOwnNonIndexProperty):
        (JSC::JSObject::defineOwnProperty):
        * runtime/JSObject.h:
        (JSC::JSObject::isSealed):
        (JSC::JSObject::isFrozen):
        (JSC::JSObject::isExtensibleImpl):
        (JSC::JSObject::isStructureExtensible):
        (JSC::JSObject::isExtensibleInline):
        (JSC::JSObject::indexingShouldBeSparse):
        (JSC::JSObject::putDirectInternal):
        (JSC::JSObject::isExtensible): Deleted.
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorSetPrototypeOf):
        (JSC::objectConstructorIsSealed):
        (JSC::objectConstructorIsFrozen):
        (JSC::objectConstructorIsExtensible):
        (JSC::objectConstructorIs):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectIsExtensible):
        (JSC::reflectObjectSetPrototypeOf):
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::putEntry):
        (JSC::SparseArrayValueMap::putDirect):
        * runtime/StringObject.cpp:
        (JSC::StringObject::defineOwnProperty):
        * runtime/Structure.cpp:
        (JSC::Structure::isSealed):
        (JSC::Structure::isFrozen):
        * runtime/Structure.h:

2016-03-01  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix CLOOP build.

        * jit/JITOperations.h:

2016-03-01  Skachkov Oleksandr  <gskachkov@gmail.com>

        [ES6] Arrow function. Some not used byte code is emited
        https://bugs.webkit.org/show_bug.cgi?id=154639

        Reviewed by Saam Barati.

        Currently bytecode that is generated for arrow function is not optimal. 
        Current fix removed following unnecessary bytecode:
        1.create_lexical_environment not emited always for arrow function, only if some of 
        features(this/super/arguments/eval) is used inside of the arrow function. 
        2.load 'this' from arrow function scope in constructor is done only if super 
        contains in arrow function 

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::isSuperCallUsedInInnerArrowFunction):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode):
        * parser/Nodes.h:
        (JSC::ScopeNode::doAnyInnerArrowFunctionsUseAnyFeature):
        * tests/stress/arrowfunction-lexical-bind-supercall-4.js:

2016-02-29  Filip Pizlo  <fpizlo@apple.com>

        Turn String.prototype.replace into an intrinsic
        https://bugs.webkit.org/show_bug.cgi?id=154835

        Reviewed by Michael Saboff.

        Octane/regexp spends a lot of time in String.prototype.replace(). That function does a lot
        of checks to see if the parameters are what they are likely to often be (a string, a
        regexp, and a string). The intuition of this patch is that it's good to remove those checks
        and it's good to call the native function as directly as possible.

        This yields a 10% speed-up on a replace microbenchmark and a 3% speed-up on Octane/regexp.
        It also improves Octane/jquery.

        This is only the beginning of what I want to do with replace optimizations. The other
        optimizations will rely on StringReplace being revealed as a construct in DFG IR.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/SpeculatedType.cpp:
        (JSC::dumpSpeculation):
        (JSC::speculationToAbbreviatedString):
        (JSC::speculationFromClassInfo):
        * bytecode/SpeculatedType.h:
        (JSC::isStringOrStringObjectSpeculation):
        (JSC::isRegExpObjectSpeculation):
        (JSC::isBoolInt32Speculation):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * 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::shouldSpeculateStringOrStringObject):
        (JSC::DFG::Node::shouldSpeculateRegExpObject):
        (JSC::DFG::Node::shouldSpeculateSymbol):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::operator()):
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculateFinalObject):
        (JSC::DFG::SpeculativeJIT::speculateRegExpObject):
        (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
        (JSC::DFG::SpeculativeJIT::speculate):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        (JSC::DFG::isCell):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
        (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
        (JSC::FTL::DFG::LowerDFGToB3::speculate):
        (JSC::FTL::DFG::LowerDFGToB3::speculateFinalObject):
        (JSC::FTL::DFG::LowerDFGToB3::speculateRegExpObject):
        (JSC::FTL::DFG::LowerDFGToB3::speculateString):
        * jit/JITOperations.h:
        * runtime/Intrinsic.h:
        * runtime/JSType.h:
        * runtime/RegExpObject.h:
        (JSC::RegExpObject::createStructure):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::removeUsingRegExpSearch):
        (JSC::replaceUsingRegExpSearch):
        (JSC::operationStringProtoFuncReplaceRegExpString):
        (JSC::replaceUsingStringSearch):
        (JSC::stringProtoFuncRepeat):
        (JSC::replace):
        (JSC::stringProtoFuncReplace):
        (JSC::operationStringProtoFuncReplaceGeneric):
        (JSC::stringProtoFuncToString):
        * runtime/StringPrototype.h:

2016-03-01  Commit Queue  <commit-queue@webkit.org>

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

        broke win ews (Requested by alexchristensen on #webkit).

        Reverted changeset:

        "[cmake] Moved PRE/POST_BUILD_COMMAND to WEBKIT_FRAMEWORK."
        https://bugs.webkit.org/show_bug.cgi?id=154651
        http://trac.webkit.org/changeset/197056

2016-02-29  Saam barati  <sbarati@apple.com>

        [[PreventExtensions]] should be a virtual method in the method table.
        https://bugs.webkit.org/show_bug.cgi?id=154800

        Reviewed by Yusuke Suzuki.

        This patch makes us more consistent with how the ES6 specification models the
        [[PreventExtensions]] trap. Moving this method into ClassInfo::methodTable 
        is a prerequisite for implementing Proxy.[[PreventExtensions]].

        * runtime/ClassInfo.h:
        * runtime/JSCell.cpp:
        (JSC::JSCell::getGenericPropertyNames):
        (JSC::JSCell::preventExtensions):
        * runtime/JSCell.h:
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::JSModuleNamespaceObject):
        (JSC::JSModuleNamespaceObject::finishCreation):
        (JSC::JSModuleNamespaceObject::destroy):
        * runtime/JSModuleNamespaceObject.h:
        (JSC::JSModuleNamespaceObject::create):
        (JSC::JSModuleNamespaceObject::moduleRecord):
        * runtime/JSObject.cpp:
        (JSC::JSObject::freeze):
        (JSC::JSObject::preventExtensions):
        (JSC::JSObject::reifyAllStaticProperties):
        * runtime/JSObject.h:
        (JSC::JSObject::isSealed):
        (JSC::JSObject::isFrozen):
        (JSC::JSObject::isExtensible):
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorSeal):
        (JSC::objectConstructorFreeze):
        (JSC::objectConstructorPreventExtensions):
        (JSC::objectConstructorIsSealed):
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectPreventExtensions):
        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        (JSC::Structure::preventExtensionsTransition):
        * runtime/Structure.h:

2016-02-29  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Private symbols should not be trapped by proxy handler
        https://bugs.webkit.org/show_bug.cgi?id=154817

        Reviewed by Mark Lam.

        Since the runtime has some assumptions on the properties associated with the private symbols, ES6 Proxy should not trap these property operations.
        For example, in ArrayIteratorPrototype.js

            var itemKind = this.@arrayIterationKind;
            if (itemKind === @undefined)
                throw new @TypeError("%ArrayIteratorPrototype%.next requires that |this| be an Array Iterator instance");

        Here, we assume that only the array iterator has the @arrayIterationKind property that value is non-undefined.
        But If we implement Proxy with the get handler, that returns a non-undefined value for every operations, we accidentally assumes that the given value is an array iterator.

        To avoid these situation, we perform the default operations onto property operations with private symbols.

        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::performPut):
        (JSC::ProxyObject::performDelete):
        (JSC::ProxyObject::deleteProperty):
        (JSC::ProxyObject::deletePropertyByIndex):
        * tests/stress/proxy-basic.js:
        * tests/stress/proxy-with-private-symbols.js: Added.
        (assert):
        (let.handler.getOwnPropertyDescriptor):

2016-02-29  Filip Pizlo  <fpizlo@apple.com>

        regress/script-tests/double-pollution-putbyoffset.js.ftl-eager timed out because of a lock ordering deadlock involving InferredType and CodeBlock
        https://bugs.webkit.org/show_bug.cgi?id=154841

        Reviewed by Benjamin Poulain.

        Here's the deadlock:

        Main thread:
            1) Change an InferredType.  This acquires InferredType::m_lock.
            2) Fire watchpoint set.  This triggers CodeBlock invalidation, which acquires
               CodeBlock::m_lock.

        DFG thread:
            1) Iterate over the information in a CodeBlock.  This acquires CodeBlock::m_lock.
            2) Ask an InferredType for its descriptor().  This acquires InferredType::m_lock.

        I think that the DFG thread's ordering should be legal, because the best logic for lock
        hierarchies is that locks that protect the largest set of stuff should be acquired first.

        This means that the main thread shouldn't be holding the InferredType::m_lock when firing
        watchpoint sets.  That's what this patch ensures.

        At the time of writing, this test was deadlocking for me on trunk 100% of the time.  With
        this change I cannot get it to deadlock.

        * runtime/InferredType.cpp:
        (JSC::InferredType::willStoreValueSlow):
        (JSC::InferredType::makeTopSlow):
        (JSC::InferredType::set):
        (JSC::InferredType::removeStructure):
        (JSC::InferredType::InferredStructureWatchpoint::fireInternal):
        * runtime/InferredType.h:

2016-02-29  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG][FTL][B3] Support floor and ceil
        https://bugs.webkit.org/show_bug.cgi?id=154683

        Reviewed by Filip Pizlo.

        This patch implements and fixes the following things.

        1. Implement Ceil and Floor in DFG, FTL and B3

        x86 SSE 4.2 and ARM64 have round instructions that can directly perform Ceil or Floor.
        This patch leverages this functionality. We introduce ArithFloor and ArithCeil.
        During DFG phase, these nodes attempt to convert itself to Identity (in Fixup phase).
        As the same to ArithRound, it tracks arith rounding mode.
        And if these nodes are required to emit machine codes, we emit rounding machine code
        if it is supported in the current machine. For example, in x86, we emit `round`.

        This `Floor` functionality is nice for @toInteger in builtin.
        That is used for Array.prototype.{forEach, map, every, some, reduce...}
        And according to the benchmark results, Kraken audio-oscillator is slightly improved
        due to its frequent Math.round and Math.floor calls.

        2. Implement Floor in B3 and Air

        As the same to Ceil in B3, we add a new B3 IR and Air opcode, Floor.
        This Floor is leveraged to implement ArithFloor in DFG.

        3. Fix ArithRound operation

        Currently, we used cvtsd2si (in x86) to convert double value to int32.
        And we also used this to implement Math.round, like, cvtsd2si(value + 0.5).
        However, this implementation is not correct. Because cvtsd2si is not floor operation.
        It is trucate operation. This is OK for positive numbers. But NG for negative numbers.
        For example, the current implementation accidentally rounds `-0.6` to `-0.0`. This should be `-1.0`.
        Using Ceil and Floor instructions, we implement correct ArithRound.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::supportsFloatingPointRounding):
        (JSC::MacroAssemblerARM::ceilDouble):
        (JSC::MacroAssemblerARM::floorDouble):
        (JSC::MacroAssemblerARM::supportsFloatingPointCeil): Deleted.
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::supportsFloatingPointRounding):
        (JSC::MacroAssemblerARM64::floorFloat):
        (JSC::MacroAssemblerARM64::supportsFloatingPointCeil): Deleted.
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::supportsFloatingPointRounding):
        (JSC::MacroAssemblerARMv7::ceilDouble):
        (JSC::MacroAssemblerARMv7::floorDouble):
        (JSC::MacroAssemblerARMv7::supportsFloatingPointCeil): Deleted.
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::ceilDouble):
        (JSC::MacroAssemblerMIPS::floorDouble):
        (JSC::MacroAssemblerMIPS::supportsFloatingPointRounding):
        (JSC::MacroAssemblerMIPS::supportsFloatingPointCeil): Deleted.
        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::supportsFloatingPointRounding):
        (JSC::MacroAssemblerSH4::ceilDouble):
        (JSC::MacroAssemblerSH4::floorDouble):
        (JSC::MacroAssemblerSH4::supportsFloatingPointCeil): Deleted.
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::floorDouble):
        (JSC::MacroAssemblerX86Common::floorFloat):
        (JSC::MacroAssemblerX86Common::supportsFloatingPointRounding):
        (JSC::MacroAssemblerX86Common::supportsFloatingPointCeil): Deleted.
        * b3/B3ConstDoubleValue.cpp:
        (JSC::B3::ConstDoubleValue::floorConstant):
        * b3/B3ConstDoubleValue.h:
        * b3/B3ConstFloatValue.cpp:
        (JSC::B3::ConstFloatValue::floorConstant):
        * b3/B3ConstFloatValue.h:
        * b3/B3LowerMacrosAfterOptimizations.cpp:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3ReduceDoubleToFloat.cpp:
        * b3/B3ReduceStrength.cpp:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::floorConstant):
        (JSC::B3::Value::isRounded):
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h:
        * b3/air/AirFixPartialRegisterStalls.cpp:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testFloorCeilArg):
        (JSC::B3::testFloorArg):
        (JSC::B3::testFloorImm):
        (JSC::B3::testFloorMem):
        (JSC::B3::testFloorFloorArg):
        (JSC::B3::testCeilFloorArg):
        (JSC::B3::testFloorIToD64):
        (JSC::B3::testFloorIToD32):
        (JSC::B3::testFloorArgWithUselessDoubleConversion):
        (JSC::B3::testFloorArgWithEffectfulDoubleConversion):
        (JSC::B3::run):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArithMode.cpp:
        (WTF::printInternal):
        * dfg/DFGArithMode.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * 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):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::roundShouldSpeculateInt32):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::arithNodeFlags):
        (JSC::DFG::Node::hasHeapPrediction):
        (JSC::DFG::Node::hasArithRoundingMode):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithRounding):
        (JSC::DFG::SpeculativeJIT::compileArithRound): Deleted.
        * 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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithFloor):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithCeil):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::doubleFloor):
        * jit/ThunkGenerators.cpp:
        (JSC::ceilThunkGenerator):
        * tests/stress/math-ceil-arith-rounding-mode.js: Added.
        (firstCareAboutZeroSecondDoesNot):
        (firstDoNotCareAboutZeroSecondDoes):
        (warmup):
        (verifyNegativeZeroIsPreserved):
        * tests/stress/math-ceil-basics.js: Added.
        (mathCeilOnIntegers):
        (mathCeilOnDoubles):
        (mathCeilOnBooleans):
        (uselessMathCeil):
        (mathCeilWithOverflow):
        (mathCeilConsumedAsDouble):
        (mathCeilDoesNotCareAboutMinusZero):
        (mathCeilNoArguments):
        (mathCeilTooManyArguments):
        (testMathCeilOnConstants):
        (mathCeilStructTransition):
        (Math.ceil):
        * tests/stress/math-floor-arith-rounding-mode.js: Added.
        (firstCareAboutZeroSecondDoesNot):
        (firstDoNotCareAboutZeroSecondDoes):
        (warmup):
        (verifyNegativeZeroIsPreserved):
        * tests/stress/math-floor-basics.js: Added.
        (mathFloorOnIntegers):
        (mathFloorOnDoubles):
        (mathFloorOnBooleans):
        (uselessMathFloor):
        (mathFloorWithOverflow):
        (mathFloorConsumedAsDouble):
        (mathFloorDoesNotCareAboutMinusZero):
        (mathFloorNoArguments):
        (mathFloorTooManyArguments):
        (testMathFloorOnConstants):
        (mathFloorStructTransition):
        (Math.floor):
        * tests/stress/math-round-should-not-use-truncate.js: Added.
        (mathRoundDoesNotCareAboutMinusZero):
        * tests/stress/math-rounding-infinity.js: Added.
        (shouldBe):
        (testRound):
        (testFloor):
        (testCeil):
        * tests/stress/math-rounding-nan.js: Added.
        (shouldBe):
        (testRound):
        (testFloor):
        (testCeil):
        * tests/stress/math-rounding-negative-zero.js: Added.
        (shouldBe):
        (testRound):
        (testFloor):
        (testCeil):
        (testRoundNonNegativeZero):
        (testRoundNonNegativeZero2):

2016-02-29  Joseph Pecoraro  <pecoraro@apple.com>

        Add new MethodTable method to get an estimated size for a cell
        https://bugs.webkit.org/show_bug.cgi?id=154838

        Reviewed by Filip Pizlo.

        The new class method estimatedSize(JSCell*) estimates the size for a single cell.
        As the name implies, this is meant to be an approximation. It is more important
        that big objects report a large size, then to get perfect size information for
        all objects in the heap.

            Base implementation (JSCell):
              - returns the MarkedBlock bucket size for this cell.
              - This gets us the object size include inline storage. Basically a better sizeof.

            Subclasses with "Extra Memory Cost":
              - Any class that reports extra memory (reportExtraMemoryVisited) should include that in the estimated size.
              - E.g. CodeBlock, JSGenericTypedArrayView, WeakMapData, etc.

            Subclasses with "Copied Space" storage:
              - Any class with data in copied space (copyBackingStore) should include that in the estimated size.
              - E.g. JSObject, JSGenericTypedArrayView, JSMap, JSSet, DirectArguments, etc.

        Add reportExtraMemoryVisited for UnlinkedCodeBlock's compressed unlinked
        instructions because this can be larger than 1kb, which is significant.

        This has one special case for RegExp generated bytecode / JIT code, which
        does not currently fall into the extra memory cost or copied space storage.
        In practice I haven't seen this grow to a significant cost.

        * runtime/ClassInfo.h:
        Add the new estimatedSize method to the table.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::visitChildren):
        (JSC::UnlinkedCodeBlock::estimatedSize):
        (JSC::UnlinkedCodeBlock::setInstructions):
        * bytecode/UnlinkedCodeBlock.h:
        Report an extra memory cost for unlinked code blocks like
        we do for linked code blocks.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::estimatedSize):
        * bytecode/CodeBlock.h:
        * bytecode/UnlinkedInstructionStream.cpp:
        (JSC::UnlinkedInstructionStream::sizeInBytes):
        * bytecode/UnlinkedInstructionStream.h:
        * runtime/DirectArguments.cpp:
        (JSC::DirectArguments::estimatedSize):
        * runtime/DirectArguments.h:
        * runtime/JSCell.cpp:
        (JSC::JSCell::estimatedSizeInBytes):
        (JSC::JSCell::estimatedSize):
        * runtime/JSCell.h:
        * runtime/JSGenericTypedArrayView.h:
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::estimatedSize):
        * runtime/JSMap.cpp:
        (JSC::JSMap::estimatedSize):
        * runtime/JSMap.h:
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitButterfly):
        * runtime/JSObject.h:
        * runtime/JSSet.cpp:
        (JSC::JSSet::estimatedSize):
        * runtime/JSSet.h:
        * runtime/JSString.cpp:
        (JSC::JSString::estimatedSize):
        * runtime/JSString.h:
        * runtime/MapData.h:
        (JSC::MapDataImpl::capacityInBytes):
        * runtime/WeakMapData.cpp:
        (JSC::WeakMapData::estimatedSize):
        (JSC::WeakMapData::visitChildren):
        * runtime/WeakMapData.h:
        Implement estimated size following the pattern of reporting
        extra visited size, or copy space memory.

        * runtime/RegExp.cpp:
        (JSC::RegExp::estimatedSize):
        * runtime/RegExp.h:
        * yarr/YarrInterpreter.h:
        (JSC::Yarr::ByteDisjunction::estimatedSizeInBytes):
        (JSC::Yarr::BytecodePattern::estimatedSizeInBytes):
        * yarr/YarrJIT.h:
        (JSC::Yarr::YarrCodeBlock::size):
        Include generated bytecode / JITCode to a RegExp's size.

2016-02-29  Filip Pizlo  <fpizlo@apple.com>

        SpeculatedType should be easier to edit
        https://bugs.webkit.org/show_bug.cgi?id=154840

        Reviewed by Mark Lam.

        We used to specify the bitmasks in SpeculatedType.h using hex codes. This used to work
        great because we didn't have so many masks and you could use the mask to visually see
        which ones overlapped. It also made it easy to visualize subset relationships.

        But now we have a lot of masks with a lot of confusing overlaps, and it's no longer
        possible to just see their relationship by looking at hex codes. Worse, the use of hex
        codes makes it super annoying to move the bits around. For example, right now we have two
        bits free, but if we wanted to reclaim them by editing the old hex masks, it would be a
        nightmare.

        So this patch replaces the hex masks with shift expressions (1u << 15 for example) and it
        makes any derived masks (i.e. masks that are the bit-or of other masks) be expressed using
        an or expression (SpecFoo | SpecBar | SpecBaz for example).

        This makes it easier to see the relationships and it makes it easier to take bits for new
        types.

        * bytecode/SpeculatedType.h:

2016-02-29  Keith Miller  <keith_miller@apple.com>

        OverridesHasInstance constant folding is wrong
        https://bugs.webkit.org/show_bug.cgi?id=154833

        Reviewed by Filip Pizlo.

        The current implementation of OverridesHasInstance constant folding
        is incorrect. Since it relies on OSR exit information it has been
        moved to the StrengthReductionPhase. Normally, such an optimazation would be
        put in FixupPhase, however, there are a number of cases where we don't
        determine an edge of OverridesHasInstance is a constant until after fixup.
        Performing the optimization during StrengthReductionPhase means we can defer
        our decision until later.

        In the future we should consider creating a version of this optimization
        that does not depend on OSR exit information and move the optimization back
        to ConstantFoldingPhase.

        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants): Deleted.
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):

2016-02-28  Filip Pizlo  <fpizlo@apple.com>

        B3 should have global store elimination
        https://bugs.webkit.org/show_bug.cgi?id=154658

        Reviewed by Benjamin Poulain.

        Implements fairly comprehensive global store elimination:

        1) If you store the result of a load with no interference in between, remove the store.

        2) If you store the same thing you stored previously, remove the store.

        3) If you store something that you either loaded previously or stored previously along
           arbitrarily many paths, remove the store.

        4) If you store to something that is stored to again in the future with no interference in
           between, remove the store.

        Rule (4) is super relevant to FTL since the DFG does not eliminate redundant PutStructures.
        A constructor that produces a large object will have many redundant stores to the same base
        pointer, offset, and heap range, with no code to observe that heap raneg in between.

        This doesn't have a decisive effect on major benchmarks, but it's an enormous win for
        microbenchmarks:

        - 30% faster to construct an object with many fields.

        - 5x faster to do many stores to a global variable.

        The compile time cost should be very small. Although the optimization is global, it aborts as
        soon as it sees anything that would confound store elimination. For rules (1)-(3), we
        piggy-back the existing load elimination, which gives up on interfering stores. For rule (4),
        we search forward through the current block and then globally a block at a time (skipping
        block contents thanks to summary data), which could be expensive. But rule (4) aborts as soon
        as it sees a read, write, or end block (Return or Oops). Any Check will claim to read TOP. Any
        Patchpoint that results from an InvalidationPoint will claim to read TOP, as will any
        Patchpoints for ICs. Those are usually sprinkled all over the program.

        In other words, this optimization rarely kicks in. When it does kick in, it makes programs run
        faster. When it doesn't kick in, it's usually O(1) because there are reasons for aborting all
        over a "normal" program so the search will halt almost immediately. This of course raises the
        question: how much more in compile time do we pay when the optimization does kick in? The
        optimization kicks in the most for the microbenchmarks I wrote for this patch. Amazingly, the
        effect of the optimization a wash for compile time: whatever cost we pay doing the O(n^2)
        searches is balanced by the massive reduction in work in the backend. On one of the two
        microbenchmarks, overall compile time actually shrank with this optimization even though CSE
        itself cost more. That's not too surprising - the backend costs much more per instruction, so
        things that remove instructions before we get to the backend tend to be a good idea.

        We could consider adding a more aggressive version of this in the future, which could sink
        stores into checks. That could be crazy fun: https://bugs.webkit.org/show_bug.cgi?id=152162#c3

        But mainly, I'm adding this optimization because it was super fun to implement during the
        WebAssembly CG summit.

        * b3/B3EliminateCommonSubexpressions.cpp:
        * b3/B3MemoryValue.h:
        * b3/B3SuccessorCollection.h:
        (JSC::B3::SuccessorCollection::begin):
        (JSC::B3::SuccessorCollection::end):
        (JSC::B3::SuccessorCollection::const_iterator::const_iterator):
        (JSC::B3::SuccessorCollection::const_iterator::operator*):
        (JSC::B3::SuccessorCollection::const_iterator::operator++):
        (JSC::B3::SuccessorCollection::const_iterator::operator==):
        (JSC::B3::SuccessorCollection::const_iterator::operator!=):

2016-02-29  Filip Pizlo  <fpizlo@apple.com>

        Make it cheap to #include "JITOperations.h"
        https://bugs.webkit.org/show_bug.cgi?id=154836

        Reviewed by Mark Lam.

        Prior to this change, this header included the whole world even though it did't have any
        definitions. This patch turns almost all of the includes into forward declarations. Right
        now this header is very cheap to include.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGSpeculativeJIT.h:
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/Repatch.h:
        * runtime/CommonSlowPaths.h:
        (JSC::encodeResult): Deleted.
        (JSC::decodeResult): Deleted.
        * runtime/SlowPathReturnType.h: Added.
        (JSC::encodeResult):
        (JSC::decodeResult):

2016-02-28  Filip Pizlo  <fpizlo@apple.com>

        FTL should be able to run everything in Octane/regexp
        https://bugs.webkit.org/show_bug.cgi?id=154266

        Reviewed by Saam Barati.

        Adds FTL support for NewRegexp, RegExpTest, and RegExpExec. I couldn't figure out how to
        make the RegExpExec peephole optimization work in FTL. This optimizations shouldn't be a
        DFG backend optimization anyway - if we need this optimization then it should be a
        strength reduction rule over IR. That way, it can be shared by all backends.

        I measured whether removing that optimization had any effect on performance separately
        from measuring the performance of this patch. Removing that optimization did not change
        our score on any benchmarks.

        This patch does have an overall negative effect on the Octane/regexp score. This is
        presumably because tiering up to the FTL has no value to the code in the regexp test. Or
        maybe it's something else. No matter - the overall effect on the Octane score is not
        statistically significant and we don't want this kind of coverage blocked by the fact
        that adding coverage hurts a benchmark.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::setIndexingType):
        (JSC::DFG::Node::hasRegexpIndex):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNotifyWrite):
        (JSC::DFG::SpeculativeJIT::compileIsObjectOrNull):
        (JSC::DFG::SpeculativeJIT::compileRegExpExec): Deleted.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckWatchdogTimer):
        (JSC::FTL::DFG::LowerDFGToB3::compileRegExpExec):
        (JSC::FTL::DFG::LowerDFGToB3::compileRegExpTest):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
        (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
        * tests/stress/ftl-regexp-exec.js: Added.
        * tests/stress/ftl-regexp-test.js: Added.

2016-02-28  Andreas Kling  <akling@apple.com>

        Make JSFunction.name allocation fully lazy.
        <https://webkit.org/b/154806>

        Reviewed by Saam Barati.

        We were reifying the "name" field on functions lazily, but created the string
        value itself up front. This patch gets rid of the up-front allocation,
        saving us a JSString allocation per function in most cases.

        * builtins/BuiltinExecutables.cpp:
        (JSC::createExecutableInternal):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::visitChildren):
        * bytecode/UnlinkedFunctionExecutable.h:
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/Executable.h:
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::reifyName):

2016-02-28  Andreas Kling  <akling@apple.com>

        REGRESSION(r197303): 4 jsc tests failing on bots.

        Unreviewed follow-up fix.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::typeProfilerExpressionInfoForBytecodeOffset): This function
        can still get called with !m_rareData, in case the type profiler is active but this
        particular code block doesn't have type profiler data. Handle it gracefully.

2016-02-28  Andreas Kling  <akling@apple.com>

        Shrink UnlinkedCodeBlock a bit.
        <https://webkit.org/b/154797>

        Reviewed by Anders Carlsson.

        Move profiler-related members of UnlinkedCodeBlock into its RareData
        structure, saving 40 bytes, and then reorder the other members of
        UnlinkedCodeBlock to save another 24 bytes, netting a nice total 64.

        The VM member was removed entirely since UnlinkedCodeBlock is a cell
        and can retrieve its VM through MarkedBlock header lookup.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::vm):
        (JSC::UnlinkedCodeBlock::typeProfilerExpressionInfoForBytecodeOffset):
        (JSC::UnlinkedCodeBlock::addTypeProfilerExpressionInfo):
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted.
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::addRegExp):
        (JSC::UnlinkedCodeBlock::addConstant):
        (JSC::UnlinkedCodeBlock::addFunctionDecl):
        (JSC::UnlinkedCodeBlock::addFunctionExpr):
        (JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset):
        (JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets):
        (JSC::UnlinkedCodeBlock::vm): Deleted.

2016-02-27  Filip Pizlo  <fpizlo@apple.com>

        FTL should lower its abstract heaps to B3 heap ranges
        https://bugs.webkit.org/show_bug.cgi?id=154782

        Reviewed by Saam Barati.

        The FTL can describe the abstract heaps (points-to sets) that a memory operation will
        affect. The abstract heaps are arranged as a hierarchy. We used to transform this into
        TBAA hierarchies in LLVM, but we never got around to wiring this up to B3's equivalent
        notion - the HeapRange. That's what this patch fixes.

        B3 has a minimalistic alias analysis. It represents abstract heaps using unsigned 32-bit
        integers. There are 1<<32 abstract heaps. The B3 client can describe what an operation
        affects by specifying a heap range: a begin...end pair that says that the operation
        affects all abstract heaps H such that begin <= H < end.

        This peculiar scheme was a deliberate attempt to distill what the abstract heap
        hierarchy is all about. We can assign begin...end numbers to abstract heaps so that:

        - A heap's end is greater than its begin.
        - A heap's begin is greater than or equal to its parent's begin.
        - A heap's end is less than or equal to its parent's end.

        This is easy to do using a recursive traversal of the abstract heap hierarchy. I almost
        went for the iterative traversal, which is a splendid algorithm, but it's totally
        unnecessary here since we tightly control the height of the heap hierarchy.

        Because abstract heaps are produced on-the-fly by FTL lowering, due to the fact that we
        generate new ones for field names and constant indices we encounter, we can't actually
        decorate the B3 instructions we create in lowering until all lowering is done. Adding a
        new abstract heap to the hierarchy after ranges were already computed would require
        updating the ranges of any heaps "to the right" of that heap in the hierarchy. This
        patch solves that problem by recording the associations between abstract heaps and their
        intended roles in the generated IR, and then decorating all of the relevant B3 values
        after we compute the ranges of the hierarchy after lowering.

        This is perf-neutral. I was hoping for a small speed-up, but I could not detect a
        speed-up on any benchmark. That's not too surprising. We already have very precise CSE
        in the DFG, so there aren't many opportunities left for the B3 CSE and it may have
        already been getting the big ones even without alias analysis.

        Even without a speed-up, this patch is valuable because it makes it easier to implement
        other optimizations, like store elimination.

        * b3/B3HeapRange.h:
        (JSC::B3::HeapRange::HeapRange):
        * ftl/FTLAbstractHeap.cpp:
        (JSC::FTL::AbstractHeap::AbstractHeap):
        (JSC::FTL::AbstractHeap::changeParent):
        (JSC::FTL::AbstractHeap::compute):
        (JSC::FTL::AbstractHeap::shallowDump):
        (JSC::FTL::AbstractHeap::dump):
        (JSC::FTL::AbstractHeap::deepDump):
        (JSC::FTL::AbstractHeap::badRangeError):
        (JSC::FTL::IndexedAbstractHeap::IndexedAbstractHeap):
        (JSC::FTL::IndexedAbstractHeap::baseIndex):
        (JSC::FTL::IndexedAbstractHeap::atSlow):
        (JSC::FTL::IndexedAbstractHeap::initialize):
        (JSC::FTL::AbstractHeap::decorateInstruction): Deleted.
        (JSC::FTL::AbstractField::dump): Deleted.
        * ftl/FTLAbstractHeap.h:
        (JSC::FTL::AbstractHeap::AbstractHeap):
        (JSC::FTL::AbstractHeap::isInitialized):
        (JSC::FTL::AbstractHeap::initialize):
        (JSC::FTL::AbstractHeap::parent):
        (JSC::FTL::AbstractHeap::heapName):
        (JSC::FTL::AbstractHeap::range):
        (JSC::FTL::AbstractHeap::offset):
        (JSC::FTL::IndexedAbstractHeap::atAnyIndex):
        (JSC::FTL::IndexedAbstractHeap::at):
        (JSC::FTL::IndexedAbstractHeap::operator[]):
        (JSC::FTL::IndexedAbstractHeap::returnInitialized):
        (JSC::FTL::IndexedAbstractHeap::WithoutZeroOrOneHashTraits::constructDeletedValue):
        (JSC::FTL::IndexedAbstractHeap::WithoutZeroOrOneHashTraits::isDeletedValue):
        (JSC::FTL::AbstractHeap::changeParent): Deleted.
        (JSC::FTL::AbstractField::AbstractField): Deleted.
        (JSC::FTL::AbstractField::initialize): Deleted.
        (JSC::FTL::AbstractField::offset): Deleted.
        * ftl/FTLAbstractHeapRepository.cpp:
        (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
        (JSC::FTL::AbstractHeapRepository::~AbstractHeapRepository):
        (JSC::FTL::AbstractHeapRepository::decorateMemory):
        (JSC::FTL::AbstractHeapRepository::decorateCCallRead):
        (JSC::FTL::AbstractHeapRepository::decorateCCallWrite):
        (JSC::FTL::AbstractHeapRepository::decoratePatchpointRead):
        (JSC::FTL::AbstractHeapRepository::decoratePatchpointWrite):
        (JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions):
        * ftl/FTLAbstractHeapRepository.h:
        (JSC::FTL::AbstractHeapRepository::forArrayType):
        (JSC::FTL::AbstractHeapRepository::HeapForValue::HeapForValue):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::load):
        (JSC::FTL::Output::load8SignExt32):
        (JSC::FTL::Output::load8ZeroExt32):
        (JSC::FTL::Output::load16SignExt32):
        (JSC::FTL::Output::load16ZeroExt32):
        (JSC::FTL::Output::store):
        (JSC::FTL::Output::store32As8):
        (JSC::FTL::Output::store32As16):
        (JSC::FTL::Output::baseIndex):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::address):
        (JSC::FTL::Output::absolute):
        (JSC::FTL::Output::load8SignExt32):
        (JSC::FTL::Output::load8ZeroExt32):
        (JSC::FTL::Output::load16SignExt32):
        (JSC::FTL::Output::load16ZeroExt32):
        (JSC::FTL::Output::load32):
        (JSC::FTL::Output::load64):
        (JSC::FTL::Output::loadPtr):
        (JSC::FTL::Output::loadDouble):
        (JSC::FTL::Output::store32):
        (JSC::FTL::Output::store64):
        (JSC::FTL::Output::storePtr):
        (JSC::FTL::Output::storeDouble):
        (JSC::FTL::Output::ascribeRange):
        (JSC::FTL::Output::nonNegative32):
        (JSC::FTL::Output::load32NonNegative):
        (JSC::FTL::Output::equal):
        (JSC::FTL::Output::notEqual):
        * ftl/FTLTypedPointer.h:
        (JSC::FTL::TypedPointer::operator!):
        (JSC::FTL::TypedPointer::heap):
        (JSC::FTL::TypedPointer::value):

2016-02-28  Skachkov Oleksandr  <gskachkov@gmail.com>

        [ES6] Arrow function syntax. Emit loading&putting this/super only if they are used in arrow function
        https://bugs.webkit.org/show_bug.cgi?id=153981

        Reviewed by Saam Barati.
       
        In first iteration of implemenation arrow function, we emit load and store variables 'this', 'arguments',
        'super', 'new.target' in case if arrow function is exist even variables are not used in arrow function. 
        Current patch added logic that prevent from emiting those varibles if they are not used in arrow function.
        During syntax analyze parser store information about using variables in arrow function inside of 
        the ordinary function scope and then put to BytecodeGenerator through UnlinkedCodeBlock

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadThisFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::isThisUsedInInnerArrowFunction):
        (JSC::BytecodeGenerator::isArgumentsUsedInInnerArrowFunction):
        (JSC::BytecodeGenerator::isNewTargetUsedInInnerArrowFunction):
        (JSC::BytecodeGenerator::isSuperUsedInInnerArrowFunction):
        (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode):
        (JSC::EvalFunctionCallNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createBracketAccess):
        (JSC::ASTBuilder::createDotAccess):
        (JSC::ASTBuilder::usesSuperCall):
        (JSC::ASTBuilder::usesSuperProperty):
        (JSC::ASTBuilder::makeFunctionCallNode):
        * parser/Nodes.cpp:
        (JSC::ScopeNode::ScopeNode):
        (JSC::ProgramNode::ProgramNode):
        (JSC::ModuleProgramNode::ModuleProgramNode):
        (JSC::EvalNode::EvalNode):
        (JSC::FunctionNode::FunctionNode):
        * parser/Nodes.h:
        (JSC::ScopeNode::innerArrowFunctionCodeFeatures):
        (JSC::ScopeNode::doAnyInnerArrowFunctionsUseArguments):
        (JSC::ScopeNode::doAnyInnerArrowFunctionsUseSuperCall):
        (JSC::ScopeNode::doAnyInnerArrowFunctionsUseSuperProperty):
        (JSC::ScopeNode::doAnyInnerArrowFunctionsUseEval):
        (JSC::ScopeNode::doAnyInnerArrowFunctionsUseThis):
        (JSC::ScopeNode::doAnyInnerArrowFunctionsUseNewTarget):
        (JSC::ScopeNode::doAnyInnerArrowFunctionUseAnyFeature):
        (JSC::ScopeNode::usesSuperCall):
        (JSC::ScopeNode::usesSuperProperty):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::isArrowFunctionBoundary):
        (JSC::Scope::innerArrowFunctionFeatures):
        (JSC::Scope::setInnerArrowFunctionUsesSuperCall):
        (JSC::Scope::setInnerArrowFunctionUsesSuperProperty):
        (JSC::Scope::setInnerArrowFunctionUsesEval):
        (JSC::Scope::setInnerArrowFunctionUsesThis):
        (JSC::Scope::setInnerArrowFunctionUsesNewTarget):
        (JSC::Scope::setInnerArrowFunctionUsesArguments):
        (JSC::Scope::setInnerArrowFunctionUsesEvalAndUseArgumentsIfNeeded):
        (JSC::Scope::collectFreeVariables):
        (JSC::Scope::mergeInnerArrowFunctionFeatures):
        (JSC::Scope::fillParametersForSourceProviderCache):
        (JSC::Scope::restoreFromSourceProviderCache):
        (JSC::Scope::setIsFunction):
        (JSC::Scope::setIsArrowFunction):
        (JSC::Parser::closestParentNonArrowFunctionNonLexicalScope):
        (JSC::Parser::pushScope):
        (JSC::Parser::popScopeInternal):
        (JSC::Parser<LexerType>::parse):
        * parser/ParserModes.h:
        * parser/SourceProviderCacheItem.h:
        (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createFunctionMetadata):
        * tests/stress/arrowfunction-lexical-bind-arguments-non-strict-1.js:
        * tests/stress/arrowfunction-lexical-bind-arguments-strict.js:
        * tests/stress/arrowfunction-lexical-bind-newtarget.js:
        * tests/stress/arrowfunction-lexical-bind-superproperty.js:
        * tests/stress/arrowfunction-lexical-bind-this-8.js: Added.

2016-02-28  Saam barati  <sbarati@apple.com>

        ProxyObject.[[GetOwnProperty]] is partially broken because it doesn't propagate information back to the slot
        https://bugs.webkit.org/show_bug.cgi?id=154768

        Reviewed by Ryosuke Niwa.

        This fixes a big bug with ProxyObject.[[GetOwnProperty]]:
        http://www.ecma-international.org/ecma-262/6.0/index.html#sec-proxy-object-internal-methods-and-internal-slots-getownproperty-p
        We weren't correctly propagating the result of this operation to the
        out PropertySlot& parameter. This patch fixes that and adds tests.

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetOwnPropertyDescriptor):
        I added a missing exception check after object allocation
        because I saw that it was missing while reading the code.

        * runtime/PropertyDescriptor.cpp:
        (JSC::PropertyDescriptor::setUndefined):
        (JSC::PropertyDescriptor::slowGetterSetter):
        (JSC::PropertyDescriptor::getter):
        * runtime/PropertyDescriptor.h:
        (JSC::PropertyDescriptor::attributes):
        (JSC::PropertyDescriptor::value):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        * tests/es6.yaml:
        * tests/stress/proxy-get-own-property.js:
        (let.handler.getOwnPropertyDescriptor):
        (set get let.handler.return):
        (set get let.handler.getOwnPropertyDescriptor):
        (set get let):
        (set get let.a):
        (let.b):
        (let.setter):
        (let.getter):

2016-02-27  Andy VanWagoner  <thetalecrafter@gmail.com>

        Intl.Collator uses POSIX locale (detected by js/intl-collator.html on iOS Simulator)
        https://bugs.webkit.org/show_bug.cgi?id=152448

        Reviewed by Darin Adler.

        Add defaultLanguage to the globalObjectMethodTable and use it for the
        default locale in Intl object initializations. Fall back to ICU default
        locale only if the defaultLanguage function is null, or returns an
        empty string.

        * jsc.cpp:
        * runtime/IntlCollator.cpp:
        (JSC::IntlCollator::initializeCollator):
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormat::initializeNumberFormat):
        * runtime/IntlObject.cpp:
        (JSC::defaultLocale):
        (JSC::lookupMatcher):
        (JSC::bestFitMatcher):
        (JSC::resolveLocale):
        * runtime/IntlObject.h:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
        * runtime/StringPrototype.cpp:
        (JSC::toLocaleCase):

2016-02-27  Oliver Hunt  <oliver@apple.com>

        CLoop build fix.

        * jit/ExecutableAllocatorFixedVMPool.cpp:

2016-02-26  Oliver Hunt  <oliver@apple.com>

        Remove the on demand executable allocator
        https://bugs.webkit.org/show_bug.cgi?id=154749

        Reviewed by Geoffrey Garen.

        Remove all the DemandExecutable code and executable allocator ifdefs.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/ExecutableAllocator.cpp: Removed.
        (JSC::DemandExecutableAllocator::DemandExecutableAllocator): Deleted.
        (JSC::DemandExecutableAllocator::~DemandExecutableAllocator): Deleted.
        (JSC::DemandExecutableAllocator::bytesAllocatedByAllAllocators): Deleted.
        (JSC::DemandExecutableAllocator::bytesCommittedByAllocactors): Deleted.
        (JSC::DemandExecutableAllocator::dumpProfileFromAllAllocators): Deleted.
        (JSC::DemandExecutableAllocator::allocateNewSpace): Deleted.
        (JSC::DemandExecutableAllocator::notifyNeedPage): Deleted.
        (JSC::DemandExecutableAllocator::notifyPageIsFree): Deleted.
        (JSC::DemandExecutableAllocator::allocators): Deleted.
        (JSC::DemandExecutableAllocator::allocatorsMutex): Deleted.
        (JSC::ExecutableAllocator::initializeAllocator): Deleted.
        (JSC::ExecutableAllocator::ExecutableAllocator): Deleted.
        (JSC::ExecutableAllocator::~ExecutableAllocator): Deleted.
        (JSC::ExecutableAllocator::isValid): Deleted.
        (JSC::ExecutableAllocator::underMemoryPressure): Deleted.
        (JSC::ExecutableAllocator::memoryPressureMultiplier): Deleted.
        (JSC::ExecutableAllocator::allocate): Deleted.
        (JSC::ExecutableAllocator::committedByteCount): Deleted.
        (JSC::ExecutableAllocator::dumpProfile): Deleted.
        (JSC::ExecutableAllocator::getLock): Deleted.
        (JSC::ExecutableAllocator::isValidExecutableMemory): Deleted.
        (JSC::ExecutableAllocator::reprotectRegion): Deleted.
        * jit/ExecutableAllocator.h:
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        * jit/JITStubRoutine.h:
        (JSC::JITStubRoutine::canPerformRangeFilter): Deleted.
        (JSC::JITStubRoutine::filteringStartAddress): Deleted.
        (JSC::JITStubRoutine::filteringExtentSize): Deleted.

2016-02-26  Joseph Pecoraro  <pecoraro@apple.com>

        Reduce direct callers of Structure::findStructuresAndMapForMaterialization
        https://bugs.webkit.org/show_bug.cgi?id=154751

        Reviewed by Mark Lam.

        * runtime/Structure.cpp:
        (JSC::Structure::toStructureShape):
        This property name iteration is identical to Structure::forEachPropertyConcurrently.
        Share the code and reduce callers to the subtle findStructuresAndMapForMaterialization.

2016-02-26  Mark Lam  <mark.lam@apple.com>

        Function.name and Function.length should be configurable.
        https://bugs.webkit.org/show_bug.cgi?id=154604

        Reviewed by Saam Barati.

        According to https://tc39.github.io/ecma262/#sec-ecmascript-language-functions-and-classes,
        "Unless otherwise specified, the name property of a built-in Function object,
        if it exists, has the attributes { [[Writable]]: false, [[Enumerable]]: false,
        [[Configurable]]: true }."

        Similarly, "the length property of a built-in Function object has the attributes
        { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true }."

        This patch makes Function.name and Function.length configurable.

        We do this by lazily reifying the JSFunction name and length properties on first
        access.  We track whether each of these properties have been reified using flags
        in the FunctionRareData.  On first access, if not already reified, we will put
        the property into the object with its default value and attributes and set the
        reified flag.  Thereafter, we rely on the base JSObject to handle access to the
        property.

        Also, lots of test results have to be re-baselined because the old Function.length
        has attribute DontDelete, which is in conflict with the ES6 requirement that it
        is configurable.

        * runtime/FunctionRareData.h:
        (JSC::FunctionRareData::hasReifiedLength):
        (JSC::FunctionRareData::setHasReifiedLength):
        (JSC::FunctionRareData::hasReifiedName):
        (JSC::FunctionRareData::setHasReifiedName):
        - Flags for tracking whether each property has been reified.

        * runtime/JSFunction.cpp:
        (JSC::JSFunction::finishCreation):
        (JSC::JSFunction::createBuiltinFunction):
        - Host and builtin functions currently always reify their name and length
          properties.  Currently, for builtins, the default names that are used may
          differ from the executable name.  For now, we'll stay with keeping this
          alternate approach to getting the name and length properties for host and
          builtin functions.
          However, we need their default attribute to be configurable as well.

        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::getOwnNonIndexPropertyNames):
        (JSC::JSFunction::put):
        (JSC::JSFunction::deleteProperty):
        (JSC::JSFunction::defineOwnProperty):
        (JSC::JSFunction::reifyLength):
        (JSC::JSFunction::reifyName):
        (JSC::JSFunction::reifyLazyPropertyIfNeeded):
        (JSC::JSFunction::lengthGetter): Deleted.
        (JSC::JSFunction::nameGetter): Deleted.
        * runtime/JSFunction.h:
        * runtime/JSFunctionInlines.h:
        (JSC::JSFunction::hasReifiedLength):
        (JSC::JSFunction::hasReifiedName):

        * tests/es6.yaml:
        - 4 new passing tests.

        * tests/mozilla/ecma/Array/15.4.4.3-1.js:
        * tests/mozilla/ecma/Array/15.4.4.4-1.js:
        * tests/mozilla/ecma/Array/15.4.4.4-2.js:
        * tests/mozilla/ecma/GlobalObject/15.1.2.1-1.js:
        * tests/mozilla/ecma/GlobalObject/15.1.2.2-1.js:
        * tests/mozilla/ecma/GlobalObject/15.1.2.3-1.js:
        * tests/mozilla/ecma/GlobalObject/15.1.2.4.js:
        * tests/mozilla/ecma/GlobalObject/15.1.2.5-1.js:
        * tests/mozilla/ecma/GlobalObject/15.1.2.6.js:
        * tests/mozilla/ecma/GlobalObject/15.1.2.7.js:
        * tests/mozilla/ecma/String/15.5.4.10-1.js:
        * tests/mozilla/ecma/String/15.5.4.11-1.js:
        * tests/mozilla/ecma/String/15.5.4.11-5.js:
        * tests/mozilla/ecma/String/15.5.4.12-1.js:
        * tests/mozilla/ecma/String/15.5.4.6-2.js:
        * tests/mozilla/ecma/String/15.5.4.7-2.js:
        * tests/mozilla/ecma/String/15.5.4.8-1.js:
        * tests/mozilla/ecma/String/15.5.4.9-1.js:
        - Rebase expected test results.

        * tests/stress/function-configurable-properties.js: Added.

2016-02-26  Keith Miller  <keith_miller@apple.com>

        Folding of OverridesHasInstance DFG nodes shoud happen in constant folding not fixup
        https://bugs.webkit.org/show_bug.cgi?id=154743

        Reviewed by Mark Lam.

        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

2016-02-26  Keith Miller  <keith_miller@apple.com>

        Native Typed Array functions should use Symbol.species
        https://bugs.webkit.org/show_bug.cgi?id=154569

        Reviewed by Michael Saboff.

        This patch adds support for Symbol.species in the native Typed Array prototype
        functions. Additionally, now that other types of typedarrays are creatable inside
        the slice we use the JSGenericTypedArrayView::set function, which has been beefed
        up, to put everything into the correct place.

        * runtime/JSDataView.cpp:
        (JSC::JSDataView::set):
        * runtime/JSDataView.h:
        * runtime/JSGenericTypedArrayView.h:
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewFromIterator):
        (JSC::constructGenericTypedArrayViewWithArguments):
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::setWithSpecificType):
        (JSC::JSGenericTypedArrayView<Adaptor>::set):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::speciesConstruct):
        (JSC::genericTypedArrayViewProtoFuncSet):
        (JSC::genericTypedArrayViewProtoFuncSlice):
        (JSC::genericTypedArrayViewProtoFuncSubarray):
        * tests/stress/typedarray-slice.js:
        (subclasses.typedArrays.map):
        (testSpecies):
        (forEach):
        (subclasses.forEach):
        (testSpeciesRemoveConstructor):
        (testSpeciesWithSameBuffer):
        * tests/stress/typedarray-subarray.js: Added.
        (subclasses.typedArrays.map):
        (testSpecies):
        (forEach):
        (subclasses.forEach):
        (testSpeciesRemoveConstructor):

2016-02-26  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add32(Imm, Tmp, Tmp) does not ZDef the destination if Imm is zero
        https://bugs.webkit.org/show_bug.cgi?id=154704

        Reviewed by Geoffrey Garen.

        If the Imm is zero, we should still zero the top bits
        to match the definition in AirOpcodes.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::add32):
        * b3/testb3.cpp:

2016-02-26  Oliver Hunt  <oliver@apple.com>

        Make testRegExp not crash when given an invalid regexp
        https://bugs.webkit.org/show_bug.cgi?id=154732

        Reviewed by Mark Lam.

        * testRegExp.cpp:
        (parseRegExpLine):

2016-02-26  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Add the test for r197155
        https://bugs.webkit.org/show_bug.cgi?id=154715

        Reviewed by Mark Lam.

        Silly me. I forgot the test in the latest patch update.

        * tests/stress/class-syntax-tdz-osr-entry-in-loop.js: Added.

2016-02-26  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG] Drop unnecessary proved type branch in ToPrimitive
        https://bugs.webkit.org/show_bug.cgi?id=154716

        Reviewed by Geoffrey Garen.

        This branching based on the proved types is unnecessary because this is already handled in constant folding phase.
        In fact, the DFGSpeculativeJIT64.cpp case is already removed in r164243.
        This patch removes the remaining JIT32_64 case.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2016-02-25  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Be aggressive with OSR Entry to FTL if the DFG function was only used for OSR Entry itself
        https://bugs.webkit.org/show_bug.cgi?id=154575

        Reviewed by Filip Pizlo.

        I noticed that imaging-gaussian-blur spends most of its
        samples in DFG code despite executing most of the loop
        iterations in FTL.

        On this particular test, the main function is only entered
        once and have a very heavy loop there. What happens is DFG
        starts by compiling the full function in FTL. That takes about
        8 to 10 milliseconds during which the DFG code makes very little
        progress. The calls to triggerOSREntryNow() try to OSR Enter
        for a while then finally start compiling something. By the time
        the function is ready, we have wasted a lot of time in DFG code.

        What this patch does is set a flag when a DFG function is entered.
        If we try to triggerOSREntryNow() and the flag was never set,
        we start compiling both the full function and the one for OSR Entry.

        * dfg/DFGJITCode.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileEntryExecutionFlag):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITCompiler.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::Plan): Deleted.
        * dfg/DFGPlan.h:
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):

2016-02-25  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Temporal Dead Zone checks on "this" are eliminated when doing OSR Entry to FTL
        https://bugs.webkit.org/show_bug.cgi?id=154664

        Reviewed by Saam Barati.

        When doing OSR Enter into a constructor, we lose the information
        that this may have been set to empty by a previously executed block.

        All the code just assumed the type for a FlushedJS value and thus
        not an empty value. It was then okay to eliminate the TDZ checks.

        In this patch, the values on root entry now assume they may be empty.
        As a result, the SetArgument() for "this" has "empty" as possible
        type and the TDZ checks are no longer eliminated.

        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):

2016-02-25  Ada Chan  <adachan@apple.com>

        Update the definition of ENABLE_VIDEO_PRESENTATION_MODE for Mac platform
        https://bugs.webkit.org/show_bug.cgi?id=154702

        Reviewed by Dan Bernstein.

        * Configurations/FeatureDefines.xcconfig:

2016-02-25  Saam barati  <sbarati@apple.com>

        [ES6] for...in iteration doesn't comply with the specification
        https://bugs.webkit.org/show_bug.cgi?id=154665

        Reviewed by Michael Saboff.

        If you read ForIn/OfHeadEvaluation inside the spec:
        https://tc39.github.io/ecma262/#sec-runtime-semantics-forin-div-ofheadevaluation-tdznames-expr-iterationkind
        It calls EnumerateObjectProperties(obj) to get a set of properties
        to enumerate over (it models this "set" as en ES6 generator function).
        EnumerateObjectProperties is defined in section 13.7.5.15:
        https://tc39.github.io/ecma262/#sec-enumerate-object-properties
        The implementation calls Reflect.getOwnPropertyDescriptor(.) on the
        properties it sees. We must do the same by modeling the operation as
        a [[GetOwnProperty]] instead of a [[HasProperty]] internal method call.

        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSObject.cpp:
        (JSC::JSObject::hasProperty):
        (JSC::JSObject::hasPropertyGeneric):
        * runtime/JSObject.h:
        * tests/stress/proxy-get-own-property.js:
        (assert):
        (let.handler.getOwnPropertyDescriptor):
        (i.set assert):

2016-02-25  Saam barati  <sbarati@apple.com>

        [ES6] Implement Proxy.[[Set]]
        https://bugs.webkit.org/show_bug.cgi?id=154511

        Reviewed by Filip Pizlo.

        This patch is mostly an implementation of
        Proxy.[[Set]] with respect to section 9.5.9
        of the ECMAScript spec.
        https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-set-p-v-receiver

        This patch also changes JSObject::putInline and JSObject::putByIndex
        to be aware that a Proxy in the prototype chain will intercept
        property accesses.

        * runtime/JSObject.cpp:
        (JSC::JSObject::putInlineSlow):
        (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
        * runtime/JSObject.h:
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::canPerformFastPutInline):
        (JSC::JSObject::putInline):
        * runtime/JSType.h:
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::getOwnPropertySlotByIndex):
        (JSC::ProxyObject::performPut):
        (JSC::ProxyObject::put):
        (JSC::ProxyObject::putByIndexCommon):
        (JSC::ProxyObject::putByIndex):
        (JSC::performProxyCall):
        (JSC::ProxyObject::getCallData):
        (JSC::performProxyConstruct):
        (JSC::ProxyObject::deletePropertyByIndex):
        (JSC::ProxyObject::visitChildren):
        * runtime/ProxyObject.h:
        (JSC::ProxyObject::create):
        (JSC::ProxyObject::createStructure):
        (JSC::ProxyObject::target):
        (JSC::ProxyObject::handler):
        * tests/es6.yaml:
        * tests/stress/proxy-set.js: Added.
        (assert):
        (throw.new.Error.let.handler.set 45):
        (throw.new.Error):
        (let.target.set x):
        (let.target.get x):
        (set let):

2016-02-25  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove a useless "Move" in the lowering of Select
        https://bugs.webkit.org/show_bug.cgi?id=154670

        Reviewed by Geoffrey Garen.

        I left the Move instruction when creating the aliasing form
        of Select.

        On ARM64, that meant a useless move for any case that can't
        be coalesced.

        On x86, that meant an extra constraint on child2, making it
        stupidly hard to alias child1.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createSelect): Deleted.

2016-02-24  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Expose Proxy target and handler internal properties to Inspector
        https://bugs.webkit.org/show_bug.cgi?id=154663

        Reviewed by Timothy Hatcher.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        Expose the ProxyObject's target and handler.

2016-02-24  Nikos Andronikos  <nikos.andronikos-webkit@cisra.canon.com.au>

        [web-animations] Add AnimationTimeline, DocumentTimeline and add extensions to Document interface
        https://bugs.webkit.org/show_bug.cgi?id=151688

        Reviewed by Dean Jackson.

        Enables the WEB_ANIMATIONS compiler switch.

        * Configurations/FeatureDefines.xcconfig:

2016-02-24  Konstantin Tokarev  <annulen@yandex.ru>

        [cmake] Moved PRE/POST_BUILD_COMMAND to WEBKIT_FRAMEWORK.
        https://bugs.webkit.org/show_bug.cgi?id=154651

        Reviewed by Alex Christensen.

        * CMakeLists.txt: Moved shared code to WEBKIT_FRAMEWORK macro.

2016-02-24  Commit Queue  <commit-queue@webkit.org>

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

        "It broke JSC tests when 'this' was loaded from global scope"
        (Requested by saamyjoon on #webkit).

        Reverted changeset:

        "[ES6] Arrow function syntax. Emit loading&putting this/super
        only if they are used in arrow function"
        https://bugs.webkit.org/show_bug.cgi?id=153981
        http://trac.webkit.org/changeset/197033

2016-02-24  Saam Barati  <sbarati@apple.com>

        [ES6] Implement Proxy.[[Delete]]
        https://bugs.webkit.org/show_bug.cgi?id=154607

        Reviewed by Mark Lam.

        This patch implements Proxy.[[Delete]] with respect to section 9.5.10 of the ECMAScript spec.
        https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-delete-p

        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::getConstructData):
        (JSC::ProxyObject::performDelete):
        (JSC::ProxyObject::deleteProperty):
        (JSC::ProxyObject::deletePropertyByIndex):
        * runtime/ProxyObject.h:
        * tests/es6.yaml:
        * tests/stress/proxy-delete.js: Added.
        (assert):
        (throw.new.Error.let.handler.get deleteProperty):
        (throw.new.Error):
        (assert.let.handler.deleteProperty):
        (let.handler.deleteProperty):

2016-02-24  Filip Pizlo  <fpizlo@apple.com>

        Stackmaps have problems with double register constraints
        https://bugs.webkit.org/show_bug.cgi?id=154643

        Reviewed by Geoffrey Garen.

        This is currently a benign bug. I found it while playing.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::fillStackmap):
        * b3/testb3.cpp:
        (JSC::B3::testURShiftSelf64):
        (JSC::B3::testPatchpointDoubleRegs):
        (JSC::B3::zero):
        (JSC::B3::run):

2016-02-24  Skachkov Oleksandr  <gskachkov@gmail.com>

        [ES6] Arrow function syntax. Emit loading&putting this/super only if they are used in arrow function
        https://bugs.webkit.org/show_bug.cgi?id=153981

        Reviewed by Saam Barati.
       
        In first iteration of implemenation arrow function, we emit load and store variables 'this', 'arguments',
        'super', 'new.target' in case if arrow function is exist even variables are not used in arrow function. 
        Current patch added logic that prevent from emiting those varibles if they are not used in arrow function.
        During syntax analyze parser store information about using variables in arrow function inside of 
        the ordinary function scope and then put to BytecodeGenerator through UnlinkedCodeBlock

        * bytecode/ExecutableInfo.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::arrowFunctionCodeFeatures):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::arrowFunctionCodeFeatures):
        (JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseArguments):
        (JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseSuperCall):
        (JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseSuperProperty):
        (JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseEval):
        (JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseThis):
        (JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseNewTarget):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadThisFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::isThisUsedInInnerArrowFunction):
        (JSC::BytecodeGenerator::isArgumentsUsedInInnerArrowFunction):
        (JSC::BytecodeGenerator::isNewTargetUsedInInnerArrowFunction):
        (JSC::BytecodeGenerator::isSuperUsedInInnerArrowFunction):
        (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode):
        (JSC::EvalFunctionCallNode::emitBytecode):
        (JSC::FunctionCallValueNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFunctionMetadata):
        * parser/Nodes.cpp:
        (JSC::FunctionMetadataNode::FunctionMetadataNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
        (JSC::Parser<LexerType>::parseFunctionBody):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::isArrowFunctionBoundary):
        (JSC::Scope::innerArrowFunctionFeatures):
        (JSC::Scope::setInnerArrowFunctionUseSuperCall):
        (JSC::Scope::setInnerArrowFunctionUseSuperProperty):
        (JSC::Scope::setInnerArrowFunctionUseEval):
        (JSC::Scope::setInnerArrowFunctionUseThis):
        (JSC::Scope::setInnerArrowFunctionUseNewTarget):
        (JSC::Scope::setInnerArrowFunctionUseArguments):
        (JSC::Scope::setInnerArrowFunctionUseEvalAndUseArgumentsIfNeeded):
        (JSC::Scope::collectFreeVariables):
        (JSC::Scope::mergeInnerArrowFunctionFeatures):
        (JSC::Scope::fillParametersForSourceProviderCache):
        (JSC::Scope::restoreFromSourceProviderCache):
        (JSC::Scope::setIsFunction):
        (JSC::Scope::setIsArrowFunction):
        (JSC::Parser::closestParentNonArrowFunctionNonLexicalScope):
        (JSC::Parser::pushScope):
        (JSC::Parser::popScopeInternal):
        * parser/ParserModes.h:
        * parser/SourceProviderCacheItem.h:
        (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createFunctionMetadata):
        * tests/stress/arrowfunction-lexical-bind-arguments-non-strict-1.js:
        * tests/stress/arrowfunction-lexical-bind-arguments-strict.js:
        * tests/stress/arrowfunction-lexical-bind-newtarget.js:
        * tests/stress/arrowfunction-lexical-bind-superproperty.js:
        * tests/stress/arrowfunction-lexical-bind-this-8.js: Added.

2016-02-23  Brian Burg  <bburg@apple.com>

        Web Inspector: teach the Objective-C protocol generators about --frontend and --backend directives
        https://bugs.webkit.org/show_bug.cgi?id=154615
        <rdar://problem/24804330>

        Reviewed by Timothy Hatcher.

        Some of the generated Objective-C bindings are only relevant to code acting as the
        protocol backend. Add a per-generator setting mechanism and propagate --frontend and
        --backend to all generators. Use the setting in a few generators to omit code that's
        not needed.

        Also fix a few places where the code emits the wrong Objective-C class prefix.
        There is some common non-generated code that must always have the RWIProtocol prefix.

        Lastly, change includes to use RWIProtocolJSONObjectPrivate.h instead of *Internal.h. The
        macros defined in the internal header now need to be used outside of the framework.

        * inspector/scripts/codegen/generate_objc_conversion_helpers.py:
        Use OBJC_STATIC_PREFIX along with the file name and use different include syntax
        depending on the target framework.

        * inspector/scripts/codegen/generate_objc_header.py:
        (ObjCHeaderGenerator.generate_output):
        For now, omit generating command protocol and event dispatchers when generating for --frontend.

        (ObjCHeaderGenerator._generate_type_interface):
        Use OBJC_STATIC_PREFIX along with the unprefixed file name.

        * inspector/scripts/codegen/generate_objc_internal_header.py:
        Use RWIProtocolJSONObjectPrivate.h instead.

        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator.generate_output):
        Include the Internal header if it's being generated (only for --backend).

        * inspector/scripts/codegen/generator.py:
        (Generator.__init__):
        (Generator.set_generator_setting):
        (Generator):
        (Generator.get_generator_setting):
        Crib a simple setting system from the Framework class. Make the names more obnoxious.

        (Generator.string_for_file_include):
        Inspired by the replay input generator, this is a function that uses the proper syntax
        for a file include depending on the file's framework and target framework.

        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator.and):
        (ObjCGenerator.and.objc_prefix):
        (ObjCGenerator):
        (ObjCGenerator.objc_type_for_raw_name):
        (ObjCGenerator.objc_class_for_raw_name):
        Whitelist the 'Automation' domain for the ObjC generators. Revise use of OBJC_STATIC_PREFIX.

        * inspector/scripts/generate-inspector-protocol-bindings.py:
        (generate_from_specification):
        Change the generators to use for the frontend. Propagate --frontend and --backend.

        * 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. They now correctly include RWIProtocolJSONObject.h and the like.

2016-02-23  Saam barati  <sbarati@apple.com>

        arrayProtoFuncConcat doesn't check for an exception after allocating an array
        https://bugs.webkit.org/show_bug.cgi?id=154621

        Reviewed by Michael Saboff.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncConcat):

2016-02-23  Dan Bernstein  <mitz@apple.com>

        [Xcode] Linker errors display mangled names, but no longer should
        https://bugs.webkit.org/show_bug.cgi?id=154632

        Reviewed by Sam Weinig.

        * Configurations/Base.xcconfig: Stop setting LINKER_DISPLAYS_MANGLED_NAMES to YES.

2016-02-23  Gavin Barraclough  <barraclough@apple.com>

        Remove HIDDEN_PAGE_DOM_TIMER_THROTTLING feature define
        https://bugs.webkit.org/show_bug.cgi?id=112323

        Reviewed by Chris Dumez.

        This feature is controlled by a runtime switch, and defaults off.

        * Configurations/FeatureDefines.xcconfig:

2016-02-23  Keith Miller  <keith_miller@apple.com>

        JSC stress tests' standalone-pre.js should exit on the first failure by default
        https://bugs.webkit.org/show_bug.cgi?id=154565

        Reviewed by Mark Lam.

        Currently, if a test writer does not call finishJSTest() at the end of
        any test using stress/resources/standalone-pre.js then the test can fail
        without actually reporting an error to the harness. By default, we
        should throw on the first error so, in the event someone does not call
        finishJSTest() the harness will still notice the error.

        * tests/stress/regress-151324.js:
        * tests/stress/resources/standalone-pre.js:
        (testFailed):

2016-02-23  Saam barati  <sbarati@apple.com>

        Make JSObject::getMethod have fewer branches
        https://bugs.webkit.org/show_bug.cgi?id=154603

        Reviewed by Mark Lam.

        Writing code with fewer branches is almost always better.

        * runtime/JSObject.cpp:
        (JSC::JSObject::getMethod):

2016-02-23  Filip Pizlo  <fpizlo@apple.com>

        B3::Value doesn't self-destruct virtually enough (Causes many leaks in LowerDFGToB3::appendOSRExit)
        https://bugs.webkit.org/show_bug.cgi?id=154592

        Reviewed by Saam Barati.

        If Foo has a virtual destructor, then:

        foo->Foo::~Foo() does a non-virtual call to Foo's destructor. Even if foo points to a
        subclass of Foo that overrides the destructor, this syntax will not call that override.

        foo->~Foo() does a virtual call to the destructor, and so if foo points to a subclass, you
        get the subclass's override.

        In B3, we used this->Value::~Value() thinking that it would call the subclass's override.
        This caused leaks because this didn't actually call the subclass's override. This fixes the
        problem by using this->~Value() instead.

        * b3/B3ControlValue.cpp:
        (JSC::B3::ControlValue::convertToJump):
        (JSC::B3::ControlValue::convertToOops):
        * b3/B3Value.cpp:
        (JSC::B3::Value::replaceWithIdentity):
        (JSC::B3::Value::replaceWithNop):
        (JSC::B3::Value::replaceWithPhi):

2016-02-23  Brian Burg  <bburg@apple.com>

        Web Inspector: the protocol generator's Objective-C name prefix should be configurable
        https://bugs.webkit.org/show_bug.cgi?id=154596
        <rdar://problem/24794962>

        Reviewed by Timothy Hatcher.

        In order to support different generated protocol sets that don't have conflicting
        file and type names, allow the Objective-C prefix to be configurable based on the
        target framework. Each name also has the implicit prefix 'Protocol' appended to the
        per-target framework prefix.

        For example, the existing protocol for remote inspection has the prefix 'RWI'
        and is generated as 'RWIProtocol'. The WebKit framework has the 'Automation' prefix
        and is generated as 'AutomationProtocol'.

        To make this change, convert ObjCGenerator to be a subclass of Generator and use
        the instance method model() to find the target framework and its setting for
        'objc_prefix'. Make all ObjC generators subclass ObjCGenerator so they can use
        these instance methods that used to be static methods. This is a large but
        mechanical change to use self instead of ObjCGenerator.

        * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
        (ObjCBackendDispatcherHeaderGenerator):
        (ObjCBackendDispatcherHeaderGenerator.__init__):
        (ObjCBackendDispatcherHeaderGenerator.output_filename):
        (ObjCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations):
        (ObjCBackendDispatcherHeaderGenerator._generate_objc_handler_declarations_for_domain):
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
        (ObjCConfigurationImplementationGenerator):
        (ObjCConfigurationImplementationGenerator.__init__):
        (ObjCConfigurationImplementationGenerator.output_filename):
        (ObjCConfigurationImplementationGenerator.generate_output):
        (ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
        (ObjCConfigurationImplementationGenerator._generate_success_block_for_command.and):
        (ObjCConfigurationImplementationGenerator._generate_conversions_for_command):
        * inspector/scripts/codegen/generate_objc_configuration_header.py:
        (ObjCConfigurationHeaderGenerator):
        (ObjCConfigurationHeaderGenerator.__init__):
        (ObjCConfigurationHeaderGenerator.output_filename):
        (ObjCConfigurationHeaderGenerator.generate_output):
        (ObjCConfigurationHeaderGenerator._generate_configuration_interface_for_domains):
        (ObjCConfigurationHeaderGenerator._generate_properties_for_domain):
        * inspector/scripts/codegen/generate_objc_configuration_implementation.py:
        (ObjCBackendDispatcherImplementationGenerator):
        (ObjCBackendDispatcherImplementationGenerator.__init__):
        (ObjCBackendDispatcherImplementationGenerator.output_filename):
        (ObjCBackendDispatcherImplementationGenerator.generate_output):
        (ObjCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains):
        (ObjCBackendDispatcherImplementationGenerator._generate_ivars):
        (ObjCBackendDispatcherImplementationGenerator._generate_handler_setter_for_domain):
        (ObjCBackendDispatcherImplementationGenerator._generate_event_dispatcher_getter_for_domain):
        * inspector/scripts/codegen/generate_objc_conversion_helpers.py:
        (ObjCConversionHelpersGenerator):
        (ObjCConversionHelpersGenerator.__init__):
        (ObjCConversionHelpersGenerator.output_filename):
        (ObjCConversionHelpersGenerator.generate_output):
        (ObjCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_declaration):
        (ObjCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_member):
        (ObjCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_parameter):
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator):
        (ObjCFrontendDispatcherImplementationGenerator.__init__):
        (ObjCFrontendDispatcherImplementationGenerator.output_filename):
        (ObjCFrontendDispatcherImplementationGenerator.generate_output):
        (ObjCFrontendDispatcherImplementationGenerator._generate_event_dispatcher_implementations):
        (ObjCFrontendDispatcherImplementationGenerator._generate_event):
        (ObjCFrontendDispatcherImplementationGenerator._generate_event.and):
        (ObjCFrontendDispatcherImplementationGenerator._generate_event_signature):
        (ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
        * inspector/scripts/codegen/generate_objc_header.py:
        (ObjCHeaderGenerator):
        (ObjCHeaderGenerator.__init__):
        (ObjCHeaderGenerator.output_filename):
        (ObjCHeaderGenerator.generate_output):
        (ObjCHeaderGenerator._generate_forward_declarations):
        (ObjCHeaderGenerator._generate_anonymous_enum_for_declaration):
        (ObjCHeaderGenerator._generate_anonymous_enum_for_member):
        (ObjCHeaderGenerator._generate_anonymous_enum_for_parameter):
        (ObjCHeaderGenerator._generate_type_interface):
        (ObjCHeaderGenerator._generate_init_method_for_required_members):
        (ObjCHeaderGenerator._generate_member_property):
        (ObjCHeaderGenerator._generate_command_protocols):
        (ObjCHeaderGenerator._generate_single_command_protocol):
        (ObjCHeaderGenerator._callback_block_for_command):
        (ObjCHeaderGenerator._generate_event_interfaces):
        (ObjCHeaderGenerator._generate_single_event_interface):
        * inspector/scripts/codegen/generate_objc_internal_header.py:
        (ObjCInternalHeaderGenerator):
        (ObjCInternalHeaderGenerator.__init__):
        (ObjCInternalHeaderGenerator.output_filename):
        (ObjCInternalHeaderGenerator.generate_output):
        (ObjCInternalHeaderGenerator._generate_event_dispatcher_private_interfaces):
        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator):
        (ObjCProtocolTypesImplementationGenerator.__init__):
        (ObjCProtocolTypesImplementationGenerator.output_filename):
        (ObjCProtocolTypesImplementationGenerator.generate_output):
        (ObjCProtocolTypesImplementationGenerator.generate_type_implementation):
        (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members):
        (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members.and):
        (ObjCProtocolTypesImplementationGenerator._generate_setter_for_member):
        (ObjCProtocolTypesImplementationGenerator._generate_setter_for_member.and):
        (ObjCProtocolTypesImplementationGenerator._generate_getter_for_member):
        * inspector/scripts/codegen/models.py:
        * inspector/scripts/codegen/objc_generator.py:
        (ObjCTypeCategory.category_for_type):
        (ObjCGenerator):
        (ObjCGenerator.__init__):
        (ObjCGenerator.objc_prefix):
        (ObjCGenerator.objc_name_for_type):
        (ObjCGenerator.objc_enum_name_for_anonymous_enum_declaration):
        (ObjCGenerator.objc_enum_name_for_anonymous_enum_member):
        (ObjCGenerator.objc_enum_name_for_anonymous_enum_parameter):
        (ObjCGenerator.objc_enum_name_for_non_anonymous_enum):
        (ObjCGenerator.objc_class_for_type):
        (ObjCGenerator.objc_class_for_array_type):
        (ObjCGenerator.objc_accessor_type_for_member):
        (ObjCGenerator.objc_accessor_type_for_member_internal):
        (ObjCGenerator.objc_type_for_member):
        (ObjCGenerator.objc_type_for_member_internal):
        (ObjCGenerator.objc_type_for_param):
        (ObjCGenerator.objc_type_for_param_internal):
        (ObjCGenerator.objc_protocol_export_expression_for_variable):
        (ObjCGenerator.objc_protocol_import_expression_for_member):
        (ObjCGenerator.objc_protocol_import_expression_for_parameter):
        (ObjCGenerator.objc_protocol_import_expression_for_variable):
        (ObjCGenerator.objc_to_protocol_expression_for_member):
        (ObjCGenerator.protocol_to_objc_expression_for_member):

        Change the prefix for the 'Test' target framework to be 'Test.' Rebaseline results.

        * 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:

2016-02-23  Mark Lam  <mark.lam@apple.com>

        Debug assertion failure while loading http://kangax.github.io/compat-table/es6/.
        https://bugs.webkit.org/show_bug.cgi?id=154542

        Reviewed by Saam Barati.

        According to the spec, the constructors of the following types "are not intended
        to be called as a function and will throw an exception".  These types are:
            TypedArrays - https://tc39.github.io/ecma262/#sec-typedarray-constructors
            Map - https://tc39.github.io/ecma262/#sec-map-constructor
            Set - https://tc39.github.io/ecma262/#sec-set-constructor
            WeakMap - https://tc39.github.io/ecma262/#sec-weakmap-constructor
            WeakSet - https://tc39.github.io/ecma262/#sec-weakset-constructor
            ArrayBuffer - https://tc39.github.io/ecma262/#sec-arraybuffer-constructor
            DataView - https://tc39.github.io/ecma262/#sec-dataview-constructor
            Promise - https://tc39.github.io/ecma262/#sec-promise-constructor
            Proxy - https://tc39.github.io/ecma262/#sec-proxy-constructor

        This patch does the foillowing:
        1. Ensures that these constructors can be called but will throw a TypeError
           when called.
        2. Makes all these objects use throwConstructorCannotBeCalledAsFunctionTypeError()
           in their implementation to be consistent.
        3. Change the error message to "calling XXX constructor without new is invalid".
           This is clearer because the error is likely due to the user forgetting to use
           the new operator on these constructors.

        * runtime/Error.h:
        * runtime/Error.cpp:
        (JSC::throwConstructorCannotBeCalledAsFunctionTypeError):
        - Added a convenience function to throw the TypeError.

        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::constructArrayBuffer):
        (JSC::callArrayBuffer):
        (JSC::JSArrayBufferConstructor::getCallData):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::callGenericTypedArrayView):
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::getCallData):
        * runtime/JSPromiseConstructor.cpp:
        (JSC::callPromise):
        * runtime/MapConstructor.cpp:
        (JSC::callMap):
        * runtime/ProxyConstructor.cpp:
        (JSC::callProxy):
        (JSC::ProxyConstructor::getCallData):
        * runtime/SetConstructor.cpp:
        (JSC::callSet):
        * runtime/WeakMapConstructor.cpp:
        (JSC::callWeakMap):
        * runtime/WeakSetConstructor.cpp:
        (JSC::callWeakSet):

        * tests/es6.yaml:
        - The typed_arrays_%TypedArray%[Symbol.species].js test now passes.

        * tests/stress/call-non-calleable-constructors-as-function.js: Added.
        (test):

        * tests/stress/map-constructor.js:
        (testCallTypeError):
        * tests/stress/promise-cannot-be-called.js:
        (shouldThrow):
        * tests/stress/proxy-basic.js:
        * tests/stress/set-constructor.js:
        * tests/stress/throw-from-ftl-call-ic-slow-path-cells.js:
        (i.catch):
        * tests/stress/throw-from-ftl-call-ic-slow-path-undefined.js:
        (i.catch):
        * tests/stress/throw-from-ftl-call-ic-slow-path.js:
        (i.catch):
        * tests/stress/weak-map-constructor.js:
        (testCallTypeError):
        * tests/stress/weak-set-constructor.js:
        - Updated error message string.

2016-02-23  Alexey Proskuryakov  <ap@apple.com>

        ASan build fix.

        Let's not export a template function that is only used in InspectorBackendDispatcher.cpp.

        * inspector/InspectorBackendDispatcher.h:

2016-02-23  Brian Burg  <bburg@apple.com>

        Connect WebAutomationSession to its backend dispatcher as if it were an agent and add stub implementations
        https://bugs.webkit.org/show_bug.cgi?id=154518
        <rdar://problem/24761096>

        Reviewed by Timothy Hatcher.

        * inspector/InspectorBackendDispatcher.h:
        Export all the classes since they are used by WebKit::WebAutomationSession.

2016-02-22  Brian Burg  <bburg@apple.com>

        Web Inspector: add 'Automation' protocol domain and generate its backend classes separately in WebKit2
        https://bugs.webkit.org/show_bug.cgi?id=154509
        <rdar://problem/24759098>

        Reviewed by Timothy Hatcher.

        Add a new 'WebKit' framework, which is used to generate protocol code
        in WebKit2.

        Add --backend and --frontend flags to the main generator script.
        These allow a framework to trigger two different sets of generators
        so they can be separately generated and compiled.

        * inspector/scripts/codegen/models.py:
        (Framework.fromString):
        (Frameworks): Add new framework.

        * inspector/scripts/generate-inspector-protocol-bindings.py:
        If neither --backend or --frontend is specified, assume both are wanted.
        This matches the behavior for JavaScriptCore and WebInspector frameworks.

        (generate_from_specification):
        Generate C++ files for the backend and Objective-C files for the frontend.

2016-02-22  Saam barati  <sbarati@apple.com>

        JSGlobalObject doesn't visit ProxyObjectStructure during GC
        https://bugs.webkit.org/show_bug.cgi?id=154564

        Rubber stamped by Mark Lam.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::visitChildren):

2016-02-22  Saam barati  <sbarati@apple.com>

        InternalFunction::createSubclassStructure doesn't take into account that get() might throw
        https://bugs.webkit.org/show_bug.cgi?id=154548

        Reviewed by Mark Lam and Geoffrey Garen and Andreas Kling.

        InternalFunction::createSubclassStructure calls newTarget.get(...) which can throw 
        an exception. Neither the function nor the call sites of the function took this into
        account. This patch audits the call sites of the function to make it work in
        the event that an exception is thrown.

        * runtime/BooleanConstructor.cpp:
        (JSC::constructWithBooleanConstructor):
        * runtime/DateConstructor.cpp:
        (JSC::constructDate):
        * runtime/ErrorConstructor.cpp:
        (JSC::Interpreter::constructWithErrorConstructor):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::createSubclassStructure):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::constructArrayBuffer):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGlobalObject.h:
        (JSC::constructEmptyArray):
        (JSC::constructArray):
        (JSC::constructArrayNegativeIndexed):
        * runtime/JSPromiseConstructor.cpp:
        (JSC::constructPromise):
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/NativeErrorConstructor.cpp:
        (JSC::Interpreter::constructWithNativeErrorConstructor):
        * runtime/NumberConstructor.cpp:
        (JSC::constructWithNumberConstructor):
        * runtime/RegExpConstructor.cpp:
        (JSC::getRegExpStructure):
        (JSC::constructRegExp):
        (JSC::constructWithRegExpConstructor):
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):
        * runtime/StringConstructor.cpp:
        (JSC::constructWithStringConstructor):
        (JSC::StringConstructor::getConstructData):
        * runtime/WeakMapConstructor.cpp:
        (JSC::constructWeakMap):
        * runtime/WeakSetConstructor.cpp:
        (JSC::constructWeakSet):
        * tests/stress/create-subclass-structure-might-throw.js: Added.
        (assert):

2016-02-22  Ting-Wei Lan  <lantw44@gmail.com>

        Fix build and implement functions to retrieve registers on FreeBSD
        https://bugs.webkit.org/show_bug.cgi?id=152258

        Reviewed by Michael Catanzaro.

        * heap/MachineStackMarker.cpp:
        (pthreadSignalHandlerSuspendResume):
        struct ucontext is not specified in POSIX and it is not available on
        FreeBSD. Replacing it with ucontext_t fixes the build problem.
        (JSC::MachineThreads::Thread::Registers::stackPointer):
        (JSC::MachineThreads::Thread::Registers::framePointer):
        (JSC::MachineThreads::Thread::Registers::instructionPointer):
        (JSC::MachineThreads::Thread::Registers::llintPC):
        * heap/MachineStackMarker.h:

2016-02-22  Saam barati  <sbarati@apple.com>

        JSValue::isConstructor and JSValue::isFunction should check getConstructData and getCallData
        https://bugs.webkit.org/show_bug.cgi?id=154552

        Reviewed by Mark Lam.

        ES6 Proxy breaks our isFunction() and isConstructor() JSValue methods.
        They return false on a Proxy with internal [[Call]] and [[Construct]]
        properties. It seems safest, most forward looking, and most adherent
        to the specification to check getCallData() and getConstructData() to
        implement these functions.

        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::createSubclassStructure):
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::isFunction):
        (JSC::JSValue::isConstructor):

2016-02-22  Keith Miller  <keith_miller@apple.com>

        Bound functions should use the prototype of the function being bound
        https://bugs.webkit.org/show_bug.cgi?id=154195

        Reviewed by Geoffrey Garen.

        Per ES6, the result of Function.prototype.bind should have the same
        prototype as the the function being bound. In order to avoid creating
        a new structure each time a function is bound we store the new
        structure in our structure map. However, we cannot currently store
        structures that have a different GlobalObject than their prototype.
        In the rare case that the GlobalObject differs or the prototype of
        the bindee is null we create a new structure each time. To further
        minimize new structures, as well as making structure lookup faster,
        we also store the structure in the RareData of the function we
        are binding.

        * runtime/FunctionRareData.cpp:
        (JSC::FunctionRareData::visitChildren):
        * runtime/FunctionRareData.h:
        (JSC::FunctionRareData::getBoundFunctionStructure):
        (JSC::FunctionRareData::setBoundFunctionStructure):
        * runtime/JSBoundFunction.cpp:
        (JSC::getBoundFunctionStructure):
        (JSC::JSBoundFunction::create):
        * tests/es6.yaml:
        * tests/stress/bound-function-uses-prototype.js: Added.
        (testChangeProto.foo):
        (testChangeProto):
        (testBuiltins):
        * tests/stress/class-subclassing-function.js:

2016-02-22  Keith Miller  <keith_miller@apple.com>

        Unreviewed, fix stress test to not print on success.

        * tests/stress/call-apply-builtin-functions-dont-use-iterators.js:
        (catch): Deleted.

2016-02-22  Keith Miller  <keith_miller@apple.com>

        Use Symbol.species in the builtin TypedArray.prototype functions
        https://bugs.webkit.org/show_bug.cgi?id=153384

        Reviewed by Geoffrey Garen.

        This patch adds the use of species constructors to the TypedArray.prototype map and filter
        functions. It also adds a new private function typedArrayGetOriginalConstructor that
        returns the TypedArray constructor used to originally create a TypedArray instance.

        There are no ES6 tests to update for this patch as species creation for these functions is
        not tested in the compatibility table.

        * builtins/TypedArrayPrototype.js:
        (map):
        (filter):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::typedArrayConstructor):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewPrivateFuncGetOriginalConstructor):
        * runtime/JSTypedArrayViewPrototype.h:
        * tests/stress/typedarray-filter.js:
        (subclasses.typedArrays.map):
        (prototype.accept):
        (testSpecies):
        (accept):
        (forEach):
        (subclasses.forEach):
        (testSpeciesRemoveConstructor):
        * tests/stress/typedarray-map.js:
        (subclasses.typedArrays.map):
        (prototype.id):
        (testSpecies):
        (id):
        (forEach):
        (subclasses.forEach):
        (testSpeciesRemoveConstructor):

2016-02-22  Keith Miller  <keith_miller@apple.com>

        Builtins that should not rely on iteration do.
        https://bugs.webkit.org/show_bug.cgi?id=154475

        Reviewed by Geoffrey Garen.

        When changing the behavior of varargs calls to use ES6 iterators the
        call builtin function's use of a varargs call was overlooked. The use
        of iterators is observable outside the scope of the the call function,
        thus it must be reimplemented.

        * builtins/FunctionPrototype.js:
        (call):
        * tests/stress/call-apply-builtin-functions-dont-use-iterators.js: Added.
        (test):
        (addAll):
        (catch):

2016-02-22  Konstantin Tokarev  <annulen@yandex.ru>

        [JSC shell] Don't put empty arguments array to VM.
        https://bugs.webkit.org/show_bug.cgi?id=154516

        Reviewed by Geoffrey Garen.

        This allows arrowfunction-lexical-bind-arguments-top-level test to pass
        in jsc as well as in browser.

        * jsc.cpp:
        (GlobalObject::finishCreation):

2016-02-22  Konstantin Tokarev  <annulen@yandex.ru>

        [cmake] Moved library setup code to WEBKIT_FRAMEWORK macro.
        https://bugs.webkit.org/show_bug.cgi?id=154450

        Reviewed by Alex Christensen.

        * CMakeLists.txt:

2016-02-22  Commit Queue  <commit-queue@webkit.org>

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

        it broke Production builds (Requested by brrian on #webkit).

        Reverted changeset:

        "Web Inspector: add 'Automation' protocol domain and generate
        its backend classes separately in WebKit2"
        https://bugs.webkit.org/show_bug.cgi?id=154509
        http://trac.webkit.org/changeset/196891

2016-02-21  Joseph Pecoraro  <pecoraro@apple.com>

        CodeBlock always visits its unlinked code twice
        https://bugs.webkit.org/show_bug.cgi?id=154494

        Reviewed by Saam Barati.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::visitChildren):
        The unlinked code is always visited in stronglyVisitStrongReferences.

2016-02-21  Brian Burg  <bburg@apple.com>

        Web Inspector: add 'Automation' protocol domain and generate its backend classes separately in WebKit2
        https://bugs.webkit.org/show_bug.cgi?id=154509
        <rdar://problem/24759098>

        Reviewed by Timothy Hatcher.

        Add a new 'WebKit' framework, which is used to generate protocol code
        in WebKit2.

        Add --backend and --frontend flags to the main generator script.
        These allow a framework to trigger two different sets of generators
        so they can be separately generated and compiled.

        * inspector/scripts/codegen/models.py:
        (Framework.fromString):
        (Frameworks): Add new framework.

        * inspector/scripts/generate-inspector-protocol-bindings.py:
        If neither --backend or --frontend is specified, assume both are wanted.
        This matches the behavior for JavaScriptCore and WebInspector frameworks.

        (generate_from_specification):
        Generate C++ files for the backend and Objective-C files for the frontend.

2016-02-21  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Improvements to Intl code
        https://bugs.webkit.org/show_bug.cgi?id=154486

        Reviewed by Darin Adler.

        This patch does several things:
        - Use std::unique_ptr to store ICU objects.
        - Pass Vector::size() to ICU functions that take a buffer size instead
          of Vector::capacity().
        - If U_SUCCESS(status) is true, it means there is no error, but there
          could be warnings. ICU functions ignore warnings. So, there is no need
          to reset status to U_ZERO_ERROR.
        - Remove the initialization of the String instance variables of
          IntlDateTimeFormat. These values are never read and cause unnecessary
          memory allocation.
        - Fix coding style.
        - Some small optimization.

        * runtime/IntlCollator.cpp:
        (JSC::IntlCollator::UCollatorDeleter::operator()):
        (JSC::IntlCollator::createCollator):
        (JSC::IntlCollator::compareStrings):
        (JSC::IntlCollator::~IntlCollator): Deleted.
        * runtime/IntlCollator.h:
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::UDateFormatDeleter::operator()):
        (JSC::defaultTimeZone):
        (JSC::canonicalizeTimeZoneName):
        (JSC::toDateTimeOptionsAnyDate):
        (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
        (JSC::IntlDateTimeFormat::weekdayString):
        (JSC::IntlDateTimeFormat::format):
        (JSC::IntlDateTimeFormat::~IntlDateTimeFormat): Deleted.
        (JSC::localeData): Deleted.
        * runtime/IntlDateTimeFormat.h:
        * runtime/IntlDateTimeFormatConstructor.cpp:
        * runtime/IntlNumberFormatConstructor.cpp:
        * runtime/IntlObject.cpp:
        (JSC::numberingSystemsForLocale):

2016-02-21  Skachkov Oleksandr  <gskachkov@gmail.com>

        Remove arrowfunction test cases that rely on arguments variable in jsc
        https://bugs.webkit.org/show_bug.cgi?id=154517

        Reviewed by Yusuke Suzuki.

        Allow to jsc has the same behavior in javascript as browser has

        * tests/stress/arrowfunction-lexical-bind-arguments-non-strict-1.js:
        * tests/stress/arrowfunction-lexical-bind-arguments-strict.js:

2016-02-21  Brian Burg  <bburg@apple.com>

        Web Inspector: it should be possible to omit generated code guarded by INSPECTOR_ALTERNATE_DISPATCHERS
        https://bugs.webkit.org/show_bug.cgi?id=154508
        <rdar://problem/24759077>

        Reviewed by Timothy Hatcher.

        In preparation for being able to generate protocol files for WebKit2,
        make it possible to not emit generated code that's guarded by
        ENABLE(INSPECTOR_ALTERNATE_DISPATCHERS). This code is not needed by
        backend dispatchers generated outside of JavaScriptCore. We can't just
        define it to 0 for WebKit2, since it's defined to 1 in <wtf/Platform.h>
        in the configurations where the code is actually used.

        Add a new opt-in Framework configuration option that turns on generating
        this code. Adjust how the code is generated so that it can be easily excluded.

        * inspector/scripts/codegen/cpp_generator_templates.py:
        Make a separate template for the declarations that are guarded.
        Add an initializer expression so the order of initalizers doesn't matter.

        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
        (CppBackendDispatcherHeaderGenerator.generate_output): Add a setting check.
        (CppBackendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
        If the declarations are needed, they will be appended to the end of the
        declarations list.

        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
        (CppBackendDispatcherImplementationGenerator.generate_output): Add a setting check.
        (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command): Add a setting check.

        * inspector/scripts/codegen/models.py: Set the 'alternate_dispatchers' setting
        to True for Framework.JavaScriptCore only. It's not needed elsewhere.

        Rebaseline affected tests.

        * 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/generate-domains-with-feature-guards.json-result:

2016-02-21  Brian Burg  <bburg@apple.com>

        Web Inspector: clean up generator selection in generate-inspector-protocol-bindings.py
        https://bugs.webkit.org/show_bug.cgi?id=154505
        <rdar://problem/24758042>

        Reviewed by Timothy Hatcher.

        It should be possible to generate code for a framework using some generators
        that other frameworks also use. Right now the generator selection code assumes
        that use of a generator is mutually exclusive among non-test frameworks.

        Make this code explicitly switch on the framework. Reorder generators
        alpabetically within each case.

        * inspector/scripts/generate-inspector-protocol-bindings.py:
        (generate_from_specification):

        Rebaseline tests that are affected by generator reorderings.

        * 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:

2016-02-19  Saam Barati  <sbarati@apple.com>

        [ES6] Implement Proxy.[[Construct]]
        https://bugs.webkit.org/show_bug.cgi?id=154440

        Reviewed by Oliver Hunt.

        This patch is mostly an implementation of
        Proxy.[[Construct]] with respect to section 9.5.13
        of the ECMAScript spec.
        https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-construct-argumentslist-newtarget

        This patch also changes op_create_this to accept new.target's
        that aren't JSFunctions. This is necessary implementing Proxy.[[Construct]] 
        because we might construct a JSFunction with a new.target being
        a Proxy. This will also be needed when we implement Reflect.construct.

        * 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):
        (JSC::JIT::emitSlow_op_create_this):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_create_this):
        (JSC::JIT::emitSlow_op_create_this):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::finishCreation):
        (JSC::ProxyObject::visitChildren):
        (JSC::performProxyConstruct):
        (JSC::ProxyObject::getConstructData):
        * runtime/ProxyObject.h:
        * tests/es6.yaml:
        * tests/stress/proxy-construct.js: Added.
        (assert):
        (throw.new.Error.let.target):
        (throw.new.Error):
        (assert.let.target):
        (assert.let.handler.get construct):
        (let.target):
        (let.handler.construct):
        (i.catch):
        (assert.let.handler.construct):
        (assert.let.construct):
        (assert.else.assert.let.target):
        (assert.else.assert.let.construct):
        (assert.else.assert):
        (new.proxy.let.target):
        (new.proxy.let.construct):
        (new.proxy):

2016-02-19  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        [INTL] Implement Number Format Functions
        https://bugs.webkit.org/show_bug.cgi?id=147605

        Reviewed by Darin Adler.

        This patch implements Intl.NumberFormat.prototype.format() according
        to the ECMAScript 2015 Internationalization API spec (ECMA-402 2nd edition.)

        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormat::UNumberFormatDeleter::operator()):
        (JSC::IntlNumberFormat::initializeNumberFormat):
        (JSC::IntlNumberFormat::createNumberFormat):
        (JSC::IntlNumberFormat::formatNumber):
        (JSC::IntlNumberFormatFuncFormatNumber): Deleted.
        * runtime/IntlNumberFormat.h:
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatFuncFormatNumber):

2016-02-18  Gavin Barraclough  <barraclough@apple.com>

        JSObject::getPropertySlot - index-as-propertyname, override on prototype, & shadow
        https://bugs.webkit.org/show_bug.cgi?id=154416

        Reviewed by Geoff Garen.

        Here's the bug. Suppose you call JSObject::getOwnProperty and -
          - PropertyName contains an index,
          - An object on the prototype chain overrides getOwnPropertySlot, and has that index property,
          - The base of the access (or another object on the prototype chain) shadows that property.

        JSObject::getPropertySlot is written assuming the common case is that propertyName is not an
        index, and as such walks up the prototype chain looking for non-index properties before it
        tries calling parseIndex.

        At the point we reach an object on the prototype chain overriding getOwnPropertySlot (which
        would potentially return the property) we may have already skipped over non-overriding
        objects that contain the property in index storage.

        * runtime/JSObject.h:
        (JSC::JSObject::getOwnNonIndexPropertySlot):
            - renamed from inlineGetOwnPropertySlot to better describe behaviour;
              added ASSERT guarding that this method never returns index properties -
              if it ever does, this is unsafe for getPropertySlot.
        (JSC::JSObject::getOwnPropertySlot):
            - inlineGetOwnPropertySlot -> getOwnNonIndexPropertySlot.
        (JSC::JSObject::getPropertySlot):
            - In case of object overriding getOwnPropertySlot check if propertyName is an index.
        (JSC::JSObject::getNonIndexPropertySlot):
            - called by getPropertySlot if we encounter an object that overrides getOwnPropertySlot,
              in order to avoid repeated calls to parseIndex.
        (JSC::JSObject::inlineGetOwnPropertySlot): Deleted.
            - this was renamed to getOwnNonIndexPropertySlot.
        (JSC::JSObject::fastGetOwnPropertySlot): Deleted.
            - this was folded back in to getPropertySlot.

2016-02-19  Saam Barati  <sbarati@apple.com>

        [ES6] Implement Proxy.[[Call]]
        https://bugs.webkit.org/show_bug.cgi?id=154425

        Reviewed by Mark Lam.

        This patch is a straight forward implementation of
        Proxy.[[Call]] with respect to section 9.5.12
        of the ECMAScript spec.
        https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-call-thisargument-argumentslist

        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::finishCreation):
        (JSC::performProxyGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::getOwnPropertySlotByIndex):
        (JSC::performProxyCall):
        (JSC::ProxyObject::getCallData):
        (JSC::ProxyObject::visitChildren):
        * runtime/ProxyObject.h:
        (JSC::ProxyObject::create):
        * tests/es6.yaml:
        * tests/stress/proxy-call.js: Added.
        (assert):
        (throw.new.Error.let.target):
        (throw.new.Error.let.handler.apply):
        (throw.new.Error):
        (assert.let.target):
        (assert.let.handler.get apply):
        (let.target):
        (let.handler.apply):
        (i.catch):
        (assert.let.handler.apply):

2016-02-19  Csaba Osztrogonác  <ossy@webkit.org>

        Remove more LLVM related dead code after r196729
        https://bugs.webkit.org/show_bug.cgi?id=154387

        Reviewed by Filip Pizlo.

        * Configurations/CompileRuntimeToLLVMIR.xcconfig: Removed.
        * Configurations/LLVMForJSC.xcconfig: Removed.
        * JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.props: Removed.
        * JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.vcxproj: Removed.
        * JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.vcxproj.filters: Removed.
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * disassembler/X86Disassembler.cpp:

2016-02-19  Joseph Pecoraro  <pecoraro@apple.com>

        Add isJSString(JSCell*) variant to avoid Cell->JSValue->Cell conversion
        https://bugs.webkit.org/show_bug.cgi?id=154442

        Reviewed by Saam Barati.

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

2016-02-19  Joseph Pecoraro  <pecoraro@apple.com>

        Remove unused SymbolTable::createNameScopeTable
        https://bugs.webkit.org/show_bug.cgi?id=154443

        Reviewed by Saam Barati.

        * runtime/SymbolTable.h:

2016-02-18  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Improve the instruction selection of Select
        https://bugs.webkit.org/show_bug.cgi?id=154432

        Reviewed by Filip Pizlo.

        Plenty of code but this patch is pretty dumb:
        -On ARM64: use the 3 operand form of CSEL instead of forcing a source
         to be alised to the destination. This gives more freedom to the register
         allocator and it is one less Move to process per Select.
        -On x86, introduce a fake 3 operands form and use aggressive aliasing
         to try to alias both sources to the destination.

         If aliasing succeed on the "elseCase", the condition of the Select
         is reverted in the MacroAssembler.

         If no aliasing is possible and we end up with 3 registers, the missing
         move instruction is generated by the MacroAssembler.

         The missing move is generated after testing the values because the destination
         can use the same register as one of the test operand.
         Experimental testing seems to indicate there is no macro-fusion on CMOV,
         there is no measurable cost to having the move there.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::isInvertible):
        (JSC::MacroAssembler::invert):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::moveConditionallyDouble):
        (JSC::MacroAssemblerARM64::moveConditionallyFloat):
        (JSC::MacroAssemblerARM64::moveConditionallyAfterFloatingPointCompare):
        (JSC::MacroAssemblerARM64::moveConditionally32):
        (JSC::MacroAssemblerARM64::moveConditionally64):
        (JSC::MacroAssemblerARM64::moveConditionallyTest32):
        (JSC::MacroAssemblerARM64::moveConditionallyTest64):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::moveConditionallyDouble):
        (JSC::MacroAssemblerX86Common::moveConditionallyFloat):
        (JSC::MacroAssemblerX86Common::moveConditionally32):
        (JSC::MacroAssemblerX86Common::moveConditionallyTest32):
        (JSC::MacroAssemblerX86Common::invert):
        (JSC::MacroAssemblerX86Common::isInvertible):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::moveConditionally64):
        (JSC::MacroAssemblerX86_64::moveConditionallyTest64):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createSelect):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::shouldTryAliasingDef):
        * b3/air/AirOpcode.opcodes:

2016-02-18  Gyuyoung Kim  <gyuyoung.kim@webkit.org>

        [CMake][GTK] Clean up llvm guard in PlatformGTK.cmake
        https://bugs.webkit.org/show_bug.cgi?id=154430

        Reviewed by Saam Barati.

        llvm isn't used anymore.

        * PlatformGTK.cmake: Remove USE_LLVM_DISASSEMBLER guard.

2016-02-18  Saam Barati  <sbarati@apple.com>

        Implement Proxy.[[HasProperty]]
        https://bugs.webkit.org/show_bug.cgi?id=154313

        Reviewed by Filip Pizlo.

        This patch is a straight forward implementation of
        Proxy.[[HasProperty]] with respect to section 9.5.7
        of the ECMAScript spec.
        https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-hasproperty-p

        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        * runtime/ProxyObject.h:
        * tests/es6.yaml:
        * tests/stress/proxy-basic.js:
        (assert):
        (let.handler.has):
        * tests/stress/proxy-has-property.js: Added.
        (assert):
        (throw.new.Error.let.handler.get has):
        (throw.new.Error):
        (assert.let.handler.has):
        (let.handler.has):
        (getOwnPropertyDescriptor):
        (i.catch):

2016-02-18  Saam Barati  <sbarati@apple.com>

        Proxy's don't properly handle Symbols as PropertyKeys.
        https://bugs.webkit.org/show_bug.cgi?id=154385

        Reviewed by Mark Lam and Yusuke Suzuki.

        We were converting all PropertyKeys to strings, even when
        the PropertyName was a Symbol. In the spec, PropertyKeys are
        either a Symbol or a String. We now respect that in Proxy.[[Get]] and
        Proxy.[[GetOwnProperty]].

        * runtime/Completion.cpp:
        (JSC::profiledEvaluate):
        (JSC::createSymbolForEntryPointModule):
        (JSC::identifierToJSValue): Deleted.
        * runtime/Identifier.h:
        (JSC::parseIndex):
        * runtime/IdentifierInlines.h:
        (JSC::Identifier::fromString):
        (JSC::identifierToJSValue):
        (JSC::identifierToSafePublicJSValue):
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        * tests/es6.yaml:
        * tests/stress/proxy-basic.js:
        (let.handler.getOwnPropertyDescriptor):

2016-02-18  Saam Barati  <sbarati@apple.com>

        Follow up fix to Implement Proxy.[[GetOwnProperty]]
        https://bugs.webkit.org/show_bug.cgi?id=154314

        Reviewed by Filip Pizlo.

        Part of the implementation was broken because
        of how JSObject::getOwnPropertyDescriptor worked.
        I've fixed JSObject::getOwnPropertyDescriptor to
        be able to handle ProxyObject.

        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnPropertyDescriptor):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        * tests/stress/proxy-get-own-property.js:
        (assert):
        (assert.let.handler.get getOwnPropertyDescriptor):

2016-02-18  Saam Barati  <sbarati@apple.com>

        Implement Proxy.[[GetOwnProperty]]
        https://bugs.webkit.org/show_bug.cgi?id=154314

        Reviewed by Filip Pizlo.

        This patch implements Proxy.[[GetOwnProperty]].
        It's a straight forward implementation as described
        in section 9.5.5 of the specification:
        http://www.ecma-international.org/ecma-262/6.0/index.html#sec-proxy-object-internal-methods-and-internal-slots-getownproperty-p

        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncBind):
        * runtime/JSObject.cpp:
        (JSC::validateAndApplyPropertyDescriptor):
        (JSC::JSObject::defineOwnNonIndexProperty):
        (JSC::JSObject::defineOwnProperty):
        (JSC::JSObject::getGenericPropertyNames):
        (JSC::JSObject::getMethod):
        * runtime/JSObject.h:
        (JSC::JSObject::butterflyAddress):
        (JSC::makeIdentifier):
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        (JSC::ProxyObject::getOwnPropertySlot):
        (JSC::ProxyObject::getOwnPropertySlotByIndex):
        (JSC::ProxyObject::visitChildren):
        * runtime/ProxyObject.h:
        * tests/es6.yaml:
        * tests/stress/proxy-basic.js:
        (let.handler.get null):
        * tests/stress/proxy-get-own-property.js: Added.
        (assert):
        (throw.new.Error.let.handler.getOwnPropertyDescriptor):
        (throw.new.Error):
        (let.handler.getOwnPropertyDescriptor):
        (i.catch):
        (assert.let.handler.getOwnPropertyDescriptor):

2016-02-18  Andreas Kling  <akling@apple.com>

        JSString resolution of substrings should use StringImpl sharing optimization.
        <https://webkit.org/b/154068>
        <rdar://problem/24629358>

        Reviewed by Antti Koivisto.

        When resolving a JSString that's actually a substring of another JSString,
        use the StringImpl sharing optimization to create a new string pointing into
        the parent one, instead of copying out the bytes of the string.

        This dramatically reduces peak memory usage on Gerrit diff viewer pages.

        Another approach to this would be to induce GC far more frequently due to
        the added cost of copying out these substrings. It would reduce the risk
        of prolonging the life of strings only kept alive by substrings.

        This patch chooses to trade that risk for less GC and lower peak memory.

        * runtime/JSString.cpp:
        (JSC::JSRopeString::resolveRope):

2016-02-18  Chris Dumez  <cdumez@apple.com>

        Crash on SES selftest page when loading the page while WebInspector is open
        https://bugs.webkit.org/show_bug.cgi?id=154378
        <rdar://problem/24713422>

        Reviewed by Mark Lam.

        Do a partial revert of r196676 so that JSObject::getOwnPropertyDescriptor()
        returns early again if it detects that getOwnPropertySlot() returns a
        non-own property. This check was removed in r196676 because we assumed that
        only JSDOMWindow::getOwnPropertySlot() could return non-own properties.
        However, as it turns out, DebuggerScope::getOwnPropertySlot() does so as
        well.

        Not having the check would lead to crashes when using the debugger because
        we would get a slot with the CustomAccessor attribute but getDirect() would
        then fail to return the property (because it is not an own property). We
        would then cast the value returned by getDirect() to a CustomGetterSetter*
        and dereference it.

        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnPropertyDescriptor):

2016-02-18  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix VS build. I didn't know we still did that, but apparently there's a bot
        for that.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:

2016-02-18  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix CMake build. This got messed up when rebasing.

        * CMakeLists.txt:

2016-02-18  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the !ENABLE(DFG_JIT) build after r195865
        https://bugs.webkit.org/show_bug.cgi?id=154391

        Reviewed by Filip Pizlo.

        * runtime/SamplingProfiler.cpp:
        (JSC::tryGetBytecodeIndex):

2016-02-17  Filip Pizlo  <fpizlo@apple.com>

        Remove remaining references to LLVM, and make sure comments refer to the backend as "B3" not "LLVM"
        https://bugs.webkit.org/show_bug.cgi?id=154383

        Reviewed by Saam Barati.

        I did a grep -i llvm of all of our code and did one of the following for each occurence:

        - Renamed it to B3. This is appropriate when we were using "LLVM" to mean "the FTL
          backend".

        - Removed the reference because I found it to be dead. In some cases it was a dead
          comment: it was telling us things about what LLVM did and that's just not relevant
          anymore. In other cases it was dead code that I forgot to delete in a previous patch.

        - Edited the comment in some smart way. There were comments talking about what LLVM did
          that were still of interest. In some cases, I added a FIXME to consider changing the
          code below the comment on the grounds that it was written in a weird way to placate
          LLVM and so we can do it better now.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGOSRAvailabilityAnalysisPhase.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::compileInThreadImpl):
        (JSC::DFG::Plan::compileTimeStats):
        * dfg/DFGPutStackSinkingPhase.cpp:
        * dfg/DFGSSAConversionPhase.h:
        * dfg/DFGStaticExecutionCountEstimationPhase.h:
        * dfg/DFGUnificationPhase.cpp:
        (JSC::DFG::UnificationPhase::run):
        * disassembler/ARM64Disassembler.cpp:
        (JSC::tryToDisassemble): Deleted.
        * disassembler/X86Disassembler.cpp:
        (JSC::tryToDisassemble):
        * ftl/FTLAbstractHeap.cpp:
        (JSC::FTL::IndexedAbstractHeap::initialize):
        * ftl/FTLAbstractHeap.h:
        * ftl/FTLFormattedValue.h:
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLocation.cpp:
        (JSC::FTL::Location::restoreInto):
        * ftl/FTLLowerDFGToB3.cpp: Copied from Source/JavaScriptCore/ftl/FTLLowerDFGToLLVM.cpp.
        (JSC::FTL::DFG::ftlUnreachable):
        (JSC::FTL::DFG::LowerDFGToB3::LowerDFGToB3):
        (JSC::FTL::DFG::LowerDFGToB3::compileBlock):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
        (JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileOverridesHasInstance):
        (JSC::FTL::DFG::LowerDFGToB3::isBoolean):
        (JSC::FTL::DFG::LowerDFGToB3::unboxBoolean):
        (JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
        (JSC::FTL::lowerDFGToB3):
        (JSC::FTL::DFG::LowerDFGToLLVM::LowerDFGToLLVM): Deleted.
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBlock): Deleted.
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithNegate): Deleted.
        (JSC::FTL::DFG::LowerDFGToLLVM::compileMultiGetByOffset): Deleted.
        (JSC::FTL::DFG::LowerDFGToLLVM::compileOverridesHasInstance): Deleted.
        (JSC::FTL::DFG::LowerDFGToLLVM::isBoolean): Deleted.
        (JSC::FTL::DFG::LowerDFGToLLVM::unboxBoolean): Deleted.
        (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier): Deleted.
        (JSC::FTL::lowerDFGToLLVM): Deleted.
        * ftl/FTLLowerDFGToB3.h: Copied from Source/JavaScriptCore/ftl/FTLLowerDFGToLLVM.h.
        * ftl/FTLLowerDFGToLLVM.cpp: Removed.
        * ftl/FTLLowerDFGToLLVM.h: Removed.
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * ftl/FTLWeight.h:
        (JSC::FTL::Weight::frequencyClass):
        (JSC::FTL::Weight::inverse):
        (JSC::FTL::Weight::scaleToTotal): Deleted.
        * ftl/FTLWeightedTarget.h:
        (JSC::FTL::rarely):
        (JSC::FTL::unsure):
        * jit/CallFrameShuffler64.cpp:
        (JSC::CallFrameShuffler::emitDisplace):
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::ftlCalleeSaveRegisters):
        * llvm: Removed.
        * llvm/InitializeLLVMLinux.cpp: Removed.
        * llvm/InitializeLLVMWin.cpp: Removed.
        * llvm/library: Removed.
        * llvm/library/LLVMTrapCallback.h: Removed.
        * llvm/library/libllvmForJSC.version: Removed.
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        (JSC::Options::initialize):
        * runtime/Options.h:
        * wasm/WASMFunctionB3IRGenerator.h: Copied from Source/JavaScriptCore/wasm/WASMFunctionLLVMIRGenerator.h.
        * wasm/WASMFunctionLLVMIRGenerator.h: Removed.
        * wasm/WASMFunctionParser.cpp:

2016-02-18  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] Build system cleanup
        https://bugs.webkit.org/show_bug.cgi?id=154337

        Reviewed by Žan Doberšek.

        * CMakeLists.txt:

2016-02-17  Mark Lam  <mark.lam@apple.com>

        Callers of JSString::value() should check for exceptions thereafter.
        https://bugs.webkit.org/show_bug.cgi?id=154346

        Reviewed by Geoffrey Garen.

        JSString::value() can throw an exception if the JS string is a rope and value() 
        needs to resolve the rope but encounters an OutOfMemory error.  If value() is not
        able to resolve the rope, it will return a null string (in addition to throwing
        the exception).  If a caller does not check for exceptions after calling
        JSString::value(), they may eventually use the returned null string and crash the
        VM.

        The fix is to add all the necessary exception checks, and do the appropriate
        handling if needed.

        * jsc.cpp:
        (functionRun):
        (functionLoad):
        (functionReadFile):
        (functionCheckSyntax):
        (functionLoadWebAssembly):
        (functionLoadModule):
        (functionCheckModuleSyntax):
        * runtime/DateConstructor.cpp:
        (JSC::dateParse):
        (JSC::dateNow):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::functionPrint):

2016-02-17  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] ARM64: Support the immediate format used for bit operations in Air
        https://bugs.webkit.org/show_bug.cgi?id=154327

        Reviewed by Filip Pizlo.

        ARM64 supports a pretty rich form of immediates for bit operation.
        There are two formats used to encode repeating patterns and common
        input in a dense form.

        In this patch, I add 2 new type of Arg: BitImm32 and BitImm64.
        Those represents the valid immediate forms for bit operation.
        On x86, any 32bits value is valid. On ARM64, all the encoding
        form are tried and the immediate is used when possible.

        The arg type Imm64 is renamed to BigImm to better represent what
        it is: an immediate that does not fit into Imm.

        * assembler/ARM64Assembler.h:
        (JSC::LogicalImmediate::create32): Deleted.
        (JSC::LogicalImmediate::create64): Deleted.
        (JSC::LogicalImmediate::value): Deleted.
        (JSC::LogicalImmediate::isValid): Deleted.
        (JSC::LogicalImmediate::is64bit): Deleted.
        (JSC::LogicalImmediate::LogicalImmediate): Deleted.
        (JSC::LogicalImmediate::mask): Deleted.
        (JSC::LogicalImmediate::partialHSB): Deleted.
        (JSC::LogicalImmediate::highestSetBit): Deleted.
        (JSC::LogicalImmediate::findBitRange): Deleted.
        (JSC::LogicalImmediate::encodeLogicalImmediate): Deleted.
        * assembler/AssemblerCommon.h:
        (JSC::ARM64LogicalImmediate::create32):
        (JSC::ARM64LogicalImmediate::create64):
        (JSC::ARM64LogicalImmediate::value):
        (JSC::ARM64LogicalImmediate::isValid):
        (JSC::ARM64LogicalImmediate::is64bit):
        (JSC::ARM64LogicalImmediate::ARM64LogicalImmediate):
        (JSC::ARM64LogicalImmediate::mask):
        (JSC::ARM64LogicalImmediate::partialHSB):
        (JSC::ARM64LogicalImmediate::highestSetBit):
        (JSC::ARM64LogicalImmediate::findBitRange):
        (JSC::ARM64LogicalImmediate::encodeLogicalImmediate):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::and64):
        (JSC::MacroAssemblerARM64::or64):
        (JSC::MacroAssemblerARM64::xor64):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::bitImm):
        (JSC::B3::Air::LowerToAir::bitImm64):
        (JSC::B3::Air::LowerToAir::appendBinOp):
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::dump):
        (WTF::printInternal):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::bitImm):
        (JSC::B3::Air::Arg::bitImm64):
        (JSC::B3::Air::Arg::isBitImm):
        (JSC::B3::Air::Arg::isBitImm64):
        (JSC::B3::Air::Arg::isSomeImm):
        (JSC::B3::Air::Arg::value):
        (JSC::B3::Air::Arg::isGP):
        (JSC::B3::Air::Arg::isFP):
        (JSC::B3::Air::Arg::hasType):
        (JSC::B3::Air::Arg::isValidBitImmForm):
        (JSC::B3::Air::Arg::isValidBitImm64Form):
        (JSC::B3::Air::Arg::isValidForm):
        (JSC::B3::Air::Arg::asTrustedImm32):
        (JSC::B3::Air::Arg::asTrustedImm64):
        * b3/air/AirOpcode.opcodes:
        * b3/air/opcode_generator.rb:

2016-02-17  Keith Miller  <keith_miller@apple.com>

        Spread operator should be allowed when not the first argument of parameter list
        https://bugs.webkit.org/show_bug.cgi?id=152721

        Reviewed by Saam Barati.

        Spread arguments to functions should now be ES6 compliant. Before we
        would only take a spread operator if it was the sole argument to a
        function. Additionally, we would not use the Symbol.iterator on the
        object to generate the arguments. Instead we would do a loop up to the
        length mapping indexed properties to the corresponding argument. We fix
        both these issues by doing an AST transformation from foo(...a, b, ...c, d)
        to foo(...[...a, b, ...c, d]) (where the spread on the rhs uses the
        old spread semantics). This solution has the downside of requiring the
        allocation of another object and copying each element twice but avoids a
        large change to the vm calling convention.

        * interpreter/Interpreter.cpp:
        (JSC::loadVarargs):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createElementList):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseArguments):
        (JSC::Parser<LexerType>::parseArgument):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/Parser.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createElementList):
        * tests/es6.yaml:
        * tests/stress/spread-calling.js: Added.
        (testFunction):
        (testEmpty):
        (makeObject):
        (otherIterator.return.next):
        (otherIterator):
        (totalIter):
        (throwingIter.return.next):
        (throwingIter):
        (i.catch):

2016-02-17  Brian Burg  <bburg@apple.com>

        Remove a wrong cast in RemoteInspector::receivedSetupMessage
        https://bugs.webkit.org/show_bug.cgi?id=154361
        <rdar://problem/24709281>

        Reviewed by Joseph Pecoraro.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::receivedSetupMessage):
        Not only is this cast unnecessary (the constructor accepts the base class),
        but it is wrong since the target could be an automation target. Remove it.

2016-02-17  Filip Pizlo  <fpizlo@apple.com>

        Rename FTLB3Blah to FTLBlah
        https://bugs.webkit.org/show_bug.cgi?id=154365

        Rubber stamped by Geoffrey Garen, Benjamin Poulain, Awesome Kling, and Saam Barati.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * ftl/FTLB3Compile.cpp: Removed.
        * ftl/FTLB3Output.cpp: Removed.
        * ftl/FTLB3Output.h: Removed.
        * ftl/FTLCompile.cpp: Copied from Source/JavaScriptCore/ftl/FTLB3Compile.cpp.
        * ftl/FTLOutput.cpp: Copied from Source/JavaScriptCore/ftl/FTLB3Output.cpp.
        * ftl/FTLOutput.h: Copied from Source/JavaScriptCore/ftl/FTLB3Output.h.

2016-02-17  Filip Pizlo  <fpizlo@apple.com>

        Remove LLVM dependencies from WebKit
        https://bugs.webkit.org/show_bug.cgi?id=154323

        Reviewed by Antti Koivisto and Benjamin Poulain.

        We have switched all ports that use the FTL JIT to using B3 as the backend. This renders all
        LLVM-related code dead, including the disassembler, which was only reachable when you were on
        a platform that already had an in-tree disassembler.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGCommon.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::compileInThreadImpl):
        (JSC::DFG::Plan::compileTimeStats):
        * disassembler/ARM64Disassembler.cpp:
        (JSC::tryToDisassemble):
        * disassembler/ARMv7Disassembler.cpp:
        (JSC::tryToDisassemble):
        * disassembler/Disassembler.cpp:
        (JSC::disassemble):
        (JSC::disassembleAsynchronously):
        * disassembler/Disassembler.h:
        (JSC::tryToDisassemble):
        * disassembler/LLVMDisassembler.cpp: Removed.
        * disassembler/LLVMDisassembler.h: Removed.
        * disassembler/UDis86Disassembler.cpp:
        (JSC::tryToDisassembleWithUDis86):
        * disassembler/UDis86Disassembler.h:
        (JSC::tryToDisassembleWithUDis86):
        * disassembler/X86Disassembler.cpp:
        (JSC::tryToDisassemble):
        * ftl/FTLAbbreviatedTypes.h:
        * ftl/FTLAbbreviations.h: Removed.
        * ftl/FTLAbstractHeap.cpp:
        (JSC::FTL::AbstractHeap::decorateInstruction):
        (JSC::FTL::AbstractHeap::dump):
        (JSC::FTL::AbstractField::dump):
        (JSC::FTL::IndexedAbstractHeap::IndexedAbstractHeap):
        (JSC::FTL::IndexedAbstractHeap::~IndexedAbstractHeap):
        (JSC::FTL::IndexedAbstractHeap::baseIndex):
        (JSC::FTL::IndexedAbstractHeap::dump):
        (JSC::FTL::NumberedAbstractHeap::NumberedAbstractHeap):
        (JSC::FTL::NumberedAbstractHeap::dump):
        (JSC::FTL::AbsoluteAbstractHeap::AbsoluteAbstractHeap):
        (JSC::FTL::AbstractHeap::tbaaMetadataSlow): Deleted.
        * ftl/FTLAbstractHeap.h:
        (JSC::FTL::AbstractHeap::AbstractHeap):
        (JSC::FTL::AbstractHeap::heapName):
        (JSC::FTL::IndexedAbstractHeap::atAnyIndex):
        (JSC::FTL::NumberedAbstractHeap::atAnyNumber):
        (JSC::FTL::AbsoluteAbstractHeap::atAnyAddress):
        (JSC::FTL::AbstractHeap::tbaaMetadata): Deleted.
        * ftl/FTLAbstractHeapRepository.cpp:
        (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLB3Compile.cpp:
        * ftl/FTLB3Output.cpp:
        (JSC::FTL::Output::Output):
        (JSC::FTL::Output::check):
        (JSC::FTL::Output::load):
        (JSC::FTL::Output::store):
        * ftl/FTLB3Output.h:
        * ftl/FTLCommonValues.cpp:
        (JSC::FTL::CommonValues::CommonValues):
        (JSC::FTL::CommonValues::initializeConstants):
        * ftl/FTLCommonValues.h:
        (JSC::FTL::CommonValues::initialize): Deleted.
        * ftl/FTLCompile.cpp: Removed.
        * ftl/FTLCompileBinaryOp.cpp: Removed.
        * ftl/FTLCompileBinaryOp.h: Removed.
        * ftl/FTLDWARFDebugLineInfo.cpp: Removed.
        * ftl/FTLDWARFDebugLineInfo.h: Removed.
        * ftl/FTLDWARFRegister.cpp: Removed.
        * ftl/FTLDWARFRegister.h: Removed.
        * ftl/FTLDataSection.cpp: Removed.
        * ftl/FTLDataSection.h: Removed.
        * ftl/FTLExceptionHandlerManager.cpp: Removed.
        * ftl/FTLExceptionHandlerManager.h: Removed.
        * ftl/FTLExceptionTarget.cpp:
        * ftl/FTLExceptionTarget.h:
        * ftl/FTLExitThunkGenerator.cpp: Removed.
        * ftl/FTLExitThunkGenerator.h: Removed.
        * ftl/FTLFail.cpp:
        (JSC::FTL::fail):
        * ftl/FTLInlineCacheDescriptor.h: Removed.
        * ftl/FTLInlineCacheSize.cpp: Removed.
        * ftl/FTLInlineCacheSize.h: Removed.
        * ftl/FTLIntrinsicRepository.cpp: Removed.
        * ftl/FTLIntrinsicRepository.h: Removed.
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::~JITCode):
        (JSC::FTL::JITCode::initializeB3Code):
        (JSC::FTL::JITCode::initializeB3Byproducts):
        (JSC::FTL::JITCode::initializeAddressForCall):
        (JSC::FTL::JITCode::contains):
        (JSC::FTL::JITCode::ftl):
        (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
        (JSC::FTL::JITCode::initializeExitThunks): Deleted.
        (JSC::FTL::JITCode::addHandle): Deleted.
        (JSC::FTL::JITCode::addDataSection): Deleted.
        (JSC::FTL::JITCode::exitThunks): Deleted.
        * ftl/FTLJITCode.h:
        (JSC::FTL::JITCode::b3Code):
        (JSC::FTL::JITCode::handles): Deleted.
        (JSC::FTL::JITCode::dataSections): Deleted.
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::codeSize):
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * ftl/FTLJITFinalizer.h:
        * ftl/FTLJSCall.cpp: Removed.
        * ftl/FTLJSCall.h: Removed.
        * ftl/FTLJSCallBase.cpp: Removed.
        * ftl/FTLJSCallBase.h: Removed.
        * ftl/FTLJSCallVarargs.cpp: Removed.
        * ftl/FTLJSCallVarargs.h: Removed.
        * ftl/FTLJSTailCall.cpp: Removed.
        * ftl/FTLJSTailCall.h: Removed.
        * ftl/FTLLazySlowPath.cpp:
        (JSC::FTL::LazySlowPath::LazySlowPath):
        (JSC::FTL::LazySlowPath::generate):
        * ftl/FTLLazySlowPath.h:
        (JSC::FTL::LazySlowPath::createGenerator):
        (JSC::FTL::LazySlowPath::patchableJump):
        (JSC::FTL::LazySlowPath::done):
        (JSC::FTL::LazySlowPath::usedRegisters):
        (JSC::FTL::LazySlowPath::callSiteIndex):
        (JSC::FTL::LazySlowPath::stub):
        (JSC::FTL::LazySlowPath::patchpoint): Deleted.
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLocation.cpp:
        (JSC::FTL::Location::forValueRep):
        (JSC::FTL::Location::dump):
        (JSC::FTL::Location::forStackmaps): Deleted.
        * ftl/FTLLocation.h:
        (JSC::FTL::Location::forRegister):
        (JSC::FTL::Location::forIndirect):
        (JSC::FTL::Location::forConstant):
        (JSC::FTL::Location::kind):
        (JSC::FTL::Location::hasReg):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::LowerDFGToLLVM):
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        (JSC::FTL::DFG::LowerDFGToLLVM::createPhiVariables):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileUpsilon):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePhi):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileDoubleConstant):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileStrCat):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithDiv):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithNegate):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitAnd):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitOr):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitXor):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitRShift):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitLShift):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitURShift):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetButterfly):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileLoadVarargs):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileIsUndefined):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
        (JSC::FTL::DFG::LowerDFGToLLVM::getById):
        (JSC::FTL::DFG::LowerDFGToLLVM::loadButterflyWithBarrier):
        (JSC::FTL::DFG::LowerDFGToLLVM::stringsEqual):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitRightShiftSnippet):
        (JSC::FTL::DFG::LowerDFGToLLVM::allocateCell):
        (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
        (JSC::FTL::DFG::LowerDFGToLLVM::speculate):
        (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
        (JSC::FTL::DFG::LowerDFGToLLVM::preparePatchpointForExceptions):
        (JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
        (JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
        (JSC::FTL::DFG::LowerDFGToLLVM::exitValueForAvailability):
        (JSC::FTL::DFG::LowerDFGToLLVM::exitValueForNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::probe):
        (JSC::FTL::DFG::LowerDFGToLLVM::crash):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileUntypedBinaryOp): Deleted.
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException): Deleted.
        (JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall): Deleted.
        (JSC::FTL::DFG::LowerDFGToLLVM::callStackmap): Deleted.
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
        (JSC::FTL::OSRExitDescriptor::validateReferences):
        (JSC::FTL::OSRExitDescriptor::emitOSRExit):
        (JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
        (JSC::FTL::OSRExit::OSRExit):
        (JSC::FTL::OSRExit::codeLocationForRepatch):
        (JSC::FTL::OSRExit::gatherRegistersToSpillForCallIfException): Deleted.
        (JSC::FTL::OSRExit::spillRegistersToSpillSlot): Deleted.
        (JSC::FTL::OSRExit::recoverRegistersFromSpillSlot): Deleted.
        (JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck): Deleted.
        (JSC::FTL::OSRExit::willArriveAtOSRExitFromCallOperation): Deleted.
        (JSC::FTL::OSRExit::needsRegisterRecoveryOnGenericUnwindOSRExitPath): Deleted.
        * ftl/FTLOSRExit.h:
        (JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
        (JSC::FTL::OSRExitDescriptorImpl::OSRExitDescriptorImpl): Deleted.
        * ftl/FTLOSRExitCompilationInfo.h: Removed.
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileRecovery):
        (JSC::FTL::compileStub):
        (JSC::FTL::compileFTLOSRExit):
        * ftl/FTLOSRExitHandle.cpp:
        * ftl/FTLOSRExitHandle.h:
        * ftl/FTLOutput.cpp: Removed.
        * ftl/FTLOutput.h: Removed.
        * ftl/FTLPatchpointExceptionHandle.cpp:
        * ftl/FTLPatchpointExceptionHandle.h:
        * ftl/FTLStackMaps.cpp: Removed.
        * ftl/FTLStackMaps.h: Removed.
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):
        (JSC::FTL::State::~State):
        (JSC::FTL::State::dumpState): Deleted.
        * ftl/FTLState.h:
        * ftl/FTLUnwindInfo.cpp: Removed.
        * ftl/FTLUnwindInfo.h: Removed.
        * ftl/FTLValueRange.cpp:
        (JSC::FTL::ValueRange::decorateInstruction):
        * ftl/FTLValueRange.h:
        (JSC::FTL::ValueRange::ValueRange):
        (JSC::FTL::ValueRange::begin):
        (JSC::FTL::ValueRange::end):
        * ftl/FTLWeight.h:
        (JSC::FTL::Weight::value):
        (JSC::FTL::Weight::frequencyClass):
        (JSC::FTL::Weight::scaleToTotal):
        * llvm/InitializeLLVM.cpp: Removed.
        * llvm/InitializeLLVM.h: Removed.
        * llvm/InitializeLLVMMac.cpp: Removed.
        * llvm/InitializeLLVMPOSIX.cpp: Removed.
        * llvm/InitializeLLVMPOSIX.h: Removed.
        * llvm/LLVMAPI.cpp: Removed.
        * llvm/LLVMAPI.h: Removed.
        * llvm/LLVMAPIFunctions.h: Removed.
        * llvm/LLVMHeaders.h: Removed.
        * llvm/library/LLVMAnchor.cpp: Removed.
        * llvm/library/LLVMExports.cpp: Removed.
        * llvm/library/LLVMOverrides.cpp: Removed.
        * llvm/library/config_llvm.h: Removed.

2016-02-17  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove the overflow check on ArithAbs when possible
        https://bugs.webkit.org/show_bug.cgi?id=154325

        Reviewed by Filip Pizlo.

        This patch adds support for ArithMode for ArithAbs.

        It is useful for kraken tests where Math.abs() is used
        on values for which the range is known.

        For example, imaging-gaussian-blur has two Math.abs() with
        integers that are always in a small range around zero.
        The IntegerRangeOptimizationPhase detects the range correctly
        so we can just update the ArithMode depending on the input.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGIntegerRangeOptimizationPhase.cpp:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToArithNegate):
        (JSC::DFG::Node::hasArithMode):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAbs):
        * tests/stress/arith-abs-integer-range-optimization.js: Added.
        (negativeRange):
        (negativeRangeIncludingZero):
        (negativeRangeWithOverflow):
        (positiveRange):
        (positiveRangeIncludingZero):
        (rangeWithoutOverflow):
        * tests/stress/arith-abs-with-bitwise-or-zero.js: Added.
        (opaqueAbs):

2016-02-17  Chris Dumez  <cdumez@apple.com>

        SES selftest page crashes on nightly r196694
        https://bugs.webkit.org/show_bug.cgi?id=154350
        <rdar://problem/24704334>

        Reviewed by Mark Lam.

        SES selftest page crashes after r196001 / r196145 when calling
        Object.getOwnPropertyDescriptor(window, "length") after the window
        has been reified and "length" has been shadowed by a value property.

        It was crashing in JSObject::getOwnPropertyDescriptor() because
        we are getting a slot that has attribute "CustomAccessor" but
        the property is not a CustomGetterSetter. In this case, since
        window.length is [Replaceable] and has been set to a numeric value,
        it makes that the property is not a CustomGetterSetter. However,
        the "CustomAccessor" attribute should have been dropped from the
        slot when window.length was shadowed. Therefore, this code path
        should not be exercised at all when calling
        getOwnPropertyDescriptor().

        The issue was that putDirectInternal() was updating the slot
        attributes only if the "Accessor" flag has changed, but not
        the "customAccessor" flag. This patch fixes the issue.

        * runtime/JSObject.h:
        (JSC::JSObject::putDirectInternal):

2016-02-17  Saam barati  <sbarati@apple.com>

        Implement Proxy [[Get]]
        https://bugs.webkit.org/show_bug.cgi?id=154081

        Reviewed by Michael Saboff.

        This patch implements ProxyObject and ProxyConstructor. Their
        implementations are straight forward and follow the spec.
        The largest change in this patch is adding a second parameter
        to PropertySlot's constructor that specifies the internal method type of
        the getOwnPropertySlot inquiry. We use getOwnPropertySlot to 
        implement more than one Internal Method in the spec. Because 
        of this, we need InternalMethodType to give us context about 
        which Internal Method we're executing. Specifically, Proxy will 
        call into different handlers based on this information.

        InternalMethodType is an enum with the following values:
        - Get
          This corresponds to [[Get]] internal method in the spec.
        - GetOwnProperty
          This corresponds to [[GetOwnProperty]] internal method in the spec.
        - HasProperty
          This corresponds to [[HasProperty]] internal method in the spec.
        - VMInquiry
          This is basically everything else that isn't one of the above
          types. This value also mandates that getOwnPropertySlot does
          not perform any user observable effects. I.e, it can't call
          a JS function.

        The other non-VMInquiry InternalMethodTypes are allowed to perform user
        observable effects. I.e, in future patches, ProxyObject will implement
        InternalMethodType::HasProperty and InternalMethodType::GetOwnProperty, which will both be defined
        to call user defined JS functions, which clearly have the right to perform
        user observable effects.

        This patch implements getOwnPropertySlot of ProxyObject under
        InternalMethodType::Get. 

        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::put):
        (JSC::JSCallbackObject<Parent>::staticFunctionGetter):
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::caughtValue):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/ArrayPrototype.cpp:
        (JSC::getProperty):
        * runtime/CommonIdentifiers.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::get):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnNonIndexPropertyNames):
        (JSC::JSFunction::put):
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewWithArguments):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::defineOwnProperty):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::regExpMatchesArrayStructure):
        (JSC::JSGlobalObject::moduleRecordStructure):
        (JSC::JSGlobalObject::moduleNamespaceObjectStructure):
        (JSC::JSGlobalObject::proxyObjectStructure):
        (JSC::JSGlobalObject::wasmModuleStructure):
        * runtime/JSModuleEnvironment.cpp:
        (JSC::JSModuleEnvironment::getOwnPropertySlot):
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::callbackGetter):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Holder::appendNextProperty):
        (JSC::Walker::walk):
        * runtime/JSObject.cpp:
        (JSC::JSObject::calculatedClassName):
        (JSC::JSObject::putDirectNonIndexAccessor):
        (JSC::JSObject::hasProperty):
        (JSC::JSObject::deleteProperty):
        (JSC::JSObject::hasOwnProperty):
        (JSC::JSObject::getOwnPropertyDescriptor):
        * runtime/JSObject.h:
        (JSC::JSObject::getDirectIndex):
        (JSC::JSObject::get):
        * runtime/JSScope.cpp:
        (JSC::abstractAccess):
        * runtime/ObjectConstructor.cpp:
        (JSC::toPropertyDescriptor):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncLookupGetter):
        (JSC::objectProtoFuncLookupSetter):
        (JSC::objectProtoFuncToString):
        * runtime/PropertySlot.h:
        (JSC::attributesForStructure):
        (JSC::PropertySlot::PropertySlot):
        (JSC::PropertySlot::isCacheableGetter):
        (JSC::PropertySlot::isCacheableCustom):
        (JSC::PropertySlot::internalMethodType):
        (JSC::PropertySlot::disableCaching):
        (JSC::PropertySlot::getValue):
        * runtime/ProxyConstructor.cpp: Added.
        (JSC::ProxyConstructor::create):
        (JSC::ProxyConstructor::ProxyConstructor):
        (JSC::ProxyConstructor::finishCreation):
        (JSC::constructProxyObject):
        (JSC::ProxyConstructor::getConstructData):
        (JSC::ProxyConstructor::getCallData):
        * runtime/ProxyConstructor.h: Added.
        (JSC::ProxyConstructor::createStructure):
        * runtime/ProxyObject.cpp: Added.
        (JSC::ProxyObject::ProxyObject):
        (JSC::ProxyObject::finishCreation):
        (JSC::performProxyGet):
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        (JSC::ProxyObject::getOwnPropertySlot):
        (JSC::ProxyObject::getOwnPropertySlotByIndex):
        (JSC::ProxyObject::visitChildren):
        * runtime/ProxyObject.h: Added.
        (JSC::ProxyObject::create):
        (JSC::ProxyObject::createStructure):
        (JSC::ProxyObject::target):
        (JSC::ProxyObject::handler):
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectGet):
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::StackFrame::nameFromCallee):
        * tests/es6.yaml:
        * tests/stress/proxy-basic.js: Added.
        (assert):
        (let.handler.get null):
        (get let):
        (let.handler.get switch):
        (let.handler):
        (let.theTarget.get x):
        * tests/stress/proxy-in-proto-chain.js: Added.
        (assert):
        * tests/stress/proxy-of-a-proxy.js: Added.
        (assert):
        (throw.new.Error.):
        * tests/stress/proxy-property-descriptor.js: Added.
        (assert):
        (set Object):
        * wasm/WASMModuleParser.cpp:
        (JSC::WASMModuleParser::getImportedValue):

2016-02-17  Mark Lam  <mark.lam@apple.com>

        StringPrototype functions should check for exceptions after calling JSString::value().
        https://bugs.webkit.org/show_bug.cgi?id=154340

        Reviewed by Filip Pizlo.

        JSString::value() can throw an exception if the JS string is a rope and value()
        needs to resolve the rope but encounters an OutOfMemory error.  If value() is not
        able to resolve the rope, it will return a null string (in addition to throwing
        the exception).  If StringPrototype functions do not check for exceptions after
        calling JSString::value(), they may eventually use the returned null string and
        crash the VM.

        The fix is to add all the necessary exception checks, and do the appropriate
        handling if needed.

        Also in a few place where when an exception is detected, we return JSValue(), I
        changed it to return jsUndefined() instead to be consistent with the rest of the
        file.

        * runtime/StringPrototype.cpp:
        (JSC::replaceUsingRegExpSearch):
        (JSC::stringProtoFuncMatch):
        (JSC::stringProtoFuncSlice):
        (JSC::stringProtoFuncSplit):
        (JSC::stringProtoFuncLocaleCompare):
        (JSC::stringProtoFuncBig):
        (JSC::stringProtoFuncSmall):
        (JSC::stringProtoFuncBlink):
        (JSC::stringProtoFuncBold):
        (JSC::stringProtoFuncFixed):
        (JSC::stringProtoFuncItalics):
        (JSC::stringProtoFuncStrike):
        (JSC::stringProtoFuncSub):
        (JSC::stringProtoFuncSup):
        (JSC::stringProtoFuncFontcolor):
        (JSC::stringProtoFuncFontsize):
        (JSC::stringProtoFuncAnchor):
        (JSC::stringProtoFuncLink):
        (JSC::trimString):

2016-02-17  Commit Queue  <commit-queue@webkit.org>

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

         "Causes major slowdowns on deltablue-varargs" (Requested by
        keith_miller on #webkit).

        Reverted changeset:

        "Spread operator should be allowed when not the first argument
        of parameter list"
        https://bugs.webkit.org/show_bug.cgi?id=152721
        http://trac.webkit.org/changeset/196675

2016-02-17  Gavin Barraclough  <barraclough@apple.com>

        JSDOMWindow::put should not do the same thing twice
        https://bugs.webkit.org/show_bug.cgi?id=154334

        Reviewed by Chris Dumez.

        It either calls JSGlobalObject::put or Base::put. Hint: these are basically the same thing.
        In the latter case it might call lookupPut. That's redundant; JSObject::put handles static
        table entries.

        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::hasOwnPropertyForWrite): Deleted.
            - no longer needed.

2016-02-16  Filip Pizlo  <fpizlo@apple.com>

        FTL_USES_B3 should be unconditionally true
        https://bugs.webkit.org/show_bug.cgi?id=154324

        Reviewed by Benjamin Poulain.

        * dfg/DFGCommon.h:

2016-02-16  Filip Pizlo  <fpizlo@apple.com>

        FTL should support CompareEq(String:, String:)
        https://bugs.webkit.org/show_bug.cgi?id=154269
        rdar://problem/24499921

        Reviewed by Benjamin Poulain.

        Looks like a slight pdfjs slow-down, probably because we're having some recompilations. I
        think we should land the increased coverage first and fix the issues after, especially since
        the regression is so small and doesn't have a statistically significant effect on the overall
        score.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareEq):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareStrictEq):
        (JSC::FTL::DFG::LowerDFGToLLVM::nonSpeculativeCompare):
        (JSC::FTL::DFG::LowerDFGToLLVM::stringsEqual):
        * tests/stress/ftl-string-equality.js: Added.
        * tests/stress/ftl-string-ident-equality.js: Added.
        * tests/stress/ftl-string-strict-equality.js: Added.

2016-02-16  Filip Pizlo  <fpizlo@apple.com>

        FTL should support NewTypedArray
        https://bugs.webkit.org/show_bug.cgi?id=154268

        Reviewed by Saam Barati.

        3% speed-up on pdfjs. This was already covered by many different tests.

        Rolling this back in after fixing the butterfly argument.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileAllocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToLLVM::allocateBasicStorageAndGetEnd):
        (JSC::FTL::DFG::LowerDFGToLLVM::allocateBasicStorage):
        (JSC::FTL::DFG::LowerDFGToLLVM::allocateObject):

2016-02-16  Gavin Barraclough  <barraclough@apple.com>

        JSDOMWindow::getOwnPropertySlot should just call getStaticPropertySlot
        https://bugs.webkit.org/show_bug.cgi?id=154257

        Reviewed by Chris Dumez.

        * runtime/Lookup.h:
        (JSC::getStaticPropertySlot):
        (JSC::getStaticFunctionSlot):
        (JSC::getStaticValueSlot):
            - this could all do with a little more love.
              But enforce the basic precedence:
                (1) regular storage properties always win over static table properties.
                (2) if properties have been reified, don't consult the static tables.
                (3) only if the property is not present on the object & not reified
                    should the static hashtable be consulted.

2016-02-16  Gavin Barraclough  <barraclough@apple.com>

        JSDOMWindow::getOwnPropertySlot should not search photo chain
        https://bugs.webkit.org/show_bug.cgi?id=154102

        Reviewed by Chris Dumez.

        Should only return *own* properties.

        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnPropertyDescriptor):
            - remove hack/special-case for DOMWindow; we no longer need this.

2016-02-16  Keith Miller  <keith_miller@apple.com>

        Spread operator should be allowed when not the first argument of parameter list
        https://bugs.webkit.org/show_bug.cgi?id=152721

        Reviewed by Saam Barati.

        Spread arguments to functions should now be ES6 compliant. Before we
        would only take a spread operator if it was the sole argument to a
        function. Additionally, we would not use the Symbol.iterator on the
        object to generate the arguments. Instead we would do a loop up to the
        length mapping indexed properties to the corresponding argument. We fix
        both these issues by doing an AST transformation from foo(...a, b, ...c, d)
        to foo(...[...a, b, ...c, d]) (where the spread on the rhs uses the
        old spread semantics). This solution has the downside of requiring the
        allocation of another object and copying each element twice but avoids a
        large change to the vm calling convention.

        * interpreter/Interpreter.cpp:
        (JSC::loadVarargs):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createElementList):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseArguments):
        (JSC::Parser<LexerType>::parseArgument):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/Parser.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createElementList):
        * tests/es6.yaml:
        * tests/stress/spread-calling.js: Added.
        (testFunction):
        (testEmpty):
        (makeObject):
        (otherIterator.return.next):
        (otherIterator):
        (totalIter):
        (throwingIter.return.next):
        (throwingIter):
        (i.catch):

2016-02-16  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Enable B3 on ARM64
        https://bugs.webkit.org/show_bug.cgi?id=154275

        Reviewed by Mark Lam.

        The port passes more tests than LLVM now, let's use it by default.

        * dfg/DFGCommon.h:

2016-02-16  Commit Queue  <commit-queue@webkit.org>

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

        This change caused LayoutTest crashes (Requested by ryanhaddad
        on #webkit).

        Reverted changeset:

        "FTL should support NewTypedArray"
        https://bugs.webkit.org/show_bug.cgi?id=154268
        http://trac.webkit.org/changeset/196652

2016-02-16  Brian Burg  <bburg@apple.com>

        RemoteInspector should forward new automation session requests to its client
        https://bugs.webkit.org/show_bug.cgi?id=154260
        <rdar://problem/24663313>

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.h:
        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::xpcConnectionReceivedMessage):
        (Inspector::RemoteInspector::listingForAutomationTarget):
        Use the correct key for the session identifier in the listing. The name()
        override for RemoteAutomationTarget is actually the session identifier.

        (Inspector::RemoteInspector::receivedAutomationSessionRequestMessage):
        * inspector/remote/RemoteInspectorConstants.h: Add new constants.

2016-02-16  Saam barati  <sbarati@apple.com>

        SamplingProfiler still fails with ASan enabled
        https://bugs.webkit.org/show_bug.cgi?id=154301
        <rdar://problem/24679502>

        Reviewed by Filip Pizlo.

        To fix this issue, I've come up with unsafe versions
        of all operations that load memory from the thread's call
        frame. All these new unsafe methods are marked with SUPPRESS_ASAN.

        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::callSiteAsRawBits):
        (JSC::CallFrame::unsafeCallSiteAsRawBits):
        (JSC::CallFrame::callSiteIndex):
        (JSC::CallFrame::unsafeCallSiteIndex):
        (JSC::CallFrame::stack):
        (JSC::CallFrame::callerFrame):
        (JSC::CallFrame::unsafeCallerFrame):
        (JSC::CallFrame::friendlyFunctionName):
        * interpreter/CallFrame.h:
        (JSC::ExecState::calleeAsValue):
        (JSC::ExecState::callee):
        (JSC::ExecState::unsafeCallee):
        (JSC::ExecState::codeBlock):
        (JSC::ExecState::unsafeCodeBlock):
        (JSC::ExecState::scope):
        (JSC::ExecState::callerFrame):
        (JSC::ExecState::callerFrameOrVMEntryFrame):
        (JSC::ExecState::unsafeCallerFrameOrVMEntryFrame):
        (JSC::ExecState::callerFrameOffset):
        (JSC::ExecState::callerFrameAndPC):
        (JSC::ExecState::unsafeCallerFrameAndPC):
        * interpreter/Register.h:
        (JSC::Register::codeBlock):
        (JSC::Register::asanUnsafeCodeBlock):
        (JSC::Register::unboxedInt32):
        (JSC::Register::tag):
        (JSC::Register::unsafeTag):
        (JSC::Register::payload):
        * interpreter/VMEntryRecord.h:
        (JSC::VMEntryRecord::prevTopCallFrame):
        (JSC::VMEntryRecord::unsafePrevTopCallFrame):
        (JSC::VMEntryRecord::prevTopVMEntryFrame):
        (JSC::VMEntryRecord::unsafePrevTopVMEntryFrame):
        * runtime/SamplingProfiler.cpp:
        (JSC::FrameWalker::walk):
        (JSC::FrameWalker::advanceToParentFrame):
        (JSC::FrameWalker::isAtTop):
        (JSC::FrameWalker::resetAtMachineFrame):

2016-02-16  Filip Pizlo  <fpizlo@apple.com>

        FTL should support NewTypedArray
        https://bugs.webkit.org/show_bug.cgi?id=154268

        Reviewed by Saam Barati.

        3% speed-up on pdfjs. This was already covered by many different tests.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileAllocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToLLVM::allocateBasicStorageAndGetEnd):
        (JSC::FTL::DFG::LowerDFGToLLVM::allocateBasicStorage):
        (JSC::FTL::DFG::LowerDFGToLLVM::allocateObject):

2016-02-16  Saam barati  <sbarati@apple.com>

        stress/sampling-profiler-deep-stack.js fails on ARM 32bit
        https://bugs.webkit.org/show_bug.cgi?id=154255
        <rdar://problem/24662996>

        Reviewed by Mark Lam.

        The bug here wasn't in the implementation of the sampling profiler 
        itself. Rather, it was a bug in the test. JSC wasn't spending a lot
        of time in a function that the test assumed a lot of time was spent in.
        That's because the DFG was doing a good job at optimizing the function
        at the leaf of the recursion. Because of that, we often wouldn't sample it.
        I fixed this by making the leaf function do more work.

        * tests/stress/sampling-profiler-deep-stack.js:
        (platformSupportsSamplingProfiler.foo):

2016-02-16  Chris Dumez  <cdumez@apple.com>

        [Web IDL] Operations should be on the instance for global objects or if [Unforgeable]
        https://bugs.webkit.org/show_bug.cgi?id=154120
        <rdar://problem/24613231>

        Reviewed by Gavin Barraclough.

        Have putEntry() take a thisValue parameter in addition to the base,
        instead of relying on PropertySlot::thisValue() because this did not
        always do the right thing. In particular, when JSDOMWindow::put() was
        called to set a function, it would end up setting the new value on the
        JSDOMWindowShell instead of the actual JSDOMWindow.
        JSDOMWindow::getOwnPropertySlot() would then not be able to find it.
        Therefore the following would fail:
        $ window.open = "test"
        $ console.log(window.open) // prints the native function instead of "test"

        * runtime/JSObject.cpp:
        (JSC::JSObject::putInlineSlow):
        * runtime/Lookup.h:
        (JSC::putEntry):
        (JSC::lookupPut):

2016-02-16  Keith Miller  <keith_miller@apple.com>

        ClonedArguments should not materialize its special properties unless they are being changed or deleted
        https://bugs.webkit.org/show_bug.cgi?id=154128

        Reviewed by Filip Pizlo.

        Before we would materialize ClonedArguments whenever they were being accessed.
        However this would cause the IC to miss every time as the structure for
        the arguments object would change as we went to IC it. Thus on the next
        function call we would miss the cache since the new arguments object
        would not have materialized the value.

        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::getOwnPropertySlot):
        * tests/stress/cloned-arguments-modification.js: Added.
        (foo):

2016-02-16  Filip Pizlo  <fpizlo@apple.com>

        FTL should support StringFromCharCode
        https://bugs.webkit.org/show_bug.cgi?id=154267
        rdar://problem/24192536

        Reviewed by Mark Lam.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): Fix a bug preventing the UntypedUse from being effective.
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileStringFromCharCode): Implement the opcode.
        * tests/stress/string-from-char-code-slow.js: Added.

2016-02-15  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] BranchAdd can override arguments of its stackmap
        https://bugs.webkit.org/show_bug.cgi?id=154274

        Reviewed by Filip Pizlo.

        With the 3 operands BranchAdd added in r196513, we can run into
        a register allocation such that the destination register is also
        used by a value in the stack map.

        It use to be that BranchAdd was a 2 operand instruction.
        In that form, the destination is also one of the source and
        can be recovered through Sub. There is no conflict between
        destination and the stackmap.

        After r196513, the destination has its own value. It is uncommon
        on x86 because of the aggressive aliasing but that can happen.
        On ARM, that's a standard form since there is no need for aliasing.

        Since the arguments of the stackmap are of type EarlyUse,
        they appeared as not interfering with the destination. When the register
        allocator gives the same register to the destination and something in
        the stack map, the result of BranchAdd destroys the value kept alive
        for the stackmap.

        In this patch, I introduce a concept very similar to ForceLateUse
        to keep the argument of the stackmap live in CheckAdd. The new
        role is "ForceLateUseUnlessRecoverable".

        In this mode, anything that is not also an input argument becomes
        LateUse. As such, it interferes with the destination of CheckAdd.
        The arguments are recovered by the slow patch of CheckAdd. They
        remain Early use.

        This new modes ensure that destination can be aliased to the source
        when that's useful, while making sure it is not aliased with another
        value that needs to be live on exit.

        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::forEachArg):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::forEachArg):
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        (WTF::printInternal):
        * b3/B3StackmapSpecial.h:
        * b3/B3StackmapValue.h:

2016-02-15  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Web Workers have no access to console for debugging
        https://bugs.webkit.org/show_bug.cgi?id=26237

        Reviewed by Timothy Hatcher.

        * inspector/ConsoleMessage.h:
        Add accessor for MessageLevel.

2016-02-15  Mark Lam  <mark.lam@apple.com>

        [ARMv7] stress/op_rshift.js and stress/op_urshift.js are failing.
        https://bugs.webkit.org/show_bug.cgi?id=151514

        Reviewed by Filip Pizlo.

        The issue turns out to be trivial: on ARMv7 (and traditional ARM too), arithmetic
        shift right (ASR) and logical shift right (LSR) takes an immediate shift amount
        from 1-32.  See http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cjacbgca.html.
        An immediate shift amount of 0 is interpreted as a shift of 32 bits.

        Meanwhile, our macro assembler is expecting the immediate shift value to be
        between 0-31.  As a result, a shift amount of 0 is being wrongly encoded with 0
        bits which means shift right by 32 bits.

        The fix is to check if the shift amount is 0, and if so, emit a move.  Else,
        emit the right shift as usual.

        This issue does not affect left shifts, as the immediate shift amount for left
        shifts is between 0-31 as our macro assembler expects.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::rshift32):
        (JSC::MacroAssemblerARM::urshift32):
        (JSC::MacroAssemblerARM::sub32):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::rshift32):
        (JSC::MacroAssemblerARMv7::urshift32):

        * tests/stress/op_rshift.js:
        * tests/stress/op_urshift.js:
        - Un-skip these tests.  They should always pass now.

2016-02-15  Filip Pizlo  <fpizlo@apple.com>

        Parser::parseVariableDeclarationList should null check the node before attempting to create a new CommaExpr
        https://bugs.webkit.org/show_bug.cgi?id=154244
        rdar://problem/24290670

        Reviewed by Michael Saboff.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::appendToCommaExpr): Catch the bug sooner in debug.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseVariableDeclarationList): Fix the bug.
        * tests/stress/for-let-comma.js: Added. This used to crash in debug and release.

2016-02-15  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Improve the interface of Inst::shouldTryAliasingDef()
        https://bugs.webkit.org/show_bug.cgi?id=154227

        Reviewed by Andreas Kling.

        Using Optional<> instead of a bool+reference looks cleaner
        at the call sites.

        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::shouldTryAliasingDef):
        * b3/B3CheckSpecial.h:
        * b3/air/AirCustom.h:
        (JSC::B3::Air::PatchCustom::shouldTryAliasingDef):
        * b3/air/AirInst.h:
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::shouldTryAliasingDef):
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * b3/air/AirSpecial.cpp:
        (JSC::B3::Air::Special::shouldTryAliasingDef):
        * b3/air/AirSpecial.h:

2016-02-14  Brian Burg  <bburg@apple.com>

        WKAutomationDelegate's requestAutomationSession should take a suggested session identifier
        https://bugs.webkit.org/show_bug.cgi?id=154012
        <rdar://problem/24557697>

        Reviewed by Darin Adler.

        Add a string parameter to the client method for requesting a new session.

        * inspector/remote/RemoteInspector.h:

2016-02-13  Timothy Hatcher  <timothy@apple.com>

        Fix WebAssembly bug URL in the feature list.

        * features.json:

2016-02-12  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Change the last RefPtr::get() to release() in String.prototype.normalize
        https://bugs.webkit.org/show_bug.cgi?id=154211

        Reviewed by Ryosuke Niwa.

        Change the last RefPtr::get() to release() in String.prototype.normalize.

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

2016-02-12  Saam barati  <sbarati@apple.com>

        [ES6] we have an incorrect syntax error when a callee of a function expression has the same name as a top-level lexical declaration
        https://bugs.webkit.org/show_bug.cgi?id=154143

        Reviewed by Benjamin Poulain.

        We were raising syntax errors on the following type of programs when
        we shouldn't have been.
        ```
        (function foo() { const foo = 20; });
        ```

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/Parser.h:
        (JSC::Scope::computeLexicallyCapturedVariablesAndPurgeCandidates):
        (JSC::Scope::declareCallee):
        (JSC::Scope::declareVariable):
        (JSC::Scope::hasDeclaredVariable):
        (JSC::Scope::hasLexicallyDeclaredVariable):
        (JSC::Scope::hasDeclaredParameter):
        (JSC::Scope::declareWrite):
        (JSC::Scope::getCapturedVars):

2016-02-12  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] ZeroExtend and SignExtend use incorrect addressing on ARM64
        https://bugs.webkit.org/show_bug.cgi?id=154208

        Reviewed by Filip Pizlo.

        When lowering:
            @1 = Load32(@x)
            @2 = SExt8(@1)

        LowerToAir would see there is a form of SignExtend8To32 (an alias for Load8S)
        and use that.

        There are two problems with that:
        1) If we have an Addr, it went through legalizeMemoryOffsets() for a 32bits
           load. If used on an other kind of load, there is no guarantee the addressing
           is still valid.
        2) If we have an Index, it is computed for the 32bits MemoryValue.
           The computed index is not valid for the 8bits load.

        (2) could be fixed by changing LowerToAir to use the current instruction width
        instead of the B3ValueWidth but that's a bit tricky. We should just embrace
        that one of our target is a Load-Store architecture.

        In this patch, I just disabled the faulty forms on ARM64. We still need those operations
        to be fast, this will be addressed in: https://bugs.webkit.org/show_bug.cgi?id=154207

        I also strengthened the m_allowScratchRegister assertion. The instructions that do not
        invalidate the temporary did not run the assertion, making this harder to debug.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::load8):
        (JSC::MacroAssemblerARM64::store64):
        (JSC::MacroAssemblerARM64::store32):
        (JSC::MacroAssemblerARM64::loadDouble):
        (JSC::MacroAssemblerARM64::storeDouble):
        (JSC::MacroAssemblerARM64::branch32):
        (JSC::MacroAssemblerARM64::branch64):
        (JSC::MacroAssemblerARM64::getCachedDataTempRegisterIDAndInvalidate):
        (JSC::MacroAssemblerARM64::getCachedMemoryTempRegisterIDAndInvalidate):
        (JSC::MacroAssemblerARM64::dataMemoryTempRegister):
        (JSC::MacroAssemblerARM64::cachedMemoryTempRegister):
        (JSC::MacroAssemblerARM64::load):
        (JSC::MacroAssemblerARM64::store):
        * b3/air/AirOpcode.opcodes:

2016-02-12  Michael Saboff  <msaboff@apple.com>

        offlineasm: Emit Dwarf2 file and location directives to allow for debugging .asm files
        https://bugs.webkit.org/show_bug.cgi?id=152703

        Reviewed by Mark Lam.

        Added support to output Dwarf2 .file and .loc assembler directives to provide the debugging
        information needed to correlate the offline assembler generated code with the source lines 
        in the .asm files.

        Changed the tracking of file data to include a file index that was provided to the .file
        directive.  That index is used when emitting the .loc directives.

        * offlineasm/arm.rb:
        * offlineasm/arm64.rb:
        * offlineasm/asm.rb:
        * offlineasm/backends.rb:
        * offlineasm/config.rb:
        * offlineasm/parser.rb:
        * offlineasm/x86.rb:

2016-02-12  Saam barati  <sbarati@apple.com>

        The parser doesn't properly protect against global variable references in builtins
        https://bugs.webkit.org/show_bug.cgi?id=154144

        Reviewed by Geoffrey Garen.

        This patch fixes our global variable reference detection
        algorithm that was broken. After fixing the algorithm, I
        detected many places where we were incorrectly using global
        variables. I've fixed all those.

        * builtins/BuiltinExecutables.cpp:
        (JSC::createExecutableInternal):
        * builtins/NumberPrototype.js:
        (toLocaleString):
        * builtins/PromiseConstructor.js:
        (race):
        (reject):
        (resolve):
        * parser/Nodes.cpp:
        (JSC::ProgramNode::ProgramNode):
        (JSC::ModuleProgramNode::ModuleProgramNode):
        (JSC::ProgramNode::setClosedVariables): Deleted.
        * parser/Nodes.h:
        (JSC::ScopeNode::setClosedVariables): Deleted.
        (JSC::ProgramNode::closedVariables): Deleted.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::didFinishParsing):
        * parser/Parser.h:
        (JSC::Scope::setIsLexicalScope):
        (JSC::Scope::isLexicalScope):
        (JSC::Scope::closedVariableCandidates):
        (JSC::Scope::declaredVariables):
        (JSC::Scope::lexicalVariables):
        (JSC::Scope::finalizeLexicalEnvironment):
        (JSC::Parser::positionBeforeLastNewline):
        (JSC::Parser::locationBeforeLastToken):
        (JSC::Parser::isFunctionMetadataNode):
        (JSC::parse):
        (JSC::Parser::closedVariables): Deleted.

2016-02-12  Filip Pizlo  <fpizlo@apple.com>

        JSObject::putByIndexBeyondVectorLengthWithoutAttributes needs to go to the sparse map based on MAX_STORAGE_VECTOR_INDEX
        https://bugs.webkit.org/show_bug.cgi?id=154201
        rdar://problem/24291387

        Reviewed by Saam Barati.

        I decided against adding a test for this, because it runs for a very long time.

        * runtime/JSObject.cpp:
        (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): Fix the bug.
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncSplit): Fix a related bug: if this code creates an array that would have
            hit the above bug, then it would probably manifest as a spin or as swapping.

2016-02-12  Jonathan Davis  <jond@apple.com>

        Add WebAssembly to the status page
        https://bugs.webkit.org/show_bug.cgi?id=154199

        Reviewed by Timothy Hatcher.

        * features.json:

2016-02-12  Brian Burg  <bburg@apple.com>

        Web Inspector: disambiguate the various identifier and connection types in RemoteInspector
        https://bugs.webkit.org/show_bug.cgi?id=154130

        Reviewed by Joseph Pecoraro.

        There are multiple identifier types:
            - connection identifier, a string UUID for a remote debugger process.
            - session identifier, a string UUID for a remote driver/debugger instance.
            - page/target identifier, a number unique within a single process.

        There are multiple connection types:
            - RemoteInspectorXPCConnection, a connection from RemoteInspectorXPCConnectionor to a relay.
            - RemoteConnectionToTarget, a class that bridges to targets' dispatch queues.

        Use consistent variable and getter names so that these don't get confused and
        so that the code is easier to read. This is especially an improvement when working
        with multiple target types or connection types within the same function.

        * inspector/remote/RemoteConnectionToTarget.h:
        * inspector/remote/RemoteConnectionToTarget.mm:
        Remove the member for m_identifier since we can ask the target for its target identifier
        or use a default value via WTF::Optional. There's no reason to cache the value.

        (Inspector::RemoteTargetHandleRunSourceWithInfo):
        (Inspector::RemoteConnectionToTarget::targetIdentifier):
        (Inspector::RemoteConnectionToTarget::destination):
        (Inspector::RemoteConnectionToTarget::setup):
        (Inspector::RemoteConnectionToTarget::sendMessageToFrontend):
        Bail out if the target pointer was somehow cleared and we can't get a useful target identifier.

        (Inspector::RemoteConnectionToTarget::RemoteConnectionToTarget): Deleted.
        * inspector/remote/RemoteControllableTarget.h:
        * inspector/remote/RemoteInspectionTarget.cpp:
        (Inspector::RemoteInspectionTarget::pauseWaitingForAutomaticInspection):
        (Inspector::RemoteInspectionTarget::unpauseForInitializedInspector):
        * inspector/remote/RemoteInspector.h:
        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::nextAvailableTargetIdentifier):
        (Inspector::RemoteInspector::registerTarget):
        (Inspector::RemoteInspector::unregisterTarget):
        (Inspector::RemoteInspector::updateTarget):
        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
        (Inspector::RemoteInspector::sendAutomaticInspectionCandidateMessage):
        (Inspector::RemoteInspector::sendMessageToRemote):
        (Inspector::RemoteInspector::setupFailed):
        (Inspector::RemoteInspector::setupCompleted):
        (Inspector::RemoteInspector::stopInternal):
        (Inspector::RemoteInspector::setupXPCConnectionIfNeeded):
        (Inspector::RemoteInspector::xpcConnectionFailed):
        (Inspector::RemoteInspector::listingForInspectionTarget):
        (Inspector::RemoteInspector::listingForAutomationTarget):
        (Inspector::RemoteInspector::pushListingsNow):
        (Inspector::RemoteInspector::pushListingsSoon):
        (Inspector::RemoteInspector::updateHasActiveDebugSession):
        (Inspector::RemoteInspector::receivedSetupMessage):
        (Inspector::RemoteInspector::receivedDataMessage):
        (Inspector::RemoteInspector::receivedDidCloseMessage):
        (Inspector::RemoteInspector::receivedIndicateMessage):
        (Inspector::RemoteInspector::receivedProxyApplicationSetupMessage):
        (Inspector::RemoteInspector::receivedConnectionDiedMessage):
        (Inspector::RemoteInspector::receivedAutomaticInspectionRejectMessage):
        (Inspector::RemoteInspector::nextAvailableIdentifier): Deleted.
        * inspector/remote/RemoteInspectorConstants.h:

2016-02-12  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] On x86, improve the selection of which value are selected for the UseDef part of commutative operations
        https://bugs.webkit.org/show_bug.cgi?id=154151

        Reviewed by Filip Pizlo.

        Previously, when an instruction destroy an argument with
        a UseDef use, we would try to pick a good target for the UseDef
        while doing instruction selection.

        For example:
            @x = Add(@1, @2)

        can be lowered to:
            Move @1 Tmp3
            Add @2 Tmp3
        or
            Move @2 Tmp3
            Add @1 Tmp3

        The choice of which value ends up copied is done by preferRightForResult()
        at lowering time.

        There are two common problems with the code we generate:
        1) It is based on UseCount. If a value is at its last use,
           it is a good target for coalescing even with a use-count > 1.
        2) When both values are at their last use, the best choice
           depends on the register pressure of each. We don't have that information
           until we do register allocation.

        This patch implements a simple idea to minimize how many of those Moves are needed.
        Each commutative operation gets a 3 op variant. The register allocator then attempts
        to alias *both* of them to the destination.
        Since our aliasing is conservative, it removes as many copy as possible without causing
        spilling.

        There was an unexpected cool impovement too. If you have:
            Move Tmp1, Tmp2
            BranchAdd32 Tmp3, Tmp2
        we would previously restore Tmp2 by substracting Tmp3 from the result.
        We can now just use Tmp1. That removes quite a few Sub from the slow paths.

        The problem is that simple idea uncoverred a bunch of issues that had to be fixed too.
        I detail them inline below.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::and64):
        * assembler/MacroAssemblerX86Common.h:
        Most addition are adding an Address version of the 3 operands opcodes.
        The reason for this is allow the complex addressing forms of instructions
        when spilling.

        (JSC::MacroAssemblerX86Common::and32):
        (JSC::MacroAssemblerX86Common::mul32):
        (JSC::MacroAssemblerX86Common::or32):
        (JSC::MacroAssemblerX86Common::xor32):
        (JSC::MacroAssemblerX86Common::moveDouble):
        This was an unexpected discovery: removing tons of Move32 made floating-point heavy
        code much slower.

        It turns out the MoveDouble we were using has partial register dependencies.

        The x86 optimization manual, Chapter 3, section 3.4.1.13 lists the move instructions executed
        directly on the frontend. That's what we use now.

        (JSC::MacroAssemblerX86Common::addDouble):
        (JSC::MacroAssemblerX86Common::addFloat):
        (JSC::MacroAssemblerX86Common::mulDouble):
        (JSC::MacroAssemblerX86Common::mulFloat):
        (JSC::MacroAssemblerX86Common::andDouble):
        (JSC::MacroAssemblerX86Common::andFloat):
        (JSC::MacroAssemblerX86Common::xorDouble):
        (JSC::MacroAssemblerX86Common::xorFloat):
        If the destination is not aliased, the version taking an address
        use LoadFloat/LoadDouble instead of direct addressing.

        That is because this:
            Move Tmp1, Tmp2
            Op [Tmp3], Tmp2
        is slower than
            Move [Tmp3] Tmp2
            Op Tmp1, Tmp2
        (sometimes significantly).

        I am not exactly sure why.

        (JSC::MacroAssemblerX86Common::branchAdd32):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::and64):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::and64):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::and32):
        (JSC::MacroAssemblerX86Common::mul32):
        (JSC::MacroAssemblerX86Common::or32):
        (JSC::MacroAssemblerX86Common::xor32):
        (JSC::MacroAssemblerX86Common::moveDouble):
        (JSC::MacroAssemblerX86Common::addDouble):
        (JSC::MacroAssemblerX86Common::addFloat):
        (JSC::MacroAssemblerX86Common::mulDouble):
        (JSC::MacroAssemblerX86Common::mulFloat):
        (JSC::MacroAssemblerX86Common::andDouble):
        (JSC::MacroAssemblerX86Common::andFloat):
        (JSC::MacroAssemblerX86Common::xorDouble):
        (JSC::MacroAssemblerX86Common::xorFloat):
        (JSC::MacroAssemblerX86Common::branchAdd32):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::and64):
        (JSC::MacroAssemblerX86_64::mul64):
        (JSC::MacroAssemblerX86_64::xor64):
        (JSC::MacroAssemblerX86_64::branchAdd64):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::movapd_rr):
        (JSC::X86Assembler::movaps_rr):
        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::shouldTryAliasingDef):
        (JSC::B3::CheckSpecial::generate):
        * b3/B3CheckSpecial.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/air/AirCustom.h:
        (JSC::B3::Air::PatchCustom::shouldTryAliasingDef):
        * b3/air/AirInst.h:
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::shouldTryAliasingDef):
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        Aliasing the operands is done the same way as any coalescing.

        There were problem with considering all those coalescing
        as equivalent for the result.

        Moves are mostly generated for Upsilon-Phis. Getting rid of
        those tends to give better loops.

        Sometimes, blocks have only Phis and a Jump. Coalescing
        those moves gets rids of the block entirely.

        Where it go interesting was that something like:
            Move Tmp1, Tmp2
            Op Tmp3, Tmp2
        was significantly better than:
            Op Tmp1, Tmp3
            Move Tmp1, Tmp4
        even in the same basic block.

        To get back to the same performance when, I had to prioritize
        regular Moves operations over argument coalescing.

        Another argument for doing this is that the alias has a shorter
        life in the hardware because the operation itself gets a new
        virtual register from the bank.

        * b3/air/AirOpcode.opcodes:
        * b3/air/AirSpecial.cpp:
        (JSC::B3::Air::Special::shouldTryAliasingDef):
        * b3/air/AirSpecial.h:
        * b3/testb3.cpp:
        (JSC::B3::testCheckAddArgumentAliasing64):
        (JSC::B3::testCheckAddArgumentAliasing32):
        (JSC::B3::testCheckAddSelfOverflow64):
        (JSC::B3::testCheckAddSelfOverflow32):
        (JSC::B3::testCheckMulArgumentAliasing64):
        (JSC::B3::testCheckMulArgumentAliasing32):
        (JSC::B3::run):

        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitSaveOrCopyCalleeSavesFor):
        This ruined my week.

        When regenerating the frame of an inlined function that
        was called through a tail call, we were ignoring r13 for some reason.

        Since this patch makes it more likely to increase the degree
        of each Tmp, the number of register used increased and r13 was more
        commonly used.

        When getting out of OSRExit, we would have that value trashed :(

        The fix is simply to restore it like the other two Baseline callee saved
        register.

2016-02-12  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement @@search
        https://bugs.webkit.org/show_bug.cgi?id=143889

        Reviewed by Darin Adler.

        Implement RegExp.prototype[@@search].
        In ES6, String.prototype.search delegates the actual matching to it
        instead of executing RegExp matching inside String.prototype.search method itself.
        By customizing @@search method, we can change the behavior of String.prototype.search for
        derived / customized RegExp object.

        * CMakeLists.txt:
        * DerivedSources.make:
        * builtins/BuiltinNames.h:
        (JSC::BuiltinNames::BuiltinNames): Deleted.
        * builtins/BuiltinUtils.h:
        * builtins/StringPrototype.js:
        (search):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        (JSC::regExpProtoFuncSearch):
        * runtime/RegExpPrototype.h:
        (JSC::RegExpPrototype::create):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::getOwnPropertySlot):
        (JSC::StringPrototype::finishCreation): Deleted.
        (JSC::stringProtoFuncSearch): Deleted.
        * runtime/StringPrototype.h:
        * tests/es6.yaml:
        * tests/stress/regexp-search.js: Added.
        (shouldBe):
        (shouldThrow):
        (errorKey.toString):
        (primitive.of.primitives.shouldThrow):
        (testRegExpSearch):
        (testSearch):
        (testBoth):
        (alwaysUnmatch):

2016-02-12  Keith Miller  <keith_miller@apple.com>

        AdaptiveInferredPropertyValueWatchpoint can trigger a GC that frees its CodeBlock and thus itself
        https://bugs.webkit.org/show_bug.cgi?id=154146

        Reviewed by Filip Pizlo.

        Consider the following: there is some CodeBlock, C, that is watching some object, O, with a
        structure, S, for replacements. Also, suppose that C has no references anymore and is due to
        be GCed. Now, when some new property is added to O, S will create a new structure S' and
        fire its transition watchpoints. Since C is watching S for replacements it will attempt to
        have its AdaptiveInferredPropertyValueWatchpoint relocate itself to S'. To do so, it needs
        it allocate RareData on S'. This allocation may cause a GC, which frees C while still
        executing its watchpoint handler. The solution to this is to defer GC while running
        AdaptiveInferredPropertyValueWatchpointBase handlers.

        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):

2016-02-12  Gavin Barraclough  <barraclough@apple.com>

        Separate out !allowsAccess path in JSDOMWindowCustom getOwnPropertySlot
        https://bugs.webkit.org/show_bug.cgi?id=154156

        Reviewed by Chris Dumez.

        * runtime/CommonIdentifiers.h:
            - added new property names, needed by jsDOMWindowGetOwnPropertySlotDisallowAccess.

2016-02-12  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Update ICU header files to version 52
        https://bugs.webkit.org/show_bug.cgi?id=154160

        Reviewed by Alex Christensen.

        Update ICU header files to version 52 to allow the use of newer APIs.

        * icu/unicode/localpointer.h:
        * icu/unicode/platform.h:
        * icu/unicode/ptypes.h:
        * icu/unicode/putil.h:
        * icu/unicode/ucal.h:
        * icu/unicode/uchar.h:
        * icu/unicode/ucnv.h:
        * icu/unicode/ucol.h:
        * icu/unicode/uconfig.h:
        * icu/unicode/udat.h:
        * icu/unicode/udatpg.h:
        * icu/unicode/udisplaycontext.h: Added.
        * icu/unicode/uenum.h:
        * icu/unicode/uformattable.h: Added.
        * icu/unicode/uiter.h:
        * icu/unicode/uloc.h:
        * icu/unicode/umachine.h:
        * icu/unicode/unorm2.h:
        * icu/unicode/unum.h:
        * icu/unicode/urename.h:
        * icu/unicode/uscript.h:
        * icu/unicode/uset.h:
        * icu/unicode/ustring.h:
        * icu/unicode/utf.h:
        * icu/unicode/utf16.h:
        * icu/unicode/utf8.h:
        * icu/unicode/utf_old.h:
        * icu/unicode/utypes.h:
        * icu/unicode/uvernum.h:
        * icu/unicode/uversion.h:

2016-02-12  Filip Pizlo  <fpizlo@apple.com>

        Fast path in JSObject::defineOwnIndexedProperty() forgets to check for the posibility of a descriptor that doesn't have a value
        https://bugs.webkit.org/show_bug.cgi?id=154175
        rdar://problem/24291497

        Reviewed by Geoffrey Garen.

        * runtime/JSObject.cpp:
        (JSC::JSObject::defineOwnIndexedProperty): Fix the bug.
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::putEntry): Catch the bug sooner in debug.
        (JSC::SparseArrayValueMap::putDirect):
        * tests/stress/sparse-define-empty-descriptor.js: Added. This used to crash in release.

2016-02-11  Brian Burg  <bburg@apple.com>

        Web Inspector: RemoteInspector's listings should include whether an AutomationTarget is paired
        https://bugs.webkit.org/show_bug.cgi?id=154077
        <rdar://problem/24589133>

        Reviewed by Joseph Pecoraro.

        Instead of not generating a listing for the target when it is occupied,
        generate the listing with a 'paired' flag. The old flag was redundant
        because a _WKAutomationDelegate will not create a session if it doesn't
        support automation or it already has an active session.

        * inspector/remote/RemoteAutomationTarget.cpp:
        (Inspector::RemoteAutomationTarget::setIsPaired):
        (Inspector::RemoteAutomationTarget::setAutomationAllowed): Deleted.
        * inspector/remote/RemoteAutomationTarget.h:
        Return false for remoteControlAllowed() if the target is already paired.
        This function is used by RemoteInspector to deny incoming connections.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::listingForAutomationTarget):
        * inspector/remote/RemoteInspectorConstants.h:

2016-02-11  Filip Pizlo  <fpizlo@apple.com>

        DFG::ByteCodeParser needs to null check the result of presenceLike()
        https://bugs.webkit.org/show_bug.cgi?id=154135
        rdar://problem/24291586

        Reviewed by Geoffrey Garen.

        ByteCodeParser::presenceLike() could return a null object property condition if it detects a
        contradiction. That could happen due to bogus profiling. It's totally OK - we just need to
        bail from using a property condition when that happens.

        * bytecode/ObjectPropertyCondition.h:
        (JSC::ObjectPropertyCondition::equivalence):
        (JSC::ObjectPropertyCondition::operator bool):
        (JSC::ObjectPropertyCondition::object):
        (JSC::ObjectPropertyCondition::condition):
        (JSC::ObjectPropertyCondition::operator!): Deleted.
        * bytecode/PropertyCondition.h:
        (JSC::PropertyCondition::equivalence):
        (JSC::PropertyCondition::operator bool):
        (JSC::PropertyCondition::kind):
        (JSC::PropertyCondition::uid):
        (JSC::PropertyCondition::operator!): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::check):
        (JSC::DFG::ByteCodeParser::load):

2016-02-11  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] SqrtFloat and CeilFloat also suffer from partial register stalls
        https://bugs.webkit.org/show_bug.cgi?id=154131

        Reviewed by Filip Pizlo.

        Looks like I forgot to update this when adding Float support.
        Credit to Filip for finding this issue.

        * b3/air/AirFixPartialRegisterStalls.cpp:

2016-02-11  Filip Pizlo  <fpizlo@apple.com>

        Cannot call initializeIndex() if we didn't create the array using tryCreateUninitialized()
        https://bugs.webkit.org/show_bug.cgi?id=154126

        Reviewed by Saam Barati.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSplice):

2016-02-11  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        [INTL] Implement Intl.NumberFormat.prototype.resolvedOptions ()
        https://bugs.webkit.org/show_bug.cgi?id=147602

        Reviewed by Darin Adler.

        This patch implements Intl.NumberFormat.prototype.resolvedOptions() according
        to the ECMAScript 2015 Internationalization API spec (ECMA-402 2nd edition.)

        * runtime/IntlDateTimeFormat.cpp:
        (JSC::localeData):
        * runtime/IntlNumberFormat.cpp:
        (JSC::localeData):
        (JSC::computeCurrencySortKey):
        (JSC::extractCurrencySortKey):
        (JSC::computeCurrencyDigits):
        (JSC::IntlNumberFormat::initializeNumberFormat):
        (JSC::IntlNumberFormat::styleString):
        (JSC::IntlNumberFormat::currencyDisplayString):
        (JSC::IntlNumberFormat::resolvedOptions):
        (JSC::IntlNumberFormat::setBoundFormat):
        * runtime/IntlNumberFormat.h:
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::constructIntlNumberFormat):
        (JSC::callIntlNumberFormat):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
        * runtime/IntlObject.cpp:
        (JSC::intlNumberOption):
        (JSC::numberingSystemsForLocale):
        (JSC::getNumberingSystemsForLocale): Deleted.
        * runtime/IntlObject.h:

2016-02-11  Filip Pizlo  <fpizlo@apple.com>

        MacroAssemblerX86 should be happy with shift(cx, cx)
        https://bugs.webkit.org/show_bug.cgi?id=154124

        Reviewed by Saam Barati.

        Prior to this change the assembler asserted that shift_amount and dest cannot be the same.
        That's a good assertion for when shift_amount is not in cx. But if it's in cx already then
        it's OK for them to be the same. Air will sometimes do shift(cx, cx) if you do "x << x" and
        the coalescing got particularly clever.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::lshift32):
        (JSC::MacroAssemblerX86Common::rshift32):
        (JSC::MacroAssemblerX86Common::urshift32):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::lshift64):
        (JSC::MacroAssemblerX86_64::rshift64):
        (JSC::MacroAssemblerX86_64::urshift64):
        * b3/testb3.cpp:
        (JSC::B3::testLShiftSelf32):
        (JSC::B3::testRShiftSelf32):
        (JSC::B3::testURShiftSelf32):
        (JSC::B3::testLShiftSelf64):
        (JSC::B3::testRShiftSelf64):
        (JSC::B3::testURShiftSelf64):
        (JSC::B3::run):

2016-02-11  Saam barati  <sbarati@apple.com>

        The sampling profiler's stack walker methods should be marked with SUPPRESS_ASAN
        https://bugs.webkit.org/show_bug.cgi?id=154123

        Reviewed by Mark Lam.

        The entire premise of the sampling profiler is to load from
        another thread's memory. We should SUPPRESS_ASAN on the
        methods that do this.

        * runtime/SamplingProfiler.cpp:
        (JSC::FrameWalker::FrameWalker):
        (JSC::FrameWalker::walk):
        (JSC::FrameWalker::advanceToParentFrame):
        (JSC::FrameWalker::isAtTop):
        (JSC::FrameWalker::resetAtMachineFrame):

2016-02-11  Csaba Osztrogonác  <ossy@webkit.org>

        Unreviewed typo fix after r190063.

        * dfg/DFGSpeculativeJIT.cpp: Removed property svn:executable.
        * dfg/DFGSpeculativeJIT.h: Removed property svn:executable.
        * jit/JIT.h: Removed property svn:executable.
        * jit/JITInlines.h: Removed property svn:executable.
        * jit/JITOpcodes.cpp: Removed property svn:executable.

2016-02-11  Csaba Osztrogonác  <ossy@webkit.org>

        Unreviewed typo fix after r190063.

        * dfg/DFGSpeculativeJIT.cpp: Removed property svn:executable.
        * dfg/DFGSpeculativeJIT.h: Removed property svn:executable.
        * jit/JIT.h: Removed property svn:executable.
        * jit/JITInlines.h: Removed property svn:executable.
        * jit/JITOpcodes.cpp: Removed property svn:executable.

2016-02-10  Keith Miller  <keith_miller@apple.com>

        Symbol.species accessors on builtin constructors should be configurable
        https://bugs.webkit.org/show_bug.cgi?id=154097

        Reviewed by Benjamin Poulain.

        We did not have the Symbol.species accessors on our builtin constructors
        marked as configurable. This does not accurately follow the ES6 spec as
        the ES6 spec states that all default accessors on builtins should be
        configurable. This means that we need an additional watchpoint on
        ArrayConstructor to make sure that no users re-configures Symbol.species.

        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        * runtime/ArrayPrototype.cpp:
        (JSC::speciesConstructArray):
        (JSC::ArrayPrototype::setConstructor):
        (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
        * runtime/ArrayPrototype.h:
        (JSC::ArrayPrototype::didChangeConstructorOrSpeciesProperties):
        (JSC::ArrayPrototype::didChangeConstructorProperty): Deleted.
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::JSArrayBufferConstructor::finishCreation):
        * runtime/JSPromiseConstructor.cpp:
        (JSC::JSPromiseConstructor::finishCreation):
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::JSTypedArrayViewConstructor::finishCreation):
        * runtime/MapConstructor.cpp:
        (JSC::MapConstructor::finishCreation):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::finishCreation):
        * runtime/SetConstructor.cpp:
        (JSC::SetConstructor::finishCreation):
        * tests/stress/array-species-config-array-constructor.js: Added.
        (A):
        * tests/stress/symbol-species.js:
        (testSymbolSpeciesOnConstructor):

2016-02-10  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] The destination of Sqrt should be Def, not UseDef
        https://bugs.webkit.org/show_bug.cgi?id=154086

        Reviewed by Geoffrey Garen.

        An unfortunate copy-paste: the destination of SqrtDouble and SqrtFloat
        was defined as UseDef. As a result, the argument would be interfering
        with everything defined prior.

        * b3/air/AirOpcode.opcodes:

2016-02-10  Chris Dumez  <cdumez@apple.com>

        [Web IDL] interface objects should be Function objects
        https://bugs.webkit.org/show_bug.cgi?id=154038
        <rdar://problem/24569358>

        Reviewed by Geoffrey Garen.

        Update functionProtoFuncToString() to handle JSObjects that
        have the TypeOfShouldCallGetCallData flag and are callable,
        as these behave like functions and use ClassInfo::className()
        as function name in this case.

        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):

2016-02-10  Chris Dumez  <cdumez@apple.com>

        Attributes on the Window instance should be configurable unless [Unforgeable]
        https://bugs.webkit.org/show_bug.cgi?id=153920
        <rdar://problem/24563211>

        Reviewed by Darin Adler.

        Marking the Window instance attributes as configurable but cause
        getOwnPropertyDescriptor() to report them as configurable, as
        expected. However, trying to delete them would actually lead to
        unexpected behavior because:
        - We did not reify custom accessor properties (most of the Window
          properties are custom accessors) upon deletion.
        - For non-reified static properties marked as configurable,
          JSObject::deleteProperty() would attempt to call the property
          setter with undefined. As a result, calling delete window.name
          would cause window.name to become the string "undefined" instead
          of the undefined value.

        * runtime/JSObject.cpp:
        (JSC::getClassPropertyNames):
        Now that we reify ALL properties, we only need to check the property table
        if we have not reified. As a result, I dropped the 'didReify' parameter for
        this function and instead only call this function if we have not yet reified.

        (JSC::JSObject::putInlineSlow):
        Only call putEntry() if we have not reified: Drop the
        '|| !(entry->attributes() & BuiltinOrFunctionOrAccessor)'
        check as such properties now get reified as well.

        (JSC::JSObject::deleteProperty):
        - Call reifyAllStaticProperties() instead of reifyStaticFunctionsForDelete()
          so that we now reify all properties upon deletion, including the custom
          accessors. reifyStaticFunctionsForDelete() is now removed and the same
          reification function is now used by: deletion, getOwnPropertyDescriptor()
          and eager reification of the prototype objects in the bindings.
        - Drop code that falls back to calling the static property setter with
          undefined if we cannot find the property in the property storage. As
          we now reify ALL properties, the code removing the property from the
          property storage should succeed, provided that the property actually
          exists.

        (JSC::JSObject::getOwnNonIndexPropertyNames):
        Only call getClassPropertyNames() if we have not reified. We should no longer
        check the static property table after reifying now that we reify all
        properties.

        (JSC::JSObject::reifyAllStaticProperties):
        Merge with reifyStaticFunctionsForDelete(). The only behavior change is the
        flattening to an uncacheable dictionary, like reifyStaticFunctionsForDelete()
        used to do.

        * runtime/JSObject.h:

2016-02-10  Commit Queue  <commit-queue@webkit.org>

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

        Large regression on Dromaeo needs explanation (Requested by
        kling on #webkit).

        Reverted changeset:

        "Visiting a WeakBlock should report bytes visited, since we
        reported them allocated."
        https://bugs.webkit.org/show_bug.cgi?id=153978
        http://trac.webkit.org/changeset/196251

2016-02-10  Csaba Osztrogonác  <ossy@webkit.org>

        REGRESSION(r196331): It made ~180 JSC tests crash on ARMv7 Linux
        https://bugs.webkit.org/show_bug.cgi?id=154064

        Reviewed by Mark Lam.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generate): Added EABI_32BIT_DUMMY_ARG where it is necessary.
        * dfg/DFGSpeculativeJIT.h: Fixed the comment.
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState): Added.
        * wasm/WASMFunctionCompiler.h: Fixed the comment.

2016-02-09  Keith Miller  <keith_miller@apple.com>

        calling methods off super in a class constructor should check for TDZ
        https://bugs.webkit.org/show_bug.cgi?id=154060

        Reviewed by Ryosuke Niwa.

        In a class constructor we need to check for TDZ when calling a method
        off the super class. This is because, for super method calls, we use
        the derived class's newly constructed object as the super method's
        this value.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionCallDotNode::emitBytecode):
        * tests/stress/super-method-calls-check-tdz.js: Added.
        (Base):
        (Derived):
        (test):

2016-02-09  Filip Pizlo  <fpizlo@apple.com>

        Don't crash if we fail to parse a builtin
        https://bugs.webkit.org/show_bug.cgi?id=154047
        rdar://problem/24300617

        Reviewed by Mark Lam.

        Crashing probably seemed like a good idea at the time, but we could get here in case of a
        near stack overflow, so that the parser bails because of recursion.

        * parser/Parser.h:
        (JSC::parse):

2016-02-07  Gavin Barraclough  <barraclough@apple.com>

        GetValueFunc/PutValueFunc should not take both slotBase and thisValue
        https://bugs.webkit.org/show_bug.cgi?id=154009

        Reviewed by Geoff Garen.

        In JavaScript there are two types of properties - regular value properties, and accessor properties.
        One difference between these is how they are reflected by getOwnPropertyDescriptor, and another is
        what object they operate on in the case of a prototype access. If you access a value property of a
        prototype object it return a value pertinent to the prototype, but in the case of a prototype object
        returning an accessor, then the accessor function is applied to the base object of the access.

        JSC supports special 'custom' properties implemented as a c++ callback, and these custom properties
        can be used to implement either value- or accessor-like behavior. getOwnPropertyDescriptor behavior
        is selected via the CustomAccessor attribute. Value- or accessor-like object selection is current
        supported by passing both the slotBase and the thisValue to the callback,and hoping it uses the
        right one. This is probably inefficient, bug-prone, and leads to crazy like JSBoundSlotBaseFunction.

        Instead, just pass one thisValue to the callback functions, consistent with CustomAccessor.

        * API/JSCallbackObject.h:
        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::getStaticValue):
        (JSC::JSCallbackObject<Parent>::staticFunctionGetter):
        (JSC::JSCallbackObject<Parent>::callbackGetter):
            - Merged slotBase & thisValue to custom property callbacks.
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generate):
            - Modified the call being JIT generated - GetValueFunc/PutValueFunc now only take 3,
              rather than 4 arguments. Selects which one to keep/drop based on access type.
        (WTF::printInternal):
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessCase::isGet):
        (JSC::AccessCase::isPut):
        (JSC::AccessCase::isIn):
        (JSC::AccessCase::doesCalls):
        (JSC::AccessCase::isGetter):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeForStubInfo):
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        (JSC::tryCachePutByID):
            - Split the CustomGetter/Setter access types into Value/Accessor variants.
        * jsc.cpp:
        (WTF::CustomGetter::getOwnPropertySlot):
        (WTF::CustomGetter::customGetter):
        (WTF::RuntimeArray::RuntimeArray):
        (WTF::RuntimeArray::lengthGetter):
            - Merged slotBase & thisValue to custom property callbacks.
        * runtime/CustomGetterSetter.cpp:
        (JSC::callCustomSetter):
            - Pass 3 arguments when calling PutValueFunc.
        * runtime/CustomGetterSetter.h:
        * runtime/JSBoundSlotBaseFunction.cpp:
        (JSC::boundSlotBaseFunctionCall):
        (JSC::JSBoundSlotBaseFunction::JSBoundSlotBaseFunction):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitive):
            - callCustomSetter currently takes a flag to distinguish value/accessor calls.
        * runtime/JSFunction.cpp:
        (JSC::retrieveArguments):
        (JSC::JSFunction::argumentsGetter):
        (JSC::retrieveCallerFunction):
        (JSC::JSFunction::callerGetter):
        (JSC::JSFunction::lengthGetter):
        (JSC::JSFunction::nameGetter):
        * runtime/JSFunction.h:
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::visitChildren):
        (JSC::callbackGetter):
            - Merged slotBase & thisValue to custom property callbacks.
        * runtime/JSObject.cpp:
        (JSC::JSObject::putInlineSlow):
            - callCustomSetter currently takes a flag to distinguish value/accessor calls.
        * runtime/Lookup.h:
        (JSC::putEntry):
            - split PutPropertySlot setCustom into Value/Accessor variants.
        * runtime/PropertySlot.cpp:
        (JSC::PropertySlot::functionGetter):
        (JSC::PropertySlot::customGetter):
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::PropertySlot):
        (JSC::PropertySlot::getValue):
            - added customGetter helper to call GetValueFunc.
        * runtime/PutPropertySlot.h:
        (JSC::PutPropertySlot::PutPropertySlot):
        (JSC::PutPropertySlot::setNewProperty):
        (JSC::PutPropertySlot::setCustomValue):
        (JSC::PutPropertySlot::setCustomAccessor):
        (JSC::PutPropertySlot::setThisValue):
        (JSC::PutPropertySlot::customSetter):
        (JSC::PutPropertySlot::context):
        (JSC::PutPropertySlot::isStrictMode):
        (JSC::PutPropertySlot::isCacheablePut):
        (JSC::PutPropertySlot::isCacheableSetter):
        (JSC::PutPropertySlot::isCacheableCustom):
        (JSC::PutPropertySlot::isCustomAccessor):
        (JSC::PutPropertySlot::isInitialization):
        (JSC::PutPropertySlot::cachedOffset):
        (JSC::PutPropertySlot::setCustomProperty): Deleted.
            - split PutPropertySlot setCustom into Value/Accessor variants.
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::getOwnPropertySlot):
        (JSC::regExpConstructorDollar1):
        (JSC::regExpConstructorDollar2):
        (JSC::regExpConstructorDollar3):
        (JSC::regExpConstructorDollar4):
        (JSC::regExpConstructorDollar5):
        (JSC::regExpConstructorDollar6):
        (JSC::regExpConstructorDollar7):
        (JSC::regExpConstructorDollar8):
        (JSC::regExpConstructorDollar9):
        (JSC::regExpConstructorInput):
        (JSC::regExpConstructorMultiline):
        (JSC::regExpConstructorLastMatch):
        (JSC::regExpConstructorLastParen):
        (JSC::regExpConstructorLeftContext):
        (JSC::regExpConstructorRightContext):
        (JSC::setRegExpConstructorInput):
        (JSC::setRegExpConstructorMultiline):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::defineOwnProperty):
        (JSC::regExpObjectSetLastIndexStrict):
        (JSC::regExpObjectSetLastIndexNonStrict):
        (JSC::RegExpObject::put):
            - Merged slotBase & thisValue to custom property callbacks.

2016-02-09  Filip Pizlo  <fpizlo@apple.com>

        Spread expressions are not fair game for direct binding
        https://bugs.webkit.org/show_bug.cgi?id=154042
        rdar://problem/24291413

        Reviewed by Saam Barati.

        Prior to this change we crashed on this:

            var [x] = [...y];

        Because NodesCodegen thinks that this is a direct binding.  It's not, because we cannot
        directly generate bytecode for "...y".  This is a unique property of spread expressions, so
        its sufficient to just bail out of direct binding if we see a spread expression. That's what
        this patch does.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrayPatternNode::emitDirectBinding):
        * tests/stress/spread-in-tail.js: Added.
        (foo):
        (catch):

2016-02-09  Commit Queue  <commit-queue@webkit.org>

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

        Looks like 5% iOS PLT regression (Requested by kling on
        #webkit).

        Reverted changeset:

        "[iOS] Throw away some unlinked code when navigating to a new
        page."
        https://bugs.webkit.org/show_bug.cgi?id=154014
        http://trac.webkit.org/changeset/196286

2016-02-08  Keith Miller  <keith_miller@apple.com>

        Error construction for inlined operations should not use the inliner's CodeBlock
        https://bugs.webkit.org/show_bug.cgi?id=154021

        Reviewed by Mark Lam.

        Previously, if one function, A, was inlined into another function, B, in the DFG/FTL
        we would use B's DFG/FTL CodeBlock to construct source information about the Error.
        We would correctly compute the bytecodeOffset in A for the an expression but we would
        not use one of A's CodeBlocks when looking up source. This caused crashes during
        operationIn as we expected to be able to find the text "in" in the source.

        * runtime/ErrorInstance.cpp:
        (JSC::appendSourceToError):
        * tests/stress/inlined-error-gets-correct-codeblock-for-bytecodeoffset.js: Added.
        (map):
        (n):
        (one):
        (catch):

2016-02-08  Saam Barati  <sbarati@apple.com>

        runtimeTypeForValue should protect against seeing TDZ value
        https://bugs.webkit.org/show_bug.cgi?id=154023
        rdar://problem/24291413

        Reviewed by Michael Saboff.

        There are a few back traces I've seen from crashes that bottom out
        inside runtimeTypeForValue. I haven't been able to reproduce
        any such crash, but it's likely that we're encountering the
        empty JSValue. It's better to just have this function protect
        against seeing the empty value instead of dereferencing a null
        pointer when it thinks the value is a cell.

        * runtime/RuntimeType.cpp:
        (JSC::runtimeTypeForValue):

2016-02-08  Andreas Kling  <akling@apple.com>

        [iOS] Throw away some unlinked code when navigating to a new page.
        <https://webkit.org/b/154014>

        Reviewed by Gavin Barraclough.

        * runtime/VM.cpp:
        (JSC::VM::deleteAllCodeExceptCaches):
        (JSC::VM::deleteAllLinkedCode): Deleted.
        * runtime/VM.h:

2016-02-08  Filip Pizlo  <fpizlo@apple.com>

        B3::foldPathConstants() needs to execute its insertion set
        https://bugs.webkit.org/show_bug.cgi?id=154020

        Reviewed by Saam Barati.

        * b3/B3FoldPathConstants.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testFoldPathEqual): Added this. It used to crash in validation.
        (JSC::B3::run):

2016-02-08  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Introduce @isObject bytecode intrinsic and use it instead of JS implemented one
        https://bugs.webkit.org/show_bug.cgi?id=153976

        Reviewed by Darin Adler.

        Use bytecode op_is_object directly.

        * builtins/GlobalObject.js:
        (isObject): Deleted.
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_toString):
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_isObject):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Deleted.

2016-02-08  Yusuke Suzuki  <utatane.tea@gmail.com>

        {Map,Set}.prototype.forEach should be visible as own properties
        https://bugs.webkit.org/show_bug.cgi?id=153974

        Reviewed by Darin Adler.

        Now, Map and Set uses builtin tables. We should inlude it in class info.

        * runtime/MapPrototype.cpp:
        * runtime/SetPrototype.cpp:

2016-02-08  Filip Pizlo  <fpizlo@apple.com>

        Baseline JIT should not require its input to be constant-propagated
        https://bugs.webkit.org/show_bug.cgi?id=154011
        rdar://problem/24290933

        Reviewed by Mark Lam.

        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitBitBinaryOpFastPath):
        (JSC::JIT::emitRightShiftFastPath):
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emit_op_div):
        (JSC::JIT::emit_op_mul):

2016-02-08  Filip Pizlo  <fpizlo@apple.com>

        CodeCache should give up on evals if there are variables under TDZ
        https://bugs.webkit.org/show_bug.cgi?id=154002
        rdar://problem/24300998

        Reviewed by Mark Lam.

        Disable the code cache optimization because our approach to TDZ for scoped variables - using
        a separate check_tdz opcode when logically it's the get_from_scope's job to do it - makes
        caching code impossible if there are any variables in TDZ.

        We should do the right thing in the future, and fold the TDZ check into the get_from_scope.
        This is better not only because it will restore caching, but because our bytecode for heap
        accesses is usually at the highest practically doable level of abstraction, so that ICs,
        compilers and caches can see the intended meaning of the bytecode more easily.

        This doesn't appear to slow anything down, but that's just because we don't have enough ES6
        benchmarks. I've filed: https://bugs.webkit.org/show_bug.cgi?id=154010

        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):

2016-02-08  Skachkov Oleksandr  <gskachkov@gmail.com>

        [ES6] Arrow function syntax. Using 'super' in arrow function that declared out of the class should lead to Syntax error
        https://bugs.webkit.org/show_bug.cgi?id=150893

        Reviewed by Saam Barati.

        'super' and 'super()' inside of the arrow function should lead to syntax error if they are used 
        out of the class context or they wrapped by ordinary function. Now JSC returns ReferenceError but 
        should return SyntaxError according to the following specs:
        http://www.ecma-international.org/ecma-262/6.0/#sec-function-definitions-static-semantics-early-errors
        and http://www.ecma-international.org/ecma-262/6.0/#sec-arrow-function-definitions-runtime-semantics-evaluation 
        Curren patch implemented only one case when super/super() are used inside of the arrow function
        Case when super/super() are used within the eval:
           class A {} 
           class B extends A { 
               costructor() { eval("super()");} 
           }
        is not part of this patch and will be implemented in this issue https://bugs.webkit.org/show_bug.cgi?id=153864. 
        The same for case when eval with super/super() is invoked in arrow function will be 
        implemented in issue https://bugs.webkit.org/show_bug.cgi?id=153977. 
 
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::setExpectedSuperBinding):
        (JSC::Scope::expectedSuperBinding):
        (JSC::Scope::setConstructorKind):
        (JSC::Scope::constructorKind):
        (JSC::Parser::closestParentNonArrowFunctionNonLexicalScope):
        * tests/stress/arrowfunction-lexical-bind-supercall-4.js:
        * tests/stress/arrowfunction-lexical-bind-superproperty.js:

2016-02-08  Filip Pizlo  <fpizlo@apple.com>

        Parser should detect error before calls to parseAssignmentExpression()
        https://bugs.webkit.org/show_bug.cgi?id=153975
        rdar://problem/24291231

        Reviewed by Saam Barati.

        Fixes a very hard-to-create situation that an internal test picked up.

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

2016-02-08  Andreas Kling  <akling@apple.com>

        Visiting a WeakBlock should report bytes visited, since we reported them allocated.
        <https://webkit.org/b/153978>

        Reviewed by Darin Adler.

        When creating a WeakBlock, we tell Heap that we've allocated 1 KB (WeakBlock::blockSize)
        of memory. Consequently, when visiting a WeakBlock, we should also report 1 KB of memory
        visited. Otherwise Heap will think that those 1 KB already went away.

        This was causing us to underestimate heap size, which affects collection scheduling.

        * heap/SlotVisitor.h:
        (JSC::SlotVisitor::reportMemoryVisited):
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::visit):

2016-02-07  Saam barati  <sbarati@apple.com>

        Follow up patch to: [ES6] bound functions .name property should be "bound " + the target function's name 
        https://bugs.webkit.org/show_bug.cgi?id=153796

        Reviewed by Darin Adler.

        This follow-up patch addresses some comments/suggestions by
        Ryosuke, Darin, and Joe. It simplifies JSBoundFunction::toStringName
        and adds some tests for bound names.

        * runtime/JSBoundFunction.cpp:
        (JSC::hasInstanceBoundFunction):
        (JSC::JSBoundFunction::create):
        (JSC::JSBoundFunction::toStringName):

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

        String.match should defend against matches that would crash the VM
        https://bugs.webkit.org/show_bug.cgi?id=153964
        rdar://problem/24301119

        Reviewed by Saam Barati.

        This fixes a crash in an internal test case.

        * runtime/ArgList.cpp:
        (JSC::MarkedArgumentBuffer::slowAppend): Use best practices to ensure that the size we
            compute makes sense. Crash if it stops making sense, since most users of this API assume
            that they are creating something small enough to fit on the stack.
        * runtime/ArgList.h:
        (JSC::MarkedArgumentBuffer::~MarkedArgumentBuffer):
        (JSC::MarkedArgumentBuffer::size):
        (JSC::MarkedArgumentBuffer::operator new): Deleted. These were ineffective. According to the
            debugger, we were still calling system malloc. So, I changed the code to use fastMalloc()
            directly.
        (JSC::MarkedArgumentBuffer::operator delete): Deleted.
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncMatch): Explicitly defend against absurd sizes. Of course, it's still
            possible to crash the VM on OOME. That's sort of always been the philosophy of JSC - we
            don't guarantee that you'll get a nice-looking error whenever you run out of memory,
            since in a GC'd environment you can't really guarantee those things. But, if you have a
            match that obvious won't fit in memory, then reporting an error is useful in case this is
            a developer experimenting with a buggy regexp.

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

        [Cocoa] Replace __has_include guards around inclusion of Apple-internal-SDK headers with USE(APPLE_INTERNAL_SDK)
        https://bugs.webkit.org/show_bug.cgi?id=153963

        Reviewed by Sam Weinig.

        * inspector/remote/RemoteInspectorXPCConnection.mm:

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

        FTL must store the call site index before runtime calls, even if it's the tail call slow path
        https://bugs.webkit.org/show_bug.cgi?id=153955
        rdar://problem/24290970

        Reviewed by Saam Barati.

        This is necessary because you could throw an exception in a host call on the tail call's slow
        path. That'll route us to lookupExceptionHandler(), which unwinds starting with the call site
        index of our frame. Bad things happen if it's not set. Prior to this patch it was possible
        for the call site index field to be uninitialized, which meant that the throwing machinery
        was making a wild guess about where we are.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
        * tests/stress/tail-call-host-call-throw.js: Added.

2016-02-06  Darin Adler  <darin@apple.com>

        Finish auditing call sites of upper() and lower(), eliminate many, and rename the functions
        https://bugs.webkit.org/show_bug.cgi?id=153905

        Reviewed by Sam Weinig.

        * runtime/IntlObject.cpp:
        (JSC::canonicalLangTag): Use converToASCIIUppercase on the language tag.

        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncToLowerCase): Tweak style and update for name change.
        (JSC::stringProtoFuncToUpperCase): Ditto.

2016-02-06  Chris Dumez  <cdumez@apple.com>

        Object.getOwnPropertyDescriptor() does not work on sub-frame's window
        https://bugs.webkit.org/show_bug.cgi?id=153925

        Reviewed by Darin Adler.

        Calling Object.getOwnPropertyDescriptor() on a sub-frame's window was
        returning undefined for that window's own properties. The reason was
        that the check getOwnPropertySlot() is using to make sure the
        PropertySlot is not for a property coming from the prototype was wrong.

        The check was checking that 'this != slotBase' which works fine unless
        this is a JSProxy (e.g. JSDOMWindowShell). To handle proxies, the code
        was also checking that 'slotBase.toThis() != this', attempting to
        get the slotBase/Window's proxy. However, due to the implementation of
        toThis(), we were getting the lexical global object's proxy instead of
        slotBase's proxy. To avoid this issue, the new code explicitly checks
        if 'this' is a JSProxy and makes sure 'JSProxy::target() != slotBase',
        instead of using toThis().

        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnPropertyDescriptor):

2016-02-06  Andreas Kling  <akling@apple.com>

        [iOS] Throw away linked code when navigating to a new page.
        <https://webkit.org/b/153851>

        Reviewed by Gavin Barraclough.

        Add a VM API for throwing away linked code only.

        * runtime/VM.cpp:
        (JSC::VM::deleteAllLinkedCode):
        * runtime/VM.h:

2016-02-06  Commit Queue  <commit-queue@webkit.org>

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

        Regressed Speedometer on iOS (Requested by kling on #webkit).

        Reverted changeset:

        "[iOS] Throw away linked code when navigating to a new page."
        https://bugs.webkit.org/show_bug.cgi?id=153851
        http://trac.webkit.org/changeset/196104

2016-02-05  Alex Christensen  <achristensen@webkit.org>

        Fix internal Windows build
        https://bugs.webkit.org/show_bug.cgi?id=153930
        <rdar://problem/24534864>

        Reviewed by Mark Lam.

        * JavaScriptCore.vcxproj/JavaScriptCore.proj:
        I made a typo in r196144.

2016-02-05  Saam barati  <sbarati@apple.com>

        Web Inspector: Include SamplingProfiler's expression-level data for stack frames in the protocol
        https://bugs.webkit.org/show_bug.cgi?id=153455
        <rdar://problem/24335884>

        Reviewed by Joseph Pecoraro.

        We now send the sampling profiler's expression-level
        line/column info in the inspector protocol.

        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::buildSamples):
        * inspector/protocol/ScriptProfiler.json:
        * runtime/SamplingProfiler.h:
        (JSC::SamplingProfiler::StackFrame::hasExpressionInfo):

2016-02-05  Saam barati  <sbarati@apple.com>

        follow-up to: JSC Sampling Profiler: (host) is confusing in cases where I would expect to see JS name
        https://bugs.webkit.org/show_bug.cgi?id=153663
        <rdar://problem/24415092>

        Rubber stamped by Joseph Pecoraro.

        We were performing operations that required us to
        hold the VM lock even when we might not have been holding it.
        We now ensure we're holding it.

        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::trackingComplete):

2016-02-05  Filip Pizlo  <fpizlo@apple.com>

        Arrayify for a typed array shouldn't create a monster
        https://bugs.webkit.org/show_bug.cgi?id=153908
        rdar://problem/24290639

        Reviewed by Mark Lam.

        Previously if you convinced the DFG to emit an Arrayify to ArrayStorage and then gave it a
        typed array, you'd corrupt the object.

        * runtime/JSArrayBufferView.cpp:
        (WTF::printInternal):
        * runtime/JSArrayBufferView.h:
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
        (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
        * runtime/JSObject.cpp:
        (JSC::JSObject::copyButterfly):
        (JSC::JSObject::enterDictionaryIndexingMode):
        (JSC::JSObject::ensureInt32Slow):
        (JSC::JSObject::ensureDoubleSlow):
        (JSC::JSObject::ensureContiguousSlow):
        (JSC::JSObject::ensureArrayStorageSlow):
        (JSC::JSObject::growOutOfLineStorage):
        (JSC::getBoundSlotBaseFunctionForGetterSetter):
        * runtime/Structure.h:
        * tests/stress/arrayify-array-storage-typed-array.js: Added. This test failed.
        * tests/stress/arrayify-int32-typed-array.js: Added. This test case already had other protections, but we beefed them up.

2016-02-04  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: InspectorTimelineAgent doesn't need to recompile functions because it now uses the sampling profiler
        https://bugs.webkit.org/show_bug.cgi?id=153500
        <rdar://problem/24352458>

        Reviewed by Timothy Hatcher.

        Be more explicit about enabling legacy profiling.

        * jsc.cpp:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::hasLegacyProfiler):
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock):
        (JSC::JSGlobalObject::createModuleProgramCodeBlock):
        (JSC::JSGlobalObject::hasProfiler): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::supportsLegacyProfiling):
        (JSC::JSGlobalObject::supportsProfiling): Deleted.

2016-02-04  Keith Miller  <keith_miller@apple.com>

        ArrayPrototype should have a destroy function
        https://bugs.webkit.org/show_bug.cgi?id=153847

        Reviewed by Filip Pizlo.

        ArrayPrototype should have an destroy function as it now has a unique_ptr member that
        needs to be freed at the end of the object's life cycle. Also, this patch adds an
        option, gcAtEnd, that will cause jsc.cpp to do a garbage collection before exiting.

        * jsc.cpp:
        (runJSC):
        (jscmain):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::create):
        (JSC::ArrayPrototype::destroy):
        * runtime/ArrayPrototype.h:
        * runtime/Options.h:

2016-02-04  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(192409): Cannot rely on add32() to zero-extend
        https://bugs.webkit.org/show_bug.cgi?id=153897

        Unreviewed rollout of r192409.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::add32):
        (JSC::MacroAssemblerARM64::add64):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::add32):
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::add32):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::add32):
        (JSC::MacroAssemblerX86Common::add8):
        (JSC::MacroAssemblerX86Common::branchAdd32):
        (JSC::MacroAssemblerX86Common::generateTest32):
        (JSC::MacroAssemblerX86Common::clz32AfterBsr):
        (JSC::MacroAssemblerX86Common::add32AndSetFlags): Deleted.
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::add32):
        (JSC::MacroAssemblerX86_64::add64):
        (JSC::MacroAssemblerX86_64::branchAdd64):
        (JSC::MacroAssemblerX86_64::repatchCall):
        (JSC::MacroAssemblerX86_64::clz64AfterBsr):
        (JSC::MacroAssemblerX86_64::add64AndSetFlags): Deleted.

2016-02-04  Andreas Kling  <akling@apple.com>

        Remove dead ENABLE(BYTECODE_COMMENTS) cruft.
        <https://webkit.org/b/153888>

        Reviewed by Antti Koivisto.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted.
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::shrinkToFit): Deleted.

2016-02-04  Saam barati  <sbarati@apple.com>

        JSC Sampling Profiler: (host) is confusing in cases where I would expect to see JS name
        https://bugs.webkit.org/show_bug.cgi?id=153663
        <rdar://problem/24415092>

        Reviewed by Geoffrey Garen.

        We now collect the Callee in the processed StackFrame
        when the Callee is a valid GC object. We later ask
        the Callee for it's .displayName or .name property.
        When we don't have a valid callee, we will still
        use the Executable for this information.

        This helps us come up with good names for frames where 
        the Callee object is a bound function or an InternalFunction.

        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::addEvent):
        (Inspector::buildSamples):
        (Inspector::InspectorScriptProfilerAgent::trackingComplete):
        * runtime/SamplingProfiler.cpp:
        (JSC::reportStats):
        (JSC::FrameWalker::walk):
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        (JSC::SamplingProfiler::visit):
        (JSC::SamplingProfiler::shutdown):
        (JSC::SamplingProfiler::clearData):
        (JSC::SamplingProfiler::StackFrame::nameFromCallee):
        (JSC::SamplingProfiler::StackFrame::displayName):
        (JSC::SamplingProfiler::StackFrame::displayNameForJSONTests):
        (JSC::SamplingProfiler::stackTracesAsJSON):
        * runtime/SamplingProfiler.h:
        (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
        (JSC::SamplingProfiler::StackFrame::StackFrame):
        * tests/stress/sampling-profiler-basic.js:
        (platformSupportsSamplingProfiler.nothing):
        (platformSupportsSamplingProfiler.top):
        * tests/stress/sampling-profiler-bound-function-name.js: Added.
        (platformSupportsSamplingProfiler.foo):
        (platformSupportsSamplingProfiler.bar):
        (platformSupportsSamplingProfiler.let.baz):
        (platformSupportsSamplingProfiler):
        * tests/stress/sampling-profiler-display-name.js: Added.
        (platformSupportsSamplingProfiler.foo):
        (platformSupportsSamplingProfiler.baz):
        (platformSupportsSamplingProfiler.):
        (platformSupportsSamplingProfiler.bar):
        (platformSupportsSamplingProfiler.jaz):
        (platformSupportsSamplingProfiler.makeFunction.let.result):
        (platformSupportsSamplingProfiler.makeFunction):
        * tests/stress/sampling-profiler-internal-function-name.js: Added.
        (platformSupportsSamplingProfiler.foo):
        (platformSupportsSamplingProfiler.bar):
        (platformSupportsSamplingProfiler):

2016-02-04  Chris Dumez  <cdumez@apple.com>

        Object.getOwnPropertyDescriptor() returns incomplete descriptor for instance properties
        https://bugs.webkit.org/show_bug.cgi?id=153817

        Reviewed by Geoffrey Garen.

        Extend support for Object.getOwnPropertyDescriptor() on native bindings
        to instance properties (e.g. Unforgeable properties or Global object
        properties) so that the returned descriptor has getter / setter
        functions, as expected.

        * runtime/JSObject.cpp:
        (JSC::JSObject::reifyAllStaticProperties):
        Add method that reifies all static properties, including the custom
        accessors. This is similar to what is done eagerly on the prototype
        objects in the bindings code.

        (JSC::JSObject::getOwnPropertyDescriptor):
        getOwnPropertyDescriptor() would previously fails for custom accessors
        that are on the instance because getDirect() does not check the static
        property table and those custom accessors were not reified (We only
        reified all properties eagerly - including custom accessors - on
        prototype objects. To address this issue, we now call
        reifyAllStaticProperties() if the call to getDirect() fails and then
        call getDirect() again. This fix is however insufficient for Window
        properties because |this| is a JSDOMWindowShell / JSProxy in this case
        and getDirect() / reifyAllStaticProperties() would fail as the proxy
        does not actually have the properties. This issue was addressed by
        checking if |this| is a JSProxy and then using JSProxy::target() instead
        of |this| for the calls to getDirect() and for the reification.

        * runtime/JSObject.h:
        * runtime/Lookup.h:
        (JSC::reifyStaticProperty):
        (JSC::reifyStaticProperties):
        Move most code in reifyStaticProperties() to a separate function so the
        code can be shared with JSObject::reifyAllStaticProperties().
        reifyStaticProperties() is currently called by the bindings on the
        prototype objects.

2016-02-04  Alex Christensen  <achristensen@webkit.org>

        Fix internal Windows build
        https://bugs.webkit.org/show_bug.cgi?id=153886
        <rdar://problem/24499887>

        Reviewed by Mark Lam.

        * JavaScriptCore.vcxproj/JavaScriptCore.proj:
        In r190253 I changed the directory of the headers from AppleInternal/include/JavaScriptCore 
        to AppleInternal/include/private/JavaScriptCore.  This is ok for WebCore and WebKit, but not
        other projects, such as CFNetwork, which expect the public API headers to be in the old location.
        This used to be done by a combination of copy-files.cmd and the old JavaScriptCore.proj.
        This change copies all the API headers, which copies everything in copy-files.cmd except APIShims.h
        which does not exist any more.  It copies additional headers that were not copied before, but
        I think this is beneficial so we do not forget to add new public headers to a list of public headers
        to be copied in the internal build.  Having extra public headers in the internal Windows build is
        not a problem because only internal clients use the internal Windows build.

2016-02-03  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Make some classes non JSDestructibleObject
        https://bugs.webkit.org/show_bug.cgi?id=153838

        Reviewed by Geoffrey Garen.

        SymbolPrototype, JSMapIterator and JSSetIterator are trivially destructible.
        So there is no need to inherit JSDestructibleObject.

        * runtime/JSMapIterator.cpp:
        (JSC::JSMapIterator::destroy): Deleted.
        * runtime/JSMapIterator.h:
        * runtime/JSSetIterator.cpp:
        (JSC::JSSetIterator::destroy): Deleted.
        * runtime/JSSetIterator.h:
        * runtime/MapData.h:
        * runtime/SymbolPrototype.h:

2016-02-03  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Symbol structure has unnecessary flags
        https://bugs.webkit.org/show_bug.cgi?id=153840

        Reviewed by Saam Barati.

        * runtime/Symbol.h:
        * tests/stress/symbol-get-own-property.js: Added.
        (shouldBe):

2016-02-03  Andreas Kling  <akling@apple.com>

        [iOS] Throw away linked code when navigating to a new page.
        <https://webkit.org/b/153851>

        Reviewed by Gavin Barraclough.

        Add a VM API for throwing away linked code only.

        * runtime/VM.cpp:
        (JSC::VM::deleteAllLinkedCode):
        * runtime/VM.h:

2016-02-03  Michael Catanzaro  <mcatanzaro@igalia.com>

        [GTK][EFL] Switch FTL to B3
        https://bugs.webkit.org/show_bug.cgi?id=153478

        Reviewed by Csaba Osztrogonác.

        Conditionalize code to make it possible to build FTL completely without LLVM.

        * CMakeLists.txt:
        * dfg/DFGCommon.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * ftl/FTLAbbreviatedTypes.h:
        * ftl/FTLFail.cpp:
        (JSC::FTL::fail):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):
        (JSC::FTL::State::~State):

2016-02-03  Carlos Garcia Campos  <cgarcia@igalia.com>

        Unreviewed. Fix JavaScriptCore build with B3 enabled.

        Include <limits.h> for UINT_MAX.

        * b3/B3StackSlot.h:
        * b3/air/AirStackSlot.h:

2016-02-02  Caitlin Potter  <caitp@igalia.com>

        JSSymbolTableObject::deleteProperty() crashes deleting Symbols
        https://bugs.webkit.org/show_bug.cgi?id=153816

        Reviewed by Darin Adler.

        Changes JSSymbolTableObject::deleteProperty() to check if its
        symbolTable() contains the property's uid() rather than publicName().
        This ensures that it will not crash in the case of Symbols.

        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::deleteProperty):
        * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js:
        (testGlobalProxy):
        * tests/stress/regress-153816.js: Added.
        (deleteSymbolFromJSSymbolTableObject):

2016-02-02  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Do not copy FP when lowering FramePointer
        https://bugs.webkit.org/show_bug.cgi?id=153769

        Reviewed by Michael Saboff.

        That extra move is just wasted time. The fewer Moves we have,
        the happier IRC is.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::tmp):
        (JSC::B3::Air::LowerToAir::lower):

2016-02-02  Keith Miller  <keith_miller@apple.com>

        DFG, FTL, B3, and Air should all have a unique option for printing their graphs
        https://bugs.webkit.org/show_bug.cgi?id=153815

        Reviewed by Benjamin Poulain.

        This patch adds a new printing option for each of the DFG/FTL compilation phases.

        * b3/B3Common.cpp:
        (JSC::B3::shouldDumpIR):
        (JSC::B3::shouldDumpIRAtEachPhase):
        * b3/B3Common.h:
        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir):
        * b3/B3PhaseScope.cpp:
        (JSC::B3::PhaseScope::PhaseScope):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        * b3/air/AirPhaseScope.cpp:
        (JSC::B3::Air::PhaseScope::PhaseScope):
        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::CFAPhase::run):
        * dfg/DFGCommon.h:
        (JSC::DFG::shouldDumpGraphAtEachPhase):
        * dfg/DFGPhase.cpp:
        (JSC::DFG::Phase::beginPhase):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:

2016-02-02  Caitlin Potter  <caitp@igalia.com>

        [JSC] make Object.getOwnPropertyDescriptors() work with non-JSObject types
        https://bugs.webkit.org/show_bug.cgi?id=153814

        Reviewed by Yusuke Suzuki.

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetOwnPropertyDescriptors):
        * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js:
        (testGlobalProxy):

2016-02-02  Aakash Jain  <aakash_jain@apple.com>

        Remove references to CallFrameInlines.h
        https://bugs.webkit.org/show_bug.cgi?id=153810

        Reviewed by Mark Lam.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:

2016-02-02  Caitlin Potter  <caitp@igalia.com>

        [JSC] Implement Object.getOwnPropertyDescriptors() proposal
        https://bugs.webkit.org/show_bug.cgi?id=153799

        Reviewed by Darin Adler.

        Implements the Object.getOwnPropertyDescriptors() proposal, which
        reached Stage 3 in the TC39 process in January 2016.
        https://github.com/tc39/proposal-object-getownpropertydescriptors

        The method extracts a set of property descriptor objects, which can
        be safely used via `Object.create()`.

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetOwnPropertyDescriptors):

2016-02-02  Filip Pizlo  <fpizlo@apple.com>

        B3 should be able to compile trivial self-loops
        https://bugs.webkit.org/show_bug.cgi?id=153802
        rdar://problem/24465632

        Reviewed by Michael Saboff.

        Tail-duplicating a self-loop would mean doing a kind of loop unrolling. It wouldn't be
        profitable even if it did work. It turns out that it doesn't work, because we edit the target
        block before reading the source block, which breaks if the target and source block are the
        same.

        This disables tail duplication of self-loops, adds a test, and adds better validation for this
        issue.

        * b3/B3DuplicateTails.cpp:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::resetReachability):
        * b3/testb3.cpp:
        (JSC::B3::testComputeDivisionMagic):
        (JSC::B3::testTrivialInfiniteLoop):
        (JSC::B3::zero):
        (JSC::B3::run):

2016-02-02  Saam barati  <sbarati@apple.com>

        [ES6] bound functions .name property should be "bound " + the target function's name
        https://bugs.webkit.org/show_bug.cgi?id=153796

        Reviewed by Mark Lam.

        See http://tc39.github.io/ecma262/#sec-function.prototype.bind for details.
        What the spec says:
        ```
        function foo() { }
        foo.bind(null).name === "bound foo"

        (function bar() { }).bind(null).name === "bound bar"
        ```

        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):
        * runtime/JSBoundFunction.cpp:
        (JSC::hasInstanceBoundFunction):
        (JSC::JSBoundFunction::create):
        (JSC::JSBoundFunction::visitChildren):
        (JSC::JSBoundFunction::toStringName):
        * runtime/JSBoundFunction.h:
        (JSC::JSBoundFunction::boundThis):
        (JSC::JSBoundFunction::boundArgs):
        (JSC::JSBoundFunction::createStructure):
        * tests/es6.yaml:

2016-02-02  Filip Pizlo  <fpizlo@apple.com>

        Get rid of anonymous stack slots
        https://bugs.webkit.org/show_bug.cgi?id=151128

        Reviewed by Mark Lam.

        When I first designed stack slots, the idea was that an "anonymous" stack slot was one that
        behaved exactly like a C variable: if it never escaped, it would not need to get stack space
        for the entire lifetime of the function - it could get any slab of stack so long as it
        didn't interfere with other stack slots that would be live at the same time. The reason I
        called them "anonymous" is that external code could not get its address. This felt like it
        gave the stack slot anonymity. But it was never a good name for this concept.

        Then I had the register allocator lower temporaries to anonymous stack slots when it spilled
        them. Spilling became the sole client of anonymous stack slots.

        Then I realized that there was an aspect of how spill slots work that make them want
        slightly different semantics than a normal C variable. A C variable is a proper memory
        location - you could do a store to only some bytes in the variable, and it's reasonable to
        expect that this will not destroy the other bytes in the variable. But that means that to
        compute their liveness, you have to do something like a per-byte liveness. That's overkill
        for spill slots. You want any store to the spill slot to kill the whole slot even if it
        writes to just part of the slot. This matches how temporaries work. So rather than implement
        per-byte liveness, I decided to change the semantics of anonymous stack slots to make them
        work like how I wanted spill slots to work. This was quite dirty, and put B3 in the awkward
        situation that B3's anonymous stack slots behaved like spill slots. But it was OK since
        nobody used anonymous stack slots in B3.

        Then I added tail duplication, which required having a mechanism for introducing non-SSA
        variables in B3. I decided to use anonymous stack slots for this purpose. All of a sudden
        this all felt like it made sense: anonymous stack slots were just like variables! Hooray for
        the amazing foresight of anonymous stack slots!

        But then I realized that this was all very bad. We want B3 to be able to optimize Store and
        Load operations by reasoning about how they affect bytes in memory. For example, if you do
        a Load of a 64-bit value, and then you modify just the low 32 bits of that value, and then
        you do a 64-bit store back to the same location, then it would be better to transform this
        into 32-bit operations. We don't do this optimization yet, but it's the kind of thing that
        we want B3 to be able to do. To do it, we need Store to mean that it only affects N bytes
        starting at the pointer, where N is the size of the thing being stored. But that's not what
        Store means for anonymous stack slots. For anonymous slots, storing to any byte in the slot
        clobbers all bytes in the slot. We were never clear if you need to store directly to an
        anonymous slot to get this behavior, or if any pointer that points to an anoymous slot must
        exhibit this behavior when stored to. Neither kinds of semantics make sense to me.

        This change fixes the problem by eradicating anonymous stack slots. In B3, they are replaced
        with Variables. In Air, they are replaced with a different stack slot kind, called Spill.
        There is no such thing as stack slot kinds in B3 anymore, all B3 stack slots are locked. In
        Air, there is still the concept of stack slot kind - Locked or Spill.

        B3 Variables are awesome. They are exactly what they seem to be. They have a type. They are
        declared at the top level in the Procedure. You can access them with new opcodes, Get and
        Set. This greatly simplifies demoting SSA values to variables and promoting them back to
        SSA. I even made the instruction selector do the right things for variables, which means
        that introducing variables won't hurt instruction selection (there will be extra moves, but
        IRC will kill them). It's great to have non-SSA variables as an explicit concept in IR
        because it means that you don't have to do any magic to use them - they Just Work.

        Air spill slots behave almost like anonymous stack slots, with one exception: you cannot
        escape them. We validate this by making it illegal to UseAddr on a spill slot. This removes
        the need to answer awkward questions like: does a 32-bit Def on a pointer that may point to
        a 64-bit spill slot do anything to the 32 bits above the pointer?  Does it write zero to it?
        Does it write zero to it just when the pointer actually points to a spill slot or always?
        These are silly questions, and we don't have to answer them because the only way to refer to
        a spill slot is directly. No escaping means no aliasing.

        This doesn't affect performance. It just makes the compiler more fun to work with by
        removing some cognitive dissonance.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3ArgumentRegValue.h:
        * b3/B3CCallValue.h:
        * b3/B3CheckValue.cpp:
        (JSC::B3::CheckValue::cloneImpl):
        (JSC::B3::CheckValue::CheckValue):
        * b3/B3CheckValue.h:
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.h:
        * b3/B3ConstDoubleValue.h:
        * b3/B3ConstFloatValue.h:
        * b3/B3ConstPtrValue.h:
        (JSC::B3::ConstPtrValue::ConstPtrValue):
        * b3/B3ControlValue.cpp:
        (JSC::B3::ControlValue::convertToJump):
        (JSC::B3::ControlValue::convertToOops):
        (JSC::B3::ControlValue::dumpMeta):
        * b3/B3ControlValue.h:
        * b3/B3Effects.cpp:
        (JSC::B3::Effects::interferes):
        (JSC::B3::Effects::dump):
        * b3/B3Effects.h:
        (JSC::B3::Effects::mustExecute):
        * b3/B3EliminateCommonSubexpressions.cpp:
        * b3/B3FixSSA.cpp:
        (JSC::B3::demoteValues):
        (JSC::B3::fixSSA):
        * b3/B3FixSSA.h:
        * b3/B3IndexMap.h:
        (JSC::B3::IndexMap::resize):
        (JSC::B3::IndexMap::clear):
        (JSC::B3::IndexMap::size):
        (JSC::B3::IndexMap::operator[]):
        * b3/B3IndexSet.h:
        (JSC::B3::IndexSet::contains):
        (JSC::B3::IndexSet::size):
        (JSC::B3::IndexSet::isEmpty):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3MemoryValue.h:
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3PatchpointValue.cpp:
        (JSC::B3::PatchpointValue::cloneImpl):
        (JSC::B3::PatchpointValue::PatchpointValue):
        * b3/B3PatchpointValue.h:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::Procedure):
        (JSC::B3::Procedure::addBlock):
        (JSC::B3::Procedure::addStackSlot):
        (JSC::B3::Procedure::addVariable):
        (JSC::B3::Procedure::clone):
        (JSC::B3::Procedure::addIntConstant):
        (JSC::B3::Procedure::dump):
        (JSC::B3::Procedure::deleteStackSlot):
        (JSC::B3::Procedure::deleteVariable):
        (JSC::B3::Procedure::deleteValue):
        (JSC::B3::Procedure::deleteOrphans):
        (JSC::B3::Procedure::calleeSaveRegisters):
        (JSC::B3::Procedure::addValueImpl):
        (JSC::B3::Procedure::setBlockOrderImpl):
        (JSC::B3::Procedure::addAnonymousStackSlot): Deleted.
        (JSC::B3::Procedure::addStackSlotIndex): Deleted.
        (JSC::B3::Procedure::addValueIndex): Deleted.
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::setBlockOrder):
        (JSC::B3::Procedure::stackSlots):
        (JSC::B3::Procedure::variables):
        (JSC::B3::Procedure::values):
        (JSC::B3::Procedure::StackSlotsCollection::StackSlotsCollection): Deleted.
        (JSC::B3::Procedure::StackSlotsCollection::size): Deleted.
        (JSC::B3::Procedure::StackSlotsCollection::at): Deleted.
        (JSC::B3::Procedure::StackSlotsCollection::operator[]): Deleted.
        (JSC::B3::Procedure::StackSlotsCollection::iterator::iterator): Deleted.
        (JSC::B3::Procedure::StackSlotsCollection::iterator::operator*): Deleted.
        (JSC::B3::Procedure::StackSlotsCollection::iterator::operator++): Deleted.
        (JSC::B3::Procedure::StackSlotsCollection::iterator::operator==): Deleted.
        (JSC::B3::Procedure::StackSlotsCollection::iterator::operator!=): Deleted.
        (JSC::B3::Procedure::StackSlotsCollection::iterator::findNext): Deleted.
        (JSC::B3::Procedure::StackSlotsCollection::begin): Deleted.
        (JSC::B3::Procedure::StackSlotsCollection::end): Deleted.
        (JSC::B3::Procedure::ValuesCollection::ValuesCollection): Deleted.
        (JSC::B3::Procedure::ValuesCollection::iterator::iterator): Deleted.
        (JSC::B3::Procedure::ValuesCollection::iterator::operator*): Deleted.
        (JSC::B3::Procedure::ValuesCollection::iterator::operator++): Deleted.
        (JSC::B3::Procedure::ValuesCollection::iterator::operator==): Deleted.
        (JSC::B3::Procedure::ValuesCollection::iterator::operator!=): Deleted.
        (JSC::B3::Procedure::ValuesCollection::iterator::findNext): Deleted.
        (JSC::B3::Procedure::ValuesCollection::begin): Deleted.
        (JSC::B3::Procedure::ValuesCollection::end): Deleted.
        (JSC::B3::Procedure::ValuesCollection::size): Deleted.
        (JSC::B3::Procedure::ValuesCollection::at): Deleted.
        (JSC::B3::Procedure::ValuesCollection::operator[]): Deleted.
        * b3/B3ProcedureInlines.h:
        (JSC::B3::Procedure::add):
        * b3/B3ReduceStrength.cpp:
        * b3/B3SlotBaseValue.h:
        * b3/B3SparseCollection.h: Added.
        (JSC::B3::SparseCollection::SparseCollection):
        (JSC::B3::SparseCollection::add):
        (JSC::B3::SparseCollection::addNew):
        (JSC::B3::SparseCollection::remove):
        (JSC::B3::SparseCollection::size):
        (JSC::B3::SparseCollection::isEmpty):
        (JSC::B3::SparseCollection::at):
        (JSC::B3::SparseCollection::operator[]):
        (JSC::B3::SparseCollection::iterator::iterator):
        (JSC::B3::SparseCollection::iterator::operator*):
        (JSC::B3::SparseCollection::iterator::operator++):
        (JSC::B3::SparseCollection::iterator::operator==):
        (JSC::B3::SparseCollection::iterator::operator!=):
        (JSC::B3::SparseCollection::iterator::findNext):
        (JSC::B3::SparseCollection::begin):
        (JSC::B3::SparseCollection::end):
        * b3/B3StackSlot.cpp:
        (JSC::B3::StackSlot::deepDump):
        (JSC::B3::StackSlot::StackSlot):
        * b3/B3StackSlot.h:
        (JSC::B3::StackSlot::byteSize):
        (JSC::B3::StackSlot::index):
        (JSC::B3::StackSlot::setOffsetFromFP):
        (JSC::B3::StackSlot::kind): Deleted.
        (JSC::B3::StackSlot::isLocked): Deleted.
        * b3/B3StackSlotKind.cpp: Removed.
        * b3/B3StackSlotKind.h: Removed.
        * b3/B3StackmapValue.cpp:
        (JSC::B3::StackmapValue::dumpMeta):
        (JSC::B3::StackmapValue::StackmapValue):
        * b3/B3StackmapValue.h:
        * b3/B3SwitchValue.cpp:
        (JSC::B3::SwitchValue::cloneImpl):
        (JSC::B3::SwitchValue::SwitchValue):
        * b3/B3SwitchValue.h:
        * b3/B3UpsilonValue.h:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::replaceWithIdentity):
        (JSC::B3::Value::replaceWithNop):
        (JSC::B3::Value::replaceWithPhi):
        (JSC::B3::Value::dump):
        (JSC::B3::Value::effects):
        (JSC::B3::Value::checkOpcode):
        * b3/B3Value.h:
        * b3/B3Variable.cpp: Added.
        (JSC::B3::Variable::~Variable):
        (JSC::B3::Variable::dump):
        (JSC::B3::Variable::deepDump):
        (JSC::B3::Variable::Variable):
        * b3/B3Variable.h: Added.
        (JSC::B3::Variable::type):
        (JSC::B3::Variable::index):
        (JSC::B3::DeepVariableDump::DeepVariableDump):
        (JSC::B3::DeepVariableDump::dump):
        (JSC::B3::deepDump):
        * b3/B3VariableValue.cpp: Added.
        (JSC::B3::VariableValue::~VariableValue):
        (JSC::B3::VariableValue::dumpMeta):
        (JSC::B3::VariableValue::cloneImpl):
        (JSC::B3::VariableValue::VariableValue):
        * b3/B3VariableValue.h: Added.
        * b3/air/AirAllocateStack.cpp:
        (JSC::B3::Air::allocateStack):
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::addStackSlot):
        (JSC::B3::Air::Code::addSpecial):
        (JSC::B3::Air::Code::cCallSpecial):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::begin):
        (JSC::B3::Air::Code::end):
        (JSC::B3::Air::Code::stackSlots):
        (JSC::B3::Air::Code::specials):
        (JSC::B3::Air::Code::forAllTmps):
        (JSC::B3::Air::Code::StackSlotsCollection::StackSlotsCollection): Deleted.
        (JSC::B3::Air::Code::StackSlotsCollection::size): Deleted.
        (JSC::B3::Air::Code::StackSlotsCollection::at): Deleted.
        (JSC::B3::Air::Code::StackSlotsCollection::operator[]): Deleted.
        (JSC::B3::Air::Code::StackSlotsCollection::iterator::iterator): Deleted.
        (JSC::B3::Air::Code::StackSlotsCollection::iterator::operator*): Deleted.
        (JSC::B3::Air::Code::StackSlotsCollection::iterator::operator++): Deleted.
        (JSC::B3::Air::Code::StackSlotsCollection::iterator::operator==): Deleted.
        (JSC::B3::Air::Code::StackSlotsCollection::iterator::operator!=): Deleted.
        (JSC::B3::Air::Code::StackSlotsCollection::begin): Deleted.
        (JSC::B3::Air::Code::StackSlotsCollection::end): Deleted.
        (JSC::B3::Air::Code::SpecialsCollection::SpecialsCollection): Deleted.
        (JSC::B3::Air::Code::SpecialsCollection::size): Deleted.
        (JSC::B3::Air::Code::SpecialsCollection::at): Deleted.
        (JSC::B3::Air::Code::SpecialsCollection::operator[]): Deleted.
        (JSC::B3::Air::Code::SpecialsCollection::iterator::iterator): Deleted.
        (JSC::B3::Air::Code::SpecialsCollection::iterator::operator*): Deleted.
        (JSC::B3::Air::Code::SpecialsCollection::iterator::operator++): Deleted.
        (JSC::B3::Air::Code::SpecialsCollection::iterator::operator==): Deleted.
        (JSC::B3::Air::Code::SpecialsCollection::iterator::operator!=): Deleted.
        (JSC::B3::Air::Code::SpecialsCollection::begin): Deleted.
        (JSC::B3::Air::Code::SpecialsCollection::end): Deleted.
        * b3/air/AirFixObviousSpills.cpp:
        * b3/air/AirInstInlines.h:
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * b3/air/AirLiveness.h:
        * b3/air/AirLowerAfterRegAlloc.cpp:
        (JSC::B3::Air::lowerAfterRegAlloc):
        * b3/air/AirSpecial.cpp:
        (JSC::B3::Air::Special::Special):
        * b3/air/AirSpecial.h:
        * b3/air/AirSpillEverything.cpp:
        (JSC::B3::Air::spillEverything):
        * b3/air/AirStackSlot.cpp:
        (JSC::B3::Air::StackSlot::dump):
        (JSC::B3::Air::StackSlot::deepDump):
        (JSC::B3::Air::StackSlot::StackSlot):
        * b3/air/AirStackSlot.h:
        (JSC::B3::Air::StackSlot::byteSize):
        (JSC::B3::Air::StackSlot::kind):
        (JSC::B3::Air::StackSlot::isLocked):
        (JSC::B3::Air::StackSlot::isSpill):
        (JSC::B3::Air::StackSlot::index):
        (JSC::B3::Air::StackSlot::ensureSize):
        * b3/air/AirStackSlotKind.cpp: Copied from Source/JavaScriptCore/b3/B3StackSlotKind.cpp.
        (WTF::printInternal):
        * b3/air/AirStackSlotKind.h: Copied from Source/JavaScriptCore/b3/B3StackSlotKind.h.
        * b3/air/opcode_generator.rb:
        * b3/air/testair.cpp:
        (JSC::B3::Air::testShuffleBroadcastAllRegs):
        (JSC::B3::Air::testShuffleShiftAllRegs):
        (JSC::B3::Air::testShuffleRotateAllRegs):
        * b3/testb3.cpp:
        (JSC::B3::testStackSlot):
        (JSC::B3::testStoreLoadStackSlot):
        * ftl/FTLB3Output.cpp:
        (JSC::FTL::Output::lockedStackSlot):
        (JSC::FTL::Output::neg):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):

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

        [JSC] Introduce BytecodeIntrinsic constant rep like @undefined
        https://bugs.webkit.org/show_bug.cgi?id=153737

        Reviewed by Darin Adler.

        This patch enhances existing BytecodeIntrinsic mechanism to accept `@xxx` form,
        that will be used to represent bytecode intrinsic constants.
        After this change, we can use 2 forms for bytecode intrinsics. (1) Function form (like, @toString(value))
        and (2) Constant form (like @undefined).

        Bytecode intrinsic constants allow us to easily expose constant values from C++ world.
        For example, we can expose ArrayIterationKind flags to JS world without using private global variables.
        Exposed constant values are loaded from bytecodes directly through constant registers.
        While previously we expose them through private global variables, bytecode intrinsic constants
        can be loaded directly from CodeBlock. And later, it will become JSConstant in DFG.

        And by using this mechanism, we implement several constants. @undefined, @arrayIterationKindKeyValue etc.

        * builtins/ArrayConstructor.js:
        (from):
        * builtins/ArrayIteratorPrototype.js:
        (next):
        * builtins/ArrayPrototype.js:
        (reduce):
        (reduceRight):
        (every):
        (forEach):
        (filter):
        (map):
        (some):
        (fill):
        (find):
        (findIndex):
        (includes):
        (sort.compactSparse):
        (sort.compactSlow):
        (sort.compact):
        (sort):
        (copyWithin):
        * builtins/DatePrototype.js:
        (toLocaleString.toDateTimeOptionsAnyAll):
        (toLocaleString):
        (toLocaleDateString.toDateTimeOptionsDateDate):
        (toLocaleDateString):
        (toLocaleTimeString.toDateTimeOptionsTimeTime):
        (toLocaleTimeString):
        * builtins/GeneratorPrototype.js:
        (generatorResume):
        * builtins/GlobalObject.js:
        (isDictionary):
        * builtins/InternalPromiseConstructor.js:
        (internalAll.newResolveElement):
        (internalAll):
        * builtins/IteratorPrototype.js:
        (symbolIteratorGetter):
        (symbolIterator): Deleted.
        * builtins/MapPrototype.js:
        (forEach):
        * builtins/ModuleLoaderObject.js:
        (newRegistryEntry):
        (forceFulfillPromise):
        (commitInstantiated):
        (requestFetch):
        (requestTranslate):
        (requestInstantiate):
        (requestLink):
        (provide):
        * builtins/PromiseConstructor.js:
        (all.newResolveElement):
        (all):
        (race):
        (reject):
        (resolve):
        * builtins/PromiseOperations.js:
        (newPromiseCapability.executor):
        (newPromiseCapability):
        (rejectPromise):
        (fulfillPromise):
        (createResolvingFunctions.resolve):
        (createResolvingFunctions.reject):
        (createResolvingFunctions):
        (promiseReactionJob):
        (promiseResolveThenableJob):
        (initializePromise):
        * builtins/PromisePrototype.js:
        (catch):
        (then):
        * builtins/SetPrototype.js:
        (forEach):
        * builtins/StringConstructor.js:
        (raw):
        * builtins/StringIteratorPrototype.js:
        (next):
        * builtins/StringPrototype.js:
        (localeCompare):
        * builtins/TypedArrayConstructor.js:
        (of):
        (from):
        * builtins/TypedArrayPrototype.js:
        (every):
        (find):
        (findIndex):
        (forEach):
        (some):
        (reduce):
        (reduceRight):
        (map):
        (filter):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        (JSC::BytecodeIntrinsicRegistry::lookup):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecompiler/NodesCodegen.cpp:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createResolve):
        (JSC::ASTBuilder::makeFunctionCallNode):
        * parser/NodeConstructors.h:
        (JSC::BytecodeIntrinsicNode::BytecodeIntrinsicNode):
        * parser/Nodes.h:
        (JSC::ExpressionNode::isBytecodeIntrinsicNode):
        (JSC::BytecodeIntrinsicNode::type):
        (JSC::BytecodeIntrinsicNode::emitter):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createResolve):
        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::CommonIdentifiers): Deleted.
        * runtime/CommonIdentifiers.h:
        (JSC::CommonIdentifiers::bytecodeIntrinsicRegistry): Deleted.
        * runtime/IteratorPrototype.cpp:
        (JSC::IteratorPrototype::finishCreation):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        (JSC::VM::bytecodeIntrinsicRegistry):

2016-02-02  Per Arne Vollan  <peavo@outlook.com>

        [B3][Win64] Compile fixes.
        https://bugs.webkit.org/show_bug.cgi?id=153605

        Reviewed by Filip Pizlo.

        Fix remaining compile errors on Win64.

        * CMakeLists.txt:
        * b3/B3CFG.h:
        (JSC::B3::CFG::newMap):
        * ftl/FTLJITCode.h:

2016-02-01  Chris Dumez  <cdumez@apple.com>

        object.__lookupGetter__() / object.__lookupSetter__() does not work for native bindings
        https://bugs.webkit.org/show_bug.cgi?id=153765
        <rdar://problem/24439699>

        Reviewed by Oliver Hunt.

        Add support for CustomAccessor slots to objectProtoFuncLookupGetter() and
        objectProtoFuncLookupSetter() by return getOwnPropertyDescriptor().get / set.
        getOwnPropertyDescriptor() now correctly deals with CustomAccessors since
        r196001.

        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncLookupGetter):
        (JSC::objectProtoFuncLookupSetter):

2016-02-01  Chris Dumez  <cdumez@apple.com>

        Native Bindings Descriptors are Incomplete
        https://bugs.webkit.org/show_bug.cgi?id=140575
        <rdar://problem/19506502>

        Reviewed by Oliver Hunt.

        This patch is based on initial work by Joe Pecoraro and Matthew Mirman.

        This patch was initially rolled out for breaking chromeexperiments.com,
        presumably because our IDL attributes were not marked as [configurable]
        at the time. However, since r190104, our IDL attributes are now
        configurable. Based on local testing, chromeexperiments.com seems to be
        working fine now.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/InjectedScriptSource.js:
        (endsWith):
        (InjectedScript.prototype.processProperties):
        * runtime/JSBoundSlotBaseFunction.cpp: Added.
        (JSC::boundSlotBaseFunctionCall):
        (JSC::JSBoundSlotBaseFunction::JSBoundSlotBaseFunction):
        (JSC::JSBoundSlotBaseFunction::create):
        (JSC::JSBoundSlotBaseFunction::visitChildren):
        (JSC::JSBoundSlotBaseFunction::finishCreation):
        * runtime/JSBoundSlotBaseFunction.h: Added.
        (JSC::JSBoundSlotBaseFunction::createStructure):
        (JSC::JSBoundSlotBaseFunction::boundSlotBase):
        (JSC::JSBoundSlotBaseFunction::customGetterSetter):
        (JSC::JSBoundSlotBaseFunction::isSetter):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::boundSlotBaseFunctionStructure):
        * runtime/JSObject.cpp:
        (JSC::getBoundSlotBaseFunctionForGetterSetter):
        (JSC::JSObject::getOwnPropertyDescriptor):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2016-02-01  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: High Level Memory Overview Instrument
        https://bugs.webkit.org/show_bug.cgi?id=153516
        <rdar://problem/24356378>

        Reviewed by Brian Burg.

        * CMakeLists.txt:
        * Configurations/FeatureDefines.xcconfig:
        * DerivedSources.make:
        * inspector/protocol/Memory.json: Added.
        * inspector/scripts/codegen/generator.py:
        New Memory domain guarded by ENABLE(RESOURCE_USAGE).
        This feature flag was already used in WebCore.

2016-02-01  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] IRC can coalesce the frame pointer with a Tmp that is modified
        https://bugs.webkit.org/show_bug.cgi?id=153694

        Reviewed by Filip Pizlo.

        Let's say we have:
            Move(FP, Tmp1)
            Add64(#1, Tmp1)

        If we were to coalesce the Move, we would modify the frame pointer.
        Well, that's exactly what was happening with IRC.

        Since the epilogue is not know to Air before IRC, the liveness analysis
        never discovers that FP is live when Tmp1 is UseDef by Add64. Adding
        FP would a be a problem anyway for a bunch of reasons.

        I tried two ways to prevent IRC to override IRC:
        1) Add an interference edge with FP for all non-duplication Defs.
        2) Let coalesce() know about FP and constraint any coalescing with a re-Def.

        The two are within margin of error for performance. The second one was considerably
        more complicated. This patch implements the first one.

        Some extra note:
        -It is very important to not increment the degree of a Tmp when making it interfere
         with FP. FP is not a valid color, it is not counted in the "K" colors considered
         for coloring. Increasing the degree with the edge to FP would make every stage
         pessimistic since there is an extra degree that can never be removed.
        -I put "interferenceEdges" and "adjacencyList" in an inconsistent state.
         This is intentional, "interferenceEdges" is used to test the existence of an edge,
         "adjacencyList" is used to go over all the edges. In this case, we don't want
         the edge with FP to be considered when pruning the graph.

        * b3/air/AirIteratedRegisterCoalescing.cpp:
        One branch could be transformed into an assertion: TmpLiveness is type specific now.
        * b3/testb3.cpp:
        (JSC::B3::testOverrideFramePointer):
        (JSC::B3::run):

2016-02-01  Csaba Osztrogonác  <ossy@webkit.org>

        Unreviewed speculative buildfix.

        * dfg/DFGCommon.h: FTL_USES_B3 should be false if FTL JIT is disabled.

2016-01-31  Dan Bernstein  <mitz@apple.com>

        [Cocoa] Remove unused definition of HAVE_HEADER_DETECTION_H
        https://bugs.webkit.org/show_bug.cgi?id=153729

        Reviewed by Sam Weinig.

        After r141700, HAVE_HEADER_DETECTION_H is no longer used.

        * Configurations/Base.xcconfig:

2016-01-30  Filip Pizlo  <fpizlo@apple.com>

        B3->Air lowering should use MoveFloat more
        https://bugs.webkit.org/show_bug.cgi?id=153714

        Reviewed by Sam Weinig.

        This is a very minor and benign bug. It just means that we will use the more canonical
        MoveFloat instruction when moving floats, rather than using MoveDouble.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::relaxedMoveForType):

2016-01-31  Yusuke Suzuki  <utatane.tea@gmail.com>

        Should not predict OtherObj for ToThis with primitive types under strict mode
        https://bugs.webkit.org/show_bug.cgi?id=153544

        Reviewed by Filip Pizlo.

        Currently, ToThis predicates OtherObj for primitive values.
        But it's not true in strict mode.
        In strict mode, ToThis does nothing on primitive values.

        In this patch, we

        1. fix prediction. Handles primitive types in strict mode. And we also handles StringObject.
        2. convert it to Identity if the argument should be predicted as primitive types.

        This optimization is important to implement Primitive.prototype.methods[1].
        Otherwise, we always got BadType OSR exits.

        [1]: https://bugs.webkit.org/show_bug.cgi?id=143889

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupToThis):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * tests/stress/to-this-boolean.js: Added.
        (Boolean.prototype.negate):
        (Boolean.prototype.negate2):
        * tests/stress/to-this-double.js: Added.
        (Number.prototype.negate):
        * tests/stress/to-this-int32.js: Added.
        (Number.prototype.negate):
        * tests/stress/to-this-int52.js: Added.
        (Number.prototype.negate):
        * tests/stress/to-this-number.js: Added.
        (Number.prototype.negate):
        * tests/stress/to-this-string.js: Added.
        (String.prototype.prefix):
        (String.prototype.first):
        (String.prototype.second):
        * tests/stress/to-this-symbol.js: Added.
        (Symbol.prototype.identity):
        (Symbol.prototype.identity2):

2016-01-31  Guillaume Emont  <guijemont@igalia.com>

        [mips] don't save to a callee saved register too early
        https://bugs.webkit.org/show_bug.cgi?id=153463

        If we save $gp to $s4 in pichdr, then in some cases, we were
        overwriting $s4 before LLInt's pushCalleeSaves() is called (as pichdr
        is at the very beginning of a function). Now we save $gp to $s4 at the
        end of pushCalleeSaves().

        Reviewed by Michael Saboff.

        * offlineasm/mips.rb:
        * llint/LowLevelInterpreter.asm:
        Move the saving of $gp to $s4 from pichdr to pushCalleeSaves(). Take
        the opportunity to only save $s4 as we never use the other callee
        saved registers.

2016-01-30  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r195799 and r195828.
        https://bugs.webkit.org/show_bug.cgi?id=153722

        Caused assertion failures, severely affecting EWS (Requested
        by ap on #webkit).

        Reverted changesets:

        "Web Inspector: InspectorTimelineAgent doesn't need to
        recompile functions because it now uses the sampling profiler"
        https://bugs.webkit.org/show_bug.cgi?id=153500
        http://trac.webkit.org/changeset/195799

        "Attempt to fix the Windows build after r195799"
        http://trac.webkit.org/changeset/195828

2016-01-30  Yusuke Suzuki  <utatane.tea@gmail.com>

        [B3] JetStream/quicksort.c fails/hangs on Linux with GCC
        https://bugs.webkit.org/show_bug.cgi?id=153647

        Reviewed by Filip Pizlo.

        In B3ComputeDivisionMagic, we accidentally perform sub, add operation onto signed integer. (In this case, int32_t)
        But integer overflow is undefined behavior in C![1][2]
        As a result, in GCC 4.9 release build, computeDivisionMagic(2) returns unexpected value.
        `divisor = 2`
        `d = 2`
        `signedMin = INT32_MIN = -2147483647 (-0x7fffffff)`
        `t = signedMin`
        `anc = t - 1 - (t % ad)` Oops, we performed overflow operation!

        So, `anc` value becomes undefined.
        In this patch, we first cast all the operated values to unsigned one.
        Reading the code, there are no operations that depends on signedness. (For example, we used aboveEqual like unsigned operations for comparison.)

        [1]: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
        [2]: http://dl.acm.org/citation.cfm?id=2522728

        * b3/B3ComputeDivisionMagic.h:
        (JSC::B3::computeDivisionMagic):
        * b3/testb3.cpp:
        (JSC::B3::testComputeDivisionMagic):
        (JSC::B3::run):

2016-01-30  Andreas Kling  <akling@apple.com>

        Shrink Heap::m_executables after cleaning it.
        <https://webkit.org/b/153682>

        Reviewed by Darin Adler.

        The Heap::m_executables Vector was never shrunk down, despite sometimes
        getting pretty huge (~500kB in my longest-running WebContent process.)

        After GC has finished pruning unmarked Executables, shrink the Vector.

        * heap/Heap.cpp:
        (JSC::Heap::clearUnmarkedExecutables):

2016-01-29  Ada Chan  <adachan@apple.com>

        Enable VIDEO_PRESENTATION_MODE only in Debug and Release builds on Mac
        https://bugs.webkit.org/show_bug.cgi?id=153665

        Reviewed by Dan Bernstein.

        * Configurations/FeatureDefines.xcconfig:

2016-01-30  Yusuke Suzuki  <utatane.tea@gmail.com>

        [B3] REGRESSION(r195882): Should break early after modConstant replaceWithNewValue succeeds
        https://bugs.webkit.org/show_bug.cgi?id=153711

        Reviewed by Filip Pizlo.

        Should break after modConstant replaceWithNewValue succeeds. m_value is already replaced with Identity
        if modConstant succeeds. So it does not have any children. m_value->child(1) breaks testb3.

        * b3/B3ReduceStrength.cpp:

2016-01-30  Yusuke Suzuki  <utatane.tea@gmail.com>

        Enable SamplingProfiler on POSIX environment
        https://bugs.webkit.org/show_bug.cgi?id=153584

        Reviewed by Michael Saboff.

        In this patch, we implement suspend and resume mechanizm for POSIX threads.
        And with GLIBC, we can retrieve registers from it.

        We take the following strategy.

        Suspend side.
        1. install sigaction to the threads.
        2. in the profiler (suspend / resume callers), emit signal with pthread_kill and wait with POSIX semaphore.
        3. in the signal handler, up the POSIX semaphore. Use sem_post because it is the async-signal-safe function in POSIX.
        4. in the signal handler, perform sigsuspend to stop the thread until being resumed.
        5. in the profiler, we can be waken up from the semaphore because (3) ups.

        Resume side.
        1. in the profiler, emit signal and wait on the semaphore.
        2. in the signal handler, it is waken up from the sigsuspend.
        3. in the signal handler, up the semaphore.
        4. in the profiler, the profiler is waken up from the semaphore. It is ensured that the given thread is resumed by the signal.

        * heap/MachineStackMarker.cpp:
        (pthreadSignalHandlerSuspendResume):
        (JSC::MachineThreads::Thread::Thread):
        (JSC::MachineThreads::Thread::~Thread):
        (JSC::MachineThreads::Thread::suspend):
        (JSC::MachineThreads::Thread::resume):
        (JSC::MachineThreads::Thread::getRegisters):
        (JSC::MachineThreads::Thread::Registers::stackPointer):
        (JSC::MachineThreads::Thread::Registers::framePointer):
        (JSC::MachineThreads::Thread::Registers::instructionPointer):
        (JSC::MachineThreads::Thread::Registers::llintPC):
        (JSC::MachineThreads::Thread::freeRegisters):
        * heap/MachineStackMarker.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::reportStats):
        * tests/stress/call-varargs-from-inlined-code-with-odd-number-of-arguments.js:
        * tests/stress/call-varargs-from-inlined-code.js:
        * tests/stress/v8-earley-boyer-strict.js:

2016-01-29  Filip Pizlo  <fpizlo@apple.com>

        B3 should reduce Mod(value, constant) to Div and Mul so that our Div optimizations can do things
        https://bugs.webkit.org/show_bug.cgi?id=153693

        Reviewed by Saam Barati.

        The most efficient way to handle Mod(value, constant) is to reduce it to
        Sub(value, Mul(Div(value, constant), constant)) and then let the Div optimizations do their
        thing.

        In the future we could add special handling of Mod(value, 1 << constant), but it's not
        obvious that this would produce better code than reducing through Div, if we also make sure
        that we have great optimizations for Mul and Div.

        * b3/B3ReduceStrength.cpp:

2016-01-29  Keith Miller  <keith_miller@apple.com>

        Array.prototype native functions should use Symbol.species to construct the result
        https://bugs.webkit.org/show_bug.cgi?id=153660

        Reviewed by Saam Barati.

        This patch adds support for Symbol.species in the Array.prototype native functions.
        We make an optimization to avoid regressions on some benchmarks by using an
        adaptive watchpoint to check if Array.prototype.constructor is ever changed.

        * runtime/ArrayPrototype.cpp:
        (JSC::putLength):
        (JSC::setLength):
        (JSC::speciesConstructArray):
        (JSC::arrayProtoFuncConcat):
        (JSC::arrayProtoFuncSlice):
        (JSC::arrayProtoFuncSplice):
        (JSC::ArrayPrototype::setConstructor):
        (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::ArrayPrototypeAdaptiveInferredPropertyWatchpoint):
        (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
        * runtime/ArrayPrototype.h:
        (JSC::ArrayPrototype::didChangeConstructorProperty):
        * runtime/ConstructData.cpp:
        (JSC::construct):
        * runtime/ConstructData.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * tests/es6.yaml:
        * tests/stress/array-species-functions.js: Added.
        (Symbol.species):
        (funcThrows):
        (test.species):
        (test):

2016-01-29  Filip Pizlo  <fpizlo@apple.com>

        CallLinkStatus should trust BadCell exit sites whenever there is no stub
        https://bugs.webkit.org/show_bug.cgi?id=153691

        Reviewed by Benjamin Poulain.

        This fixes a regression in our treatment of inlining failure exit sites when deciding if we
        should inline a call.

        A long time ago, a BadCell exit site would ensure that a CallLinkStatus returned
        takesSlowPath.

        But then we added closure calls. A BadCell exit site might just mean that we should do
        closure call inlining. We added a BadExecutable exit site to indicate that even closure call
        inlining had failed. BadCell would no longer force CallLinkStatus to return takesSlowPath,
        but BadExecutable would stuff do so.

        But then we unified the IR for checking functions and executables, and the DFG stopped using
        the BadExecutable exit kind. Probably this change disabled our ability to use exit site
        counting for deciding when to takesSlowPath. But this isn't necessarily a disaster, since
        any time you exited in this way, you'd be taken to a baseline call inline cache, and that
        inline cache would record the slow path.

        But then we introduced polymorphic call inlining. Polymorphic call inlining means that call
        unlinking, like when one of the callees is optimized, will reset the stub. We also made it
        so that the stub is like a gate for the slow path count. A clear inline cache must first
        cause the creation of a stub and then cause it to overflow before the slow path is counted.

        So, if the DFG or FTL exits on a cell check associated with a particular callsite being
        speculatively inlined, then it's possible that nobody will know about the exit because:

        - The exit kind is BadCell but CallLinkStatus needs BadExecutable to disable inlining.

        - Between when we tiered up to the DFG (or FTL) and when the exit happened, one of the
          callees was tiered up, causing the baseline CallLinkInfo to be unlinked. Therefore, after
          the exit, the inline cache is in a reset state and will not count the call as taking slow
          path.

        The challenge when dealing with this is that often, we will have an super early compilation
        of a minimorphic call site before we have seen all of its small set of callees. For example
        we may have seen only one of two possible callees. That early compilation will OSR exit, and
        in trunk, will be recompiled with bimorphic speculative inlining. That's a pretty good
        outcome. Basically, we are trusting that if during the time that the function has been
        running prior to a given compilation, a callsite has only seen a small number of callees,
        then it's safe to assume that it won't see another one anytime soon.

        So, simply forcing the CallLinkStatus to set takesSlowPath any time there was a BadCell exit
        would hurt our performance in some cases, because trunk prior to this change would have their
        final compilation use speculative inlining, and this change would make guarded inlining
        instead.

        The compromise that I came up with relies on the fact that a CallLinkInfo must be reset quite
        frequently for it to routinely happen in between tier-up to DFG (or FTL) and an exit. So,
        most likely, such a CallLinkInfo will also show up as being clear when the CallLinkStatus
        is built during DFG profiling. The CallLinkStatus will then fall back on the CallLinkInfo's
        lastSeenCallee field, which is persistent across resets. This change just makes it so that
        CallLinkStatus sets takesSlowPath if there is a BadCell exit and the status had to be
        inferred from the lastSeenCallee.

        This change reduces pointless recompilations in gbemu. It's an 11% speed-up on gbemu. It
        doesn't seem to hurt any benchmarks.

        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFor):
        (JSC::CallLinkStatus::computeExitSiteData):
        (JSC::CallLinkStatus::computeFromCallLinkInfo):
        * bytecode/CallLinkStatus.h:
        (JSC::CallLinkStatus::CallLinkStatus):
        (JSC::CallLinkStatus::at):
        (JSC::CallLinkStatus::operator[]):
        (JSC::CallLinkStatus::isProved):
        (JSC::CallLinkStatus::isBasedOnStub):
        (JSC::CallLinkStatus::canOptimize):
        (JSC::CallLinkStatus::maxNumArguments):
        (JSC::CallLinkStatus::ExitSiteData::ExitSiteData): Deleted.

2016-01-29  Saam barati  <sbarati@apple.com>

        Pack FunctionExecutable and UnlinkedFunctionExecutable harder
        https://bugs.webkit.org/show_bug.cgi?id=153687

        Reviewed by Andreas Kling.

        This patch reduces FunctionExecutable from 120 to 104 bytes.
        This patch reduces UnlinkedFunctionExecutable from 144 to 136 bytes.

        * bytecode/ExecutableInfo.h:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * parser/ParserModes.h:
        (JSC::functionNameScopeIsDynamic):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::ScriptExecutable):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::needsActivation):
        (JSC::ScriptExecutable::isArrowFunctionContext):
        (JSC::ScriptExecutable::isStrictMode):
        (JSC::ScriptExecutable::derivedContextType):
        (JSC::ScriptExecutable::ecmaMode):
        (JSC::ScriptExecutable::finishCreation):

2016-01-29  Saam barati  <sbarati@apple.com>

        JSC Sampling Profiler: Come up with a (program counter => CodeOrigin) mapping
        https://bugs.webkit.org/show_bug.cgi?id=152629

        Reviewed by Filip Pizlo.

        This patch implements a mapping from PC to CodeOrigin
        that lives off of JITed CodeBlocks. We build this mapping
        while JITing code, and then we compress it and store
        it on the CodeBlock. We only build the mapping if a debugger
        has ever been attached to any global object.

        CodeBlock consults this mapping when searching for a CodeOrigin
        for a given PC, but it also consults other code ranges
        off the main path that may own the PC. Specifically, it searches
        through inline caches, OSRExits, and LazySlowPaths.

        To find PC info for the LLInt, we also save the LLInt pc when
        taking a stack trace where the top frame is in LLInt code.

        This patch also cleans up code inside the SamplingProfier.
        I realized a bug in the SamplingProfiler's implementation.
        We used to walk the inline stack while gathering a stack
        trace. This is wrong. It's super dangerous to do this because
        we might pause the JSC process while it's modifying its
        CodeOrigin table. We used to walk the inline stack while
        taking a stack trace because doing so could save us from
        having to verify a particular stack trace. This patch changes that.
        We now have to verify all stack traces taken. This verification step
        includes walking the inline stack.

        Because we have a PC=>CodeOrigin map, we can now gather more
        detailed information about the top-frame we pause. This allows
        us to correctly observe inlining. It also allows us to observe
        expression-level line/column information for the top frame.
        The reason we don't consult this mapping for parent frames is 
        that all parent frames should set the CallSiteIndex on the call
        frame header, which means we can consult that value to get inlining 
        and expression-level line/column information.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::Label::Label):
        (JSC::AbstractMacroAssembler::Label::operator==):
        (JSC::AbstractMacroAssembler::Label::isSet):
        * assembler/AssemblerBuffer.h:
        (JSC::AssemblerLabel::labelAtOffset):
        (JSC::AssemblerLabel::operator==):
        * b3/B3Generate.cpp:
        * b3/B3Origin.h:
        (JSC::B3::Origin::data):
        (JSC::B3::Origin::operator==):
        * b3/B3PCToOriginMap.h: Added.
        (JSC::B3::PCToOriginMap::PCToOriginMap):
        (JSC::B3::PCToOriginMap::appendItem):
        (JSC::B3::PCToOriginMap::ranges):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::pcToOriginMap):
        (JSC::B3::Procedure::releasePCToOriginMap):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
        (JSC::CodeBlock::setPCToCodeOriginMap):
        (JSC::CodeBlock::findPC):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::jitCodeMap):
        (JSC::CodeBlock::bytecodeOffset):
        * bytecode/CodeOrigin.h:
        (JSC::CodeOrigin::operator==):
        (JSC::CodeOriginHash::hash):
        (JSC::CodeOriginHash::equal):
        * bytecode/InlineCallFrame.h:
        (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
        (JSC::CodeOrigin::walkUpInlineStack):
        * bytecode/PolymorphicAccess.h:
        (JSC::PolymorphicAccess::containsPC):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::visitWeakReferences):
        (JSC::StructureStubInfo::containsPC):
        * bytecode/StructureStubInfo.h:
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::hasExpressionInfo):
        (JSC::UnlinkedCodeBlock::expressionInfo):
        (JSC::UnlinkedCodeBlock::setThisRegister):
        * debugger/Debugger.cpp:
        (JSC::Debugger::attach):
        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::validateReferences):
        (JSC::DFG::JITCode::findPC):
        * dfg/DFGJITCode.h:
        (JSC::DFG::JITCode::commonDataOffset):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::JITCompiler):
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        (JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded):
        (JSC::DFG::JITCompiler::setEndOfMainPath):
        (JSC::DFG::JITCompiler::setEndOfCode):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::setStartOfCode):
        (JSC::DFG::JITCompiler::setForNode):
        (JSC::DFG::JITCompiler::addCallSite):
        (JSC::DFG::JITCompiler::pcToCodeOriginMapBuilder):
        (JSC::DFG::JITCompiler::setEndOfMainPath): Deleted.
        (JSC::DFG::JITCompiler::setEndOfCode): Deleted.
        * dfg/DFGSlowPathGenerator.h:
        (JSC::DFG::SlowPathGenerator::call):
        (JSC::DFG::SlowPathGenerator::origin):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
        (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        * dfg/DFGSpeculativeJIT.h:
        * ftl/FTLB3Compile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
        (JSC::FTL::JITCode::findPC):
        * ftl/FTLJITCode.h:
        (JSC::FTL::JITCode::b3Code):
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::Thread::Registers::instructionPointer):
        (JSC::MachineThreads::Thread::Registers::llintPC):
        (JSC::MachineThreads::Thread::freeRegisters):
        * heap/MachineStackMarker.h:
        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::addEvent):
        (Inspector::buildSamples):
        (Inspector::InspectorScriptProfilerAgent::trackingComplete):
        * jit/JIT.cpp:
        (JSC::JIT::JIT):
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        (JSC::JIT::privateCompile):
        * jit/JIT.h:
        * jit/JITCode.h:
        (JSC::JITCode::findPC):
        * jit/PCToCodeOriginMap.cpp: Added.
        (JSC::PCToCodeOriginMapBuilder::PCToCodeOriginMapBuilder):
        (JSC::PCToCodeOriginMapBuilder::appendItem):
        (JSC::PCToCodeOriginMap::PCToCodeOriginMap):
        (JSC::PCToCodeOriginMap::~PCToCodeOriginMap):
        (JSC::PCToCodeOriginMap::memorySize):
        (JSC::PCToCodeOriginMap::findPC):
        * jit/PCToCodeOriginMap.h: Added.
        (JSC::PCToCodeOriginMapBuilder::defaultCodeOrigin):
        (JSC::PCToCodeOriginMapBuilder::didBuildMapping):
        * jsc.cpp:
        (functionSamplingProfilerStackTraces):
        * llint/LLIntPCRanges.h:
        (JSC::LLInt::isLLIntPC):
        * llint/LowLevelInterpreter.asm:
        * runtime/Options.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::reportStats):
        (JSC::FrameWalker::FrameWalker):
        (JSC::FrameWalker::walk):
        (JSC::FrameWalker::resetAtMachineFrame):
        (JSC::FrameWalker::isValidFramePointer):
        (JSC::SamplingProfiler::SamplingProfiler):
        (JSC::SamplingProfiler::~SamplingProfiler):
        (JSC::tryGetBytecodeIndex):
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        (JSC::SamplingProfiler::visit):
        (JSC::SamplingProfiler::noticeVMEntry):
        (JSC::SamplingProfiler::clearData):
        (JSC::SamplingProfiler::StackFrame::displayName):
        (JSC::SamplingProfiler::StackFrame::displayNameForJSONTests):
        (JSC::SamplingProfiler::StackFrame::functionStartLine):
        (JSC::SamplingProfiler::StackFrame::functionStartColumn):
        (JSC::SamplingProfiler::StackFrame::sourceID):
        (JSC::SamplingProfiler::StackFrame::url):
        (JSC::SamplingProfiler::releaseStackTraces):
        (JSC::SamplingProfiler::stackTracesAsJSON):
        (WTF::printInternal):
        (JSC::SamplingProfiler::StackFrame::startLine): Deleted.
        (JSC::SamplingProfiler::StackFrame::startColumn): Deleted.
        (JSC::SamplingProfiler::stackTraces): Deleted.
        * runtime/SamplingProfiler.h:
        (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
        (JSC::SamplingProfiler::StackFrame::StackFrame):
        (JSC::SamplingProfiler::StackTrace::StackTrace):
        (JSC::SamplingProfiler::totalTime):
        (JSC::SamplingProfiler::setStopWatch):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        (JSC::VM::setShouldBuildPCToCodeOriginMapping):
        (JSC::VM::shouldBuilderPCToCodeOriginMapping):
        * tests/stress/sampling-profiler-basic.js:
        (platformSupportsSamplingProfiler.top):
        (platformSupportsSamplingProfiler.jaz):
        (platformSupportsSamplingProfiler.kaz):

2016-01-29  Saam barati  <sbarati@apple.com>

        Remove our notion of having a single activation register
        https://bugs.webkit.org/show_bug.cgi?id=153673

        Reviewed by Filip Pizlo.

        We have many functions lurking around where we think a function 
        might only have one activation register. This is clearly wrong
        now that ES6 has block scoping. This patch removes this false notion.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::scopeRegister):
        (JSC::CodeBlock::codeType):
        (JSC::CodeBlock::setActivationRegister): Deleted.
        (JSC::CodeBlock::activationRegister): Deleted.
        (JSC::CodeBlock::uncheckedActivationRegister): Deleted.
        (JSC::CodeBlock::needsActivation): Deleted.
        * bytecode/ExecutableInfo.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::usesEval):
        (JSC::ExecutableInfo::isStrictMode):
        (JSC::ExecutableInfo::isConstructor):
        (JSC::ExecutableInfo::isClassContext):
        (JSC::ExecutableInfo::needsActivation): Deleted.
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::isArrowFunctionContext):
        (JSC::UnlinkedCodeBlock::isClassContext):
        (JSC::UnlinkedCodeBlock::setThisRegister):
        (JSC::UnlinkedCodeBlock::setScopeRegister):
        (JSC::UnlinkedCodeBlock::usesGlobalObject):
        (JSC::UnlinkedCodeBlock::setGlobalObjectRegister):
        (JSC::UnlinkedCodeBlock::thisRegister):
        (JSC::UnlinkedCodeBlock::scopeRegister):
        (JSC::UnlinkedCodeBlock::addPropertyAccessInstruction):
        (JSC::UnlinkedCodeBlock::needsFullScopeChain): Deleted.
        (JSC::UnlinkedCodeBlock::setActivationRegister): Deleted.
        (JSC::UnlinkedCodeBlock::activationRegister): Deleted.
        (JSC::UnlinkedCodeBlock::hasActivationRegister): Deleted.
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::destinationForAssignResult):
        (JSC::BytecodeGenerator::leftHandSideNeedsCopy):
        (JSC::BytecodeGenerator::emitNodeForLeftHandSide):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::inliningCost):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::hasExitSite):
        (JSC::DFG::Graph::activationRegister): Deleted.
        (JSC::DFG::Graph::uncheckedActivationRegister): Deleted.
        (JSC::DFG::Graph::machineActivationRegister): Deleted.
        (JSC::DFG::Graph::uncheckedMachineActivationRegister): Deleted.
        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::callSiteIndex):
        (JSC::CallFrame::stack):
        (JSC::CallFrame::callerFrame):
        (JSC::CallFrame::friendlyFunctionName):
        (JSC::CallFrame::hasActivation): Deleted.
        (JSC::CallFrame::uncheckedActivation): Deleted.
        (JSC::CallFrame::lexicalEnvironment): Deleted.
        (JSC::CallFrame::lexicalEnvironmentOrNullptr): Deleted.
        (JSC::CallFrame::setActivation): Deleted.
        * interpreter/CallFrame.h:
        (JSC::ExecState::scope):
        (JSC::ExecState::setCallerFrame):
        (JSC::ExecState::setScope):
        (JSC::ExecState::init):
        * interpreter/Register.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::usesEval):
        (JSC::ScriptExecutable::usesArguments):
        (JSC::ScriptExecutable::isArrowFunctionContext):
        (JSC::ScriptExecutable::isStrictMode):
        (JSC::ScriptExecutable::derivedContextType):
        (JSC::ScriptExecutable::needsActivation): Deleted.
        * runtime/JSLexicalEnvironment.h:
        (JSC::asActivation):
        (JSC::Register::lexicalEnvironment): Deleted.

2016-01-29  Filip Pizlo  <fpizlo@apple.com>

        Air:fixObviousSpills should handle floats and doubles
        https://bugs.webkit.org/show_bug.cgi?id=153197

        Reviewed by Saam Barati.

        This adds the most obvious handling of float spills, where we just enable load elimination on
        float spill code.

        * b3/air/AirFixObviousSpills.cpp:

2016-01-29  Andreas Kling  <akling@apple.com>

        Shrink CodeBlock!
        <https://webkit.org/b/153640>

        Reviewed by Saam Barati.

        Shrink CodeBlock by 112 bytes (from 640 to 528) by employing
        these sophisticated tricks:

            - Remove members that are not used by anyone.
            - Don't cache both VM* and Heap* in members.
            - Reorder members to minimize struct padding.
            - Use RefCountedArray instead of Vector for arrays that never resize.
            - Put a not-always-present HashMap in a std::unique_ptr.

        This increases CodeBlock space efficiency by 20%, as we can now
        fit 30 of them in a MarkedBlock, up from 25.)

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::setNumParameters):
        (JSC::CodeBlock::jettison):
        (JSC::CodeBlock::noticeIncomingCall):
        (JSC::CodeBlock::resultProfileForBytecodeOffset):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setJITCode):
        (JSC::CodeBlock::capabilityLevelState):
        (JSC::CodeBlock::codeType):
        (JSC::CodeBlock::ensureResultProfile):
        (JSC::CodeBlock::heap):

2016-01-29  Saam barati  <sbarati@apple.com>

        Exits from exceptions shouldn't jettison code
        https://bugs.webkit.org/show_bug.cgi?id=153564

        Reviewed by Geoffrey Garen.

        We create two new exit kinds for exception-handling
        OSRExits:
        - ExceptionCheck: an exception check after a C call.
        - GenericUnwind: an OSR exit executes because it's jumped to from genericUnwind machinery.

        Having these two new exit kinds allows us to remove fields from
        various OSRExit variants that store booleans indicating
        if the exit is an exception handler, and if so, what kind
        of exception handler. Most of this patch is just removing
        those old fields and adding new equivalent functions.

        This patch also implements the policy that we should never consider jettisoning
        code from exits that happen from an exception check to an op_catch (it might be worth
        considering a similar policy for 'throw'). We're choosing this policy because
        it will almost never be more expensive, in total, to execute the OSR exit than
        to execute the baseline variant of the code. When an exception is thrown, we do
        really expensive work, like call through to genericUnwind, and also create an error
        object with a stack trace. The cost of OSR exiting here is small in comparison to
        those other operations. And penalizing a CodeBlock for OSR exiting from an exception
        is silly because the basis of our implementation of exception handling in the
        upper tiers is to OSR exit on a caught exception. So we used to penalize
        ourselves for having an implementation that is correct w.r.t our design goals.

        I've verified this hypothesis with on v8-raytrace by adding a new 
        benchmark that throws with very high frequency. Implementing
        this policy on that benchmark results in about a 4-5% speed up.

        * bytecode/ExitKind.cpp:
        (JSC::exitKindToString):
        (JSC::exitKindMayJettison):
        (JSC::exitKindIsCountable): Deleted.
        * bytecode/ExitKind.h:
        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::noticeOSREntry):
        (JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
        (JSC::DFG::JITCompiler::exceptionCheck):
        (JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded):
        * dfg/DFGJITCompiler.h:
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExit.h:
        (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
        * dfg/DFGOSRExitBase.h:
        (JSC::DFG::OSRExitBase::OSRExitBase):
        (JSC::DFG::OSRExitBase::isExceptionHandler):
        (JSC::DFG::OSRExitBase::isGenericUnwindHandler):
        (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::handleExitCounts):
        (JSC::DFG::osrWriteBarrier):
        (JSC::DFG::adjustAndJumpToTarget):
        * dfg/DFGOSRExitCompilerCommon.h:
        (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLExitThunkGenerator.cpp:
        (JSC::FTL::ExitThunkGenerator::emitThunk):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExitDescriptor::emitOSRExit):
        (JSC::FTL::OSRExitDescriptor::emitOSRExitLater):
        (JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
        (JSC::FTL::OSRExit::OSRExit):
        (JSC::FTL::OSRExit::spillRegistersToSpillSlot):
        (JSC::FTL::OSRExit::recoverRegistersFromSpillSlot):
        (JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck):
        (JSC::FTL::OSRExit::willArriveAtOSRExitFromCallOperation):
        (JSC::FTL::exceptionTypeWillArriveAtOSRExitFromGenericUnwind): Deleted.
        (JSC::FTL::OSRExit::willArriveAtOSRExitFromGenericUnwind): Deleted.
        * ftl/FTLOSRExit.h:
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        (JSC::FTL::compileFTLOSRExit):
        * ftl/FTLPatchpointExceptionHandle.cpp:
        (JSC::FTL::PatchpointExceptionHandle::scheduleExitCreation):
        (JSC::FTL::PatchpointExceptionHandle::scheduleExitCreationForUnwind):
        (JSC::FTL::PatchpointExceptionHandle::PatchpointExceptionHandle):
        (JSC::FTL::PatchpointExceptionHandle::createHandle):
        * ftl/FTLPatchpointExceptionHandle.h:

2016-01-28  Yusuke Suzuki  <utatane.tea@gmail.com>

        [B3] REGRESSION(r195395): testComplex(64, 128) asserts on Linux with GCC
        https://bugs.webkit.org/show_bug.cgi?id=153422

        Reviewed by Filip Pizlo.

        Previously proc.values() returns ValuesCollection (Not reference!).
        values.values takes const ValueCollection&.
        And later it produces IndexSet<Value>::Iterable<Procedure::ValuesCollection>,
        it holds const ValueCollection& as its member.
        But IndexSet<Value>::Iterable<Procedure::ValuesCollection> is just an instance.
        So after creating this, the lifetime of the ValueCollection const reference finished.

        To fix that, we hold ValuesCollection as a member of Procedure.
        And change the signature to const ValuesCollection& Procedure::values().

        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::Procedure):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::values):

2016-01-28  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: InspectorTimelineAgent doesn't need to recompile functions because it now uses the sampling profiler
        https://bugs.webkit.org/show_bug.cgi?id=153500
        <rdar://problem/24352458>

        Reviewed by Timothy Hatcher.

        Be more explicit about enabling legacy profiling.

        * jsc.cpp:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::hasLegacyProfiler):
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock):
        (JSC::JSGlobalObject::createModuleProgramCodeBlock):
        (JSC::JSGlobalObject::hasProfiler): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::supportsLegacyProfiling):
        (JSC::JSGlobalObject::supportsProfiling): Deleted.

2016-01-28  Yusuke Suzuki  <utatane.tea@gmail.com>

        Fix the B3 build with GCC 4.9.3
        https://bugs.webkit.org/show_bug.cgi?id=151624

        Reviewed by Filip Pizlo.

        Due to GCC 4.9's compiler issue[1], method calls inside (2 or so) nested lambdas need to use `this` to avoid internal compiler errors.
        [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62272

        * b3/air/AirIteratedRegisterCoalescing.cpp:

2016-01-28  Filip Pizlo  <fpizlo@apple.com>

        LowerToAir::preferRightForResult() should resolve use count ties by selecting the child that is closest in an idom walk
        https://bugs.webkit.org/show_bug.cgi?id=153583

        Reviewed by Benjamin Poulain.

        This undoes the AsmBench/n-body regression in r195654 while preserving that revision's
        Kraken progression.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::LowerToAir):
        (JSC::B3::Air::LowerToAir::preferRightForResult):

2016-01-28  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] B3 Tail Call with Varargs do not restore callee saved registers
        https://bugs.webkit.org/show_bug.cgi?id=153579

        Reviewed by Michael Saboff.

        We were trashing the callee saved registers in Tail Calls.

        I just copied the code from DFG to fix this :)

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):

2016-01-27  Filip Pizlo  <fpizlo@apple.com>

        B3 IntRange analysis should know more about shifting
        https://bugs.webkit.org/show_bug.cgi?id=153568

        Reviewed by Benjamin Poulain.

        This teaches the IntRange analysis that the result of a right shift is usually better than
        the worst-case mask based on the shift amount. In fact, you can reach useful conclusions
        from looking at the IntRange of the input. This helps because Octane/crypto does something
        like:

            CheckMul((@x & $268435455) >> 14, @y >> 14, ...)

        If you consider just the shifts, then this may overflow. But if you consider that @x is
        first masked, then the IntRange coming out of the first shift is tight enough to prove that
        the CheckMul cannot overflow.

        * b3/B3ReduceStrength.cpp:
        * b3/testb3.cpp:

2016-01-27  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] adjustFrameAndStackInOSRExitCompilerThunk() can trash values in FTL
        https://bugs.webkit.org/show_bug.cgi?id=153536

        Reviewed by Saam Barati.

        Workaround to get B3 working on ARM.

        * dfg/DFGOSRExitCompilerCommon.h:
        (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
        The code was using the scratch registers in a few places.

        I initially tried to make is not use scratch registers anywhere
        but that looked super fragile.

        Instead, I just preserve the scratch registers. That's easy and
        it should be relatively cheap compared to everything done on OSR Exits.

2016-01-27  Konstantin Tokarev  <annulen@yandex.ru>

        [mips] Use reinterpret_cast_ptr to suppress alignment warnings.
        https://bugs.webkit.org/show_bug.cgi?id=153424

        Reviewed by Darin Adler.

        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::sortFloat):

2016-01-27  Per Arne Vollan  <peavo@outlook.com>

        [FTL][Win64] Compile fix.
        https://bugs.webkit.org/show_bug.cgi?id=153555

        Reviewed by Alex Christensen.

        MSVC does not accept preprocessor conditionals in macros.

        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):

2016-01-27  Filip Pizlo  <fpizlo@apple.com>

        Air::TmpWidth uses a stale pointer into its HashMap after it calls add()
        https://bugs.webkit.org/show_bug.cgi?id=153546

        Reviewed by Saam Barati.

        * b3/air/AirTmpWidth.cpp:
        (JSC::B3::Air::TmpWidth::recompute):

2016-01-27  Alexey Proskuryakov  <ap@apple.com>

        Remove ENABLE_CURRENTSRC
        https://bugs.webkit.org/show_bug.cgi?id=153545

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig:

2016-01-26  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] When lowering B3 to Air, preferRightForResult() should prefer values from the same block
        https://bugs.webkit.org/show_bug.cgi?id=153477

        Reviewed by Filip Pizlo.

        In cases like this:

        Block #0
            @1 = something
            @2 = Jump #1
        Block #1
            @3 = something else
            @4 = Add(@3, @1)
            ...
            @42 = Branch(@x, #1, #2)

        B3LowerToAir would pick @1 for the argument copied
        for what goes into the UseDef side of Add.

        This created a bunch of moves that could never be coalesced.
        In Kraken's imaging-desaturate, there were enough Moves to slow
        down the hot loop.

        Ideally, we should not use UseCount for lowering. We should use
        the real liveness for preferRightForResult(), and a loop-weighted
        use-count for effective addresses. The problem is keeping the cost
        low for those simple helpers.

        In this patch, I went with a simple heuristic: prioritize the value
        defined in the same block for UseDef.

        There is one other way that would be cheap but a bit invasive:
        -Get rid of UseDef.
        -Make every ops, 3 operands.
        -Tell the register allocator to attempt aliasing of the 2 uses
         with the def.
        -If the allocator fails, just add a move as needed.

        For now, the simple heuristic seems okay for the cases have.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::preferRightForResult):

2016-01-26  Filip Pizlo  <fpizlo@apple.com>

        Tail duplication should break critical edges first
        https://bugs.webkit.org/show_bug.cgi?id=153530

        Reviewed by Benjamin Poulain.

        This speeds up Octane/boyer.

        * b3/B3DuplicateTails.cpp:

2016-01-26  Joseph Pecoraro  <pecoraro@apple.com>

        Generalize ResourceUsageData gathering to be used outside of ResourceUsageOverlay
        https://bugs.webkit.org/show_bug.cgi?id=153509
        <rdar://problem/24354291>

        Reviewed by Andreas Kling.

        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::didAllocateBlock):
        (JSC::Heap::didFreeBlock):
        Rename the ENABLE flag.

2016-01-26  Csaba Osztrogonác  <ossy@webkit.org>

        [B3] Fix control reaches end of non-void function GCC warning after r195139
        https://bugs.webkit.org/show_bug.cgi?id=153426

        Reviewed by Michael Catanzaro.

        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::cooled):

2016-01-26  Saam barati  <sbarati@apple.com>

        testb3 and testAir should be compiled under -O0
        https://bugs.webkit.org/show_bug.cgi?id=153520

        Reviewed by Benjamin Poulain.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2016-01-26  Filip Pizlo  <fpizlo@apple.com>

        B3's integer range analysis should know that Mul'ing two sufficiently small numbers will yield a number that still has a meaningful range
        https://bugs.webkit.org/show_bug.cgi?id=153518

        Reviewed by Benjamin Poulain.

        Octane/encrypt had an addition overflow check that can be proved away by being sufficiently
        sneaky about the analysis of adds, multiplies, and shifts.

        I almost added these optimizations to the DFG integer range optimization phase. That phase is
        very complicated. B3's integer range analysis is trivial. So I added it to B3. Eventually
        we'll want this same machinery in the DFG also.

        8% speed-up on Octane/encrypt.

        * b3/B3ReduceStrength.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::dump): Dumping a constant value's name now dumps its value. This makes a huge difference for reading IR.
        (JSC::B3::Value::cloneImpl):
        (JSC::B3::Value::deepDump):

2016-01-26  Filip Pizlo  <fpizlo@apple.com>

        It should be possible to disable FTL for a range like we disable DFG for a range
        https://bugs.webkit.org/show_bug.cgi?id=153511

        Reviewed by Geoffrey Garen.

        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        * runtime/Options.h:

2016-01-26  Filip Pizlo  <fpizlo@apple.com>

        Shifts by an amount computed using BitAnd with a mask that subsumes the shift's own mask should be rewired around the BitAnd
        https://bugs.webkit.org/show_bug.cgi?id=153505

        Reviewed by Saam Barati.

        Turn this: Shl(@x, BitAnd(@y, 63))
        Into this: Shl(@x, @y)

        It matters for Octane/crypto.

        We should also stop FTL from generating such code, but even if we did that, we'd still want
        this optimization in case user code did the BitAnd.

        Also we can't stop the FTL from generating such code yet, because when targetting LLVM, you
        must mask your shifts this way.

        * b3/B3ReduceStrength.cpp:

2016-01-26  Filip Pizlo  <fpizlo@apple.com>

        The thing that B3 uses to describe a stack slot should not be a Value
        https://bugs.webkit.org/show_bug.cgi?id=153491
        rdar://problem/24349446

        Reviewed by Geoffrey Garen and Saam Barati.

        Prior to this change, B3 represented stack slots by having a StackSlotValue that carried
        two meanings:

        - It represented a stack slot.

        - It was a kind of Value for getting the base of the stack slot.

        This seems like a good idea until you consider the following issues.

        1) A Value can be killed if it is on an unreachable path, or if it has no effects and
           nobody refers to it. But the FTL uses StackSlotValue to allocate space on the stack.
           When it does this, it doesn't want it to be killed. It will dereference the object, so
           killing it is a bug.

        2) A premise of B3 is that it should be always legal to perform the following
           transformation on a value:

           value->replaceWithIdentity(insertionSet.insertValue(index, proc.clone(value)));

           This inserts a new value just before the old one. The new value is a clone of the old
           one. Then the old one is essentially deleted (anything that becomes an identity dies
           shortly thereafter). Problem (1) prevents this from being legal, which breaks a major
           premise of B3 IR.

        3) A premise of B3 is that it should be always legal to perform the following
           transformation on a value:

           Before:
                   @42 = Thing(...)

           After:
                   Branch(@doesntMatter, #yes, #no)
               BB#yes:
                   @42_one = Thing(...)
                   Upsilon(@42_one, ^42)
                   Jump(#done)
               BB#no:
                   @42_two = Thing(...)
                   Upsilon(@42_two, ^42)
                   Jump(#done)
               BB#done:
                   @42 = Phi()

           But prior to this change, such a transformation makes absolutely no sense for
           StackSlot. It will "work" in the sense that the compiler will proceed undaunted, but
           it will disable SSA fix-up for the cloned stack slot and we will end up allocating two
           stack slots instead of one, and then we will assume that they both escape, which will
           disable efficient stack allocation. Note that the moral equivalent of this
           transformation could already happen due to tail duplication, and the only reason why
           it's not a bug right now is that we happen to hoist stack slots to the root block. But
           the whole point of our stack slots was supposed to be that they do not have to be
           hoisted.

        This change fixes this issue by splitting StackSlotValue into two things: SlotBaseValue,
        which is a pure operation for getting the base address of a StackSlot, and StackSlot,
        which is a representation of the actual stack slot. StackSlot cannot get duplicated and
        can only be killed if it's anonymous. SlotBaseValue can be killed, moved, cloned,
        hoisted, etc. Since it has no effects and it has a ValueKey, it's one of the most
        permissive Values in the IR, just as one would hope (after all, there is actually zero
        code that needs to execute to evaluate SlotBaseValue).

        This fixes a crash that we saw with GuardMalloc and ASan. It also makes the IR a lot more
        easy to reason about.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3EliminateCommonSubexpressions.cpp:
        * b3/B3FixSSA.cpp:
        (JSC::B3::demoteValues):
        (JSC::B3::fixSSA):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::effectiveAddr):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::setBlockOrderImpl):
        (JSC::B3::Procedure::addStackSlot):
        (JSC::B3::Procedure::addAnonymousStackSlot):
        (JSC::B3::Procedure::clone):
        (JSC::B3::Procedure::dump):
        (JSC::B3::Procedure::blocksInPostOrder):
        (JSC::B3::Procedure::deleteStackSlot):
        (JSC::B3::Procedure::deleteValue):
        (JSC::B3::Procedure::calleeSaveRegisters):
        (JSC::B3::Procedure::addStackSlotIndex):
        (JSC::B3::Procedure::addValueIndex):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::setBlockOrder):
        (JSC::B3::Procedure::StackSlotsCollection::StackSlotsCollection):
        (JSC::B3::Procedure::StackSlotsCollection::size):
        (JSC::B3::Procedure::StackSlotsCollection::at):
        (JSC::B3::Procedure::StackSlotsCollection::operator[]):
        (JSC::B3::Procedure::StackSlotsCollection::iterator::iterator):
        (JSC::B3::Procedure::StackSlotsCollection::iterator::operator*):
        (JSC::B3::Procedure::StackSlotsCollection::iterator::operator++):
        (JSC::B3::Procedure::StackSlotsCollection::iterator::operator==):
        (JSC::B3::Procedure::StackSlotsCollection::iterator::operator!=):
        (JSC::B3::Procedure::StackSlotsCollection::iterator::findNext):
        (JSC::B3::Procedure::StackSlotsCollection::begin):
        (JSC::B3::Procedure::StackSlotsCollection::end):
        (JSC::B3::Procedure::stackSlots):
        (JSC::B3::Procedure::ValuesCollection::ValuesCollection):
        * b3/B3ReduceStrength.cpp:
        * b3/B3SlotBaseValue.cpp: Copied from Source/JavaScriptCore/b3/B3StackSlotValue.cpp.
        (JSC::B3::SlotBaseValue::~SlotBaseValue):
        (JSC::B3::SlotBaseValue::dumpMeta):
        (JSC::B3::SlotBaseValue::cloneImpl):
        (JSC::B3::StackSlotValue::~StackSlotValue): Deleted.
        (JSC::B3::StackSlotValue::dumpMeta): Deleted.
        (JSC::B3::StackSlotValue::cloneImpl): Deleted.
        * b3/B3SlotBaseValue.h: Copied from Source/JavaScriptCore/b3/B3StackSlotValue.h.
        * b3/B3StackSlot.cpp: Added.
        (JSC::B3::StackSlot::~StackSlot):
        (JSC::B3::StackSlot::dump):
        (JSC::B3::StackSlot::deepDump):
        (JSC::B3::StackSlot::StackSlot):
        * b3/B3StackSlot.h: Added.
        (JSC::B3::StackSlot::byteSize):
        (JSC::B3::StackSlot::kind):
        (JSC::B3::StackSlot::isLocked):
        (JSC::B3::StackSlot::index):
        (JSC::B3::StackSlot::offsetFromFP):
        (JSC::B3::StackSlot::setOffsetFromFP):
        (JSC::B3::DeepStackSlotDump::DeepStackSlotDump):
        (JSC::B3::DeepStackSlotDump::dump):
        (JSC::B3::deepDump):
        * b3/B3StackSlotValue.cpp: Removed.
        * b3/B3StackSlotValue.h: Removed.
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::checkOpcode):
        * b3/B3ValueKey.cpp:
        (JSC::B3::ValueKey::materialize):
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::addBlock):
        (JSC::B3::Air::Code::addStackSlot):
        (JSC::B3::Air::Code::addSpecial):
        * b3/air/AirCode.h:
        * b3/air/AirStackSlot.cpp:
        (JSC::B3::Air::StackSlot::setOffsetFromFP):
        (JSC::B3::Air::StackSlot::dump):
        (JSC::B3::Air::StackSlot::deepDump):
        (JSC::B3::Air::StackSlot::StackSlot):
        * b3/air/AirStackSlot.h:
        (JSC::B3::Air::StackSlot::alignment):
        (JSC::B3::Air::StackSlot::b3Slot):
        (JSC::B3::Air::StackSlot::offsetFromFP):
        (WTF::printInternal):
        (JSC::B3::Air::StackSlot::value): Deleted.
        * b3/testb3.cpp:
        (JSC::B3::testStackSlot):
        (JSC::B3::testStoreLoadStackSlot):
        * ftl/FTLB3Compile.cpp:
        * ftl/FTLB3Output.cpp:
        (JSC::FTL::Output::appendTo):
        (JSC::FTL::Output::lockedStackSlot):
        (JSC::FTL::Output::neg):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::framePointer):
        (JSC::FTL::Output::constBool):
        (JSC::FTL::Output::constInt32):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        * ftl/FTLState.h:

2016-01-26  Benjamin Poulain  <benjamin@webkit.org>

        Remove a useless #include
        https://bugs.webkit.org/show_bug.cgi?id=153474

        Reviewed by Alexey Proskuryakov.

        * b3/B3ReduceStrength.cpp:

2016-01-26  Alex Christensen  <achristensen@webkit.org>

        [Win] Fix clean build after r195545.
        ​https://bugs.webkit.org/show_bug.cgi?id=153434

        * CMakeLists.txt:
        * PlatformWin.cmake:
        Derived sources need to be copied after the build, but everything else should be copied before.
        This should fix ews issues like the one seen in bug 153473.

2016-01-25  Filip Pizlo  <fpizlo@apple.com>

        FTLB3Output should maintain good block order like the LLVM one does
        https://bugs.webkit.org/show_bug.cgi?id=152222

        Reviewed by Geoffrey Garen.

        This fixes FTLB3Output to emit an ordered B3 IR. This makes inspecting IR *a lot* easier.
        It will also be a performance win whenever we use range-based data structures for
        liveness.

        Also two small other changes:
        - Added some more dumping in integer range optimization phase.
        - Refined the disassembler's printing of instruction width suffixes so that "jzl" is not
          a thing. It was using "l" as the suffix because jumps take a 32-bit immediate.

        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::addBlock):
        (JSC::B3::Procedure::setBlockOrderImpl):
        (JSC::B3::Procedure::clone):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::frontendData):
        (JSC::B3::Procedure::setBlockOrder):
        * dfg/DFGIntegerRangeOptimizationPhase.cpp:
        * disassembler/udis86/udis86_syn-att.c:
        (ud_translate_att):
        * ftl/FTLB3Output.cpp:
        (JSC::FTL::Output::initialize):
        (JSC::FTL::Output::newBlock):
        (JSC::FTL::Output::applyBlockOrder):
        (JSC::FTL::Output::appendTo):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::setFrequency):
        (JSC::FTL::Output::insertNewBlocksBefore):
        (JSC::FTL::Output::callWithoutSideEffects):
        (JSC::FTL::Output::newBlock): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):

2016-01-25  Skachkov Oleksandr  <gskachkov@gmail.com>

        [ES6] Arrow function syntax. Arrow function specific features. Lexical bind "arguments"
        https://bugs.webkit.org/show_bug.cgi?id=145132

        Reviewed by Saam Barati.
        
        Added support of ES6 arrow function specific feature, lexical bind of arguments. 
        http://www.ecma-international.org/ecma-262/6.0/#sec-arrow-function-definitions-runtime-semantics-evaluation
        'arguments' variable in arrow function must resolve to a binding in a lexically enclosing environment.
        In srict mode it points to arguments object, and in non-stric mode it points to arguments object or varible 
        with name 'arguments' if it was declared. 

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::setSourceParseMode):
        (JSC::Scope::isArrowFunction):
        (JSC::Scope::collectFreeVariables):
        (JSC::Scope::setIsArrowFunction):
        * tests/es6.yaml:
        * tests/stress/arrowfunction-lexical-bind-arguments-non-strict-1.js: Added.
        * tests/stress/arrowfunction-lexical-bind-arguments-non-strict-2.js: Added.
        * tests/stress/arrowfunction-lexical-bind-arguments-strict.js: Added.

2016-01-25  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] We should never use x18 on iOS ARM64
        https://bugs.webkit.org/show_bug.cgi?id=153461

        Reviewed by Filip Pizlo.

        The register x18 is reserved in the iOS variant of the ARM64 ABI.

        The weird thing is: if you use it, its value will change completely
        randomly. It looks like it is changed by the system on interrupts.

        This patch adds x18 to the reserved register and add assertions
        to the assembler to prevent similar problems in the future.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::xOrSp):
        (JSC::ARM64Assembler::xOrZr):
        * assembler/AbstractMacroAssembler.h:
        (JSC::isIOS): Deleted.
        * assembler/AssemblerCommon.h:
        (JSC::isIOS):
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::reservedHardwareRegisters):

2016-01-25  Commit Queue  <commit-queue@webkit.org>

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

        broke animometer bot (and now we have crash logs!) (Requested
        by kling on #webkit).

        Reverted changeset:

        "Restore CodeBlock jettison code Geoff accidentally removed"
        https://bugs.webkit.org/show_bug.cgi?id=151241
        http://trac.webkit.org/changeset/195550

2016-01-25  Andreas Kling  <akling@apple.com>

        MarkedSpace should have more precise allocators.
        <https://webkit.org/b/153448>
        <rdar://problem/23897477>

        Reviewed by Geoffrey Garen.

        The four classes responsible for the bulk of MarkedBlock allocations today are:

            - FunctionCodeBlock (640 bytes)
            - UnlinkedFunctionCodeBlock (304 bytes)
            - FunctionExecutable (168 bytes)
            - UnlinkedFunctionExecutable (144 bytes)

        Due to the size class distribution in MarkedSpace, we've been wasting quite a lot
        of heap space on these objects. Our "precise" allocators allowed allocation sizes
        in 16-byte increments up to 128 bytes, but after that point, we'd only allocate
        in 256-byte size increments.

        Thus each instance of those classes would waste space as follows:

            - FunctionCodeBlock (768-byte cell, 128 bytes wasted)
            - UnlinkedFunctionCodeBlock (512-byte cell, 208 bytes wasted)
            - FunctionExecutable(256-byte cell, 88 bytes wasted)
            - UnlinkedFunctionExecutable(256-byte cell, 112 bytes wasted)

        This patch raises the limit for precise allocations from 128 to 768, allowing us
        to allocate these objects with far better space efficiency.

        The cost of this is 7kB worth of MarkedAllocators and 70 (~2x) more allocators to
        iterate whenever we iterate all the allocators.

        * heap/MarkedSpace.h:
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::forEachAllocator):
        (JSC::MarkedSpace::isPagedOut):

2016-01-25  Filip Pizlo  <fpizlo@apple.com>

        Fix the comment about FTL_USES_B3.

        * dfg/DFGCommon.h:

2016-01-25  Filip Pizlo  <fpizlo@apple.com>

        Switch FTL to B3 on X86_64/Mac
        https://bugs.webkit.org/show_bug.cgi?id=153445

        Rubber stamped by Geoffrey Garen.

        This finally switches from LLVM to B3 in the FTL on X86_64 on the Mac. We recommend that other
        X86_64 platforms make the switch as well. We will be focusing our performance work on B3 rather
        than LLVM in the future. ARM64 support is also coming soon, so we will be able to remove FTL
        LLVM code once that lands.

        Right now this mostly appears as perf-neutral on the major tests. However, it does have the
        following immediate benefits:

        - Dramatic reduction in FTL compile times, on the order of 5x-10x. This means huge speed-ups in
          shorter-running tests like V8Spider (21%) and JSRegress (8%).

        - It makes the FTL simpler and more robust because we don't have to do stackmap section
          parsing. This makes it easier to add new FTL features. We are already working on features,
          like the sampling profiler, which will only have a FTL B3 implementation.

        - Speed-ups on some throughput benchmarks like mandreel, richards, imaging-gaussian-blur. It's
          still a slow down on other throughput benchmarks, though.

        We started writing B3 in October, so it's pretty awesome that the throughput of the code it
        generates is already on par with LLVM.
        
        This does not fundamentally change how the FTL works. FTL was built to lower DFG IR to a C-like
        SSA IR, and then rely on powerful SSA optimizations and comprehensive instruction selection and
        register allocation to turn that code into something that runs fast. B3 also has a C-like SSA
        IR, has an instruction selector that is in some ways more powerful than LLVM's (B3 does global
        instruction selection rather than block-local like LLVM), and it has a register allocator that
        is in some ways more powerful also (B3 uses IRC, a mature graph coloring allocator, while LLVM
        does not do graph coloring). We expect FTL B3's performance to improve a lot after we turn it
        on and can focus our efforts on tuning it.

        I didn't find any test regressions after running both JSC tests and layout tests. Basic
        browsing still works. JetStream performance difference is within the margin of error. EWS is
        happy.

        * dfg/DFGCommon.h:

2016-01-25  Andreas Kling  <akling@apple.com>

        Restore CodeBlock jettison code Geoff accidentally removed
        https://bugs.webkit.org/show_bug.cgi?id=151241

        Rubber-stamped by Geoffrey Garen.

        Geoff meant to add this back in <http://trac.webkit.org/changeset/190827>
        but missed.

        Then he added it back in, but it was rolled out due to a crash on Animometer.
        I can no longer produce a crash on Animometer, either with today's version of
        the benchmark, or the one that existed at the time of the rollout.

        Given this, let's roll it back in and see how it goes.

        * bytecode/CodeBlock.cpp:
        (JSC::timeToLive):
        (JSC::CodeBlock::shouldJettisonDueToOldAge):

2016-01-22  Filip Pizlo  <fpizlo@apple.com>

        mandreel should run just as fast in FTL B3 as FTL LLVM
        https://bugs.webkit.org/show_bug.cgi?id=153394

        Reviewed by Gavin Barraclough.

        This fixes two performance bugs and one disassembler bug.

        - B3 now turns Branches into Jumps when they are dominated by a Check on the same
          condition. This is like the opposite of foldPathConstants() was doing.

        - Air now supports adding to 8-bit or 16-bit memory locations on x86. B3 now knows how to
          lower Store8(Add(Load8Z(...))) and various other things to these new instructions.

        - Disassembler now knows to print out the instruction's width, whenever it has one.
          Previously, we'd print movb, movw, movl, and movq as "mov", which is unhelpful if
          you're storing an immediate, for example.

        This adds a bunch of tests for the new instruction forms. This is a big speed-up on
        mandreel. It makes us just as fast as LLVM on that benchmark.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::add32):
        (JSC::MacroAssemblerX86Common::add8):
        (JSC::MacroAssemblerX86Common::add16):
        (JSC::MacroAssemblerX86Common::add32AndSetFlags):
        (JSC::MacroAssemblerX86Common::clz32AfterBsr):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::addl_rm):
        (JSC::X86Assembler::addb_rm):
        (JSC::X86Assembler::addw_rm):
        (JSC::X86Assembler::addl_ir):
        (JSC::X86Assembler::addl_im):
        (JSC::X86Assembler::addb_im):
        (JSC::X86Assembler::addw_im):
        (JSC::X86Assembler::addq_rr):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::addr):
        (JSC::B3::Air::LowerToAir::loadPromiseAnyOpcode):
        (JSC::B3::Air::LowerToAir::loadPromise):
        (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3PureCSE.cpp:
        (JSC::B3::PureCSE::clear):
        (JSC::B3::PureCSE::findMatch):
        (JSC::B3::PureCSE::process):
        * b3/B3PureCSE.h:
        * b3/B3ReduceStrength.cpp:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testNegPtr):
        (JSC::B3::testStoreAddLoad32):
        (JSC::B3::testStoreAddLoadImm32):
        (JSC::B3::testStoreAddLoad8):
        (JSC::B3::testStoreAddLoadImm8):
        (JSC::B3::testStoreAddLoad16):
        (JSC::B3::testStoreAddLoadImm16):
        (JSC::B3::testStoreAddLoad64):
        (JSC::B3::testStoreAddLoadImm64):
        (JSC::B3::testStoreAddLoad32Index):
        (JSC::B3::testStoreAddLoadImm32Index):
        (JSC::B3::testStoreAddLoad8Index):
        (JSC::B3::testStoreAddLoadImm8Index):
        (JSC::B3::testStoreAddLoad16Index):
        (JSC::B3::testStoreAddLoadImm16Index):
        (JSC::B3::testStoreAddLoad64Index):
        (JSC::B3::testStoreAddLoadImm64Index):
        (JSC::B3::testStoreSubLoad):
        (JSC::B3::run):
        (JSC::B3::testStoreAddLoad): Deleted.
        * disassembler/udis86/udis86_syn-att.c:
        (ud_translate_att):

2016-01-25  Alex Christensen  <achristensen@webkit.org>

        [Win] Copy forwarding headers before building a project
        https://bugs.webkit.org/show_bug.cgi?id=153434

        Reviewed by Brent Fulgham.

        * CMakeLists.txt:
        * PlatformWin.cmake:

2016-01-25  Andreas Kling  <akling@apple.com>

        Reduce number of Structures created at startup.
        <https://webkit.org/b/153399>

        Reviewed by Darin Adler.

        For *Constructor and *Prototype objects that are only created once per JSGlobalObject,
        build up the Structures using addPropertyWithoutTransition() helpers to avoid creating
        tons of transitions that would just end up floating around and never getting used.

        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        * runtime/ConsolePrototype.cpp:
        (JSC::ConsolePrototype::finishCreation):
        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::finishCreation):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::JSArrayBufferConstructor::finishCreation):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::JSArrayBufferPrototype::finishCreation):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putDirectNativeFunctionWithoutTransition):
        (JSC::JSObject::putDirectBuiltinFunctionWithoutTransition): Deleted.
        * runtime/JSObject.h:
        * runtime/JSPromiseConstructor.cpp:
        (JSC::JSPromiseConstructor::addOwnInternalSlots):
        * runtime/JSPromisePrototype.cpp:
        (JSC::JSPromisePrototype::addOwnInternalSlots):
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::JSTypedArrayViewConstructor::finishCreation):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototype::finishCreation):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/NumberPrototype.cpp:
        (JSC::NumberPrototype::finishCreation):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        * runtime/ObjectPrototype.cpp:
        (JSC::ObjectPrototype::finishCreation):
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototype::finishCreation):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        * runtime/WeakMapPrototype.cpp:
        (JSC::WeakMapPrototype::finishCreation):
        * runtime/WeakSetPrototype.cpp:
        (JSC::WeakSetPrototype::finishCreation):

2016-01-22  Filip Pizlo  <fpizlo@apple.com>

        B3 should strength-reduce division by a constant
        https://bugs.webkit.org/show_bug.cgi?id=153386

        Reviewed by Benjamin Poulain.

        You can turn a 32-bit division by a constant into a 64-bit multiplication by a constant
        plus some shifts. A book called "Hacker's Delight" has a bunch of math about this. The
        hard part is finding the constant by which to multiply, and the amount by which to shift.
        The book tells you some theroems, but you still have to turn that into code by thinking
        deep thoughts. Luckily I was able to avoid that because it turns out that LLVM already
        has code for this. It's called APInt::magic(), where APInt is their class for reasoning
        about integers.

        The code has a compatible license to ours and we have already in the past taken code from
        LLVM. So, that's what this patch does. The LLVM code is localized in
        B3ComputeDivisionMagic.h. Then reduceStrength() uses that to construct the multiply+shift
        sequence.

        This is an enormous speed-up on AsmBench-0.9/bigfib.cpp.js. It makes us as fast on that
        test as LLVM. It reduces our deficit on AsmBench to 1.5%. Previously it was 4.5%.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3ComputeDivisionMagic.h: Added.
        (JSC::B3::computeDivisionMagic):
        * b3/B3ReduceStrength.cpp:

2016-01-22  Saam barati  <sbarati@apple.com>

        genericUnwind might overflow the instructions() vector when catching an FTL exception
        https://bugs.webkit.org/show_bug.cgi?id=153383

        Reviewed by Benjamin Poulain.

        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):

2016-01-22  Mark Lam  <mark.lam@apple.com>

        We should OSR exit with Int52Overflow when we fail to make an Int52 where we expect one.
        https://bugs.webkit.org/show_bug.cgi?id=153379

        Reviewed by Filip Pizlo.

        In DFG::Graph::addShouldSpeculateMachineInt(), we check
        !hasExitSite(add, Int52Overflow) when determining whether it's ok to speculate
        that an operand is of type Int52 or not.  However, the Int52Rep code that
        converts a double to Int52 will OSR exit with exit kind BadType instead.
        This renders the hasExitSite() check in addShouldSpeculateMachineInt() useless.
        This patch fixes this by changing Int52Rep to OSR exit with exit kind
        Int52Overflow instead when it fails to convert a double to an Int52.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
        (JSC::DFG::SpeculativeJIT::typeCheck):
        (JSC::DFG::SpeculativeJIT::usedRegisters):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::needsTypeCheck):
        (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::typeCheck):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendTypeCheck):
        (JSC::FTL::DFG::LowerDFGToLLVM::doubleToStrictInt52):

2016-01-22  Saam barati  <sbarati@apple.com>

        Current implementation of Parser::createSavePoint is a foot gun
        https://bugs.webkit.org/show_bug.cgi?id=153293

        Reviewed by Oliver Hunt.

        The previous use of SavePoint (up until this patch)
        really meant that we're saving the LexerState. This
        was so poorly named that it was being misused all over
        our parser. For example, anything that parsed an
        AssignmentExpression between saving/restoring really
        wanted to save both Lexer state and Parser state.

        This patch changes SavePoint to mean save all the
        state. The old SavePoint is renamed to LexerState with
        corresponding internal<Save/Restore>LexerState functions.
        The old <save/restore>State() function is renamed to
        internal<Save/Restore>ParserState().

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::isArrowFunctionParameters):
        (JSC::Parser<LexerType>::parseSourceElements):
        (JSC::Parser<LexerType>::declareRestOrNormalParameter):
        (JSC::Parser<LexerType>::parseAssignmentElement):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        (JSC::Parser<LexerType>::parseForStatement):
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseExpression):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseYieldExpression):
        (JSC::Parser<LexerType>::parseConditionalExpression):
        (JSC::Parser<LexerType>::parseBinaryExpression):
        (JSC::Parser<LexerType>::parseObjectLiteral):
        (JSC::Parser<LexerType>::parseStrictObjectLiteral):
        (JSC::Parser<LexerType>::parseArrayLiteral):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):
        (JSC::Parser<LexerType>::parseUnaryExpression):
        * parser/Parser.h:
        (JSC::Parser::hasError):
        (JSC::Parser::internalSaveParserState):
        (JSC::Parser::restoreParserState):
        (JSC::Parser::internalSaveLexerState):
        (JSC::Parser::restoreLexerState):
        (JSC::Parser::createSavePointForError):
        (JSC::Parser::createSavePoint):
        (JSC::Parser::restoreSavePointWithError):
        (JSC::Parser::restoreSavePoint):
        (JSC::Parser::saveState): Deleted.
        (JSC::Parser::restoreState): Deleted.

2016-01-22  Keith Miller  <keith_miller@apple.com>

        Unreviewed. fnormal => normal.

        * tests/es6.yaml:

2016-01-22  Keith Miller  <keith_miller@apple.com>

        Unreviewed. Forgot to git stash pop some of the changes.
        This should mark the rest of the es6 tests as passing.

        * tests/es6.yaml:

2016-01-22  Keith Miller  <keith_miller@apple.com>

        Unreviewed. Mark es6 tests as passing.

        * tests/es6.yaml:

2016-01-22  Saam barati  <sbarati@apple.com>

        op_profile_type 32-bit LLInt implementation has a bug
        https://bugs.webkit.org/show_bug.cgi?id=153368

        Reviewed by Michael Saboff.

        r189293 changed which registers were used, specifically
        using t5 instead of t4. That change forgot to replace
        t4 with t5 in one specific instance.

        * llint/LowLevelInterpreter32_64.asm:

2016-01-22  Filip Pizlo  <fpizlo@apple.com>

        B3 should reduce obvious forms of Shl(SShr)
        https://bugs.webkit.org/show_bug.cgi?id=153362

        Reviewed by Mark Lam and Saam Barati.

        This is a 40% speed-up in AsmBench-0.9/dry.c.js.

        * b3/B3ReduceStrength.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testStore16Load16Z):
        (JSC::B3::testSShrShl32):
        (JSC::B3::testSShrShl64):
        (JSC::B3::zero):
        (JSC::B3::run):

2016-01-22  Alex Christensen  <achristensen@webkit.org>

        Fix internal Windows build
        https://bugs.webkit.org/show_bug.cgi?id=153364
        <rdar://problem/24296328>

        Reviewed by Brent Fulgham.

        * PlatformWin.cmake:
        The internal build does not build JavaScriptCore with WTF, so it does not automatically link to winmm.lib
        like it does when everything is built together.

2016-01-22  Keith Miller  <keith_miller@apple.com>

        Equivalence PropertyCondition needs to check the offset it uses to load the value from is not invalidOffset
        https://bugs.webkit.org/show_bug.cgi?id=152912

        Reviewed by Mark Lam.

        When checking the validity of an Equivalence PropertyCondition we do not check that the offset returned by
        the structure of the object in the equivalence condition is valid. The offset might be wrong for many reasons.
        The one we now test for is when the GlobalObject has a property that becomes a variable the property is deleted
        thus the offset is now invalid.

        * bytecode/PropertyCondition.cpp:
        (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint):
        * tests/stress/global-property-into-variable-get-from-scope.js: Added.

2016-01-22  Keith Miller  <keith_miller@apple.com>

        [ES6] Add Symbol.species properties to the relevant constructors
        https://bugs.webkit.org/show_bug.cgi?id=153339

        Reviewed by Michael Saboff.

        This patch adds Symbol.species to the RegExp, Array, TypedArray, Map, Set, ArrayBuffer, and
        Promise constructors.  The functions that use these properties will be added in a later
        patch.

        * builtins/GlobalObject.js:
        (speciesGetter):
        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        * runtime/ArrayConstructor.h:
        (JSC::ArrayConstructor::create):
        * runtime/BooleanConstructor.h:
        (JSC::BooleanConstructor::create):
        * runtime/CommonIdentifiers.h:
        * runtime/DateConstructor.h:
        (JSC::DateConstructor::create):
        * runtime/ErrorConstructor.h:
        (JSC::ErrorConstructor::create):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::JSArrayBufferConstructor::finishCreation):
        (JSC::JSArrayBufferConstructor::create):
        * runtime/JSArrayBufferConstructor.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSInternalPromiseConstructor.cpp:
        (JSC::JSInternalPromiseConstructor::create):
        * runtime/JSInternalPromiseConstructor.h:
        * runtime/JSPromiseConstructor.cpp:
        (JSC::JSPromiseConstructor::create):
        (JSC::JSPromiseConstructor::finishCreation):
        * runtime/JSPromiseConstructor.h:
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::JSTypedArrayViewConstructor::finishCreation):
        (JSC::JSTypedArrayViewConstructor::create): Deleted.
        * runtime/JSTypedArrayViewConstructor.h:
        (JSC::JSTypedArrayViewConstructor::create):
        * runtime/MapConstructor.cpp:
        (JSC::MapConstructor::finishCreation):
        * runtime/MapConstructor.h:
        (JSC::MapConstructor::create):
        * runtime/NumberConstructor.h:
        (JSC::NumberConstructor::create):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::finishCreation):
        * runtime/RegExpConstructor.h:
        (JSC::RegExpConstructor::create):
        * runtime/SetConstructor.cpp:
        (JSC::SetConstructor::finishCreation):
        * runtime/SetConstructor.h:
        (JSC::SetConstructor::create):
        * runtime/StringConstructor.h:
        (JSC::StringConstructor::create):
        * runtime/SymbolConstructor.h:
        (JSC::SymbolConstructor::create):
        * runtime/WeakMapConstructor.h:
        (JSC::WeakMapConstructor::create):
        * runtime/WeakSetConstructor.h:
        (JSC::WeakSetConstructor::create):
        * tests/stress/symbol-species.js: Added.
        (testSymbolSpeciesOnConstructor):

2016-01-21  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] The IRC allocator can mess up the degree of Tmps interfering with move-related Tmps
        https://bugs.webkit.org/show_bug.cgi?id=153340

        Reviewed by Filip Pizlo.

        The JavaScriptCore tests uncovered an interested bug in the iterated register
        coalescing allocator. When coalescing a move under the right conditions, it is
        possible to mess-up the graph for the Tmps interfering with the coalesced Tmps.

        Some context first:
        -When coalescing a move, we alias one Tmp to another. Let say that we had
             Move X, Y
         the coalescing may alias Y to X: Y->X.
        -Since X and Y are equivalent after coalescing, any interference
         edge with Y is "moved" to X.
         The way this was done was to add an edge to X for every edge there was with Y.
         Say we had an edge R--Y, we add an edge R--X.
         Adding an edge increases the degree of R and Y. The degree of R was then
         fixed by calling decrementDegree() on it.
        -decrementDegree() is non trivial. It will move the Tmp to the right list
         for further processing if the Tmp's degree becomes lower than the number
         of available registers.

        The bug appear in a particular case. Say we have 3 Tmp, A, B, and C.
        -A and B are move related, they can be coalesced.
        -A has an interference edge with C.
        -B does not have and interfence edge with C.
        -C's degree is exactly the number of avaialble registers/colors minus one (k - 1).
         -> This implies C is already in its list.

        We coalesce A and B into B (A->B).
        -The first step, addEdgeDistinct() adds an edge between B and C. The degrees of
         B and C are increased by one. The degree of C becomes k.
        -Next, decrementDegree() is called on C. Its degree decreases to k-1.
         Because of the change from k to k-1, decrementDegree() adds C to a list again.

        We have two kinds of bugs depending on the test:
        -A Tmp can be added to the simplifyWorklist several time.
        -A Tmp can be in both simplifyWorklist and freezeWorklist (because its move-related
         status changed since the last decrementDegree()).
        In both cases, the Tmps interfering with the duplicated Tmp will end up with
        a degree lower than their real value.

        * b3/air/AirIteratedRegisterCoalescing.cpp:

2016-01-21  Andreas Kling  <akling@apple.com>

        Add some missing WTF_MAKE_FAST_ALLOCATED in JavaScriptCore.
        <https://webkit.org/b/153335>

        Reviewed by Alex Christensen.

        Saw these things getting system malloc()'ed in an Instruments trace.

        * inspector/InspectorAgentBase.h:
        * jit/CallFrameShuffleData.h:
        * jit/CallFrameShuffler.h:
        * jit/RegisterAtOffsetList.h:
        * runtime/GenericOffset.h:

2016-01-21  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Catch parameter should accept BindingPattern
        https://bugs.webkit.org/show_bug.cgi?id=152385

        Reviewed by Saam Barati.

        This patch implements destructuring in catch parameter.
        Catch parameter accepts binding pattern and binding identifier.
        It creates lexical bindings. And "yield" and "let" are specially
        handled as is the same to function parameters.

        In addition to that, we make destructuring parsing errors more descriptive.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitPushCatchScope):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::TryNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createTryStatement):
        * parser/NodeConstructors.h:
        (JSC::TryNode::TryNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::createBindingPattern):
        (JSC::Parser<LexerType>::tryParseDestructuringPatternExpression):
        (JSC::Parser<LexerType>::parseBindingOrAssignmentElement):
        (JSC::destructuringKindToVariableKindName):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        (JSC::Parser<LexerType>::parseTryStatement):
        (JSC::Parser<LexerType>::parseFormalParameters):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        * parser/Parser.h:
        (JSC::Parser::destructuringKindFromDeclarationType):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createTryStatement):
        * tests/es6.yaml:
        * tests/es6/destructuring_in_catch_heads.js: Added.
        (test):
        * tests/stress/catch-parameter-destructuring.js: Added.
        (shouldBe):
        (shouldThrow):
        (prototype.call):
        (catch):
        (shouldThrow.try.throw.get error):
        (initialize):
        (array):
        (generator.gen):
        (generator):
        * tests/stress/catch-parameter-syntax.js: Added.
        (testSyntax):
        (testSyntaxError):
        * tests/stress/reserved-word-with-escape.js:
        (testSyntaxError.String.raw.a):
        (String.raw.SyntaxError.Cannot.use.the.keyword.string_appeared_here.as.a.name):
        * tests/stress/yield-named-variable.js:

2016-01-21  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix build.

        * b3/B3EliminateCommonSubexpressions.cpp:

2016-01-21  Filip Pizlo  <fpizlo@apple.com>

        B3 CSE should be able to match a full redundancy even if none of the matches dominate the value in question
        https://bugs.webkit.org/show_bug.cgi?id=153321

        Reviewed by Benjamin Poulain.

        I once learned that LLVM's GVN can manufacture Phi functions. I don't know the details
        but I'm presuming that it involves:

            if (p)
                tmp1 = *ptr
            else
                tmp2 = *ptr
            tmp3 = *ptr // Replace this with Phi(tmp1, tmp2).

        This adds such an optimization to our CSE. The idea is that we search through basic
        blocks until we find the value we want, a side effect, or the start of the procedure. If
        we find a value that matches our search criteria, we record it and ignore the
        predecessors. If we find a side effect or the start of the procedure, we give up the
        whole search. This ensures that if we come out of the search without giving up, we'll
        have a set of matches that are fully redundant.

        CSE could then create a Phi graph by using SSACalculator. But the recent work on FixSSA
        revealed a much more exciting option: create a stack slot! In case there is more than one
        match, CSE now creates a stack slot that each match stores to, and replaces the redundant
        instruction with a loadfrom the stack slot. The stack slot is anonymous, which ensures
        that FixSSA will turn it into an optimal Phi graph or whatever.

        This is a significant speed-up on Octane/richards.

        * b3/B3DuplicateTails.cpp:
        * b3/B3EliminateCommonSubexpressions.cpp:
        * b3/B3FixSSA.cpp:
        (JSC::B3::fixSSA):
        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::setFrontendData):
        (JSC::B3::Procedure::frontendData):
        * b3/testb3.cpp:
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):

2016-01-21  Filip Pizlo  <fpizlo@apple.com>

        Air should know that CeilDouble has the partial register stall issue
        https://bugs.webkit.org/show_bug.cgi?id=153338

        Rubber stamped by Benjamin Poulain.

        This is a 8% speed-up on Kraken with B3 enabled, mostly because of a 2.4x speed-up on
        audio-oscillator.

        * b3/air/AirFixPartialRegisterStalls.cpp:

2016-01-21  Andy VanWagoner  <andy@instructure.com>

        [INTL] Implement Array.prototype.toLocaleString in ECMA-402
        https://bugs.webkit.org/show_bug.cgi?id=147614

        Reviewed by Benjamin Poulain.

        The primary changes in the ECMA-402 version, and the existing implementation
        are passing the arguments on to each element's toLocaleString call, and
        missing/undefined/null elements become empty string instead of being skipped.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncToLocaleString):

2016-01-21  Per Arne Vollan  <peavo@outlook.com>

        [B3][Win64] Compile fixes.
        https://bugs.webkit.org/show_bug.cgi?id=153312

        Reviewed by Alex Christensen.

        Since MSVC has several overloads of sin, cos, pow, and log, we need to specify
        which one we want to use.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::doubleSin):
        (JSC::FTL::Output::doubleCos):
        (JSC::FTL::Output::doublePow):
        (JSC::FTL::Output::doubleLog):

2016-01-21  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] foldPathConstants() makes invalid assumptions with Switch
        https://bugs.webkit.org/show_bug.cgi?id=153324

        Reviewed by Filip Pizlo.

        If a Switch() has two cases pointing to the same basic block, foldPathConstants()
        was adding two override for that block with two different constants.
        If the block with the Switch dominates the target, both override were equally valid
        and we were assuming any of the constants as the value in the target block.

        See testSwitchTargettingSameBlockFoldPathConstant() for an example that breaks.

        This patch adds checks to ignore any block that is reached more than
        once by the control value.

        * b3/B3FoldPathConstants.cpp:
        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir):
        * b3/testb3.cpp:
        (JSC::B3::testSwitchTargettingSameBlock):
        (JSC::B3::testSwitchTargettingSameBlockFoldPathConstant):
        (JSC::B3::run):

2016-01-21  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, undo DFGCommon.h change that accidentally enabled the B3 JIT.

        * dfg/DFGCommon.h:

2016-01-21  Filip Pizlo  <fpizlo@apple.com>

        Move32 should have an Imm, Tmp form
        https://bugs.webkit.org/show_bug.cgi?id=153313

        Reviewed by Mark Lam.

        This enables some useful optimizations, like constant propagation in fixObviousSpills().

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::zeroExtend32ToPtr):
        (JSC::MacroAssemblerX86Common::move):
        * b3/air/AirOpcode.opcodes:

2016-01-21  Filip Pizlo  <fpizlo@apple.com>

        B3 should have load elimination
        https://bugs.webkit.org/show_bug.cgi?id=153288

        Reviewed by Geoffrey Garen.

        This adds a complete GCSE pass that includes load elimination. It would have been super hard
        to make this work as part of the reduceStrength() fixpoint, since GCSE needs to analyze
        control flow and reduceStrength() is messing with control flow. So, I did a compromise: I
        factored out the pure CSE that reduceStrength() was already doing, and now we have:

        - reduceStrength() still does pure CSE using the new PureCSE helper.

        - eliminateCommonSubexpressions() is a separate phase that does general CSE. It uses the
          PureCSE helper for pure values and does its own special thing for memory values.
        
        Unfortunately, this doesn't help any benchmark right now. It doesn't hurt anything, either,
        and it's likely to become a bigger pay-off once we implement other features, like mapping
        FTL's abstract heaps onto B3's heap ranges.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3EliminateCommonSubexpressions.cpp: Added.
        (JSC::B3::eliminateCommonSubexpressions):
        * b3/B3EliminateCommonSubexpressions.h: Added.
        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir):
        * b3/B3HeapRange.h:
        (JSC::B3::HeapRange::HeapRange):
        * b3/B3InsertionSet.h:
        (JSC::B3::InsertionSet::InsertionSet):
        (JSC::B3::InsertionSet::isEmpty):
        (JSC::B3::InsertionSet::code):
        (JSC::B3::InsertionSet::appendInsertion):
        * b3/B3MemoryValue.h:
        * b3/B3PureCSE.cpp: Added.
        (JSC::B3::PureCSE::PureCSE):
        (JSC::B3::PureCSE::~PureCSE):
        (JSC::B3::PureCSE::clear):
        (JSC::B3::PureCSE::process):
        * b3/B3PureCSE.h: Added.
        * b3/B3ReduceStrength.cpp:
        * b3/B3ReduceStrength.h:
        * b3/B3Validate.cpp:

2016-01-21  Keith Miller  <keith_miller@apple.com>

        Fix bug in TypedArray.prototype.set and add tests
        https://bugs.webkit.org/show_bug.cgi?id=153309

        Reviewed by Michael Saboff.

        This patch fixes an issue with TypedArray.prototype.set where we would
        assign a double to an unsigned without checking that the double was
        in the range of the unsigned. Additionally, the patch also adds
        tests for set for cases that were not covered before.

        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncSet):
        * tests/stress/typedarray-set.js: Added.

2016-01-19  Ada Chan  <adachan@apple.com>

        Make it possible to enable VIDEO_PRESENTATION_MODE on other Cocoa platforms.
        https://bugs.webkit.org/show_bug.cgi?id=153218

        Reviewed by Eric Carlson.

        * Configurations/FeatureDefines.xcconfig:

2016-01-21  Per Arne Vollan  <peavo@outlook.com>

        [B3][CMake] Add missing source file.
        https://bugs.webkit.org/show_bug.cgi?id=153303

        Reviewed by Csaba Osztrogonác.

        * CMakeLists.txt:

2016-01-20  Commit Queue  <commit-queue@webkit.org>

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

        Caused crashes on GuardMalloc (Requested by ap on #webkit).

        Reverted changeset:

        "TypedArray's .buffer does not return the JSArrayBuffer that
        was passed to it on creation."
        https://bugs.webkit.org/show_bug.cgi?id=153281
        http://trac.webkit.org/changeset/195375

2016-01-19  Filip Pizlo  <fpizlo@apple.com>

        B3 should have basic path specialization
        https://bugs.webkit.org/show_bug.cgi?id=153200

        Reviewed by Benjamin Poulain.

        This adds two different kind of path specializations:

        - Check(Select) where the Select results are constants is specialized into a Branch
          instead of a Select and duplicated paths where the results of the Select are folded.

        - Tail duplication. A jump to a small block causes the block's contents to be copied over
          the Jump.

        Both optimizations required being able to clone Values. We can now do that using
        proc.clone(value).

        Check(Select) specialization needed some utilities for walking graphs of Values.

        Tail duplication needed SSA fixup, so I added a way to demote values to anonymous stack
        slots (B3's equivalent of non-SSA variables) and a way to "fix SSA", i.e. to allocate
        anonymous stack slots to SSA values along with an optimal Phi graph.

        This is a big speed-up on Octane/deltablue. It's a 2.2% speed-up on Octane overall.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3ArgumentRegValue.cpp:
        (JSC::B3::ArgumentRegValue::dumpMeta):
        (JSC::B3::ArgumentRegValue::cloneImpl):
        * b3/B3ArgumentRegValue.h:
        * b3/B3BasicBlock.cpp:
        (JSC::B3::BasicBlock::append):
        (JSC::B3::BasicBlock::appendNonTerminal):
        (JSC::B3::BasicBlock::removeLast):
        * b3/B3BasicBlock.h:
        (JSC::B3::BasicBlock::values):
        * b3/B3BasicBlockInlines.h:
        (JSC::B3::BasicBlock::appendNew):
        (JSC::B3::BasicBlock::appendNewNonTerminal):
        (JSC::B3::BasicBlock::replaceLastWithNew):
        * b3/B3BlockInsertionSet.h:
        * b3/B3BreakCriticalEdges.cpp: Added.
        (JSC::B3::breakCriticalEdges):
        * b3/B3BreakCriticalEdges.h: Added.
        * b3/B3CCallValue.cpp:
        (JSC::B3::CCallValue::~CCallValue):
        (JSC::B3::CCallValue::cloneImpl):
        * b3/B3CCallValue.h:
        * b3/B3CheckValue.cpp:
        (JSC::B3::CheckValue::convertToAdd):
        (JSC::B3::CheckValue::cloneImpl):
        (JSC::B3::CheckValue::CheckValue):
        * b3/B3CheckValue.h:
        * b3/B3Const32Value.cpp:
        (JSC::B3::Const32Value::dumpMeta):
        (JSC::B3::Const32Value::cloneImpl):
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.cpp:
        (JSC::B3::Const64Value::dumpMeta):
        (JSC::B3::Const64Value::cloneImpl):
        * b3/B3Const64Value.h:
        * b3/B3ConstDoubleValue.cpp:
        (JSC::B3::ConstDoubleValue::dumpMeta):
        (JSC::B3::ConstDoubleValue::cloneImpl):
        * b3/B3ConstDoubleValue.h:
        * b3/B3ConstFloatValue.cpp:
        (JSC::B3::ConstFloatValue::dumpMeta):
        (JSC::B3::ConstFloatValue::cloneImpl):
        * b3/B3ConstFloatValue.h:
        * b3/B3ControlValue.cpp:
        (JSC::B3::ControlValue::dumpMeta):
        (JSC::B3::ControlValue::cloneImpl):
        * b3/B3ControlValue.h:
        * b3/B3DuplicateTails.cpp: Added.
        (JSC::B3::duplicateTails):
        * b3/B3DuplicateTails.h: Added.
        * b3/B3FixSSA.cpp: Added.
        (JSC::B3::demoteValues):
        (JSC::B3::fixSSA):
        * b3/B3FixSSA.h: Added.
        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir):
        * b3/B3IndexSet.h:
        (JSC::B3::IndexSet::Iterable::Iterable):
        (JSC::B3::IndexSet::values):
        (JSC::B3::IndexSet::indices):
        * b3/B3InsertionSet.cpp:
        (JSC::B3::InsertionSet::insertIntConstant):
        (JSC::B3::InsertionSet::insertBottom):
        (JSC::B3::InsertionSet::execute):
        * b3/B3InsertionSet.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::tmp):
        * b3/B3MemoryValue.cpp:
        (JSC::B3::MemoryValue::dumpMeta):
        (JSC::B3::MemoryValue::cloneImpl):
        * b3/B3MemoryValue.h:
        * b3/B3OriginDump.cpp: Added.
        (JSC::B3::OriginDump::dump):
        * b3/B3OriginDump.h:
        (JSC::B3::OriginDump::OriginDump):
        (JSC::B3::OriginDump::dump): Deleted.
        * b3/B3PatchpointValue.cpp:
        (JSC::B3::PatchpointValue::dumpMeta):
        (JSC::B3::PatchpointValue::cloneImpl):
        (JSC::B3::PatchpointValue::PatchpointValue):
        * b3/B3PatchpointValue.h:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::addBlock):
        (JSC::B3::Procedure::clone):
        (JSC::B3::Procedure::addIntConstant):
        (JSC::B3::Procedure::addBottom):
        (JSC::B3::Procedure::addBoolConstant):
        (JSC::B3::Procedure::deleteValue):
        * b3/B3Procedure.h:
        * b3/B3ReduceStrength.cpp:
        * b3/B3SSACalculator.cpp: Added.
        (JSC::B3::SSACalculator::Variable::dump):
        (JSC::B3::SSACalculator::Variable::dumpVerbose):
        (JSC::B3::SSACalculator::Def::dump):
        (JSC::B3::SSACalculator::SSACalculator):
        (JSC::B3::SSACalculator::~SSACalculator):
        (JSC::B3::SSACalculator::reset):
        (JSC::B3::SSACalculator::newVariable):
        (JSC::B3::SSACalculator::newDef):
        (JSC::B3::SSACalculator::nonLocalReachingDef):
        (JSC::B3::SSACalculator::reachingDefAtTail):
        (JSC::B3::SSACalculator::dump):
        * b3/B3SSACalculator.h: Added.
        (JSC::B3::SSACalculator::Variable::index):
        (JSC::B3::SSACalculator::Variable::Variable):
        (JSC::B3::SSACalculator::Def::variable):
        (JSC::B3::SSACalculator::Def::block):
        (JSC::B3::SSACalculator::Def::value):
        (JSC::B3::SSACalculator::Def::Def):
        (JSC::B3::SSACalculator::variable):
        (JSC::B3::SSACalculator::computePhis):
        (JSC::B3::SSACalculator::phisForBlock):
        (JSC::B3::SSACalculator::reachingDefAtHead):
        * b3/B3StackSlotKind.h:
        * b3/B3StackSlotValue.cpp:
        (JSC::B3::StackSlotValue::dumpMeta):
        (JSC::B3::StackSlotValue::cloneImpl):
        * b3/B3StackSlotValue.h:
        * b3/B3SwitchValue.cpp:
        (JSC::B3::SwitchValue::dumpMeta):
        (JSC::B3::SwitchValue::cloneImpl):
        (JSC::B3::SwitchValue::SwitchValue):
        * b3/B3SwitchValue.h:
        * b3/B3UpsilonValue.cpp:
        (JSC::B3::UpsilonValue::dumpMeta):
        (JSC::B3::UpsilonValue::cloneImpl):
        * b3/B3UpsilonValue.h:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::replaceWithNop):
        (JSC::B3::Value::replaceWithPhi):
        (JSC::B3::Value::dump):
        (JSC::B3::Value::cloneImpl):
        (JSC::B3::Value::dumpChildren):
        (JSC::B3::Value::deepDump):
        * b3/B3Value.h:
        (JSC::B3::DeepValueDump::DeepValueDump):
        (JSC::B3::DeepValueDump::dump):
        (JSC::B3::deepDump):
        * b3/B3ValueInlines.h:
        (JSC::B3::Value::asNumber):
        (JSC::B3::Value::walk):
        * b3/B3ValueKey.cpp:
        (JSC::B3::ValueKey::intConstant):
        (JSC::B3::ValueKey::dump):
        * b3/B3ValueKey.h:
        (JSC::B3::ValueKey::ValueKey):
        (JSC::B3::ValueKey::opcode):
        (JSC::B3::ValueKey::type):
        (JSC::B3::ValueKey::childIndex):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::forAllTmps):
        (JSC::B3::Air::Code::isFastTmp):
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * b3/air/AirUseCounts.h:
        (JSC::B3::Air::UseCounts::UseCounts):
        (JSC::B3::Air::UseCounts::operator[]):
        (JSC::B3::Air::UseCounts::dump):
        * b3/testb3.cpp:
        (JSC::B3::testSelectInvert):
        (JSC::B3::testCheckSelect):
        (JSC::B3::testCheckSelectCheckSelect):
        (JSC::B3::testPowDoubleByIntegerLoop):
        (JSC::B3::run):
        * runtime/Options.h:

2016-01-20  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Fix a typo in the Air definition of CeilDouble/CeilFloat
        https://bugs.webkit.org/show_bug.cgi?id=153286

        Reviewed by Mark Lam.

        * b3/air/AirOpcode.opcodes:
        The second argument should a Def. The previous definition was
        adding useless constraints on the allocation of the second argument.

2016-01-20  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] The register allocator can use a dangling pointer when selecting a spill candidate
        https://bugs.webkit.org/show_bug.cgi?id=153287

        Reviewed by Mark Lam.

        A tricky bug I discovered while experimenting with live range breaking.

        We have the following initial conditions:
        -UseCounts is slow, so we only compute it once for all the iterations
         of the allocator.
        -The only new Tmps we create are for spills and refills. They are unspillable
         by definition so it is fine to not update UseCounts accordingly.

        But, in selectSpill(), we go over all the spill candidates and select the best
        one based on its score. The score() lambda uses useCounts, it cannot be used
        with a new Tmps created for something we already spilled.

        The first time we use score is correct, we started by skipping all the unspillable
        Tmps from the candidate. The next use was incorrect: we were checking unspillableTmps
        *after* calling score().

        The existing tests did not catch this due to back luck. I added an assertion
        to find similar problems in the future.

        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * b3/air/AirUseCounts.h:

2016-01-20  Saam barati  <sbarati@apple.com>

        Fix CLoop build after bug https://bugs.webkit.org/show_bug.cgi?id=152766

        Unreviewed build fix.

        * inspector/agents/InspectorScriptProfilerAgent.h:

2016-01-20  Andy VanWagoner  <thetalecrafter@gmail.com>

        [INTL] Implement Date.prototype.toLocaleTimeString in ECMA-402
        https://bugs.webkit.org/show_bug.cgi?id=147613

        Reviewed by Darin Adler.

        Implement toLocaleTimeString in builtin JavaScript.

        * builtins/DatePrototype.js:
        (toLocaleTimeString.toDateTimeOptionsTimeTime):
        (toLocaleTimeString):
        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::finishCreation):

2016-01-20  Saam barati  <sbarati@apple.com>

        Web Inspector: Hook the sampling profiler into the Timelines UI
        https://bugs.webkit.org/show_bug.cgi?id=152766
        <rdar://problem/24066360>

        Reviewed by Joseph Pecoraro.

        This patch adds some necessary functions to SamplingProfiler::StackFrame
        to allow it to give data to the Inspector for the timelines UI. i.e, the
        sourceID of the executable of a stack frame.

        This patch also swaps in the SamplingProfiler in place of the
        LegacyProfiler inside InspectorScriptProfilerAgent. It adds
        the necessary protocol data to allow the SamplingProfiler's
        data to hook into the timelines UI.

        * debugger/Debugger.cpp:
        (JSC::Debugger::setProfilingClient):
        (JSC::Debugger::willEvaluateScript):
        (JSC::Debugger::didEvaluateScript):
        (JSC::Debugger::toggleBreakpoint):
        * debugger/Debugger.h:
        * debugger/ScriptProfilingScope.h:
        (JSC::ScriptProfilingScope::ScriptProfilingScope):
        (JSC::ScriptProfilingScope::~ScriptProfilingScope):
        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::willDestroyFrontendAndBackend):
        (Inspector::InspectorScriptProfilerAgent::startTracking):
        (Inspector::InspectorScriptProfilerAgent::stopTracking):
        (Inspector::InspectorScriptProfilerAgent::isAlreadyProfiling):
        (Inspector::InspectorScriptProfilerAgent::willEvaluateScript):
        (Inspector::InspectorScriptProfilerAgent::didEvaluateScript):
        (Inspector::InspectorScriptProfilerAgent::addEvent):
        (Inspector::buildSamples):
        (Inspector::InspectorScriptProfilerAgent::trackingComplete):
        (Inspector::buildAggregateCallInfoInspectorObject): Deleted.
        (Inspector::buildInspectorObject): Deleted.
        (Inspector::buildProfileInspectorObject): Deleted.
        * inspector/agents/InspectorScriptProfilerAgent.h:
        * inspector/protocol/ScriptProfiler.json:
        * jsc.cpp:
        (functionSamplingProfilerStackTraces):
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::start):
        (JSC::SamplingProfiler::stop):
        (JSC::SamplingProfiler::clearData):
        (JSC::SamplingProfiler::StackFrame::displayName):
        (JSC::SamplingProfiler::StackFrame::displayNameForJSONTests):
        (JSC::SamplingProfiler::StackFrame::startLine):
        (JSC::SamplingProfiler::StackFrame::startColumn):
        (JSC::SamplingProfiler::StackFrame::sourceID):
        (JSC::SamplingProfiler::StackFrame::url):
        (JSC::SamplingProfiler::stackTraces):
        (JSC::SamplingProfiler::stackTracesAsJSON):
        (JSC::displayName): Deleted.
        (JSC::SamplingProfiler::stacktracesAsJSON): Deleted.
        * runtime/SamplingProfiler.h:
        (JSC::SamplingProfiler::StackFrame::StackFrame):
        (JSC::SamplingProfiler::getLock):
        (JSC::SamplingProfiler::setTimingInterval):
        (JSC::SamplingProfiler::totalTime):
        (JSC::SamplingProfiler::setStopWatch):
        (JSC::SamplingProfiler::stackTraces): Deleted.
        * tests/stress/sampling-profiler-anonymous-function.js:
        (platformSupportsSamplingProfiler.baz):
        (platformSupportsSamplingProfiler):
        * tests/stress/sampling-profiler-basic.js:
        (platformSupportsSamplingProfiler.nothing):
        (platformSupportsSamplingProfiler.top):
        * tests/stress/sampling-profiler/samplingProfiler.js:
        (doesTreeHaveStackTrace):

2016-01-20  Keith Miller  <keith_miller@apple.com>

        TypedArray's .buffer does not return the JSArrayBuffer that was passed to it on creation.
        https://bugs.webkit.org/show_bug.cgi?id=153281

        Reviewed by Geoffrey Garen.

        When creating an JSArrayBuffer we should make sure that the backing ArrayBuffer uses the
        new JSArrayBuffer as its wrapper. This causes issues when we get the buffer of a Typed Array
        created by passing a JSArrayBuffer as the backing ArrayBuffer does not have a reference to
        the original JSArrayBuffer and a new object is created.

        * runtime/JSArrayBuffer.cpp:
        (JSC::JSArrayBuffer::finishCreation):
        * tests/stress/typedarray-buffer-neutered.js: Added.
        (arrays.typedArrays.map):

2016-01-20  Andreas Kling  <akling@apple.com>

        Pack RegisterAtOffset harder.
        <https://webkit.org/b/152501>

        Reviewed by Michael Saboff.

        Pack the register index and the offset into a single pointer-sized word instead of two.
        This reduces memory consumption by 620 kB on mobile theverge.com.

        The packing doesn't succeed on MSVC for some reason, so I've left out the static
        assertion about class size in those builds.

        * jit/RegisterAtOffset.cpp:
        * jit/RegisterAtOffset.h:

2016-01-20  Per Arne Vollan  <peavo@outlook.com>

        [B3][Win64] Compile fix.
        https://bugs.webkit.org/show_bug.cgi?id=153278

        Reviewed by Filip Pizlo.

        MSVC does not accept that a class declared as exported also have members declared as exported.

        * b3/B3Const32Value.h:
        * b3/B3ControlValue.h:

2016-01-19  Keith Miller  <keith_miller@apple.com>

        [ES6] Fix various issues with TypedArrays.
        https://bugs.webkit.org/show_bug.cgi?id=153245

        Reviewed by Geoffrey Garen.

        This patch fixes a couple of issues with TypedArrays:

        1) We were not checking if a view had been neutered and throwing an error
        if it had in the our TypedArray.prototype functions.

        2) The TypedArray.prototype.set function had a couple of minor issues with
        checking for the offset being negative.

        3) The JSArrayBufferView class did not check if the backing store had
        been neutered when computing the offset even though the view's vector
        pointer had been set to NULL. This meant that under some conditions we
        could, occasionally, return a garbage number as the offset. Now, we only
        neuter views if the backing ArrayBuffer's view is actually transfered.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionNeuterTypedArray):
        * runtime/JSArrayBufferView.h:
        (JSC::JSArrayBufferView::isNeutered):
        * runtime/JSArrayBufferViewInlines.h:
        (JSC::JSArrayBufferView::byteOffset):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncSet):
        (JSC::genericTypedArrayViewProtoFuncEntries):
        (JSC::genericTypedArrayViewProtoFuncCopyWithin):
        (JSC::genericTypedArrayViewProtoFuncFill):
        (JSC::genericTypedArrayViewProtoFuncIndexOf):
        (JSC::genericTypedArrayViewProtoFuncJoin):
        (JSC::genericTypedArrayViewProtoFuncKeys):
        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
        (JSC::genericTypedArrayViewProtoFuncReverse):
        (JSC::genericTypedArrayViewPrivateFuncSort):
        (JSC::genericTypedArrayViewProtoFuncSlice):
        (JSC::genericTypedArrayViewProtoFuncSubarray):
        (JSC::typedArrayViewProtoFuncValues):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewPrivateFuncLength):
        (JSC::typedArrayViewPrivateFuncSort): Deleted.
        * tests/stress/typedarray-functions-with-neutered.js: Added.
        (getGetter):
        (unit):
        (args.new.Int32Array):
        (arrays.typedArrays.map):
        (checkProtoFunc.throwsCorrectError):
        (checkProtoFunc):
        (test):

2016-01-19  Andy VanWagoner  <thetalecrafter@gmail.com>

        [INTL] Implement Date.prototype.toLocaleDateString in ECMA-402
        https://bugs.webkit.org/show_bug.cgi?id=147612

        Reviewed by Benjamin Poulain.

        Implement toLocaleDateString in builtin JavaScript. Remove comments with
        spec steps, and instead link to the new HTML version of the spec.

        Avoids creating an extra empty object in the prototype chain of the options
        object in ToDateTimeOptions. The version used in toLocaleString was updated
        to match as well.

        * builtins/DatePrototype.js:
        (toLocaleString.toDateTimeOptionsAnyAll):
        (toLocaleString):
        (toLocaleDateString.toDateTimeOptionsDateDate):
        (toLocaleDateString):
        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::finishCreation):

2016-01-19  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] fixSpillSlotZDef() crashes on ARM64
        https://bugs.webkit.org/show_bug.cgi?id=153246

        Reviewed by Geoffrey Garen.

        Moving an immediate to memory is not a valid instruction on ARM64.
        This patch adds a small workaround for this specific case: an instruction
        to zero a chunk of memory.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::storeZero32):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::storeZero32):
        * b3/air/AirFixSpillSlotZDef.h:
        (JSC::B3::Air::fixSpillSlotZDef):
        * b3/air/AirOpcode.opcodes:

2016-01-19  Enrica Casucci  <enrica@apple.com>

        Add support for DataDetectors in WK (iOS).
        https://bugs.webkit.org/show_bug.cgi?id=152989
        rdar://problem/22855960

        Reviewed by Tim Horton.

        Adding feature definition for data detection.

        * Configurations/FeatureDefines.xcconfig:

2016-01-19  Per Arne Vollan  <peavo@outlook.com>

        [B3][Win64] Compile and warning fixes.
        https://bugs.webkit.org/show_bug.cgi?id=153234

        Reviewed by Alex Christensen.

        The size of 'long' is 4 bytes on Win64. We can use 'long long' instead,
        when we want the size to be 8 bytes.

        * b3/B3LowerMacrosAfterOptimizations.cpp:
        * b3/B3ReduceStrength.cpp:

2016-01-19  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] Fix the B3 build after r195159
        https://bugs.webkit.org/show_bug.cgi?id=153232

        Reviewed by Yusuke Suzuki.

        * CMakeLists.txt:

2016-01-19  Commit Queue  <commit-queue@webkit.org>

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

        enrica wants more time to fix Windows (Requested by thorton on
        #webkit).

        Reverted changeset:

        "Add support for DataDetectors in WK (iOS)."
        https://bugs.webkit.org/show_bug.cgi?id=152989
        http://trac.webkit.org/changeset/195300

2016-01-19  Filip Pizlo  <fpizlo@apple.com>

        Reconsider B3's constant motion policy
        https://bugs.webkit.org/show_bug.cgi?id=152202

        Reviewed by Geoffrey Garen.

        This changes moveConstants() to hoist constants. This is a speed-up on things like mandreel.
        It has a generally positive impact on the Octane score, but it's within margin of error.

        This also changes IRC to make it a bit more likely to spill constants. We don't want it to
        spill them too much, because we can't rely on fixObviousSpills() to always replace a load of
        a constant from the stack with the constant itself, especially in case of instructions that
        need an extra register to materialize the immediate.

        Also fixed DFG graph dumping to print a bit less things. It was trying to print the results of
        constant property inference, and this sometimes caused crashes when you dumped the graph at an
        inopportune time.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3MoveConstants.cpp:
        * b3/air/AirArg.h:
        * b3/air/AirArgInlines.h: Added.
        (JSC::B3::Air::ArgThingHelper<Tmp>::is):
        (JSC::B3::Air::ArgThingHelper<Tmp>::as):
        (JSC::B3::Air::ArgThingHelper<Tmp>::forEachFast):
        (JSC::B3::Air::ArgThingHelper<Tmp>::forEach):
        (JSC::B3::Air::ArgThingHelper<Arg>::is):
        (JSC::B3::Air::ArgThingHelper<Arg>::as):
        (JSC::B3::Air::ArgThingHelper<Arg>::forEachFast):
        (JSC::B3::Air::ArgThingHelper<Arg>::forEach):
        (JSC::B3::Air::Arg::is):
        (JSC::B3::Air::Arg::as):
        (JSC::B3::Air::Arg::forEachFast):
        (JSC::B3::Air::Arg::forEach):
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * b3/air/AirUseCounts.h:
        (JSC::B3::Air::UseCounts::UseCounts):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):

2016-01-19  Enrica Casucci  <enrica@apple.com>

        Add support for DataDetectors in WK (iOS).
        https://bugs.webkit.org/show_bug.cgi?id=152989
        rdar://problem/22855960

        Reviewed by Tim Horton.

        Adding feature definition.

        * Configurations/FeatureDefines.xcconfig:

2016-01-17  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should be just as fast as FTL LLVM on Octane/crypto
        https://bugs.webkit.org/show_bug.cgi?id=153113

        Reviewed by Saam Barati.

        This is the result of a hacking rampage to close the gap between FTL B3 and FTL LLVM on
        Octane/crypto. It was a very successful rampage.

        The biggest change in this patch is the introduction of a phase called fixObviousSpills()
        that fixes patterns like:

        Store register to stack slot and then use stack slot:
            Move %rcx, (stack42)
            Foo use:(stack42) // replace (stack42) with %rcx here.

        Load stack slot into register and then use stack slot:
            Move (stack42), %rcx
            Foo use:(stack42) // replace (stack42) with %rcx here.

        Store constant into stack slot and then use stack slot:
            Move $42, %rcx
            Move %rcx, (stack42)
            Bar def:%rcx // %rcx isn't available anymore, but we still know that (stack42) is $42
            Foo use:(stack42) // replace (stack42) with $42 here.

        This phases does these fixups by doing a global forward flow that propagates sets of
        must-aliases.

        Also added a phase to report register pressure. It pretty-prints code alongside the set of
        in-use registers above each instruction. Using this phase, I found that our register
        allocator is actually doing a pretty awesome job. I had previously feared that we'd have to
        make substantial changes to register allocation. I don't have such a fear anymore, at least
        for Octane/crypto. In the future, we can check how the regalloc is performing just by
        enabling logAirRegisterPressure.

        Also fixed some FTL codegen pathologies. We were using bitOr where we meant to use a
        conditional or. LLVM likes to canonicalize boolean expressions this way. B3, on the other
        hand, doesn't do this canonicalization and doesn't have logic to decompose it into sequences
        of branches.

        Also added strength reductions for checked arithmetic. It turns out that LLVM learned how to
        reduce checked multiply to unchecked multiply in some obvious cases that our existing DFG
        optimizations lacked. Ideally, our DFG integer range optimization phase would cover this. But
        the cases of interest were dead simple - the incoming values to the CheckMul were obviously
        too small to cause overflow. I added such reasoning to B3's strength reduction.

        Finally, this fixes some bugs with how we were handling subwidth spill slots. The register
        allocator was making two mistakes. First, it might cause a Width64 def or use of a 4-byte
        spill slot. In that case, it would extend the size of the spill slot to ensure that the use
        or def is safe. Second, it emulates ZDef on Tmp behavior by emitting a Move32 to initialize
        the high bits of a spill slot. But this is unsound because of the liveness semantics of spill
        slots. They cannot have more than one def to initialize their value. I fixed that by making
        allocateStack() be the thing that fixes ZDefs. That's a change to ZDef semantics: now, ZDef
        on an anonymous stack slot means that the high bits are zero-filled. I wasn't able to
        construct a test for this. It might be a hypothetical bug, but still, I like how this
        simplifies the register allocator.

        This is a ~0.7% speed-up on Octane.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::hiddenBranch):
        (JSC::B3::CheckSpecial::forEachArg):
        (JSC::B3::CheckSpecial::commitHiddenBranch): Deleted.
        * b3/B3CheckSpecial.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::fillStackmap):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3StackmapValue.h:
        * b3/air/AirAllocateStack.cpp:
        (JSC::B3::Air::allocateStack):
        * b3/air/AirAllocateStack.h:
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::callArg):
        (JSC::B3::Air::Arg::stackAddr):
        (JSC::B3::Air::Arg::isValidScale):
        * b3/air/AirBasicBlock.cpp:
        (JSC::B3::Air::BasicBlock::deepDump):
        (JSC::B3::Air::BasicBlock::dumpHeader):
        (JSC::B3::Air::BasicBlock::dumpFooter):
        * b3/air/AirBasicBlock.h:
        * b3/air/AirCCallSpecial.cpp:
        (JSC::B3::Air::CCallSpecial::CCallSpecial):
        (JSC::B3::Air::CCallSpecial::~CCallSpecial):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::lastPhaseName):
        (JSC::B3::Air::Code::setEnableRCRS):
        (JSC::B3::Air::Code::enableRCRS):
        * b3/air/AirCustom.cpp:
        (JSC::B3::Air::PatchCustom::isValidForm):
        (JSC::B3::Air::CCallCustom::isValidForm):
        * b3/air/AirCustom.h:
        (JSC::B3::Air::PatchCustom::isValidFormStatic):
        (JSC::B3::Air::PatchCustom::admitsStack):
        (JSC::B3::Air::PatchCustom::isValidForm): Deleted.
        * b3/air/AirEmitShuffle.cpp:
        (JSC::B3::Air::ShufflePair::dump):
        (JSC::B3::Air::createShuffle):
        (JSC::B3::Air::emitShuffle):
        * b3/air/AirEmitShuffle.h:
        * b3/air/AirFixObviousSpills.cpp: Added.
        (JSC::B3::Air::fixObviousSpills):
        * b3/air/AirFixObviousSpills.h: Added.
        * b3/air/AirFixSpillSlotZDef.h: Removed.
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        (JSC::B3::Air::generate):
        * b3/air/AirHandleCalleeSaves.cpp:
        (JSC::B3::Air::handleCalleeSaves):
        * b3/air/AirInst.h:
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::reportUsedRegisters):
        (JSC::B3::Air::Inst::admitsStack):
        (JSC::B3::Air::isShiftValid):
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * b3/air/AirLiveness.h:
        (JSC::B3::Air::AbstractLiveness::AbstractLiveness):
        (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::begin):
        (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::end):
        (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::contains):
        (JSC::B3::Air::AbstractLiveness::LocalCalc::live):
        (JSC::B3::Air::AbstractLiveness::LocalCalc::isLive):
        (JSC::B3::Air::AbstractLiveness::LocalCalc::execute):
        (JSC::B3::Air::AbstractLiveness::rawLiveAtHead):
        (JSC::B3::Air::AbstractLiveness::Iterable::begin):
        (JSC::B3::Air::AbstractLiveness::Iterable::end):
        (JSC::B3::Air::AbstractLiveness::Iterable::contains):
        (JSC::B3::Air::AbstractLiveness::liveAtTail):
        (JSC::B3::Air::AbstractLiveness::workset):
        * b3/air/AirLogRegisterPressure.cpp: Added.
        (JSC::B3::Air::logRegisterPressure):
        * b3/air/AirLogRegisterPressure.h: Added.
        * b3/air/AirOptimizeBlockOrder.cpp:
        (JSC::B3::Air::blocksInOptimizedOrder):
        (JSC::B3::Air::optimizeBlockOrder):
        * b3/air/AirOptimizeBlockOrder.h:
        * b3/air/AirReportUsedRegisters.cpp:
        (JSC::B3::Air::reportUsedRegisters):
        * b3/air/AirReportUsedRegisters.h:
        * b3/air/AirSpillEverything.cpp:
        (JSC::B3::Air::spillEverything):
        * b3/air/AirStackSlot.h:
        (JSC::B3::Air::StackSlot::isLocked):
        (JSC::B3::Air::StackSlot::index):
        (JSC::B3::Air::StackSlot::ensureSize):
        (JSC::B3::Air::StackSlot::alignment):
        * b3/air/AirValidate.cpp:
        * ftl/FTLB3Compile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithDiv):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithMod):
        * jit/RegisterSet.h:
        (JSC::RegisterSet::get):
        (JSC::RegisterSet::setAll):
        (JSC::RegisterSet::merge):
        (JSC::RegisterSet::filter):
        * runtime/Options.h:

2016-01-19  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, undo unintended commit.

        * dfg/DFGCommon.h:

2016-01-18  Filip Pizlo  <fpizlo@apple.com>

        Fix Air shuffling assertions
        https://bugs.webkit.org/show_bug.cgi?id=153213

        Reviewed by Saam Barati.

        Fixes some assertions that I was seeing running JSC tests. Adds a new Air test.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::store8):
        (JSC::MacroAssemblerX86Common::getUnusedRegister):
        * b3/air/AirEmitShuffle.cpp:
        (JSC::B3::Air::emitShuffle):
        * b3/air/AirLowerAfterRegAlloc.cpp:
        (JSC::B3::Air::lowerAfterRegAlloc):
        * b3/air/testair.cpp:
        (JSC::B3::Air::testShuffleRotateWithFringe):
        (JSC::B3::Air::testShuffleRotateWithFringeInWeirdOrder):
        (JSC::B3::Air::testShuffleRotateWithLongFringe):
        (JSC::B3::Air::run):

2016-01-19  Konstantin Tokarev  <annulen@yandex.ru>

        [mips] Logical instructions allow immediates in range 0..0xffff, not 0x7fff
        https://bugs.webkit.org/show_bug.cgi?id=152693

        Reviewed by Michael Saboff.

        * offlineasm/mips.rb:

2016-01-18  Saam barati  <sbarati@apple.com>

        assertions in BytecodeUseDef.h about opcode length are off by one
        https://bugs.webkit.org/show_bug.cgi?id=153215

        Reviewed by Dan Bernstein.

        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):

2016-01-18  Saam barati  <sbarati@apple.com>

        FTL doesn't do proper spilling for exception handling when GetById/Snippets go to slow path
        https://bugs.webkit.org/show_bug.cgi?id=153186

        Reviewed by Michael Saboff.

        Michael was investigating a bug he found while doing the new JSC calling 
        convention work and it turns out to be a latent bug in FTL try/catch machinery.
        After I looked at the code again, I realized that what I had previously
        written is wrong in a subtle way. The FTL callOperation machinery will remove
        its result register from the set of registers it needs to spill. This is not
        correct when we have try/catch. We may want to do value recovery on
        the value that the result register is prior to the call after the call
        throws an exception. The case that we were solving before was when the 
        resultRegister == baseRegister in a GetById, or left/rightRegister == resultRegister in a Snippet.
        This code is correct in wanting to spill in that case, even though it might spill
        when we don't need it to (i.e the result is not needed for value recovery). Once I
        investigated this bug further, I realized that the previous rule is just a
        partial subset of the rule that says we should spill anytime the result is
        a register we might do value recovery on. This patch implements the rule that
        says we always want to spill the result when we will do value recovery on it 
        if an exception is thrown.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * tests/stress/ftl-try-catch-getter-throw-interesting-value-recovery.js: Added.
        (assert):
        (random):
        (identity):
        (let.o2.get f):
        (let.o3.get f):
        (foo):
        (i.else):

2016-01-18  Konstantin Tokarev  <annulen@yandex.ru>

        [MIPS] LLInt: fix calculation of Global Offset Table
        https://bugs.webkit.org/show_bug.cgi?id=150381

        Offlineasm adds a .cpload $t9 when we create a label in MIPS, which
        computes address of GOT. However, this instruction requires $t9 to
        contain address of current function. So we need to set $t9 to pcBase,
        otherwise GOT-related calculations will be invalid.

        Since offlineasm does not allow direct move to $t9 on MIPS, added new
        instruction setcallreg which does exactly that.

        Reviewed by Michael Saboff.

        * llint/LowLevelInterpreter.asm:
        * offlineasm/instructions.rb:
        * offlineasm/mips.rb:

2016-01-18  Csaba Osztrogonác  <ossy@webkit.org>

        REGRESSION(r194601): Fix the jsc timeout option of jsc.cpp
        https://bugs.webkit.org/show_bug.cgi?id=153204

        Reviewed by Michael Catanzaro.

        * jsc.cpp:
        (main):

2016-01-18  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] Add testair to the build system
        https://bugs.webkit.org/show_bug.cgi?id=153126

        Reviewed by Michael Catanzaro.

        * shell/CMakeLists.txt:

2016-01-17  Jeremy Huddleston Sequoia  <jeremyhu@apple.com>

        Ensure that CF_AVAILABLE is undefined when building webkit-gtk

        https://bugs.webkit.org/show_bug.cgi?id=152720

        This change ensures that CF_AVAILABLE is correctly a no-op to
        address build failure that was observed when building on older
        versions of OSX.  Previously, CF_AVAILABLE may have been unexpectedly
        re-defined to the system header value based on include-order.

        Reviewed by Michael Catanzaro.

        * API/WebKitAvailability.h:

2016-01-17  Julien Brianceau  <jbriance@cisco.com>

        [mips] Fix regT2 and regT3 trampling in MacroAssembler
        https://bugs.webkit.org/show_bug.cgi?id=153131

        Mips $t2 and $t3 registers were used as temporary registers
        in MacroAssemblerMIPS.h, whereas they are mapped to regT2
        and regT3 in LLInt and GPRInfo.

        This patch rearranges register mapping for the mips architecture:
        - use $t0 and $t1 as temp registers in LLInt (as in MacroAssembler)
        - use $t7 and $t8 as temp registers in MacroAssembler (as in LLInt)
        - remove $t6 from temp registers list in LLInt
        - update GPRInfo.h accordingly
        - add mips macroScratchRegisters() list in RegisterSet.cpp

        Reviewed by Michael Saboff.

        * assembler/MacroAssemblerMIPS.h:
        * jit/GPRInfo.h:
        (JSC::GPRInfo::toRegister):
        (JSC::GPRInfo::toIndex):
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::macroScratchRegisters):
        (JSC::RegisterSet::calleeSaveRegisters):
        * offlineasm/mips.rb:

2016-01-16  Skachkov Oleksandr  <gskachkov@gmail.com>

        [ES6] Arrow function syntax. Arrow function should support the destructuring parameters.
        https://bugs.webkit.org/show_bug.cgi?id=146934

        Reviewed by Saam Barati.
        
        Added support of destructuring parameters, before arrow function expect only simple parameters,
        e.g. (), (x), (x, y) or x in assigment expressio. To support destructuring parameters added
        additional check that check for destructuring paramters if check does not pass for simple parameters.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::isArrowFunctionParameters):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        * parser/Parser.h:

2016-01-15  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Legalize Memory Offsets for ARM64 before lowering to Air
        https://bugs.webkit.org/show_bug.cgi?id=153065

        Reviewed by Mark Lam.
        Reviewed by Filip Pizlo.

        On ARM64, we cannot use signed 32bits offset for memory addressing.
        There are two available addressing: signed 9bits and unsigned scaled 12bits.
        Air already knows about it.

        In this patch, the offsets are changed to something valid for ARM64
        prior to lowering. When an offset is invalid, it is just computed
        before the instruction and used as the base for addressing.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir):
        * b3/B3LegalizeMemoryOffsets.cpp: Added.
        (JSC::B3::legalizeMemoryOffsets):
        * b3/B3LegalizeMemoryOffsets.h: Added.
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::effectiveAddr): Deleted.
        * b3/testb3.cpp:
        (JSC::B3::testLoadWithOffsetImpl):
        (JSC::B3::testLoadOffsetImm9Max):
        (JSC::B3::testLoadOffsetImm9MaxPlusOne):
        (JSC::B3::testLoadOffsetImm9MaxPlusTwo):
        (JSC::B3::testLoadOffsetImm9Min):
        (JSC::B3::testLoadOffsetImm9MinMinusOne):
        (JSC::B3::testLoadOffsetScaledUnsignedImm12Max):
        (JSC::B3::testLoadOffsetScaledUnsignedOverImm12Max):
        (JSC::B3::run):

2016-01-15  Alex Christensen  <achristensen@webkit.org>

        Fix internal Windows build
        https://bugs.webkit.org/show_bug.cgi?id=153142

        Reviewed by Brent Fulgham.

        The internal Windows build builds JavaScriptCore from a directory that is not called JavaScriptCore.
        Searching for JavaScriptCore/API/APICast.h fails because it is in SomethingElse/API/APICast.h.
        Since we are including the JavaScriptCore directory, it is not necessary to have JavaScriptCore in
        the forwarding headers, but removing it allows builds form directories that are not named JavaScriptCore.

        * ForwardingHeaders/JavaScriptCore/APICast.h:
        * ForwardingHeaders/JavaScriptCore/JSBase.h:
        * ForwardingHeaders/JavaScriptCore/JSCTestRunnerUtils.h:
        * ForwardingHeaders/JavaScriptCore/JSContextRef.h:
        * ForwardingHeaders/JavaScriptCore/JSObjectRef.h:
        * ForwardingHeaders/JavaScriptCore/JSRetainPtr.h:
        * ForwardingHeaders/JavaScriptCore/JSStringRef.h:
        * ForwardingHeaders/JavaScriptCore/JSStringRefCF.h:
        * ForwardingHeaders/JavaScriptCore/JSValueRef.h:
        * ForwardingHeaders/JavaScriptCore/JavaScript.h:
        * ForwardingHeaders/JavaScriptCore/JavaScriptCore.h:
        * ForwardingHeaders/JavaScriptCore/OpaqueJSString.h:
        * ForwardingHeaders/JavaScriptCore/WebKitAvailability.h:

2016-01-15  Per Arne Vollan  <peavo@outlook.com>

        [B3][Win64] Compile fixes.
        https://bugs.webkit.org/show_bug.cgi?id=153127

        Reviewed by Alex Christensen.

        MSVC have several overloads of fmod, pow, and ceil. We need to suggest to MSVC
        which one we want to use.

        * b3/B3LowerMacros.cpp:
        * b3/B3LowerMacrosAfterOptimizations.cpp:
        * b3/B3MathExtras.cpp:
        (JSC::B3::powDoubleInt32):
        * b3/B3ReduceStrength.cpp:

2016-01-15  Filip Pizlo  <fpizlo@apple.com>

        Air needs a Shuffle instruction
        https://bugs.webkit.org/show_bug.cgi?id=152952

        Reviewed by Saam Barati.

        This adds an instruction called Shuffle. Shuffle allows you to simultaneously perform
        multiple moves to perform arbitrary permutations over registers and memory. We call these
        rotations. It also allows you to perform "shifts", like (a => b, b => c): after the shift,
        c will have b's old value, b will have a's old value, and a will be unchanged. Shifts can
        use immediates as their source.

        Shuffle is added as a custom instruction, since it has a variable number of arguments. It
        takes any number of triplets of arguments, where each triplet describes one mapping of the
        shuffle. For example, to represent (a => b, b => c), we might say:

            Shuffle %a, %b, 64, %b, %c, 64

        Note the "64"s, those are width arguments that describe how many bits of the register are
        being moved. Each triplet is referred to as a "shuffle pair". We call it a pair because the
        most relevant part of it is the pair of registers or memroy locations (i.e. %a, %b form one
        of the pairs in the example). For GP arguments, the width follows ZDef semantics.

        In the future, we will be able to use Shuffle for a lot of things. This patch is modest about
        how to use it:

        - C calling convention argument marshalling. Previously we used move instructions. But that's
          problematic since it introduces artificial interference between the argument registers and
          the inputs. Using Shuffle removes that interference. This helps a bit.

        - Cold C calls. This is what really motivated me to write this patch. If we have a C call on
          a cold path, then we want it to appear to the register allocator like it doesn't clobber
          any registers. Only after register allocation should we handle the clobbering by simply
          saving all of the live volatile registers to the stack. If you imagine the saving and the
          argument marshalling, you can see how before the call, we want to have a Shuffle that does
          both of those things. This is important. If argument marshalling was separate from the
          saving, then we'd still appear to clobber argument registers. Doing them together as one
          Shuffle means that the cold call doesn't appear to even clobber the argument registers.

        Unfortunately, I was wrong about cold C calls being the dominant problem with our register
        allocator right now. Fixing this revealed other problems in my current tuning benchmark,
        Octane/encrypt. Nonetheless, this is a small speed-up across the board, and gives us some
        functionality we will need to implement other optimizations.

        Relanding after fixing production build.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbstractMacroAssembler.h:
        (JSC::isX86_64):
        (JSC::isIOS):
        (JSC::optimizeForARMv7IDIVSupported):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::zeroExtend32ToPtr):
        (JSC::MacroAssemblerX86Common::swap32):
        (JSC::MacroAssemblerX86Common::moveConditionally32):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::store64WithAddressOffsetPatch):
        (JSC::MacroAssemblerX86_64::swap64):
        (JSC::MacroAssemblerX86_64::move64ToDouble):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::xchgl_rr):
        (JSC::X86Assembler::xchgl_rm):
        (JSC::X86Assembler::xchgq_rr):
        (JSC::X86Assembler::xchgq_rm):
        (JSC::X86Assembler::movl_rr):
        * b3/B3CCallValue.h:
        * b3/B3Compilation.cpp:
        (JSC::B3::Compilation::Compilation):
        (JSC::B3::Compilation::~Compilation):
        * b3/B3Compilation.h:
        (JSC::B3::Compilation::code):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::createSelect):
        (JSC::B3::Air::LowerToAir::lower):
        (JSC::B3::Air::LowerToAir::marshallCCallArgument): Deleted.
        * b3/B3OpaqueByproducts.h:
        (JSC::B3::OpaqueByproducts::count):
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::isArgValidForValue):
        (JSC::B3::StackmapSpecial::isArgValidForRep):
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::isStackMemory):
        (JSC::B3::Air::Arg::isRepresentableAs):
        (JSC::B3::Air::Arg::usesTmp):
        (JSC::B3::Air::Arg::canRepresent):
        (JSC::B3::Air::Arg::isCompatibleType):
        (JSC::B3::Air::Arg::dump):
        (WTF::printInternal):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::forEachType):
        (JSC::B3::Air::Arg::isWarmUse):
        (JSC::B3::Air::Arg::cooled):
        (JSC::B3::Air::Arg::isEarlyUse):
        (JSC::B3::Air::Arg::imm64):
        (JSC::B3::Air::Arg::immPtr):
        (JSC::B3::Air::Arg::addr):
        (JSC::B3::Air::Arg::special):
        (JSC::B3::Air::Arg::widthArg):
        (JSC::B3::Air::Arg::operator==):
        (JSC::B3::Air::Arg::isImm64):
        (JSC::B3::Air::Arg::isSomeImm):
        (JSC::B3::Air::Arg::isAddr):
        (JSC::B3::Air::Arg::isIndex):
        (JSC::B3::Air::Arg::isMemory):
        (JSC::B3::Air::Arg::isRelCond):
        (JSC::B3::Air::Arg::isSpecial):
        (JSC::B3::Air::Arg::isWidthArg):
        (JSC::B3::Air::Arg::isAlive):
        (JSC::B3::Air::Arg::base):
        (JSC::B3::Air::Arg::hasOffset):
        (JSC::B3::Air::Arg::offset):
        (JSC::B3::Air::Arg::width):
        (JSC::B3::Air::Arg::isGPTmp):
        (JSC::B3::Air::Arg::isGP):
        (JSC::B3::Air::Arg::isFP):
        (JSC::B3::Air::Arg::isType):
        (JSC::B3::Air::Arg::isGPR):
        (JSC::B3::Air::Arg::isValidForm):
        (JSC::B3::Air::Arg::forEachTmpFast):
        * b3/air/AirBasicBlock.h:
        (JSC::B3::Air::BasicBlock::insts):
        (JSC::B3::Air::BasicBlock::appendInst):
        (JSC::B3::Air::BasicBlock::append):
        * b3/air/AirCCallingConvention.cpp: Added.
        (JSC::B3::Air::computeCCallingConvention):
        (JSC::B3::Air::cCallResult):
        (JSC::B3::Air::buildCCall):
        * b3/air/AirCCallingConvention.h: Added.
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::proc):
        * b3/air/AirCustom.cpp: Added.
        (JSC::B3::Air::CCallCustom::isValidForm):
        (JSC::B3::Air::CCallCustom::generate):
        (JSC::B3::Air::ShuffleCustom::isValidForm):
        (JSC::B3::Air::ShuffleCustom::generate):
        * b3/air/AirCustom.h:
        (JSC::B3::Air::PatchCustom::forEachArg):
        (JSC::B3::Air::PatchCustom::generate):
        (JSC::B3::Air::CCallCustom::forEachArg):
        (JSC::B3::Air::CCallCustom::isValidFormStatic):
        (JSC::B3::Air::CCallCustom::admitsStack):
        (JSC::B3::Air::CCallCustom::hasNonArgNonControlEffects):
        (JSC::B3::Air::ColdCCallCustom::forEachArg):
        (JSC::B3::Air::ShuffleCustom::forEachArg):
        (JSC::B3::Air::ShuffleCustom::isValidFormStatic):
        (JSC::B3::Air::ShuffleCustom::admitsStack):
        (JSC::B3::Air::ShuffleCustom::hasNonArgNonControlEffects):
        * b3/air/AirEmitShuffle.cpp: Added.
        (JSC::B3::Air::ShufflePair::dump):
        (JSC::B3::Air::emitShuffle):
        * b3/air/AirEmitShuffle.h: Added.
        (JSC::B3::Air::ShufflePair::ShufflePair):
        (JSC::B3::Air::ShufflePair::src):
        (JSC::B3::Air::ShufflePair::dst):
        (JSC::B3::Air::ShufflePair::width):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        * b3/air/AirGenerate.h:
        * b3/air/AirInsertionSet.cpp:
        (JSC::B3::Air::InsertionSet::insertInsts):
        (JSC::B3::Air::InsertionSet::execute):
        * b3/air/AirInsertionSet.h:
        (JSC::B3::Air::InsertionSet::insertInst):
        (JSC::B3::Air::InsertionSet::insert):
        * b3/air/AirInst.h:
        (JSC::B3::Air::Inst::operator bool):
        (JSC::B3::Air::Inst::append):
        * b3/air/AirLowerAfterRegAlloc.cpp: Added.
        (JSC::B3::Air::lowerAfterRegAlloc):
        * b3/air/AirLowerAfterRegAlloc.h: Added.
        * b3/air/AirLowerMacros.cpp: Added.
        (JSC::B3::Air::lowerMacros):
        * b3/air/AirLowerMacros.h: Added.
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirRegisterPriority.h:
        (JSC::B3::Air::regsInPriorityOrder):
        * b3/air/testair.cpp: Added.
        (hiddenTruthBecauseNoReturnIsStupid):
        (usage):
        (JSC::B3::Air::compile):
        (JSC::B3::Air::invoke):
        (JSC::B3::Air::compileAndRun):
        (JSC::B3::Air::testSimple):
        (JSC::B3::Air::loadConstantImpl):
        (JSC::B3::Air::loadConstant):
        (JSC::B3::Air::loadDoubleConstant):
        (JSC::B3::Air::testShuffleSimpleSwap):
        (JSC::B3::Air::testShuffleSimpleShift):
        (JSC::B3::Air::testShuffleLongShift):
        (JSC::B3::Air::testShuffleLongShiftBackwards):
        (JSC::B3::Air::testShuffleSimpleRotate):
        (JSC::B3::Air::testShuffleSimpleBroadcast):
        (JSC::B3::Air::testShuffleBroadcastAllRegs):
        (JSC::B3::Air::testShuffleTreeShift):
        (JSC::B3::Air::testShuffleTreeShiftBackward):
        (JSC::B3::Air::testShuffleTreeShiftOtherBackward):
        (JSC::B3::Air::testShuffleMultipleShifts):
        (JSC::B3::Air::testShuffleRotateWithFringe):
        (JSC::B3::Air::testShuffleRotateWithLongFringe):
        (JSC::B3::Air::testShuffleMultipleRotates):
        (JSC::B3::Air::testShuffleShiftAndRotate):
        (JSC::B3::Air::testShuffleShiftAllRegs):
        (JSC::B3::Air::testShuffleRotateAllRegs):
        (JSC::B3::Air::testShuffleSimpleSwap64):
        (JSC::B3::Air::testShuffleSimpleShift64):
        (JSC::B3::Air::testShuffleSwapMixedWidth):
        (JSC::B3::Air::testShuffleShiftMixedWidth):
        (JSC::B3::Air::testShuffleShiftMemory):
        (JSC::B3::Air::testShuffleShiftMemoryLong):
        (JSC::B3::Air::testShuffleShiftMemoryAllRegs):
        (JSC::B3::Air::testShuffleShiftMemoryAllRegs64):
        (JSC::B3::Air::combineHiLo):
        (JSC::B3::Air::testShuffleShiftMemoryAllRegsMixedWidth):
        (JSC::B3::Air::testShuffleRotateMemory):
        (JSC::B3::Air::testShuffleRotateMemory64):
        (JSC::B3::Air::testShuffleRotateMemoryMixedWidth):
        (JSC::B3::Air::testShuffleRotateMemoryAllRegs64):
        (JSC::B3::Air::testShuffleRotateMemoryAllRegsMixedWidth):
        (JSC::B3::Air::testShuffleSwapDouble):
        (JSC::B3::Air::testShuffleShiftDouble):
        (JSC::B3::Air::run):
        (run):
        (main):
        * b3/testb3.cpp:
        (JSC::B3::testCallSimple):
        (JSC::B3::testCallRare):
        (JSC::B3::testCallRareLive):
        (JSC::B3::testCallSimplePure):
        (JSC::B3::run):

2016-01-15  Andy VanWagoner  <thetalecrafter@gmail.com>

        [INTL] Implement Date.prototype.toLocaleString in ECMA-402
        https://bugs.webkit.org/show_bug.cgi?id=147611

        Reviewed by Benjamin Poulain.

        Expose dateProtoFuncGetTime as thisTimeValue for builtins.
        Remove unused code in DateTimeFormat toDateTimeOptions, and make the
        function specific to the call in initializeDateTimeFormat. Properly
        throw when the options parameter is null.
        Add toLocaleString in builtin JavaScript, with it's own specific branch
        of toDateTimeOptions.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/DatePrototype.js: Added.
        (toLocaleString.toDateTimeOptionsAnyAll):
        (toLocaleString):
        * runtime/CommonIdentifiers.h:
        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::finishCreation):
        * runtime/DatePrototype.h:
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::toDateTimeOptionsAnyDate):
        (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
        (JSC::toDateTimeOptions): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):

2016-01-15  Konstantin Tokarev  <annulen@yandex.ru>

        [mips] Implemented emitFunctionPrologue/Epilogue
        https://bugs.webkit.org/show_bug.cgi?id=152947

        Reviewed by Michael Saboff.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::popPair):
        (JSC::MacroAssemblerMIPS::pushPair):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitFunctionPrologue):
        (JSC::AssemblyHelpers::emitFunctionEpilogueWithEmptyFrame):
        (JSC::AssemblyHelpers::emitFunctionEpilogue):

2016-01-15  Commit Queue  <commit-queue@webkit.org>

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

        Broke Production build (Requested by ap on #webkit).

        Reverted changeset:

        "Air needs a Shuffle instruction"
        https://bugs.webkit.org/show_bug.cgi?id=152952
        http://trac.webkit.org/changeset/195084

2016-01-15  Julien Brianceau  <jbriance@cisco.com>

        [mips] Add countLeadingZeros32 implementation in macro assembler
        https://bugs.webkit.org/show_bug.cgi?id=152886

        Reviewed by Michael Saboff.

        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::lui):
        (JSC::MIPSAssembler::clz):
        (JSC::MIPSAssembler::addiu):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::and32):
        (JSC::MacroAssemblerMIPS::countLeadingZeros32):
        (JSC::MacroAssemblerMIPS::lshift32):

2016-01-14  Filip Pizlo  <fpizlo@apple.com>

        Air needs a Shuffle instruction
        https://bugs.webkit.org/show_bug.cgi?id=152952

        Reviewed by Saam Barati.

        This adds an instruction called Shuffle. Shuffle allows you to simultaneously perform
        multiple moves to perform arbitrary permutations over registers and memory. We call these
        rotations. It also allows you to perform "shifts", like (a => b, b => c): after the shift,
        c will have b's old value, b will have a's old value, and a will be unchanged. Shifts can
        use immediates as their source.

        Shuffle is added as a custom instruction, since it has a variable number of arguments. It
        takes any number of triplets of arguments, where each triplet describes one mapping of the
        shuffle. For example, to represent (a => b, b => c), we might say:

            Shuffle %a, %b, 64, %b, %c, 64

        Note the "64"s, those are width arguments that describe how many bits of the register are
        being moved. Each triplet is referred to as a "shuffle pair". We call it a pair because the
        most relevant part of it is the pair of registers or memroy locations (i.e. %a, %b form one
        of the pairs in the example). For GP arguments, the width follows ZDef semantics.

        In the future, we will be able to use Shuffle for a lot of things. This patch is modest about
        how to use it:

        - C calling convention argument marshalling. Previously we used move instructions. But that's
          problematic since it introduces artificial interference between the argument registers and
          the inputs. Using Shuffle removes that interference. This helps a bit.

        - Cold C calls. This is what really motivated me to write this patch. If we have a C call on
          a cold path, then we want it to appear to the register allocator like it doesn't clobber
          any registers. Only after register allocation should we handle the clobbering by simply
          saving all of the live volatile registers to the stack. If you imagine the saving and the
          argument marshalling, you can see how before the call, we want to have a Shuffle that does
          both of those things. This is important. If argument marshalling was separate from the
          saving, then we'd still appear to clobber argument registers. Doing them together as one
          Shuffle means that the cold call doesn't appear to even clobber the argument registers.

        Unfortunately, I was wrong about cold C calls being the dominant problem with our register
        allocator right now. Fixing this revealed other problems in my current tuning benchmark,
        Octane/encrypt. Nonetheless, this is a small speed-up across the board, and gives us some
        functionality we will need to implement other optimizations.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbstractMacroAssembler.h:
        (JSC::isX86_64):
        (JSC::isIOS):
        (JSC::optimizeForARMv7IDIVSupported):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::zeroExtend32ToPtr):
        (JSC::MacroAssemblerX86Common::swap32):
        (JSC::MacroAssemblerX86Common::moveConditionally32):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::store64WithAddressOffsetPatch):
        (JSC::MacroAssemblerX86_64::swap64):
        (JSC::MacroAssemblerX86_64::move64ToDouble):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::xchgl_rr):
        (JSC::X86Assembler::xchgl_rm):
        (JSC::X86Assembler::xchgq_rr):
        (JSC::X86Assembler::xchgq_rm):
        (JSC::X86Assembler::movl_rr):
        * b3/B3CCallValue.h:
        * b3/B3Compilation.cpp:
        (JSC::B3::Compilation::Compilation):
        (JSC::B3::Compilation::~Compilation):
        * b3/B3Compilation.h:
        (JSC::B3::Compilation::code):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::createSelect):
        (JSC::B3::Air::LowerToAir::lower):
        (JSC::B3::Air::LowerToAir::marshallCCallArgument): Deleted.
        * b3/B3OpaqueByproducts.h:
        (JSC::B3::OpaqueByproducts::count):
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::isArgValidForValue):
        (JSC::B3::StackmapSpecial::isArgValidForRep):
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::isStackMemory):
        (JSC::B3::Air::Arg::isRepresentableAs):
        (JSC::B3::Air::Arg::usesTmp):
        (JSC::B3::Air::Arg::canRepresent):
        (JSC::B3::Air::Arg::isCompatibleType):
        (JSC::B3::Air::Arg::dump):
        (WTF::printInternal):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::forEachType):
        (JSC::B3::Air::Arg::isWarmUse):
        (JSC::B3::Air::Arg::cooled):
        (JSC::B3::Air::Arg::isEarlyUse):
        (JSC::B3::Air::Arg::imm64):
        (JSC::B3::Air::Arg::immPtr):
        (JSC::B3::Air::Arg::addr):
        (JSC::B3::Air::Arg::special):
        (JSC::B3::Air::Arg::widthArg):
        (JSC::B3::Air::Arg::operator==):
        (JSC::B3::Air::Arg::isImm64):
        (JSC::B3::Air::Arg::isSomeImm):
        (JSC::B3::Air::Arg::isAddr):
        (JSC::B3::Air::Arg::isIndex):
        (JSC::B3::Air::Arg::isMemory):
        (JSC::B3::Air::Arg::isRelCond):
        (JSC::B3::Air::Arg::isSpecial):
        (JSC::B3::Air::Arg::isWidthArg):
        (JSC::B3::Air::Arg::isAlive):
        (JSC::B3::Air::Arg::base):
        (JSC::B3::Air::Arg::hasOffset):
        (JSC::B3::Air::Arg::offset):
        (JSC::B3::Air::Arg::width):
        (JSC::B3::Air::Arg::isGPTmp):
        (JSC::B3::Air::Arg::isGP):
        (JSC::B3::Air::Arg::isFP):
        (JSC::B3::Air::Arg::isType):
        (JSC::B3::Air::Arg::isGPR):
        (JSC::B3::Air::Arg::isValidForm):
        (JSC::B3::Air::Arg::forEachTmpFast):
        * b3/air/AirBasicBlock.h:
        (JSC::B3::Air::BasicBlock::insts):
        (JSC::B3::Air::BasicBlock::appendInst):
        (JSC::B3::Air::BasicBlock::append):
        * b3/air/AirCCallingConvention.cpp: Added.
        (JSC::B3::Air::computeCCallingConvention):
        (JSC::B3::Air::cCallResult):
        (JSC::B3::Air::buildCCall):
        * b3/air/AirCCallingConvention.h: Added.
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::proc):
        * b3/air/AirCustom.cpp: Added.
        (JSC::B3::Air::CCallCustom::isValidForm):
        (JSC::B3::Air::CCallCustom::generate):
        (JSC::B3::Air::ShuffleCustom::isValidForm):
        (JSC::B3::Air::ShuffleCustom::generate):
        * b3/air/AirCustom.h:
        (JSC::B3::Air::PatchCustom::forEachArg):
        (JSC::B3::Air::PatchCustom::generate):
        (JSC::B3::Air::CCallCustom::forEachArg):
        (JSC::B3::Air::CCallCustom::isValidFormStatic):
        (JSC::B3::Air::CCallCustom::admitsStack):
        (JSC::B3::Air::CCallCustom::hasNonArgNonControlEffects):
        (JSC::B3::Air::ColdCCallCustom::forEachArg):
        (JSC::B3::Air::ShuffleCustom::forEachArg):
        (JSC::B3::Air::ShuffleCustom::isValidFormStatic):
        (JSC::B3::Air::ShuffleCustom::admitsStack):
        (JSC::B3::Air::ShuffleCustom::hasNonArgNonControlEffects):
        * b3/air/AirEmitShuffle.cpp: Added.
        (JSC::B3::Air::ShufflePair::dump):
        (JSC::B3::Air::emitShuffle):
        * b3/air/AirEmitShuffle.h: Added.
        (JSC::B3::Air::ShufflePair::ShufflePair):
        (JSC::B3::Air::ShufflePair::src):
        (JSC::B3::Air::ShufflePair::dst):
        (JSC::B3::Air::ShufflePair::width):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        * b3/air/AirGenerate.h:
        * b3/air/AirInsertionSet.cpp:
        (JSC::B3::Air::InsertionSet::insertInsts):
        (JSC::B3::Air::InsertionSet::execute):
        * b3/air/AirInsertionSet.h:
        (JSC::B3::Air::InsertionSet::insertInst):
        (JSC::B3::Air::InsertionSet::insert):
        * b3/air/AirInst.h:
        (JSC::B3::Air::Inst::operator bool):
        (JSC::B3::Air::Inst::append):
        * b3/air/AirLowerAfterRegAlloc.cpp: Added.
        (JSC::B3::Air::lowerAfterRegAlloc):
        * b3/air/AirLowerAfterRegAlloc.h: Added.
        * b3/air/AirLowerMacros.cpp: Added.
        (JSC::B3::Air::lowerMacros):
        * b3/air/AirLowerMacros.h: Added.
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirRegisterPriority.h:
        (JSC::B3::Air::regsInPriorityOrder):
        * b3/air/testair.cpp: Added.
        (hiddenTruthBecauseNoReturnIsStupid):
        (usage):
        (JSC::B3::Air::compile):
        (JSC::B3::Air::invoke):
        (JSC::B3::Air::compileAndRun):
        (JSC::B3::Air::testSimple):
        (JSC::B3::Air::loadConstantImpl):
        (JSC::B3::Air::loadConstant):
        (JSC::B3::Air::loadDoubleConstant):
        (JSC::B3::Air::testShuffleSimpleSwap):
        (JSC::B3::Air::testShuffleSimpleShift):
        (JSC::B3::Air::testShuffleLongShift):
        (JSC::B3::Air::testShuffleLongShiftBackwards):
        (JSC::B3::Air::testShuffleSimpleRotate):
        (JSC::B3::Air::testShuffleSimpleBroadcast):
        (JSC::B3::Air::testShuffleBroadcastAllRegs):
        (JSC::B3::Air::testShuffleTreeShift):
        (JSC::B3::Air::testShuffleTreeShiftBackward):
        (JSC::B3::Air::testShuffleTreeShiftOtherBackward):
        (JSC::B3::Air::testShuffleMultipleShifts):
        (JSC::B3::Air::testShuffleRotateWithFringe):
        (JSC::B3::Air::testShuffleRotateWithLongFringe):
        (JSC::B3::Air::testShuffleMultipleRotates):
        (JSC::B3::Air::testShuffleShiftAndRotate):
        (JSC::B3::Air::testShuffleShiftAllRegs):
        (JSC::B3::Air::testShuffleRotateAllRegs):
        (JSC::B3::Air::testShuffleSimpleSwap64):
        (JSC::B3::Air::testShuffleSimpleShift64):
        (JSC::B3::Air::testShuffleSwapMixedWidth):
        (JSC::B3::Air::testShuffleShiftMixedWidth):
        (JSC::B3::Air::testShuffleShiftMemory):
        (JSC::B3::Air::testShuffleShiftMemoryLong):
        (JSC::B3::Air::testShuffleShiftMemoryAllRegs):
        (JSC::B3::Air::testShuffleShiftMemoryAllRegs64):
        (JSC::B3::Air::combineHiLo):
        (JSC::B3::Air::testShuffleShiftMemoryAllRegsMixedWidth):
        (JSC::B3::Air::testShuffleRotateMemory):
        (JSC::B3::Air::testShuffleRotateMemory64):
        (JSC::B3::Air::testShuffleRotateMemoryMixedWidth):
        (JSC::B3::Air::testShuffleRotateMemoryAllRegs64):
        (JSC::B3::Air::testShuffleRotateMemoryAllRegsMixedWidth):
        (JSC::B3::Air::testShuffleSwapDouble):
        (JSC::B3::Air::testShuffleShiftDouble):
        (JSC::B3::Air::run):
        (run):
        (main):
        * b3/testb3.cpp:
        (JSC::B3::testCallSimple):
        (JSC::B3::testCallRare):
        (JSC::B3::testCallRareLive):
        (JSC::B3::testCallSimplePure):
        (JSC::B3::run):

2016-01-14  Keith Miller  <keith_miller@apple.com>

        Unreviewed mark passing es6 tests as no longer failing.

        * tests/es6.yaml:

2016-01-14  Keith Miller  <keith_miller@apple.com>

        [ES6] Support subclassing Function.
        https://bugs.webkit.org/show_bug.cgi?id=153081

        Reviewed by Geoffrey Garen.

        This patch enables subclassing the Function object. It also fixes an existing
        bug that prevented users from subclassing functions that have a function in
        the superclass's prototype property.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ClassExprNode::emitBytecode):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructWithFunctionConstructor):
        (JSC::constructFunction):
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionConstructor.h:
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::create):
        * runtime/JSFunction.h:
        (JSC::JSFunction::createImpl):
        * runtime/JSFunctionInlines.h:
        (JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
        (JSC::JSFunction::JSFunction): Deleted.
        * tests/stress/class-subclassing-function.js: Added.

2016-01-13  Carlos Garcia Campos  <cgarcia@igalia.com>

        [CMake] Do not use LLVM static libraries for FTL JIT
        https://bugs.webkit.org/show_bug.cgi?id=151559

        Reviewed by Michael Catanzaro.

        Allow ports decide whether to prefer linking to llvm static or
        dynamic libraries. This patch only changes the behavior of the GTK
        port, other ports can change the default behavior by setting
        llvmForJSC_LIBRARIES in their platform specific cmake files.

        * CMakeLists.txt: Move llvmForJSC library definition after the
        WEBKIT_INCLUDE_CONFIG_FILES_IF_EXISTS, to allow platform specific
        files to set their own llvmForJSC_LIBRARIES. When not set, it
        defaults to LLVM_STATIC_LIBRARIES. The command to create
        WebKitLLVMLibraryToken.h no longer depends on the static
        libraries, since we are going to make the build fail anyway when
        not found in case of linking to the static libraries. If platform
        specific file defined llvmForJSC_INSTALL_DIR llvmForJSC is also
        installed to the given destination.
        * PlatformGTK.cmake: Set llvmForJSC_LIBRARIES and
        llvmForJSC_INSTALL_DIR.

2016-01-13  Saam barati  <sbarati@apple.com>

        NativeExecutable should have a name field
        https://bugs.webkit.org/show_bug.cgi?id=153083

        Reviewed by Geoffrey Garen.

        This is going to help the SamplingProfiler come up
        with names for NativeExecutable objects it encounters.

        * jit/JITThunks.cpp:
        (JSC::JITThunks::finalize):
        (JSC::JITThunks::hostFunctionStub):
        * jit/JITThunks.h:
        * runtime/Executable.h:
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::create):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::create):
        (JSC::JSFunction::lookUpOrCreateNativeExecutable):
        * runtime/JSFunction.h:
        (JSC::JSFunction::createImpl):
        * runtime/JSNativeStdFunction.cpp:
        (JSC::JSNativeStdFunction::create):
        * runtime/VM.cpp:
        (JSC::thunkGeneratorForIntrinsic):
        (JSC::VM::getHostFunction):
        * runtime/VM.h:
        (JSC::VM::getCTIStub):
        (JSC::VM::exceptionOffset):

2016-01-13  Keith Miller  <keith_miller@apple.com>

        [ES6] Support subclassing the String builtin object
        https://bugs.webkit.org/show_bug.cgi?id=153068

        Reviewed by Michael Saboff.

        This patch adds subclassing of strings. Also, this patch fixes a bug where we could have
        the wrong indexing type for builtins constructed without storage.

        * runtime/PrototypeMap.cpp:
        (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure):
        * runtime/StringConstructor.cpp:
        (JSC::constructWithStringConstructor):
        * tests/stress/class-subclassing-string.js: Added.
        (test):

2016-01-13  Mark Lam  <mark.lam@apple.com>

        The StringFromCharCode DFG intrinsic should support untyped operands.
        https://bugs.webkit.org/show_bug.cgi?id=153046

        Reviewed by Geoffrey Garen.

        The current StringFromCharCode DFG intrinsic assumes that its operand charCode
        must be an Int32.  This results in 26000+ BadType OSR exits in the LongSpider
        crypto-aes benchmark.  With support for Untyped operands, the number of OSR
        exits drops to 202.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileFromCharCode):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validate):
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::toUInt32):

2016-01-13  Mark Lam  <mark.lam@apple.com>

        Use DFG Graph::binary/unaryArithShouldSpeculateInt32/MachineInt() functions consistently.
        https://bugs.webkit.org/show_bug.cgi?id=153080

        Reviewed by Geoffrey Garen.

        We currently have Graph::mulShouldSpeculateInt32/machineInt() and
        Graph::negateShouldSpeculateInt32/MachineInt() functions which are only used by
        the ArithMul and ArithNegate nodes.  However, the same tests need to be done for
        many other arith nodes in the DFG.  This patch renames these functions as
        Graph::binaryArithShouldSpeculateInt32/machineInt() and
        Graph::unaryArithShouldSpeculateInt32/MachineInt(), and uses them consistently
        in the DFG.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addShouldSpeculateMachineInt):
        (JSC::DFG::Graph::binaryArithShouldSpeculateInt32):
        (JSC::DFG::Graph::binaryArithShouldSpeculateMachineInt):
        (JSC::DFG::Graph::unaryArithShouldSpeculateInt32):
        (JSC::DFG::Graph::unaryArithShouldSpeculateMachineInt):
        (JSC::DFG::Graph::mulShouldSpeculateInt32): Deleted.
        (JSC::DFG::Graph::mulShouldSpeculateMachineInt): Deleted.
        (JSC::DFG::Graph::negateShouldSpeculateInt32): Deleted.
        (JSC::DFG::Graph::negateShouldSpeculateMachineInt): Deleted.
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):

2016-01-13  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Inspector should use the last sourceURL / sourceMappingURL directive
        https://bugs.webkit.org/show_bug.cgi?id=153072
        <rdar://problem/24168312>

        Reviewed by Timothy Hatcher.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::parseCommentDirective):
        Just keep overwriting the member variable so we end up with
        the last directive value.

2016-01-13  Commit Queue  <commit-queue@webkit.org>

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

        This change broke the iOS build (Requested by ryanhaddad on
        #webkit).

        Reverted changeset:

        "[JSC] Legalize Memory Offsets for ARM64 before lowering to
        Air"
        https://bugs.webkit.org/show_bug.cgi?id=153065
        http://trac.webkit.org/changeset/194969

2016-01-13  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Legalize Memory Offsets for ARM64 before lowering to Air
        https://bugs.webkit.org/show_bug.cgi?id=153065

        Reviewed by Mark Lam.
        Reviewed by Filip Pizlo.

        On ARM64, we cannot use signed 32bits offset for memory addressing.
        There are two available addressing: signed 9bits and unsigned scaled 12bits.
        Air already knows about it.

        In this patch, the offsets are changed to something valid for ARM64
        prior to lowering. When an offset is invalid, it is just computed
        before the instruction and used as the base for addressing.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir):
        * b3/B3LegalizeMemoryOffsets.cpp: Added.
        (JSC::B3::legalizeMemoryOffsets):
        * b3/B3LegalizeMemoryOffsets.h: Added.
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::effectiveAddr): Deleted.
        * b3/testb3.cpp:
        (JSC::B3::testLoadWithOffsetImpl):
        (JSC::B3::testLoadOffsetImm9Max):
        (JSC::B3::testLoadOffsetImm9MaxPlusOne):
        (JSC::B3::testLoadOffsetImm9MaxPlusTwo):
        (JSC::B3::testLoadOffsetImm9Min):
        (JSC::B3::testLoadOffsetImm9MinMinusOne):
        (JSC::B3::testLoadOffsetScaledUnsignedImm12Max):
        (JSC::B3::testLoadOffsetScaledUnsignedOverImm12Max):
        (JSC::B3::run):

2016-01-12  Per Arne Vollan  <peavo@outlook.com>

        [FTL][Win64] Compile error.
        https://bugs.webkit.org/show_bug.cgi?id=153031

        Reviewed by Brent Fulgham.

        The header file dlfcn.h does not exist on Windows.

        * ftl/FTLLowerDFGToLLVM.cpp:

2016-01-12  Ryosuke Niwa  <rniwa@webkit.org>

        Add a build flag for custom element
        https://bugs.webkit.org/show_bug.cgi?id=153005

        Reviewed by Alex Christensen.

        * Configurations/FeatureDefines.xcconfig:

2016-01-12  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove some invalid immediate instruction forms from ARM64 Air
        https://bugs.webkit.org/show_bug.cgi?id=153024

        Reviewed by Michael Saboff.

        * b3/B3BasicBlock.h:
        Export the symbols for testb3.

        * b3/air/AirOpcode.opcodes:
        We had 2 invalid opcodes:
        -Compare with immediate just does not exist.
        -Test64 with immediate exists but Air does not recognize
         the valid form of bit-immediates.

        * b3/testb3.cpp:
        (JSC::B3::genericTestCompare):
        (JSC::B3::testCompareImpl):
        Extend the tests to cover what was invalid.

2016-01-12  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] JSC does not build with FTL_USES_B3 on ARM64
        https://bugs.webkit.org/show_bug.cgi?id=153011

        Reviewed by Saam Barati.

        Apparently the static const member can only be used for constexpr.
        C++ is weird.

        * jit/GPRInfo.cpp:
        * jit/GPRInfo.h:

2016-01-11  Johan K. Jensen  <jj@johanjensen.dk>

        Web Inspector: console.count() shouldn't show a colon in front of a number
        https://bugs.webkit.org/show_bug.cgi?id=152038

        Reviewed by Brian Burg.

        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::count):
        Do not include title and colon if the title is empty.

2016-01-11  Dan Bernstein  <mitz@apple.com>

        Reverted r194317.

        Reviewed by Joseph Pecoraro.

        r194317 did not contain a change log entry, did not explain the motivation, did not name a
        reviewer, and does not seem necessary.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2016-01-11  Joseph Pecoraro  <pecoraro@apple.com>

        keywords ("super", "delete", etc) should be valid method names
        https://bugs.webkit.org/show_bug.cgi?id=144281

        Reviewed by Ryosuke Niwa.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):
        - When parsing "static(" treat it as a method named "static" and not a static method.
        - When parsing a keyword treat it like a string method name (get and set are not keywords)
        - When parsing a getter / setter method name identifier, allow lookahead to be a keyword

        (JSC::Parser<LexerType>::parseGetterSetter):
        - When parsing the getter / setter's name, allow it to be a keyword.

2016-01-11  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add Div/Mod and fix Mul for B3 ARM64
        https://bugs.webkit.org/show_bug.cgi?id=152978

        Reviewed by Filip Pizlo.

        Add the 3 operands forms of Mul.
        Remove the form taking immediate on ARM64, there are no such instruction.

        Add Div with sdiv.

        Unfortunately, I discovered ChillMod's division by zero
        makes it non-trivial on ARM64. I just made it into a macro like on x86.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::mul32):
        (JSC::MacroAssemblerARM64::mul64):
        (JSC::MacroAssemblerARM64::div32):
        (JSC::MacroAssemblerARM64::div64):
        * b3/B3LowerMacros.cpp:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/air/AirOpcode.opcodes:

2016-01-11  Keith Miller  <keith_miller@apple.com>

        Arrays should use the InternalFunctionAllocationProfile when constructing new Arrays
        https://bugs.webkit.org/show_bug.cgi?id=152949

        Reviewed by Michael Saboff.

        This patch updates Array constructors to use the new InternalFunctionAllocationProfile.

        * runtime/ArrayConstructor.cpp:
        (JSC::constructArrayWithSizeQuirk):
        (JSC::constructWithArrayConstructor):
        * runtime/InternalFunction.h:
        (JSC::InternalFunction::createStructure):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::arrayStructureForIndexingTypeDuringAllocation):
        (JSC::JSGlobalObject::arrayStructureForProfileDuringAllocation):
        (JSC::constructEmptyArray):
        (JSC::constructArray):
        (JSC::constructArrayNegativeIndexed):
        * runtime/PrototypeMap.cpp:
        (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure):
        * runtime/Structure.h:
        * runtime/StructureInlines.h:

2016-01-08  Keith Miller  <keith_miller@apple.com>

        Use a profile to store allocation structures for subclasses of InternalFunctions
        https://bugs.webkit.org/show_bug.cgi?id=152942

        Reviewed by Michael Saboff.

        This patch adds InternalFunctionAllocationProfile to FunctionRareData, which holds
        a cached structure that can be used to quickly allocate any derived class of an InternalFunction.
        InternalFunctionAllocationProfile ended up being distinct from ObjectAllocationProfile, due to
        constraints imposed by Reflect.construct. Reflect.construct allows the user to pass an arbitrary
        constructor as a new.target to any other constructor. This means that a user can pass some
        non-derived constructor to an InternalFunction (they can even pass another InternalFunction as the
        new.target). If we use the same profile for both InternalFunctions and JS allocations then we always
        need to check in both JS code and C++ code that the profiled structure has the same ClassInfo as the
        current constructor. By using different profiles, we only need to check the profile in InternalFunctions
        as all JS constructed objects share the same ClassInfo (JSFinalObject). This comes at the relatively
        low cost of using slightly more memory on FunctionRareData and being slightly more conceptually complex.

        Additionally, this patch adds subclassing to some omitted classes.

        * API/JSObjectRef.cpp:
        (JSObjectMakeDate):
        (JSObjectMakeRegExp):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/InternalFunctionAllocationProfile.h: Added.
        (JSC::InternalFunctionAllocationProfile::structure):
        (JSC::InternalFunctionAllocationProfile::clear):
        (JSC::InternalFunctionAllocationProfile::visitAggregate):
        (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * 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/BooleanConstructor.cpp:
        (JSC::constructWithBooleanConstructor):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/DateConstructor.cpp:
        (JSC::constructDate):
        (JSC::constructWithDateConstructor):
        * runtime/DateConstructor.h:
        * runtime/ErrorConstructor.cpp:
        (JSC::Interpreter::constructWithErrorConstructor):
        * runtime/FunctionRareData.cpp:
        (JSC::FunctionRareData::create):
        (JSC::FunctionRareData::visitChildren):
        (JSC::FunctionRareData::FunctionRareData):
        (JSC::FunctionRareData::initializeObjectAllocationProfile):
        (JSC::FunctionRareData::clear):
        (JSC::FunctionRareData::finishCreation): Deleted.
        (JSC::FunctionRareData::initialize): Deleted.
        * runtime/FunctionRareData.h:
        (JSC::FunctionRareData::offsetOfObjectAllocationProfile):
        (JSC::FunctionRareData::objectAllocationProfile):
        (JSC::FunctionRareData::objectAllocationStructure):
        (JSC::FunctionRareData::allocationProfileWatchpointSet):
        (JSC::FunctionRareData::isObjectAllocationProfileInitialized):
        (JSC::FunctionRareData::internalFunctionAllocationStructure):
        (JSC::FunctionRareData::createInternalFunctionAllocationStructureFromBase):
        (JSC::FunctionRareData::offsetOfAllocationProfile): Deleted.
        (JSC::FunctionRareData::allocationProfile): Deleted.
        (JSC::FunctionRareData::allocationStructure): Deleted.
        (JSC::FunctionRareData::isInitialized): Deleted.
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::createSubclassStructure):
        * runtime/InternalFunction.h:
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::constructArrayBuffer):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::allocateRareData):
        (JSC::JSFunction::allocateAndInitializeRareData):
        (JSC::JSFunction::initializeRareData):
        * runtime/JSFunction.h:
        (JSC::JSFunction::rareData):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayView):
        * runtime/JSObject.h:
        (JSC::JSFinalObject::typeInfo):
        (JSC::JSFinalObject::createStructure):
        * runtime/JSPromiseConstructor.cpp:
        (JSC::constructPromise):
        * runtime/JSPromiseConstructor.h:
        * runtime/JSWeakMap.cpp:
        * runtime/JSWeakSet.cpp:
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/NativeErrorConstructor.cpp:
        (JSC::Interpreter::constructWithNativeErrorConstructor):
        * runtime/NumberConstructor.cpp:
        (JSC::constructWithNumberConstructor):
        * runtime/PrototypeMap.cpp:
        (JSC::PrototypeMap::createEmptyStructure):
        (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure):
        (JSC::PrototypeMap::emptyObjectStructureForPrototype):
        (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
        * runtime/PrototypeMap.h:
        * runtime/RegExpConstructor.cpp:
        (JSC::getRegExpStructure):
        (JSC::constructRegExp):
        (JSC::constructWithRegExpConstructor):
        * runtime/RegExpConstructor.h:
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):
        * runtime/WeakMapConstructor.cpp:
        (JSC::constructWeakMap):
        * runtime/WeakSetConstructor.cpp:
        (JSC::constructWeakSet):
        * tests/stress/class-subclassing-misc.js:
        (A):
        (D):
        (E):
        (WM):
        (WS):
        (test):
        * tests/stress/class-subclassing-typedarray.js: Added.
        (test):

2016-01-11  Per Arne Vollan  <peavo@outlook.com>

        [B3][Win64] Compile error.
        https://bugs.webkit.org/show_bug.cgi?id=152984

        Reviewed by Alex Christensen.

        Windows does not have bzero, use memset instead.

        * b3/air/AirIteratedRegisterCoalescing.cpp:

2016-01-11  Konstantin Tokarev  <annulen@yandex.ru>

        Fixed compilation of JavaScriptCore with GCC 4.8 on 32-bit platforms
        https://bugs.webkit.org/show_bug.cgi?id=152923

        Reviewed by Alex Christensen.

        * jit/CallFrameShuffler.h:
        (JSC::CallFrameShuffler::assumeCalleeIsCell):

2016-01-11  Csaba Osztrogonác  <ossy@webkit.org>

        [B3] Fix control reaches end of non-void function GCC warnings on Linux
        https://bugs.webkit.org/show_bug.cgi?id=152887

        Reviewed by Mark Lam.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createBranch):
        (JSC::B3::Air::LowerToAir::createCompare):
        (JSC::B3::Air::LowerToAir::createSelect):
        * b3/B3Type.h:
        (JSC::B3::sizeofType):
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::isRepresentableAs):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isAnyUse):
        (JSC::B3::Air::Arg::isColdUse):
        (JSC::B3::Air::Arg::isEarlyUse):
        (JSC::B3::Air::Arg::isLateUse):
        (JSC::B3::Air::Arg::isAnyDef):
        (JSC::B3::Air::Arg::isEarlyDef):
        (JSC::B3::Air::Arg::isLateDef):
        (JSC::B3::Air::Arg::isZDef):
        (JSC::B3::Air::Arg::widthForB3Type):
        (JSC::B3::Air::Arg::isGP):
        (JSC::B3::Air::Arg::isFP):
        (JSC::B3::Air::Arg::isType):
        (JSC::B3::Air::Arg::isValidForm):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::newTmp):
        (JSC::B3::Air::Code::numTmps):

2016-01-11  Filip Pizlo  <fpizlo@apple.com>

        Make it easier to introduce exotic instructions to Air
        https://bugs.webkit.org/show_bug.cgi?id=152953

        Reviewed by Benjamin Poulain.

        Currently, you can define new "opcodes" in Air using either:

        1) New opcode declared in AirOpcode.opcodes.
        2) Patch opcode with a new implementation of Air::Special.

        With (1), you are limited to fixed-argument-length instructions. There are other
        restrictions as well, like that you can only use the roles that the AirOpcode syntax
        supports.

        With (2), you can do anything you like, but the instruction will be harder to match
        since it will share the same opcode as any other Patch. Also, the instruction will have
        the Special argument, which means more busy-work when creating the instruction and
        validating it.

        This introduces an in-between facility called "custom". This replaces what AirOpcode
        previously called "special". A custom instruction is one whose behavior is defined by a
        FooCustom struct with some static methods. Calls to those methods are emitted by
        opcode_generator.rb.

        The "custom" facility is powerful enough to be used to implement Patch, with the caveat
        that we now treat the Patch instruction specially in a few places. Those places were
        already effectively treating it specially by assuming that only Patch instructions have
        a Special as their first argument.

        This will let me implement the Shuffle instruction (bug 152952), which I think is needed
        for performance work.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/AirCustom.h: Added.
        (JSC::B3::Air::PatchCustom::forEachArg):
        (JSC::B3::Air::PatchCustom::isValidFormStatic):
        (JSC::B3::Air::PatchCustom::isValidForm):
        (JSC::B3::Air::PatchCustom::admitsStack):
        (JSC::B3::Air::PatchCustom::hasNonArgNonControlEffects):
        (JSC::B3::Air::PatchCustom::generate):
        * b3/air/AirHandleCalleeSaves.cpp:
        (JSC::B3::Air::handleCalleeSaves):
        * b3/air/AirInst.h:
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::forEach):
        (JSC::B3::Air::Inst::extraClobberedRegs):
        (JSC::B3::Air::Inst::extraEarlyClobberedRegs):
        (JSC::B3::Air::Inst::forEachDefWithExtraClobberedRegs):
        (JSC::B3::Air::Inst::reportUsedRegisters):
        (JSC::B3::Air::Inst::hasSpecial): Deleted.
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirReportUsedRegisters.cpp:
        (JSC::B3::Air::reportUsedRegisters):
        * b3/air/opcode_generator.rb:

2016-01-11  Filip Pizlo  <fpizlo@apple.com>

        Turn Check(true) into Patchpoint() followed by Oops
        https://bugs.webkit.org/show_bug.cgi?id=152968

        Reviewed by Benjamin Poulain.

        This is an obvious strength reduction to have, especially since if we discover that the
        input to the Check is true after some amount of B3 optimization, then stubbing out the rest
        of the basic block unlocks CFG simplification opportunities.

        It's also a proof-of-concept for the Check->Patchpoint conversion that I'll use once I
        implement sinking (bug 152162).

        * b3/B3ControlValue.cpp:
        (JSC::B3::ControlValue::convertToJump):
        (JSC::B3::ControlValue::convertToOops):
        (JSC::B3::ControlValue::dumpMeta):
        * b3/B3ControlValue.h:
        * b3/B3InsertionSet.h:
        (JSC::B3::InsertionSet::insertValue):
        * b3/B3InsertionSetInlines.h:
        (JSC::B3::InsertionSet::insert):
        * b3/B3ReduceStrength.cpp:
        * b3/B3StackmapValue.h:
        * b3/B3Value.h:
        * tests/stress/ftl-force-osr-exit.js: Added.

2016-01-11  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] When resolving Stack arguments, use addressing from SP when addressing from FP is invalid
        https://bugs.webkit.org/show_bug.cgi?id=152840

        Reviewed by Mark Lam.

        ARM64 has two kinds of addressing with immediates:
        -Signed 9bits direct (really only -256 to 255).
        -Unsigned 12bits scaled by the load/store size.

        When resolving the stack addresses, we easily run
        past -256 bytes from FP. Addressing from SP gives us more
        room to address the stack efficiently because we can
        use unsigned immediates.

        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::repForArg):
        * b3/air/AirAllocateStack.cpp:
        (JSC::B3::Air::allocateStack):

2016-01-10  Saam barati  <sbarati@apple.com>

        Implement a sampling profiler
        https://bugs.webkit.org/show_bug.cgi?id=151713

        Reviewed by Filip Pizlo.

        This patch implements a sampling profiler for JavaScriptCore
        that will be used in the Inspector UI. The implementation works as follows:
        We queue the sampling profiler to run a task on a background
        thread every 1ms. When the queued task executes, the sampling profiler
        will pause the JSC execution thread and attempt to take a stack trace. 
        The sampling profiler does everything it can to be very careful
        while taking this stack trace. Because it's reading arbitrary memory,
        the sampling profiler must validate every pointer it reads from.

        The sampling profiler tries to get an ExecutableBase for every call frame
        it reads. It first tries to read the CodeBlock slot. It does this because
        it can be 100% certain that a pointer is a CodeBlock while it's taking a
        stack trace. But, not every call frame will have a CodeBlock. So we must read
        the call frame's callee. For these stack traces where we read the callee, we
        must verify the callee pointer, and the pointer traversal to an ExecutableBase,
        on the main JSC execution thread, and not on the thread taking the stack
        trace. We do this verification either before we run the marking phase in
        GC, or when somebody asks the SamplingProfiler to materialize its data.

        The SamplingProfiler must also be careful to not grab any locks while the JSC execution
        thread is paused (this means it can't do anything that mallocs) because
        that could cause a deadlock. Therefore, the sampling profiler grabs
        locks for all data structures it consults before it pauses the JSC
        execution thread.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::clearVisitWeaklyHasBeenCalled):
        (JSC::CodeBlockSet::mark):
        * dfg/DFGNodeType.h:
        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::add):
        (JSC::CodeBlockSet::promoteYoungCodeBlocks):
        (JSC::CodeBlockSet::clearMarksForFullCollection):
        (JSC::CodeBlockSet::lastChanceToFinalize):
        (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
        (JSC::CodeBlockSet::contains):
        (JSC::CodeBlockSet::writeBarrierCurrentlyExecutingCodeBlocks):
        (JSC::CodeBlockSet::remove): Deleted.
        * heap/CodeBlockSet.h:
        (JSC::CodeBlockSet::getLock):
        (JSC::CodeBlockSet::iterate):
        The sampling pofiler uses the heap's CodeBlockSet to validate
        CodeBlock pointers. This data structure must now be under a lock
        because we must be certain we're not pausing the JSC execution thread
        while it's manipulating this data structure.

        * heap/ConservativeRoots.cpp:
        (JSC::ConservativeRoots::ConservativeRoots):
        (JSC::ConservativeRoots::grow):
        (JSC::ConservativeRoots::genericAddPointer):
        (JSC::ConservativeRoots::genericAddSpan):
        (JSC::ConservativeRoots::add):
        (JSC::CompositeMarkHook::CompositeMarkHook):
        (JSC::CompositeMarkHook::mark):
        * heap/ConservativeRoots.h:
        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::visitHandleStack):
        (JSC::Heap::visitSamplingProfiler):
        (JSC::Heap::traceCodeBlocksAndJITStubRoutines):
        (JSC::Heap::snapshotMarkedSpace):
        * heap/Heap.h:
        (JSC::Heap::structureIDTable):
        (JSC::Heap::codeBlockSet):
        * heap/MachineStackMarker.cpp:
        (pthreadSignalHandlerSuspendResume):
        (JSC::getCurrentPlatformThread):
        (JSC::MachineThreads::MachineThreads):
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::Thread::createForCurrentThread):
        (JSC::MachineThreads::Thread::operator==):
        (JSC::isThreadInList):
        (JSC::MachineThreads::addCurrentThread):
        (JSC::MachineThreads::machineThreadForCurrentThread):
        (JSC::MachineThreads::removeThread):
        (JSC::MachineThreads::gatherFromCurrentThread):
        (JSC::MachineThreads::Thread::Thread):
        (JSC::MachineThreads::Thread::~Thread):
        (JSC::MachineThreads::Thread::suspend):
        (JSC::MachineThreads::Thread::resume):
        (JSC::MachineThreads::Thread::getRegisters):
        (JSC::MachineThreads::Thread::Registers::stackPointer):
        (JSC::MachineThreads::Thread::Registers::framePointer):
        (JSC::MachineThreads::Thread::Registers::instructionPointer):
        (JSC::MachineThreads::Thread::freeRegisters):
        (JSC::MachineThreads::tryCopyOtherThreadStacks):
        (JSC::pthreadSignalHandlerSuspendResume): Deleted.
        (JSC::MachineThreads::Thread::operator!=): Deleted.
        * heap/MachineStackMarker.h:
        (JSC::MachineThreads::Thread::operator!=):
        (JSC::MachineThreads::getLock):
        (JSC::MachineThreads::threadsListHead):
        We can now ask a MachineThreads::Thread for its frame pointer
        and program counter on darwin and windows platforms. efl
        and gtk implementations will happen in another patch.

        * heap/MarkedBlockSet.h:
        (JSC::MarkedBlockSet::getLock):
        (JSC::MarkedBlockSet::add):
        (JSC::MarkedBlockSet::remove):
        (JSC::MarkedBlockSet::recomputeFilter):
        (JSC::MarkedBlockSet::filter):
        (JSC::MarkedBlockSet::set):
        * heap/MarkedSpace.cpp:
        (JSC::Free::Free):
        (JSC::Free::operator()):
        (JSC::FreeOrShrink::FreeOrShrink):
        (JSC::FreeOrShrink::operator()):
        (JSC::MarkedSpace::~MarkedSpace):
        (JSC::MarkedSpace::isPagedOut):
        (JSC::MarkedSpace::freeBlock):
        (JSC::MarkedSpace::freeOrShrinkBlock):
        (JSC::MarkedSpace::shrink):
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::forEachLiveCell):
        (JSC::MarkedSpace::forEachDeadCell):
        * interpreter/CallFrame.h:
        (JSC::ExecState::calleeAsValue):
        (JSC::ExecState::callee):
        (JSC::ExecState::unsafeCallee):
        (JSC::ExecState::codeBlock):
        (JSC::ExecState::scope):
        * jit/ExecutableAllocator.cpp:
        (JSC::ExecutableAllocator::dumpProfile):
        (JSC::ExecutableAllocator::getLock):
        (JSC::ExecutableAllocator::isValidExecutableMemory):
        * jit/ExecutableAllocator.h:
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC::ExecutableAllocator::allocate):
        (JSC::ExecutableAllocator::isValidExecutableMemory):
        (JSC::ExecutableAllocator::getLock):
        (JSC::ExecutableAllocator::committedByteCount):
        The sampling profiler consults the ExecutableAllocator to check
        if the frame pointer it reads is in executable allocated memory.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionCheckModuleSyntax):
        (functionStartSamplingProfiler):
        (functionSamplingProfilerStackTraces):
        * llint/LLIntPCRanges.h: Added.
        (JSC::LLInt::isLLIntPC):
        * offlineasm/asm.rb:
        I added the ability to test whether the PC is executing
        LLInt code because this code is not part of the memory
        our executable allocator allocates.

        * runtime/Executable.h:
        (JSC::ExecutableBase::isModuleProgramExecutable):
        (JSC::ExecutableBase::isExecutableType):
        (JSC::ExecutableBase::isHostFunction):
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):
        (JSC::JSLock::unlock):
        * runtime/Options.h:
        * runtime/SamplingProfiler.cpp: Added.
        (JSC::reportStats):
        (JSC::FrameWalker::FrameWalker):
        (JSC::FrameWalker::walk):
        (JSC::FrameWalker::wasValidWalk):
        (JSC::FrameWalker::advanceToParentFrame):
        (JSC::FrameWalker::isAtTop):
        (JSC::FrameWalker::resetAtMachineFrame):
        (JSC::FrameWalker::isValidFramePointer):
        (JSC::FrameWalker::isValidCodeBlock):
        (JSC::FrameWalker::tryToGetExecutableFromCallee):
        The FrameWalker class is used to walk the stack in a safe
        manner. It doesn't do anything that would deadlock, and it
        validates all pointers that it sees.

        (JSC::SamplingProfiler::SamplingProfiler):
        (JSC::SamplingProfiler::~SamplingProfiler):
        (JSC::SamplingProfiler::visit):
        (JSC::SamplingProfiler::shutdown):
        (JSC::SamplingProfiler::start):
        (JSC::SamplingProfiler::stop):
        (JSC::SamplingProfiler::pause):
        (JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread):
        (JSC::SamplingProfiler::dispatchIfNecessary):
        (JSC::SamplingProfiler::dispatchFunction):
        (JSC::SamplingProfiler::noticeJSLockAcquisition):
        (JSC::SamplingProfiler::noticeVMEntry):
        (JSC::SamplingProfiler::observeStackTrace):
        (JSC::SamplingProfiler::clearData):
        (JSC::displayName):
        (JSC::startLine):
        (JSC::startColumn):
        (JSC::sourceID):
        (JSC::url):
        (JSC::SamplingProfiler::stacktracesAsJSON):
        * runtime/SamplingProfiler.h: Added.
        (JSC::SamplingProfiler::getLock):
        (JSC::SamplingProfiler::setTimingInterval):
        (JSC::SamplingProfiler::stackTraces):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):
        (JSC::VM::setLastStackTop):
        (JSC::VM::createContextGroup):
        (JSC::VM::ensureWatchdog):
        (JSC::VM::ensureSamplingProfiler):
        (JSC::thunkGeneratorForIntrinsic):
        * runtime/VM.h:
        (JSC::VM::watchdog):
        (JSC::VM::isSafeToRecurse):
        (JSC::VM::lastStackTop):
        (JSC::VM::scratchBufferForSize):
        (JSC::VM::samplingProfiler):
        (JSC::VM::setShouldRewriteConstAsVar):
        (JSC::VM::setLastStackTop): Deleted.
        * runtime/VMEntryScope.cpp:
        (JSC::VMEntryScope::VMEntryScope):
        * tests/stress/sampling-profiler: Added.
        * tests/stress/sampling-profiler-anonymous-function.js: Added.
        (foo):
        (baz):
        * tests/stress/sampling-profiler-basic.js: Added.
        (bar):
        (foo):
        (nothing):
        (top):
        (jaz):
        (kaz):
        (checkInlining):
        * tests/stress/sampling-profiler-deep-stack.js: Added.
        (foo):
        (hellaDeep):
        (start):
        * tests/stress/sampling-profiler-microtasks.js: Added.
        (testResults):
        (loop.jaz):
        (loop):
        * tests/stress/sampling-profiler/samplingProfiler.js: Added.
        (assert):
        (let.nodePrototype.makeChildIfNeeded):
        (makeNode):
        (updateCallingContextTree):
        (doesTreeHaveStackTrace):
        (makeTree):
        (runTest):
        (dumpTree):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::JSDollarVMPrototype::isInObjectSpace):
        (JSC::JSDollarVMPrototype::isInStorageSpace):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::generateEnter):
        (JSC::Yarr::YarrGenerator::generateReturn):
        (JSC::Yarr::YarrGenerator::YarrGenerator):
        (JSC::Yarr::YarrGenerator::compile):
        (JSC::Yarr::jitCompile):
        We now have a boolean that's set to true when
        we're executing a RegExp, and to false otherwise.
        The boolean lives off of VM.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::clearVisitWeaklyHasBeenCalled):
        (JSC::CodeBlockSet::mark):
        * dfg/DFGNodeType.h:
        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::add):
        (JSC::CodeBlockSet::promoteYoungCodeBlocks):
        (JSC::CodeBlockSet::clearMarksForFullCollection):
        (JSC::CodeBlockSet::lastChanceToFinalize):
        (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
        (JSC::CodeBlockSet::contains):
        (JSC::CodeBlockSet::writeBarrierCurrentlyExecutingCodeBlocks):
        (JSC::CodeBlockSet::remove): Deleted.
        * heap/CodeBlockSet.h:
        (JSC::CodeBlockSet::getLock):
        (JSC::CodeBlockSet::iterate):
        * heap/ConservativeRoots.cpp:
        (JSC::ConservativeRoots::ConservativeRoots):
        (JSC::ConservativeRoots::genericAddPointer):
        (JSC::ConservativeRoots::add):
        (JSC::CompositeMarkHook::CompositeMarkHook):
        (JSC::CompositeMarkHook::mark):
        * heap/ConservativeRoots.h:
        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::visitHandleStack):
        (JSC::Heap::visitSamplingProfiler):
        (JSC::Heap::traceCodeBlocksAndJITStubRoutines):
        * heap/Heap.h:
        (JSC::Heap::structureIDTable):
        (JSC::Heap::codeBlockSet):
        * heap/HeapInlines.h:
        (JSC::Heap::didFreeBlock):
        (JSC::Heap::isPointerGCObject):
        (JSC::Heap::isValueGCObject):
        * heap/MachineStackMarker.cpp:
        (pthreadSignalHandlerSuspendResume):
        (JSC::getCurrentPlatformThread):
        (JSC::MachineThreads::MachineThreads):
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::Thread::createForCurrentThread):
        (JSC::MachineThreads::Thread::operator==):
        (JSC::isThreadInList):
        (JSC::MachineThreads::addCurrentThread):
        (JSC::MachineThreads::machineThreadForCurrentThread):
        (JSC::MachineThreads::removeThread):
        (JSC::MachineThreads::gatherFromCurrentThread):
        (JSC::MachineThreads::Thread::Thread):
        (JSC::MachineThreads::Thread::~Thread):
        (JSC::MachineThreads::Thread::suspend):
        (JSC::MachineThreads::Thread::resume):
        (JSC::MachineThreads::Thread::getRegisters):
        (JSC::MachineThreads::Thread::Registers::stackPointer):
        (JSC::MachineThreads::Thread::Registers::framePointer):
        (JSC::MachineThreads::Thread::Registers::instructionPointer):
        (JSC::MachineThreads::Thread::freeRegisters):
        (JSC::pthreadSignalHandlerSuspendResume): Deleted.
        (JSC::MachineThreads::Thread::operator!=): Deleted.
        * heap/MachineStackMarker.h:
        (JSC::MachineThreads::Thread::operator!=):
        (JSC::MachineThreads::getLock):
        (JSC::MachineThreads::threadsListHead):
        * heap/MarkedBlockSet.h:
        * heap/MarkedSpace.cpp:
        (JSC::Free::Free):
        (JSC::Free::operator()):
        (JSC::FreeOrShrink::FreeOrShrink):
        (JSC::FreeOrShrink::operator()):
        * interpreter/CallFrame.h:
        (JSC::ExecState::calleeAsValue):
        (JSC::ExecState::callee):
        (JSC::ExecState::unsafeCallee):
        (JSC::ExecState::codeBlock):
        (JSC::ExecState::scope):
        * jit/ExecutableAllocator.cpp:
        (JSC::ExecutableAllocator::dumpProfile):
        (JSC::ExecutableAllocator::getLock):
        (JSC::ExecutableAllocator::isValidExecutableMemory):
        * jit/ExecutableAllocator.h:
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC::ExecutableAllocator::allocate):
        (JSC::ExecutableAllocator::isValidExecutableMemory):
        (JSC::ExecutableAllocator::getLock):
        (JSC::ExecutableAllocator::committedByteCount):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionCheckModuleSyntax):
        (functionPlatformSupportsSamplingProfiler):
        (functionStartSamplingProfiler):
        (functionSamplingProfilerStackTraces):
        * llint/LLIntPCRanges.h: Added.
        (JSC::LLInt::isLLIntPC):
        * offlineasm/asm.rb:
        * runtime/Executable.h:
        (JSC::ExecutableBase::isModuleProgramExecutable):
        (JSC::ExecutableBase::isExecutableType):
        (JSC::ExecutableBase::isHostFunction):
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):
        (JSC::JSLock::unlock):
        * runtime/Options.h:
        * runtime/SamplingProfiler.cpp: Added.
        (JSC::reportStats):
        (JSC::FrameWalker::FrameWalker):
        (JSC::FrameWalker::walk):
        (JSC::FrameWalker::wasValidWalk):
        (JSC::FrameWalker::advanceToParentFrame):
        (JSC::FrameWalker::isAtTop):
        (JSC::FrameWalker::resetAtMachineFrame):
        (JSC::FrameWalker::isValidFramePointer):
        (JSC::FrameWalker::isValidCodeBlock):
        (JSC::SamplingProfiler::SamplingProfiler):
        (JSC::SamplingProfiler::~SamplingProfiler):
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        (JSC::SamplingProfiler::visit):
        (JSC::SamplingProfiler::shutdown):
        (JSC::SamplingProfiler::start):
        (JSC::SamplingProfiler::stop):
        (JSC::SamplingProfiler::pause):
        (JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread):
        (JSC::SamplingProfiler::dispatchIfNecessary):
        (JSC::SamplingProfiler::dispatchFunction):
        (JSC::SamplingProfiler::noticeJSLockAcquisition):
        (JSC::SamplingProfiler::noticeVMEntry):
        (JSC::SamplingProfiler::clearData):
        (JSC::displayName):
        (JSC::SamplingProfiler::stacktracesAsJSON):
        (WTF::printInternal):
        * runtime/SamplingProfiler.h: Added.
        (JSC::SamplingProfiler::StackFrame::StackFrame):
        (JSC::SamplingProfiler::getLock):
        (JSC::SamplingProfiler::setTimingInterval):
        (JSC::SamplingProfiler::stackTraces):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):
        (JSC::VM::setLastStackTop):
        (JSC::VM::createContextGroup):
        (JSC::VM::ensureWatchdog):
        (JSC::VM::ensureSamplingProfiler):
        (JSC::thunkGeneratorForIntrinsic):
        * runtime/VM.h:
        (JSC::VM::watchdog):
        (JSC::VM::samplingProfiler):
        (JSC::VM::isSafeToRecurse):
        (JSC::VM::lastStackTop):
        (JSC::VM::scratchBufferForSize):
        (JSC::VM::setLastStackTop): Deleted.
        * runtime/VMEntryScope.cpp:
        (JSC::VMEntryScope::VMEntryScope):
        * tests/stress/sampling-profiler: Added.
        * tests/stress/sampling-profiler-anonymous-function.js: Added.
        (platformSupportsSamplingProfiler.foo):
        (platformSupportsSamplingProfiler.baz):
        (platformSupportsSamplingProfiler):
        * tests/stress/sampling-profiler-basic.js: Added.
        (platformSupportsSamplingProfiler.bar):
        (platformSupportsSamplingProfiler.foo):
        (platformSupportsSamplingProfiler.nothing):
        (platformSupportsSamplingProfiler.top):
        (platformSupportsSamplingProfiler.jaz):
        (platformSupportsSamplingProfiler.kaz):
        (platformSupportsSamplingProfiler.checkInlining):
        (platformSupportsSamplingProfiler):
        * tests/stress/sampling-profiler-deep-stack.js: Added.
        (platformSupportsSamplingProfiler.foo):
        (platformSupportsSamplingProfiler.let.hellaDeep):
        (platformSupportsSamplingProfiler.let.start):
        (platformSupportsSamplingProfiler):
        * tests/stress/sampling-profiler-microtasks.js: Added.
        (platformSupportsSamplingProfiler.testResults):
        (platformSupportsSamplingProfiler):
        (platformSupportsSamplingProfiler.loop.jaz):
        (platformSupportsSamplingProfiler.loop):
        * tests/stress/sampling-profiler/samplingProfiler.js: Added.
        (assert):
        (let.nodePrototype.makeChildIfNeeded):
        (makeNode):
        (updateCallingContextTree):
        (doesTreeHaveStackTrace):
        (makeTree):
        (runTest):
        (dumpTree):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::generateEnter):
        (JSC::Yarr::YarrGenerator::generateReturn):
        (JSC::Yarr::YarrGenerator::YarrGenerator):
        (JSC::Yarr::YarrGenerator::compile):
        (JSC::Yarr::jitCompile):

2016-01-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Iterating over a Set/Map is too slow
        https://bugs.webkit.org/show_bug.cgi?id=152691

        Reviewed by Saam Barati.

        Set#forEach and Set & for-of are very slow. There are 2 reasons.

        1. forEach is implemented in C++. And typically, taking JS callback and calling it from C++.

        C++ to JS transition seems costly. perf result in Linux machine shows this.

            Samples: 23K of event 'cycles', Event count (approx.): 21446074385
            34.04%  jsc  libjavascriptcoregtk-4.0.so.18.3.1  [.] JSC::Interpreter::execute(JSC::CallFrameClosure&)
            20.48%  jsc  libjavascriptcoregtk-4.0.so.18.3.1  [.] vmEntryToJavaScript
             9.80%  jsc  libjavascriptcoregtk-4.0.so.18.3.1  [.] JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*)
             7.95%  jsc  libjavascriptcoregtk-4.0.so.18.3.1  [.] JSC::setProtoFuncForEach(JSC::ExecState*)
             5.65%  jsc  perf-22854.map                      [.] 0x00007f5d2c204a6f

        Writing forEach in JS eliminates this.

            Samples: 23K of event 'cycles', Event count (approx.): 21255691651
            62.91%  jsc  perf-22890.map                      [.] 0x00007fd117c0a3b9
            24.89%  jsc  libjavascriptcoregtk-4.0.so.18.3.1  [.] JSC::privateFuncSetIteratorNext(JSC::ExecState*)
             0.29%  jsc  libjavascriptcoregtk-4.0.so.18.3.1  [.] JSC::CodeBlock::updateAllPredictionsAndCountLiveness(unsigned int&, unsigned int&)
             0.24%  jsc  [vdso]                              [.] 0x00000000000008e8
             0.22%  jsc  libjavascriptcoregtk-4.0.so.18.3.1  [.] JSC::CodeBlock::predictedMachineCodeSize()
             0.16%  jsc  libjavascriptcoregtk-4.0.so.18.3.1  [.] WTF::MetaAllocator::currentStatistics()
             0.15%  jsc  libjavascriptcoregtk-4.0.so.18.3.1  [.] JSC::Lexer<unsigned char>::lex(JSC::JSToken*, unsigned int, bool)

        2. Iterator result object allocation is costly.

        Iterator result object allocation is costly. Even if the (1) is solved, when executing Set & for-of, perf result shows very slow performance due to (2).

            Samples: 108K of event 'cycles', Event count (approx.): 95529273748
            18.02%  jsc  libjavascriptcoregtk-4.0.so.18.3.1  [.] JSC::createIteratorResultObject(JSC::ExecState*, JSC::JSValue, bool)
            15.68%  jsc  jsc                                 [.] JSC::JSObject::putDirect(JSC::VM&, JSC::PropertyName, JSC::JSValue, unsigned int)
            14.18%  jsc  libjavascriptcoregtk-4.0.so.18.3.1  [.] JSC::PrototypeMap::emptyObjectStructureForPrototype(JSC::JSObject*, unsigned int)
            13.40%  jsc  perf-25420.map                      [.] 0x00007fce158006a1
             6.79%  jsc  libjavascriptcoregtk-4.0.so.18.3.1  [.] JSC::StructureTransitionTable::get(WTF::UniquedStringImpl*, unsigned int) const

        In the long term, we should implement SetIterator#next in JS and make the iterator result object allocation written in JS to encourage object allocation elimination in FTL.
        But seeing the perf result, we can find the easy to fix bottleneck in the current implementation.
        Every time createIteratorResultObject creates the empty object and use putDirect to store properties.
        The pre-baked Structure* with `done` and `value` properties makes this implementation fast.

        After these improvements, the micro benchmark[1] shows the following.

        old:
            Linked List x 212,776 ops/sec ±0.21% (162 runs sampled)
            Array x 376,156 ops/sec ±0.20% (162 runs sampled)
            Array forEach x 17,345 ops/sec ±0.99% (137 runs sampled)
            Array for-of x 16,518 ops/sec ±0.58% (160 runs sampled)
            Set forEach x 13,263 ops/sec ±0.20% (162 runs sampled)
            Set for-of x 4,732 ops/sec ±0.34% (123 runs sampled)

        new:
            Linked List x 210,833 ops/sec ±0.28% (161 runs sampled)
            Array x 371,347 ops/sec ±0.36% (162 runs sampled)
            Array forEach x 17,460 ops/sec ±0.84% (136 runs sampled)
            Array for-of x 16,188 ops/sec ±1.27% (158 runs sampled)
            Set forEach x 23,684 ops/sec ±2.46% (139 runs sampled)
            Set for-of x 12,176 ops/sec ±0.54% (157 runs sampled)

        Set#forEach becomes comparable to Array#forEach. And Set#forEach and Set & for-of are improved (1.79x, and 2.57x).
        After this optimizations, they are still much slower than linked list and array.
        This should be optimized in the long term.

        [1]: https://gist.github.com/Constellation/8db5f5b8f12fe7e283d0

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/MapPrototype.js: Copied from Source/JavaScriptCore/runtime/IteratorOperations.h.
        (forEach):
        * builtins/SetPrototype.js: Copied from Source/JavaScriptCore/runtime/IteratorOperations.h.
        (forEach):
        * runtime/CommonIdentifiers.h:
        * runtime/IteratorOperations.cpp:
        (JSC::createIteratorResultObjectStructure):
        (JSC::createIteratorResultObject):
        * runtime/IteratorOperations.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::iteratorResultObjectStructure):
        (JSC::JSGlobalObject::iteratorResultStructure): Deleted.
        (JSC::JSGlobalObject::iteratorResultStructureOffset): Deleted.
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::getOwnPropertySlot):
        (JSC::privateFuncIsMap):
        (JSC::privateFuncMapIterator):
        (JSC::privateFuncMapIteratorNext):
        (JSC::MapPrototype::finishCreation): Deleted.
        (JSC::mapProtoFuncForEach): Deleted.
        * runtime/MapPrototype.h:
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::getOwnPropertySlot):
        (JSC::privateFuncIsSet):
        (JSC::privateFuncSetIterator):
        (JSC::privateFuncSetIteratorNext):
        (JSC::SetPrototype::finishCreation): Deleted.
        (JSC::setProtoFuncForEach): Deleted.
        * runtime/SetPrototype.h:

2016-01-10  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix ARM64 build.

        * b3/air/AirOpcode.opcodes:

2016-01-10  Filip Pizlo  <fpizlo@apple.com>

        B3 should reduce Trunc(BitOr(value, constant)) where !(constant & 0xffffffff) to Trunc(value)
        https://bugs.webkit.org/show_bug.cgi?id=152955

        Reviewed by Saam Barati.

        This happens when we box an int32 and then immediately unbox it.

        This makes an enormous difference on AsmBench/FloatMM. It's a 2x speed-up on that
        benchmark. It's neutral elsewhere.

        * b3/B3ReduceStrength.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testPowDoubleByIntegerLoop):
        (JSC::B3::testTruncOrHigh):
        (JSC::B3::testTruncOrLow):
        (JSC::B3::testBitAndOrHigh):
        (JSC::B3::testBitAndOrLow):
        (JSC::B3::zero):
        (JSC::B3::run):

2016-01-10  Skachkov Oleksandr  <gskachkov@gmail.com>

        [ES6] Arrow function syntax. Get rid of JSArrowFunction and use standard JSFunction class
        https://bugs.webkit.org/show_bug.cgi?id=149855

        Reviewed by Saam Barati.

        JSArrowFunction.h/cpp were removed from JavaScriptCore, because now is used new approach for storing 
        'this', 'arguments' and 'super'

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunction):
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):
        * ftl/FTLAbstractHeapRepository.cpp:
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewFunction):
        * interpreter/Interpreter.cpp:
        * interpreter/Interpreter.h:
        * jit/JITOpcodes.cpp:
        * jit/JITOpcodes32_64.cpp:
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LLIntSlowPaths.cpp:
        * runtime/JSArrowFunction.cpp: Removed.
        * runtime/JSArrowFunction.h: Removed.
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:

2016-01-10  Filip Pizlo  <fpizlo@apple.com>

        It should be possible to run liveness over registers without also tracking Tmps
        https://bugs.webkit.org/show_bug.cgi?id=152963

        Reviewed by Saam Barati.

        This adds a RegLivenessAdapter so that we can run Liveness over registers. This makes it
        easier to write certain kinds of phases, like ReportUsedRegisters. I anticipate writing more
        code like that for handling cold function calls. It also makes code like that somewhat more
        scalable, since we're no longer using HashSets.

        Currently, the way we track sets of registers is with a BitVector. Normally, we use the
        RegisterSet class, which wraps BitVector, so that we can add()/contains() on Reg's. But in
        the liveness analysis, everything gets turned into an index. So, we want to use BitVector
        directly. To do that, I needed to make the BitVector API look a bit more like a set API. I
        think that this is good, because the lack of set methods (add/remove/contains) has caused
        bugs in the past. This makes BitVector have methods both for set operations on bits and array
        operations on bits. I think that's good, since BitVector gets used in both contexts.

        * b3/B3IndexSet.h:
        (JSC::B3::IndexSet::Iterable::iterator::iterator):
        (JSC::B3::IndexSet::Iterable::begin):
        (JSC::B3::IndexSet::dump):
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::ForEach<Tmp>::forEach):
        (JSC::B3::Air::ForEach<Arg>::forEach):
        (JSC::B3::Air::ForEach<Reg>::forEach):
        (JSC::B3::Air::Inst::forEach):
        * b3/air/AirLiveness.h:
        (JSC::B3::Air::RegLivenessAdapter::RegLivenessAdapter):
        (JSC::B3::Air::RegLivenessAdapter::maxIndex):
        (JSC::B3::Air::RegLivenessAdapter::acceptsType):
        (JSC::B3::Air::RegLivenessAdapter::valueToIndex):
        (JSC::B3::Air::RegLivenessAdapter::indexToValue):
        * b3/air/AirReportUsedRegisters.cpp:
        (JSC::B3::Air::reportUsedRegisters):
        * jit/Reg.h:
        (JSC::Reg::next):
        (JSC::Reg::index):
        (JSC::Reg::maxIndex):
        (JSC::Reg::isSet):
        (JSC::Reg::operator bool):
        * jit/RegisterSet.h:
        (JSC::RegisterSet::forEach):

2016-01-10  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Make branchMul functional in ARM B3 and minor fixes
        https://bugs.webkit.org/show_bug.cgi?id=152889

        Reviewed by Mark Lam.

        ARM64 does not have a "S" version of MUL setting the flags.
        What we do is abstract that in the MacroAssembler. The problem
        is that form requires scratch registers.

        For simplicity, I just exposed the two scratch registers
        for Air. Filip already added the concept of Scratch role,
        all I needed was to expose it for opcodes.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::branchMul32):
        (JSC::MacroAssemblerARM64::branchMul64):
        Expose a version with the scratch registers as arguments.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        Add the new form of CheckMul lowering.

        * b3/air/AirOpcode.opcodes:
        Expose the new BranchMuls.
        Remove all the Test variants that use immediates
        since Air can't handle those immediates correctly yet.

        * b3/air/opcode_generator.rb:
        Expose the Scratch role.

        * b3/testb3.cpp:
        (JSC::B3::testPatchpointLotsOfLateAnys):
        Ooops, the scratch registers were not clobbered. We were just lucky
        on x86.

2016-01-10  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] B3 is unable to do function calls on ARM64
        https://bugs.webkit.org/show_bug.cgi?id=152895

        Reviewed by Mark Lam.

        Apparently iOS does not follow the ARM64 ABI for function calls.
        Instead of giving each value a 8 bytes slot, it must be packed
        while preserving alignment.

        This patch adds a #ifdef to make function calls functional.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::marshallCCallArgument):
        (JSC::B3::Air::LowerToAir::lower):

2016-01-09  Filip Pizlo  <fpizlo@apple.com>

        Air should support Branch64 with immediates
        https://bugs.webkit.org/show_bug.cgi?id=152951

        Reviewed by Oliver Hunt.

        This doesn't significantly improve performance on any benchmarks, but it's great to get this
        obvious omission out of the way.

        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::branch64):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testPowDoubleByIntegerLoop):
        (JSC::B3::testBranch64Equal):
        (JSC::B3::testBranch64EqualImm):
        (JSC::B3::testBranch64EqualMem):
        (JSC::B3::testBranch64EqualMemImm):
        (JSC::B3::zero):
        (JSC::B3::run):

2016-01-09  Dan Bernstein  <mitz@apple.com>

        [Cocoa] Allow overriding the frameworks directory independently of using a staging install path
        https://bugs.webkit.org/show_bug.cgi?id=152926

        Reviewed by Tim Horton.

        Introduce a new build setting, WK_OVERRIDE_FRAMEWORKS_DIR. When not empty, it determines
        where the frameworks are installed. Setting USE_STAGING_INSTALL_PATH to YES sets
        WK_OVERRIDE_FRAMEWORKS_DIR to $(SYSTEM_LIBRARY_DIR)/StagedFrameworks/Safari.

        Account for the possibility of WK_OVERRIDE_FRAMEWORKS_DIR containing spaces.

        * Configurations/Base.xcconfig:
        - Replace STAGED_FRAMEWORKS_SEARCH_PATH in FRAMEWORK_SEARCH_PATHS with
          WK_OVERRIDE_FRAMEWORKS_DIR and add quotes to account for spaces.
        - Define JAVASCRIPTCORE_FRAMEWORKS_DIR based on WK_OVERRIDE_FRAMEWORKS_DIR.
        * Configurations/JSC.xcconfig:
          Add quotes to account for spaces.
        * Configurations/ToolExecutable.xcconfig:
          Ditto.
        * postprocess-headers.sh:
          Ditto.

2016-01-09  Mark Lam  <mark.lam@apple.com>

        The FTL allocated spill slots for BinaryOps is sometimes inaccurate.
        https://bugs.webkit.org/show_bug.cgi?id=152918

        Reviewed by Filip Pizlo and Saam Barati.

        * ftl/FTLCompile.cpp:
        - Updated a comment.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        - The code to compute maxNumberOfCatchSpills was unnecessarily allocating an
          extra slot for BinaryOps that don't have Untyped operands, and failing to
          allocate that extra slot for some binary ops.  This is now fixed.

        * tests/stress/ftl-shr-exception.js:
        * tests/stress/ftl-xor-exception.js:
        - Un-skipped these tests.  They now pass with this patch.

2016-01-09  Andreas Kling  <akling@apple.com>

        Use NeverDestroyed instead of DEPRECATED_DEFINE_STATIC_LOCAL
        <https://webkit.org/b/152902>

        Reviewed by Anders Carlsson.

        Mostly mechanical conversion to NeverDestroyed throughout JavaScriptCore.

        * API/JSAPIWrapperObject.mm:
        (jsAPIWrapperObjectHandleOwner):
        * API/JSManagedValue.mm:
        (managedValueHandleOwner):
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::objectGroupForBreakpointAction):
        * jit/ExecutableAllocator.cpp:
        (JSC::DemandExecutableAllocator::allocators):

2016-01-08  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should do varargs tail calls and stack overflows
        https://bugs.webkit.org/show_bug.cgi?id=152934

        Reviewed by Saam Barati.

        I was trying to get tail-call-varargs-no-stack-overflow.js.ftl-no-cjit-validate to work and
        at first I hit the stack overflow issue and then I hit the varargs tail call issue. That's
        why I have two fixes in one change. Now the test passes.

        This reduces the number of failures from 13 to 0.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower): Implement stack overflow handling.
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs): Varargs tail calls need to
        append an Oops (i.e. "unreachable").

2016-01-08  Filip Pizlo  <fpizlo@apple.com>

        B3 needs Neg()
        https://bugs.webkit.org/show_bug.cgi?id=152925

        Reviewed by Mark Lam.

        Previously we said that negation should be represented as Sub(0, x). That's wrong, since
        for floats, Sub(0, 0) == 0 while Neg(0) == -0.

        One way to solve this would be to say that anyone trying to say Neg(x) where x is a float
        should instead say BitXor(x, -0). That's actually correct, but I think that it would be odd
        to use bitops to represent floating point operations. Whatever cuteness this would have
        bought us would be outweighed by the annoyance of having to write code that matches
        Sub(0, x) for integer negation and BitXor(x, -0) for double negation. For example, this
        would mean strictly more code for anyone implementing a Neg(Neg(x))=>x strength reduction.
        Also, I suspect that the omission of Neg would cause others to make the mistake of using
        Sub to represent floating point negation.

        So, this introduces a proper Neg() opcode to B3. It's now the canonical way of saying
        negation for both ints and floats. For ints, we canonicalize Sub(0, x) to Neg(x). For
        floats, we lower it to BitXor(x, -0) on x86.

        This reduces the number of failures from 13 to 12.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::andFloat):
        (JSC::MacroAssemblerX86Common::xorDouble):
        (JSC::MacroAssemblerX86Common::xorFloat):
        (JSC::MacroAssemblerX86Common::convertInt32ToDouble):
        * b3/B3LowerMacrosAfterOptimizations.cpp:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3ReduceStrength.cpp:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::typeFor):
        * b3/air/AirOpcode.opcodes:
        * ftl/FTLB3Output.cpp:
        (JSC::FTL::Output::lockedStackSlot):
        (JSC::FTL::Output::neg):
        (JSC::FTL::Output::bitNot):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::chillDiv):
        (JSC::FTL::Output::mod):
        (JSC::FTL::Output::chillMod):
        (JSC::FTL::Output::doubleAdd):
        (JSC::FTL::Output::doubleSub):
        (JSC::FTL::Output::doubleMul):
        (JSC::FTL::Output::doubleDiv):
        (JSC::FTL::Output::doubleMod):
        (JSC::FTL::Output::doubleNeg):
        (JSC::FTL::Output::bitAnd):
        (JSC::FTL::Output::bitOr):
        (JSC::FTL::Output::neg): Deleted.
        * tests/stress/ftl-negate-zero.js: Added. This was already covered by op_negate but since
        it's such a glaring bug, I thought having a test for it specifically would be good.

2016-01-08  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 compile() doesn't clear exception handlers before we add FTL-specific ones
        https://bugs.webkit.org/show_bug.cgi?id=152922

        Reviewed by Saam Barati.

        FTL B3 was generating a handler table that first contained the old baseline handlers keyed
        by baseline's bytecode indices and then the FTL handlers keyed by FTL callsite index. That's
        wrong, since the FTL code block should not contain any baseline handlers. The fix is to
        clear the handlers before generation, sort of like FTL LLVM does.

        Also added some stuff to make it easier to inspect the handler table.

        This reduces the numbe rof failures from 25 to 13.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::dumpExceptionHandlers):
        (JSC::CodeBlock::beginDumpProfiling):
        * bytecode/CodeBlock.h:
        * ftl/FTLB3Compile.cpp:
        (JSC::FTL::compile):

2016-01-08  Filip Pizlo  <fpizlo@apple.com>

        B3 incorrectly turns NotEqual(bool, 1) into Equal(bool, 1) instead of Equal(bool, 0)
        https://bugs.webkit.org/show_bug.cgi?id=152916

        Reviewed by Mark Lam.

        This was causing a failure in an ancient DFG layout test. Thanks, ftl-eager-no-cjit!

        This reduces the number of failures from 27 to 25.

        * b3/B3ReduceStrength.cpp:

2016-01-08  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 allocateCell() should not crash
        https://bugs.webkit.org/show_bug.cgi?id=152909

        Reviewed by Mark Lam.

        This code was crashing in some tests that forced GC slow paths because it was stubbed out
        due to the use of undef. B3 doesn't have undef. In this case, there's no good reason to use
        undef. We can just use zero. Since the path is dead anyway in that case, we weren't gaining
        any LLVM optimizations by using undef.

        This reduces the number of failures from 35 to 27.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::allocateCell):

2016-01-08  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 fails to realize that binary snippets might choose to omit their fast path
        https://bugs.webkit.org/show_bug.cgi?id=152901

        Reviewed by Mark Lam.

        This reduces the number of failures from 99 to 35.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::emitBinarySnippet):

2016-01-08  Saam barati  <sbarati@apple.com>

        restoreCalleeSavesFromVMCalleeSavesBuffer should use the scratch register
        https://bugs.webkit.org/show_bug.cgi?id=152879

        Reviewed by Filip Pizlo.

        We were clobbering a register we needed when picking
        a scratch register inside an FTL OSR Exit.

        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrEntryThunkGenerator):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitRandomThunk):
        (JSC::AssemblyHelpers::restoreCalleeSavesFromVMCalleeSavesBuffer):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMCalleeSavesBuffer):
        (JSC::AssemblyHelpers::restoreCalleeSavesFromVMCalleeSavesBuffer): Deleted.
        * tests/stress/ftl-put-by-id-setter-exception-interesting-live-state.js:
        (foo):

2016-01-08  Mark Lam  <mark.lam@apple.com>

        Rolling out: Rename StringFromCharCode to StringFromSingleCharCode.
        https://bugs.webkit.org/show_bug.cgi?id=152897

        Not reviewed.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * 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::compileFromCharCode):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * runtime/StringConstructor.cpp:
        (JSC::stringFromCharCode):
        (JSC::stringFromSingleCharCode): Deleted.
        * runtime/StringConstructor.h:

2016-01-08  Per Arne Vollan  <peavo@outlook.com>

        [JSC] Use std::call_once instead of pthread_once when initializing LLVM.
        https://bugs.webkit.org/show_bug.cgi?id=152893

        Reviewed by Mark Lam.

        Use std::call_once since pthreads is not present on all platforms.

        * llvm/InitializeLLVM.cpp:
        (JSC::initializeLLVMImpl):
        (JSC::initializeLLVM):

2016-01-08  Mark Lam  <mark.lam@apple.com>

        Rename StringFromCharCode to StringFromSingleCharCode.
        https://bugs.webkit.org/show_bug.cgi?id=152897

        Reviewed by Daniel Bates.

        StringFromSingleCharCode is a better name because the intrinsic it represents
        only applies when we are converting from a single char code.  This is purely
        a refactoring patch.  There is no semantic change.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * 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::compileFromCharCode):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * runtime/StringConstructor.cpp:
        (JSC::stringFromCharCode):
        (JSC::stringFromSingleCharCode):
        * runtime/StringConstructor.h:

2016-01-08  Konstantin Tokarev  <annulen@yandex.ru>

        [mips] Fixed unused parameter warnings
        https://bugs.webkit.org/show_bug.cgi?id=152885

        Reviewed by Mark Lam.

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

2016-01-08  Konstantin Tokarev  <annulen@yandex.ru>

        [mips] Max value of immediate arg of logical ops is 0xffff
        https://bugs.webkit.org/show_bug.cgi?id=152884

        Reviewed by Michael Saboff.

        Replaced imm.m_value < 65535 checks with imm.m_value <= 65535

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::and32):
        (JSC::MacroAssemblerMIPS::or32):

2016-01-08  Konstantin Tokarev  <annulen@yandex.ru>

        [mips] Add new or32 implementation after r194613
        https://bugs.webkit.org/show_bug.cgi?id=152865

        Reviewed by Michael Saboff.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::or32):

2016-01-07  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 lazy slow paths should do exceptions
        https://bugs.webkit.org/show_bug.cgi?id=152853

        Reviewed by Saam Barati.

        This reduces the number of JSC test failures to 97.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
        * tests/stress/ftl-new-negative-array-size.js: Added.
        (foo):

2016-01-07  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, skip more tests that fail.

        * tests/stress/ftl-shr-exception.js:
        (foo):
        * tests/stress/ftl-xor-exception.js:
        (foo):

2016-01-07  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 binary snippets should do exceptions
        https://bugs.webkit.org/show_bug.cgi?id=152852

        Reviewed by Saam Barati.

        This reduces the number of JSC test failures to 110.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::emitBinarySnippet):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitBinaryBitOpSnippet):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitRightShiftSnippet):
        * tests/stress/ftl-shr-exception.js: Added.
        (foo):
        (result.foo.valueOf):
        * tests/stress/ftl-sub-exception.js: Added.
        (foo):
        (result.foo.valueOf):
        * tests/stress/ftl-xor-exception.js: Added.
        (foo):
        (result.foo.valueOf):

2016-01-07  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, skipping this test. Looks like LLVM can't handle this one, either.

        * tests/stress/ftl-call-varargs-bad-args-exception-interesting-live-state.js:
        (foo):

2016-01-07  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, skipping this test. Looks like LLVM can't handle it.

        * tests/stress/ftl-put-by-id-setter-exception-interesting-live-state.js:
        (foo):

2016-01-07  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 JS calls should do exceptions
        https://bugs.webkit.org/show_bug.cgi?id=152851

        Reviewed by Geoffrey Garen.

        This reduces the number of JSC test failures with FTL B3 to 111.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
        * tests/stress/ftl-call-bad-args-exception-interesting-live-state.js: Added.
        * tests/stress/ftl-call-bad-callee-exception-interesting-live-state.js: Added.
        * tests/stress/ftl-call-exception-interesting-live-state.js: Added.
        * tests/stress/ftl-call-exception-no-catch.js: Added.
        * tests/stress/ftl-call-exception.js: Added.
        * tests/stress/ftl-call-varargs-bad-callee-exception-interesting-live-state.js: Added.
        * tests/stress/ftl-call-varargs-exception-interesting-live-state.js: Added.
        * tests/stress/ftl-call-varargs-exception-no-catch.js: Added.
        * tests/stress/ftl-call-varargs-exception.js: Added.

2016-01-07  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 PutById should do exceptions
        https://bugs.webkit.org/show_bug.cgi?id=152850

        Reviewed by Saam Barati.

        Implemented PutById exception handling by following the idiom used in GetById. Reduces the
        number of JSC test failures to 128.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
        * tests/stress/ftl-put-by-id-setter-exception-interesting-live-state.js: Added.
        * tests/stress/ftl-put-by-id-setter-exception-no-catch.js: Added.
        * tests/stress/ftl-put-by-id-setter-exception.js: Added.
        * tests/stress/ftl-put-by-id-slow-exception-interesting-live-state.js: Added.
        * tests/stress/ftl-put-by-id-slow-exception-no-catch.js: Added.
        * tests/stress/ftl-put-by-id-slow-exception.js: Added.

2016-01-07  Commit Queue  <commit-queue@webkit.org>

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

        it broke many JSC tests when FTL B3 is enabled (Requested by
        pizlo on #webkit).

        Reverted changeset:

        "[JSC] When resolving Stack arguments, use addressing from SP
        when addressing from FP is invalid"
        https://bugs.webkit.org/show_bug.cgi?id=152840
        http://trac.webkit.org/changeset/194714

2016-01-07  Konstantin Tokarev  <annulen@yandex.ru>

        [mips] Lower immediates of logical operations.
        https://bugs.webkit.org/show_bug.cgi?id=152693

        On MIPS immediate operands of andi, ori, and xori are required to be 16-bit
        non-negative numbers.

        Reviewed by Michael Saboff.

        * offlineasm/mips.rb:

2016-01-07  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Update testCheckSubBadImm() for ARM64
        https://bugs.webkit.org/show_bug.cgi?id=152846

        Reviewed by Mark Lam.

        * b3/testb3.cpp:
        (JSC::B3::testCheckSubBadImm):
        The test was assuming the constant can always be used
        as immediate. That's obviously not the case on ARM64.

2016-01-07  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 getById() should do exceptions
        https://bugs.webkit.org/show_bug.cgi?id=152810

        Reviewed by Saam Barati.

        This adds abstractions for doing exceptions from patchpoints, and uses them to implement
        exceptions from GetById. This covers all of the following ways that a GetById might throw an
        exceptions:

        - Throw without try/catch from the vmCall() in a GetById(Untyped:)
        - Throw with try/catch from the vmCall() in a GetById(Untyped:)
        - Throw without try/catch from the callOperation() in the patchpoint of a GetById
        - Throw with try/catch from the callOperation() in the patchpoint of a GetById
        - Throw without try/catch from the Call IC generated in the patchpoint of a GetById
        - Throw with try/catch from the Call IC generated in the patchpoint of a GetById

        This requires having a default exception target in FTL-generated code, and ensuring that this
        target is generated regardless of whether we have branches to the B3 basic block of the
        default exception target. This also requires adding some extra arguments to a
        PatchpointValue, and then knowing that the arguments are used for OSR exit and not anything
        else. This also requires associating the CallSiteIndex of the patchpoint with the register
        set used for exit and with the OSR exit label for the unwind exit.

        All of the stuff that you have to worry about when wiring a patchpoint to exception handling
        is covered by the new PatchpointExceptionHandle object. You create one by calling
        preparePatchpointForExceptions(). This sets up the B3 IR representation of the patchpoint
        with stackmap arguments for the exceptional exit, and creates a PatchpointExceptionHandle
        object that can be used to create zero or more actual OSR exits. It can create both OSR exits
        for operation calls and OSR exits for unwind. You call the
        PatchpointExceptionHandle::scheduleExitCreationXXX() methods from the generator callback to
        actually get OSR exits.

        This API makes heavy use of Box<>, late paths, and link tasks. For example, you can use the
        PatchpointExceptionHandle to get a Box<JumpList> that you can append exception jumps to. When
        you use this API, it automatically registers a link task that will link the JumpList to the
        actual OSR exit label.

        This API is very flexible about how you get to the label of the OSR exit. You are encouraged
        to use the Box<JumpList> approach, but if you really just need the label, you can also get
        a RefPtr<ExceptionTarget> and rely on the fact that the ExceptionTarget object will be able
        to vend you the OSR exit label at link-time.

        This reduces the number of JSC test failures with FTL B3 from 186 to 133. It also adds a
        bunch of new tests specifically for all of the ways you might throw from GetById, and B3
        passes all of these new tests. Note that I'm not counting the new tests as part of the
        previous 186 test failures (FTL B3 failed all of the new tests prior to this change).

        After this change, it should be easy to make all of the other patchpoints also handle
        exceptions by just following the preparePatchpointForExceptions() idiom.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3StackmapValue.h:
        * b3/B3ValueRep.cpp:
        (JSC::B3::ValueRep::addUsedRegistersTo):
        (JSC::B3::ValueRep::usedRegisters):
        (JSC::B3::ValueRep::dump):
        * b3/B3ValueRep.h:
        (JSC::B3::ValueRep::doubleValue):
        (JSC::B3::ValueRep::withOffset):
        (JSC::B3::ValueRep::usedRegisters):
        * ftl/FTLB3Compile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::unreachable):
        (JSC::FTL::Output::speculate):
        * ftl/FTLExceptionTarget.cpp: Added.
        (JSC::FTL::ExceptionTarget::~ExceptionTarget):
        (JSC::FTL::ExceptionTarget::label):
        (JSC::FTL::ExceptionTarget::jumps):
        (JSC::FTL::ExceptionTarget::ExceptionTarget):
        * ftl/FTLExceptionTarget.h: Added.
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
        (JSC::FTL::DFG::LowerDFGToLLVM::getById):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitBinarySnippet):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitBinaryBitOpSnippet):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitRightShiftSnippet):
        (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
        (JSC::FTL::DFG::LowerDFGToLLVM::preparePatchpointForExceptions):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
        (JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
        * ftl/FTLPatchpointExceptionHandle.cpp: Added.
        (JSC::FTL::PatchpointExceptionHandle::create):
        (JSC::FTL::PatchpointExceptionHandle::defaultHandle):
        (JSC::FTL::PatchpointExceptionHandle::~PatchpointExceptionHandle):
        (JSC::FTL::PatchpointExceptionHandle::scheduleExitCreation):
        (JSC::FTL::PatchpointExceptionHandle::scheduleExitCreationForUnwind):
        (JSC::FTL::PatchpointExceptionHandle::PatchpointExceptionHandle):
        (JSC::FTL::PatchpointExceptionHandle::createHandle):
        * ftl/FTLPatchpointExceptionHandle.h: Added.
        * ftl/FTLState.cpp:
        * ftl/FTLState.h:
        (JSC::FTL::verboseCompilationEnabled):
        * tests/stress/ftl-get-by-id-getter-exception-interesting-live-state.js: Added.
        * tests/stress/ftl-get-by-id-getter-exception-no-catch.js: Added.
        * tests/stress/ftl-get-by-id-getter-exception.js: Added.
        * tests/stress/ftl-get-by-id-slow-exception-interesting-live-state.js: Added.
        * tests/stress/ftl-get-by-id-slow-exception-no-catch.js: Added.
        * tests/stress/ftl-get-by-id-slow-exception.js: Added.
        * tests/stress/ftl-operation-exception-interesting-live-state.js: Added.
        * tests/stress/ftl-operation-exception-no-catch.js: Added.

2016-01-07  Konstantin Tokarev  <annulen@yandex.ru>

        [mips] Implemented missing branch patching methods.
        https://bugs.webkit.org/show_bug.cgi?id=152845

        Reviewed by Michael Saboff.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::canJumpReplacePatchableBranch32WithPatch):
        (JSC::MacroAssemblerMIPS::startOfPatchableBranch32WithPatchOnAddress):
        (JSC::MacroAssemblerMIPS::revertJumpReplacementToPatchableBranch32WithPatch):

2016-01-07  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] When resolving Stack arguments, use addressing from SP when addressing from FP is invalid
        https://bugs.webkit.org/show_bug.cgi?id=152840

        Reviewed by Mark Lam.

        ARM64 has two kinds of addressing with immediates:
        -Signed 9bits direct (really only -256 to 255).
        -Unsigned 12bits scaled by the load/store size.

        When resolving the stack addresses, we easily run
        past -256 bytes from FP. Addressing from SP gives us more
        room to address the stack efficiently because we can
        use unsigned immediates.

        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::repForArg):
        * b3/air/AirAllocateStack.cpp:
        (JSC::B3::Air::allocateStack):

2016-01-07  Konstantin Tokarev  <annulen@yandex.ru>

        [mips] Make repatchCall public to fix compilation.
        https://bugs.webkit.org/show_bug.cgi?id=152843

        Reviewed by Michael Saboff.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::repatchCall):
        (JSC::MacroAssemblerMIPS::linkCall): Deleted.

2016-01-07  Konstantin Tokarev  <annulen@yandex.ru>

        [mips] Replaced subi with addi in getHostCallReturnValue
        https://bugs.webkit.org/show_bug.cgi?id=152841

        Reviewed by Michael Saboff.

        MIPS architecture does not have subi instruction, addi with negative
        number should be used instead.

        * jit/JITOperations.cpp:

2016-01-07  Mark Lam  <mark.lam@apple.com>

        ARMv7 or32(TrustedImm32, AbsoluteAddress) may have a bug with its use of dataTempRegister.
        https://bugs.webkit.org/show_bug.cgi?id=152833

        Reviewed by Michael Saboff.

        Follow-up patch to fix illegal use of memoryTempRegister as the src for ARM64's
        store32.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::or32):
        (JSC::MacroAssemblerARM64::store):

2016-01-07  Konstantin Tokarev  <annulen@yandex.ru>

        [mips] GPRInfo::toArgumentRegister missing
        https://bugs.webkit.org/show_bug.cgi?id=152838

        Reviewed by Michael Saboff.

        * jit/GPRInfo.h:
        (JSC::GPRInfo::toArgumentRegister):

2016-01-07  Mark Lam  <mark.lam@apple.com>

        ARMv7 or32(TrustedImm32, AbsoluteAddress) may have a bug with its use of dataTempRegister.
        https://bugs.webkit.org/show_bug.cgi?id=152833

        Reviewed by Benjamin Poulain.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::or32):
        - Added some assertions to make sure it is safe to use ARMRegisters::S0 as a temp.
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::or32):
        - Implement an optimization that avoids reloading the memoryTempRegister when
          the immediate is encodable as an instruction immediate.
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::or32):
        - Added an assertion to make sure it is safe to use the dataTempRegister as a temp.
        - Implement an optimization that avoids reloading the memoryTempRegister when
          the immediate is encodable as an instruction immediate.  In the event that we
          cannot encode the immediate, we'll use the addressTempRegister as a temp, and
          reload it later.

2016-01-07  Konstantin Tokarev  <annulen@yandex.ru>

        [CMake] JSC shell sources should include JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES
        https://bugs.webkit.org/show_bug.cgi?id=152664

        Reviewed by Alex Christensen.

        * shell/CMakeLists.txt:

2016-01-06  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: CRASH Attempting to pause on CSP violation not inside of script
        https://bugs.webkit.org/show_bug.cgi?id=152825
        <rdar://problem/24021276>

        Reviewed by Timothy Hatcher.

        * debugger/Debugger.cpp:
        (JSC::Debugger::breakProgram):
        We cannot pause if we are not evaluating JavaScript, so bail.

2016-01-07  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Re-enable lea() in Air on ARM64
        https://bugs.webkit.org/show_bug.cgi?id=152832

        Reviewed by Michael Saboff.

        Lea() on the MacroAssembler is not the full x86 Lea (the real one being
        x86Lea32()). Instead, it is a addPtr() with SP and a constant.

        The instruction is required to implement B3's StackSlot. It is not
        safe for big offsets but none of the stack operations are at the moment.

        * b3/air/AirOpcode.opcodes:

2016-01-07  Julien Brianceau  <jbriance@cisco.com>

        [mips] Add two missing abortWithReason implementations
        https://bugs.webkit.org/show_bug.cgi?id=136753

        Reviewed by Benjamin Poulain.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::memoryFence):
        (JSC::MacroAssemblerMIPS::abortWithReason):
        (JSC::MacroAssemblerMIPS::readCallTarget):

2016-01-07  Csaba Osztrogonác  <ossy@webkit.org>

        Add new or32 implementation to MacroAssemblerARM after r194613
        https://bugs.webkit.org/show_bug.cgi?id=152784

        Reviewed by Benjamin Poulain.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::or32):

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

        REGRESSION(r194613): JITMulGenerator needs a scratch GPR on 32-bit too.
        https://bugs.webkit.org/show_bug.cgi?id=152805

        Reviewed by Michael Saboff.

        There aren't enough registers on x86 32-bit to allocate the needed scratch GPR.
        So, we'll continue to use one of the result registers as the scratch, and
        re-compute the result at the end.

        * jit/JITMulGenerator.cpp:
        (JSC::JITMulGenerator::generateFastPath):

2016-01-06  Anders Carlsson  <andersca@apple.com>

        Add a smart block pointer
        https://bugs.webkit.org/show_bug.cgi?id=152799

        Reviewed by Tim Horton.

        Get rid of RemoteTargetBlock and replace it with WTF::BlockPtr<void ()>.

        * inspector/remote/RemoteConnectionToTarget.h:
        (Inspector::RemoteTargetBlock::RemoteTargetBlock): Deleted.
        (Inspector::RemoteTargetBlock::~RemoteTargetBlock): Deleted.
        (Inspector::RemoteTargetBlock::operator=): Deleted.
        (Inspector::RemoteTargetBlock::operator()): Deleted.
        * inspector/remote/RemoteConnectionToTarget.mm:
        (Inspector::RemoteTargetQueueTaskOnGlobalQueue):
        (Inspector::RemoteConnectionToTarget::queueTaskOnPrivateRunLoop):

2016-01-06  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] More B3 tests passing on ARM64
        https://bugs.webkit.org/show_bug.cgi?id=152787

        Reviewed by Michael Saboff.

        Some more minor bugs.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::urshift64):
        The offset was being truncated. That code was just copied
        from the 32bits version of urshift.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createGenericCompare):
        Very few instructions can encode -1 as immediate.
        TST certainly can't. The fallback works for ARM.

        * b3/air/AirOpcode.opcodes:
        Bit instructions have very specific immediate encoding.
        B3 cannot express that properly yet. I disabled those
        forms for now. Immediates encoding is something we'll really 
        have to look into at some point for B3 ARM64.

2016-01-06  Michael Catanzaro  <mcatanzaro@igalia.com>

        Silence -Wtautological-compare
        https://bugs.webkit.org/show_bug.cgi?id=152768

        Reviewed by Saam Barati.

        * runtime/Options.cpp:
        (JSC::Options::setAliasedOption):

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

        Make sure that the basic throw-from-operation mode of throwing makes sense in FTL B3
        https://bugs.webkit.org/show_bug.cgi?id=152798

        Reviewed by Oliver Hunt.

        This really just contains one change: we inline emitBranchToOSRExitIfWillCatchException()
        into callCheck(), since that was its only caller. This makes it a bit more clear what is
        going on.

        It turns out that FTL B3 already handled this case properly. I added a test that I believe
        illustrates this. Note that although the test uses GetById, which ordinarily throws
        exceptions from inside a patchpoint, it uses it in such a way that the exception is thrown
        from the operation call for the non-cell bypass path of a GetById(UntypedUse:).

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
        (JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitBranchToOSRExitIfWillCatchException): Deleted.
        * tests/stress/ftl-operation-exception.js: Added.
        (foo):

2016-01-06  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove duplicate check
        https://bugs.webkit.org/show_bug.cgi?id=152792

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.RemoteObject.prototype._generatePreview): Deleted.
        This method is only called from one place, and it does an equivalent
        check before calling this function. Remove the duplicate check.

2016-01-06  Brian Burg  <bburg@apple.com>

        Add a WebKit SPI for registering an automation controller with RemoteInspector
        https://bugs.webkit.org/show_bug.cgi?id=151576

        Reviewed by Dan Bernstein and Joseph Pecoraro.

        Given a RemoteInspector endpoint that is instantiated in UIProcess, there
        should be a way to delegate automation-related functionality and policy to
        clients of WebKit.

        This class adds a RemoteInspector::Client interface that serves a delegate.
        This is ultimately delegated via _WKAutomationDelegate, which is an SPI
        that allows clients to install an Objective-C delegate for automation.

        The setting for whether remote automation is allowed is included in the
        listing that RemoteInspector sends out. It is updated when RemoteInspector::Client
        is assigned, or when the client signals that its capabilities have changed.

        * inspector/remote/RemoteInspector.h:
        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::setRemoteInspectorClient): Added.
        (Inspector::RemoteInspector::pushListingsNow):

            In the listing, include whether the application supports remote automation.

        * inspector/remote/RemoteInspectorConstants.h: Add a constant.

2016-01-05  Keith Miller  <keith_miller@apple.com>

        [ES6] Boolean, Number, Map, RegExp, and Set should be subclassable
        https://bugs.webkit.org/show_bug.cgi?id=152765

        Reviewed by Michael Saboff.

        This patch enables subclassing of five more builtins: Boolean, Number, Map, RegExp, and Set.

        * runtime/BooleanConstructor.cpp:
        (JSC::constructWithBooleanConstructor):
        (JSC::constructBoolean): Deleted.
        * runtime/BooleanConstructor.h:
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/NumberConstructor.cpp:
        (JSC::constructWithNumberConstructor):
        * runtime/RegExpConstructor.cpp:
        (JSC::getRegExpStructure):
        (JSC::constructRegExp):
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):
        * tests/es6.yaml:
        * tests/stress/class-subclassing-misc.js: Added.
        (B):
        (N):
        (M):
        (R):
        (S):
        (test):

2016-01-06  Julien Brianceau  <jbriance@cisco.com>

        [mips] Fix branchTruncateDoubleToUint32 implementation in macro assembler
        https://bugs.webkit.org/show_bug.cgi?id=152782

        Reviewed by Benjamin Poulain.

        Already covered by LayoutTests/js/dfg-uint32array-overflow-values test.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::branchTruncateDoubleToUint32):

2016-01-06  Julien Brianceau  <jbriance@cisco.com>

        [mips] Fix or32 implementation in macro assembler
        https://bugs.webkit.org/show_bug.cgi?id=152781

        Reviewed by Michael Saboff.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::or32):

2016-01-06  Julien Brianceau  <jbriance@cisco.com>

        [mips] Add missing branchAdd32 implementation in macro assembler
        https://bugs.webkit.org/show_bug.cgi?id=152785

        Reviewed by Michael Saboff.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::branchAdd32):

2016-01-06  Andy VanWagoner  <thetalecrafter@gmail.com>

        [ES6] Date.prototype should be a plain object
        https://bugs.webkit.org/show_bug.cgi?id=152574

        Reviewed by Benjamin Poulain.

        * runtime/DateConstructor.cpp:
        (JSC::DateConstructor::finishCreation):
        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::DatePrototype):
        * runtime/DatePrototype.h:
        * tests/mozilla/mozilla-tests.yaml: Expect errors from old Date.prototype as Date instance tests.

2016-01-06  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Get more of testb3 to pass on ARM64
        https://bugs.webkit.org/show_bug.cgi?id=152737

        Reviewed by Geoffrey Garen.

        A bunch of minor bugs and missing function to make most of testb3
        run on ARM64.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::canEncodePImmOffset):
        (JSC::ARM64Assembler::canEncodeSImmOffset):
        (JSC::isInt9): Deleted.
        (JSC::isUInt12): Deleted.
        * assembler/ARMv7Assembler.h:
        * assembler/AssemblerCommon.h: Added.
        (JSC::isInt9):
        (JSC::isUInt12):
        (JSC::isValidScaledUImm12):
        (JSC::isValidSignedImm9):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::load16SignedExtendTo32):
        (JSC::MacroAssemblerARM64::load8SignedExtendTo32):
        (JSC::MacroAssemblerARM64::store16):
        (JSC::MacroAssemblerARM64::absFloat):
        (JSC::MacroAssemblerARM64::loadFloat):
        (JSC::MacroAssemblerARM64::storeFloat):
        (JSC::MacroAssemblerARM64::loadSignedAddressedByUnsignedImmediate):
        (JSC::MacroAssemblerARM64::loadSignedAddressedByUnscaledImmediate):
        (JSC::MacroAssemblerARM64::tryLoadSignedWithOffset):
        (JSC::MacroAssemblerARM64::loadSignedAddressedByUnsignedImmediate<8>):
        (JSC::MacroAssemblerARM64::loadSignedAddressedByUnsignedImmediate<16>):
        (JSC::MacroAssemblerARM64::loadSignedAddressedByUnscaledImmediate<8>):
        (JSC::MacroAssemblerARM64::loadSignedAddressedByUnscaledImmediate<16>):
        * assembler/X86Assembler.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::effectiveAddr):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isValidImmForm):
        (JSC::B3::Air::Arg::isValidAddrForm):
        (JSC::B3::Air::Arg::isValidForm):
        * b3/air/AirOpcode.opcodes:

2016-01-05  Zan Dobersek  <zdobersek@igalia.com>

        [CMake] Remove USE_UDIS86 variable
        https://bugs.webkit.org/show_bug.cgi?id=152731

        Reviewed by Gyuyoung Kim.

        * CMakeLists.txt: Unconditionally build the Udis86-specific files.

2016-01-05  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 fails cdjs-tests.yaml/red_black_tree_test.js.ftl-eager-no-cjit
        https://bugs.webkit.org/show_bug.cgi?id=152770

        Reviewed by Mark Lam.

        It turns out that liveness didn't know that the return value GPR or FPR is live at the
        return. Consequently, we can end up with code that clobbers the return value register after
        the move of the return value into that register. This could happen if we start with
        something like:

            Move 42(%tmp1), %tmp2
            Move 50(%tmp1), %tmp3
            Move %tmp3, 58(%tmp1)
            Move %tmp2, %rax
            Ret

        Then we might coalesce %tmp2 with %rax:

            Move 42(%tmp1), %rax
            Move 50(%tmp1), %tmp3
            Move %tmp3, 58(%tmp1)
            Ret

        But now there is no use of %rax after that first instruction, so %rax appears dead at the
        other two Move's. So, the register allocator could then do this:

            Move 42(%tmp1), %rax
            Move 50(%tmp1), %rax
            Move %rax, 58(%tmp1)
            Ret

        And that's clearly wrong. This patch solves this issue by replacing the old Ret instruction
        with Ret32, Ret64, RetFloat, and RetDouble. These all take the return value register as an
        argument. They also tell Air which parts of the return value register the caller will
        observe. That's great for width analysis.

        This resolves a test failure in the CDjs red_black_tree_test. This reduces the total number
        of JSC test failures from 217 to 191.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::oops):
        (JSC::MacroAssembler::ret32):
        (JSC::MacroAssembler::ret64):
        (JSC::MacroAssembler::retFloat):
        (JSC::MacroAssembler::retDouble):
        (JSC::MacroAssembler::shouldConsiderBlinding):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * b3/air/AirHandleCalleeSaves.cpp:
        (JSC::B3::Air::handleCalleeSaves):
        * b3/air/AirOpcode.opcodes:
        * b3/air/opcode_generator.rb:

2016-01-05  Keith Miller  <keith_miller@apple.com>

        Unreviewed build fix. A symbol was being exported that should not have been.

        * runtime/Structure.h:

2016-01-05  Commit Queue  <commit-queue@webkit.org>

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

        This change introduced JSC test failures (Requested by
        ryanhaddad on #webkit).

        Reverted changeset:

        "[ES6] Date.prototype should be a plain object"
        https://bugs.webkit.org/show_bug.cgi?id=152574
        http://trac.webkit.org/changeset/194603

2016-01-05  Filip Pizlo  <fpizlo@apple.com>

        stress/v8-crypto-strict.js.ftl-eager-no-cjit in FTL B3 fails with an assertion in the callframe shuffler
        https://bugs.webkit.org/show_bug.cgi?id=152756

        Reviewed by Saam Barati.

        This fixes a really obvious and dumb tail call bug in FTL B3. I think that tail calls work
        for real now. I have no idea why I got any tail call tests to pass before this fix.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):

2016-01-04  Mark Lam  <mark.lam@apple.com>

        Profiling should detect when multiplication overflows but does not create negative zero.
        https://bugs.webkit.org/show_bug.cgi?id=132470

        Reviewed by Geoffrey Garen.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::or32):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::or32):
        - New or32 emitter needed by the mul snippet.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::resultProfileForBytecodeOffset):
        (JSC::CodeBlock::updateResultProfileForBytecodeOffset): Deleted.
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::ensureResultProfile):
        (JSC::CodeBlock::addResultProfile): Deleted.
        (JSC::CodeBlock::likelyToTakeDeepestSlowCase): Deleted.
        - Added a m_bytecodeOffsetToResultProfileIndexMap because we can now add result
          profiles in any order (based on runtime execution), not necessarily in bytecode
          order at baseline compilation time.

        * bytecode/ValueProfile.cpp:
        (WTF::printInternal):
        * bytecode/ValueProfile.h:
        (JSC::ResultProfile::didObserveInt52Overflow):
        (JSC::ResultProfile::setObservedInt52Overflow):
        - Add new Int52Overflow flags.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::makeSafe):
        - Now with more straightforward mapping of profiling info.

        * dfg/DFGCommon.h:
        - Fixed a typo in a comment.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::arithNodeFlags):
        (JSC::DFG::Node::mayHaveNonIntResult):
        (JSC::DFG::Node::hasConstantBuffer):
        * dfg/DFGNodeFlags.cpp:
        (JSC::DFG::dumpNodeFlags):
        * dfg/DFGNodeFlags.h:
        (JSC::DFG::nodeMayOverflowInt52):
        (JSC::DFG::nodeCanSpeculateInt52):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        - We now have profiling info for whether the result was ever seen to be a non-Int.
          Use this to make a better prediction.

        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_div):
        (JSC::JIT::emit_op_mul):
        - Switch to using CodeBlock::ensureResultProfile().  ResultProfiles can now be
          created at any time (including the slow path), not just in bytecode order
          during baseline compilation.

        * jit/JITMulGenerator.cpp:
        (JSC::JITMulGenerator::generateFastPath):
        - Removed the fast path profiling code for NegZero because we'll go to the slow
          path anyway.  Let the slow path do the profiling for us.
        - Added profiling for NegZero and potential Int52 overflows in the fast path
          that does double math.

        * runtime/CommonSlowPaths.cpp:
        (JSC::updateResultProfileForBinaryArithOp):
        - Removed the RETURN_WITH_RESULT_PROFILING macro (2 less macros), and just use
          the RETURN_WITH_PROFILING macro instead with a call to
          updateResultProfileForBinaryArithOp().  This makes it clear what we're doing
          to do profiling in each case, and also allows us to do custom profiling for
          each opcode if needed.  However, so far, we always call
          updateResultProfileForBinaryArithOp().

2016-01-05  Keith Miller  <keith_miller@apple.com>

        [ES6] Arrays should be subclassable.
        https://bugs.webkit.org/show_bug.cgi?id=152706

        Reviewed by Benjamin Poulain.

        This patch enables full subclassing of Arrays. We do this by fetching the new.target's prototype property
        in the Array constructor and transitioning the old structure to have the new prototype. This method has
        two downsides. The first is that we clobber the transition watchpoint on the base structure. The second,
        which is currently very significant but should be fixed in a future patch, is that we allocate a new
        structure for each new derived class we allocate.

        * runtime/ArrayConstructor.cpp:
        (JSC::constructArrayWithSizeQuirk):
        (JSC::constructWithArrayConstructor):
        (JSC::callArrayConstructor):
        * runtime/ArrayConstructor.h:
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::arrayStructureForIndexingTypeDuringAllocation):
        (JSC::JSGlobalObject::arrayStructureForProfileDuringAllocation):
        (JSC::constructEmptyArray):
        (JSC::constructArray):
        (JSC::constructArrayNegativeIndexed):
        * runtime/PrototypeMap.h:
        * runtime/Structure.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::createSubclassStructure):
        * tests/es6.yaml:
        * tests/stress/class-subclassing-array.js: Added.
        (A):
        (B.prototype.get 1):
        (B):
        (C):
        (test):

2016-01-05  Filip Pizlo  <fpizlo@apple.com>

        regress/script-tests/deltablue-varargs.js.ftl-no-cjit-no-put-stack-validate on FTL B3 gets a B3 validation failure
        https://bugs.webkit.org/show_bug.cgi?id=152754

        Reviewed by Geoffrey Garen and Saam Barati.

        It turns out that the FTL was creating orphans. Rather than making the FTL handle them by
        itself, I gave B3 the power to eliminate them for you. I also made the dumper print them
        since otherwise, you wouldn't know anything about the orphan when looking at a validation
        failure or other kind of procedure dump.

        * b3/B3IndexSet.h:
        (JSC::B3::IndexSet::add):
        (JSC::B3::IndexSet::addAll):
        (JSC::B3::IndexSet::remove):
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::dump):
        (JSC::B3::Procedure::deleteValue):
        (JSC::B3::Procedure::deleteOrphans):
        (JSC::B3::Procedure::dominators):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::cfg):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):

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

        Re-landing: Add validation of JSC options to catch typos.
        https://bugs.webkit.org/show_bug.cgi?id=152549

        Reviewed by Benjamin Poulain.

        1. If a JSC_xxx option is found and xxx is not a valid option, we will now log
           an error message.
        2. If a --xxx jsc option is specified, but xxx is not a valid option, we will
           now log an error message.
        3. Added JSC_validateOptions, which if set to true will cause the VM to crash if
           an invalid option was seen during options parsing.

        In this version for re-landing, I removed the change where I disallowed -- options
        after the script name.  Apparently, we have some test harnesses that do append the
        -- options after the script name.

        * jsc.cpp:
        (CommandLine::parseArguments):
        * runtime/Options.cpp:
        (JSC::Options::initialize):
        * runtime/Options.h:

2016-01-05  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should do ArithNegate
        https://bugs.webkit.org/show_bug.cgi?id=152745

        Reviewed by Geoffrey Garen.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithNegate):

2016-01-05  Andy VanWagoner  <thetalecrafter@gmail.com>

        [ES6] Date.prototype should be a plain object
        https://bugs.webkit.org/show_bug.cgi?id=152574

        Reviewed by Benjamin Poulain.

        * runtime/DateConstructor.cpp:
        (JSC::DateConstructor::finishCreation):
        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::DatePrototype):
        * runtime/DatePrototype.h:

2016-01-05  Commit Queue  <commit-queue@webkit.org>

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

        "Causes bot failures" (Requested by mlam on #webkit).

        Reverted changeset:

        "Add validation of JSC options to catch typos."
        https://bugs.webkit.org/show_bug.cgi?id=152549
        http://trac.webkit.org/changeset/194590

2016-01-05  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should do In
        https://bugs.webkit.org/show_bug.cgi?id=152744

        Reviewed by Michael Saboff.

        This was easy; I just used the same idiom that we already established for ICs in FTL B3.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileIn):

2016-01-05  Filip Pizlo  <fpizlo@apple.com>

        Implement B3 version of FTL::Output::check()
        https://bugs.webkit.org/show_bug.cgi?id=152743

        Reviewed by Geoffrey Garen.

        Turns out this was just like the LLVM version.

        * ftl/FTLB3Output.cpp:
        (JSC::FTL::Output::branch):
        (JSC::FTL::Output::check):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::switchInstruction):
        (JSC::FTL::Output::check): Deleted.

2016-01-05  Mark Lam  <mark.lam@apple.com>

        Add support for aliasing JSC Options.
        https://bugs.webkit.org/show_bug.cgi?id=152551

        Reviewed by Filip Pizlo.

        This allows us to use old options names as well.  This is for the benefit of
        third party tools which may have been built to rely on those old options.  The
        old option names will be mapped to the current option names in setOption().

        For some options, the old option name specifies the inverse boolean value of the
        current option name.  setOption() will take care of inverting the value before
        applying it to the option.

        * jsc.cpp:
        (CommandLine::parseArguments):
        - Switch to dumping only overridden options here.  Verbose dumping is too much
          for common usage.
        * runtime/Options.cpp:
        (JSC::overrideOptionWithHeuristic):
        (JSC::Options::overrideAliasedOptionWithHeuristic):
        (JSC::computeNumberOfWorkerThreads):
        (JSC::Options::initialize):
        (JSC::Options::setOptionWithoutAlias):
        (JSC::invertBoolOptionValue):
        (JSC::Options::setAliasedOption):
        (JSC::Options::setOption):
        (JSC::Options::dumpAllOptions):
        - String.ascii() converts newline characters to '?', and this was messing up the
          printing of the options.  Switched to using String.utf8() instead.
        (JSC::Options::dumpOption):
        * runtime/Options.h:

2016-01-05  Mark Lam  <mark.lam@apple.com>

        Add validation of JSC options to catch typos.
        https://bugs.webkit.org/show_bug.cgi?id=152549

        Reviewed by Benjamin Poulain.

        1. If a JSC_xxx option is found and xxx is not a valid option, we will now log
           an error message.
        2. The jsc app is commonly used as follows:

               $ jsc [jsc options] [scripts]
     
           Previously, we'll continue to parse for [jsc options] after [scripts] is seen.
           We won't do this anymore.  Any --xxx jsc options must precede the [scripts]
           arguments.

        3. If a --xxx jsc option is specified, but xxx is not a valid option, we will
           now log an error message.

        4. Added JSC_validateOptions, which if set to true will cause the VM to crash if
           an invalid option was seen during options parsing.

        * jsc.cpp:
        (CommandLine::parseArguments):
        * runtime/Options.cpp:
        (JSC::Options::initialize):
        * runtime/Options.h:

2016-01-04  Keith Miller  <keith_miller@apple.com>

        Turn off Internal Function inlining in the DFG for super calls.
        https://bugs.webkit.org/show_bug.cgi?id=152695

        Reviewed by Geoffrey Garen.

        Currently, we inline several InternalFunctions into an alloctation with a
        fixed structure in the DFG. This optimization is not valid when the
        InternalFunction is called via a super call.

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

2016-01-04  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should do binary snippets
        https://bugs.webkit.org/show_bug.cgi?id=152668

        Reviewed by Mark Lam.

        This finishes all of the rest of the snippets.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitOr):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitXor):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitRShift):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitLShift):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitURShift):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitBinaryBitOpSnippet):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitRightShiftSnippet):
        (JSC::FTL::DFG::LowerDFGToLLVM::allocateCell):
        * tests/stress/object-bit-or.js: Added.
        (foo):
        (things.valueOf):
        * tests/stress/object-bit-xor.js: Added.
        (foo):
        (things.valueOf):
        * tests/stress/object-lshift.js: Added.
        (foo):
        (things.valueOf):
        * tests/stress/object-rshift.js: Added.
        (foo):
        (things.valueOf):
        * tests/stress/object-urshift.js: Added.
        (foo):
        (things.valueOf):
        * tests/stress/untyped-bit-or.js: Added.
        (foo):
        (valueOf):
        * tests/stress/untyped-bit-xor.js: Added.
        (foo):
        (valueOf):
        * tests/stress/untyped-lshift.js: Added.
        (foo):
        (valueOf):
        * tests/stress/untyped-rshift.js: Added.
        (foo):
        (valueOf):
        * tests/stress/untyped-urshift.js: Added.
        (foo):
        (valueOf):

2016-01-04  Mark Lam  <mark.lam@apple.com>

        isUntypedSpeculationForArithmetic is wrong.
        https://bugs.webkit.org/show_bug.cgi?id=152708

        Reviewed by Filip Pizlo.

        The isUntypedSpeculation...() checks should return true is we ever see
        non-numeric types, regardless of whether numeric types are seen or not.
        Previously, they only return true if we only see non-numeric types, and false if
        we ever see numeric types.

        This patch is perf neutral on both x86_64 and x86.

        * bytecode/SpeculatedType.h:
        (JSC::isUntypedSpeculationForArithmetic):
        (JSC::isUntypedSpeculationForBitOps):

2016-01-04  Tim Horton  <timothy_horton@apple.com>

        Turn on gesture events when building for Yosemite
        https://bugs.webkit.org/show_bug.cgi?id=152704
        rdar://problem/24042472

        Reviewed by Anders Carlsson.

        * Configurations/FeatureDefines.xcconfig:

2016-01-04  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should do BitAnd binary snippets
        https://bugs.webkit.org/show_bug.cgi?id=152713

        Reviewed by Mark Lam.

        Getting ready to finish up the binary bitop snippets.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitAnd):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitBinarySnippet):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitBinaryBitOpSnippet):
        (JSC::FTL::DFG::LowerDFGToLLVM::allocateCell):
        * tests/stress/object-bit-and.js: Added.
        (foo):
        (things.valueOf):
        * tests/stress/untyped-bit-and.js: Added.
        (foo):
        (valueOf):

2016-01-04  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should do all of the non-bitop binary snippets
        https://bugs.webkit.org/show_bug.cgi?id=152709

        Reviewed by Mark Lam.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileStrCat):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithDiv):
        * tests/stress/object-add.js: Added.
        (foo):
        (things.valueOf):
        * tests/stress/object-div.js: Added.
        (foo):
        (things.valueOf):
        * tests/stress/object-mul.js: Added.
        (foo):
        (things.valueOf):
        * tests/stress/untyped-add.js: Added.
        (foo):
        (valueOf):
        * tests/stress/untyped-div.js: Added.
        (foo):
        (valueOf):
        * tests/stress/untyped-mul.js: Added.
        (foo):
        (valueOf):

2016-01-04  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should do the ArithSub binary snippet
        https://bugs.webkit.org/show_bug.cgi?id=152705

        Reviewed by Saam Barati.

        This implements the ArithSub binary snippet generator in FTL B3.

        While doing this, I discovered that the DFG type inference logic for ArithSub contains a
        classic mistake: it causes the snippets to kick in when the type set does not contain numbers
        rather than kicking in when the type set contains non-numbers. So, the original test that I
        wrote for this doesn't work right (it runs to completion but OSR exits ad infinitum). I wrote
        a second test that is simpler, and that one shows that the binary snippets "work". That's
        sort of a joke though, since the only way to trigger binary snippets is to never pass numbers
        and the only way to actually cause a binary snippet to do meaninful work is to pass numbers.
        I filed a bug about this mess: https://bugs.webkit.org/show_bug.cgi?id=152708.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileUntypedBinaryOp):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
        (JSC::FTL::DFG::LowerDFGToLLVM::nonSpeculativeCompare):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitBinarySnippet):
        (JSC::FTL::DFG::LowerDFGToLLVM::allocateCell):
        (JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
        * tests/stress/object-sub.js: Added.
        (foo):
        (things.valueOf):
        * tests/stress/untyped-sub.js: Added.
        (foo):
        (valueOf):

2016-01-04  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, disable FTL B3 for now. I didn't intend to enable it yet.

        * dfg/DFGCommon.h:

2016-01-04  Filip Pizlo  <fpizlo@apple.com>

        B3 patchpoints should allow requesting scratch registers
        https://bugs.webkit.org/show_bug.cgi?id=152669

        Reviewed by Benjamin Poulain.

        Scratch registers are something that we often need in many patchpoint use cases. In LLVM's
        patchpoints, we didn't have a good way to request scratch registers. So, our current FTL code
        often does crazy scratch register allocation madness even when it would be better to just ask
        the backend for some registers. This patch adds a mechanism for requesting scratch registers
        in B3, and wires it all the way to all of our register allocation and liveness
        infrastructure.

        From the standpoint of a patchpoint, a "scratch register" is an instruction argument that
        only admits Tmp and is defined early (like an early clobber register) and is used late (like
        what we previously called LateUse, except that this time it's also a warm use). We already
        had the beginning of support for early def's because of early clobbers, and we already
        supported late uses albeit cold ones. I really only needed to add one new role: "Scratch",
        which means both early def and late use in much the same way as "UseDef" means both early
        use and late def. But, it feels better to complete the set of roles, so I added LateColdUse
        to differentiate from LateUse (which is now a warm use) and EarlyDef to differentiate from
        Def (which is, and always has been, a late def). Forcing the code to deal with the full
        matrix of possibilities resulted in what is probably a progression in how we handle defs in
        the register and stack allocators. The new Inst::forEachDef(Inst*, Inst*, callback) fully
        recognizes that a "def" is something that can come from either the preceding instruction or
        the succeeding one.

        This doesn't add any new functionality to FTL B3 yet, but the new scratch register mechanism
        is covered by new testb3 tests.

        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::isValid):
        (JSC::B3::CheckSpecial::admitsStack):
        (JSC::B3::CheckSpecial::generate):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::forEachArg):
        (JSC::B3::PatchpointSpecial::isValid):
        (JSC::B3::PatchpointSpecial::admitsStack):
        (JSC::B3::PatchpointSpecial::generate):
        * b3/B3PatchpointValue.cpp:
        (JSC::B3::PatchpointValue::dumpMeta):
        (JSC::B3::PatchpointValue::PatchpointValue):
        * b3/B3PatchpointValue.h:
        * b3/B3StackmapGenerationParams.cpp:
        (JSC::B3::StackmapGenerationParams::unavailableRegisters):
        * b3/B3StackmapGenerationParams.h:
        (JSC::B3::StackmapGenerationParams::gpScratch):
        (JSC::B3::StackmapGenerationParams::fpScratch):
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        (JSC::B3::StackmapSpecial::isValidImpl):
        (JSC::B3::StackmapSpecial::admitsStackImpl):
        (JSC::B3::StackmapSpecial::repsImpl):
        (JSC::B3::StackmapSpecial::isArgValidForValue):
        (JSC::B3::StackmapSpecial::appendRepsImpl): Deleted.
        * b3/B3StackmapSpecial.h:
        * b3/air/AirAllocateStack.cpp:
        (JSC::B3::Air::allocateStack):
        * b3/air/AirArg.cpp:
        (WTF::printInternal):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isAnyUse):
        (JSC::B3::Air::Arg::isColdUse):
        (JSC::B3::Air::Arg::isEarlyUse):
        (JSC::B3::Air::Arg::isLateUse):
        (JSC::B3::Air::Arg::isAnyDef):
        (JSC::B3::Air::Arg::isEarlyDef):
        (JSC::B3::Air::Arg::isLateDef):
        (JSC::B3::Air::Arg::isZDef):
        (JSC::B3::Air::Arg::Arg):
        (JSC::B3::Air::Arg::imm):
        (JSC::B3::Air::Arg::isDef): Deleted.
        * b3/air/AirBasicBlock.h:
        (JSC::B3::Air::BasicBlock::at):
        (JSC::B3::Air::BasicBlock::get):
        (JSC::B3::Air::BasicBlock::last):
        * b3/air/AirEliminateDeadCode.cpp:
        (JSC::B3::Air::eliminateDeadCode):
        * b3/air/AirFixPartialRegisterStalls.cpp:
        (JSC::B3::Air::fixPartialRegisterStalls):
        * b3/air/AirInst.cpp:
        (JSC::B3::Air::Inst::hasArgEffects):
        * b3/air/AirInst.h:
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::extraEarlyClobberedRegs):
        (JSC::B3::Air::Inst::forEachDef):
        (JSC::B3::Air::Inst::forEachDefWithExtraClobberedRegs):
        (JSC::B3::Air::Inst::reportUsedRegisters):
        (JSC::B3::Air::Inst::forEachTmpWithExtraClobberedRegs): Deleted.
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * b3/air/AirLiveness.h:
        (JSC::B3::Air::AbstractLiveness::AbstractLiveness):
        (JSC::B3::Air::AbstractLiveness::LocalCalc::execute):
        * b3/air/AirSpillEverything.cpp:
        (JSC::B3::Air::spillEverything):
        * b3/air/AirTmpWidth.cpp:
        (JSC::B3::Air::TmpWidth::recompute):
        * b3/air/AirUseCounts.h:
        (JSC::B3::Air::UseCounts::UseCounts):
        * b3/testb3.cpp:
        (JSC::B3::testPatchpointAny):
        (JSC::B3::testPatchpointGPScratch):
        (JSC::B3::testPatchpointFPScratch):
        (JSC::B3::testPatchpointLotsOfLateAnys):
        (JSC::B3::run):

2016-01-04  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the !ENABLE(INTL) build after r193493
        https://bugs.webkit.org/show_bug.cgi?id=152689

        Reviewed by Alex Christensen.

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

2016-01-04  Csaba Osztrogonác  <ossy@webkit.org>

        JSC generator scripts shouldn't have verbose output
        https://bugs.webkit.org/show_bug.cgi?id=152382

        Reviewed by Michael Catanzaro.

        * b3/air/opcode_generator.rb:
        * generate-bytecode-files:
        * offlineasm/asm.rb:
        * offlineasm/generate_offset_extractor.rb:
        * offlineasm/parser.rb:

2016-01-04  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Build B3 by default on iOS ARM64
        https://bugs.webkit.org/show_bug.cgi?id=152525

        Reviewed by Filip Pizlo.

        Minor changes required to get testb3 to compile.

        * Configurations/ToolExecutable.xcconfig:
        We need an entitlement to allocate executable memory.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::scratchRegister):
        (JSC::MacroAssemblerARM64::getCachedDataTempRegisterIDAndInvalidate):
        (JSC::MacroAssemblerARM64::getCachedMemoryTempRegisterIDAndInvalidate):
        Expose one of the scratch registers for ValueRep::emitRestore().
        Guard the use of scratch registers when not allowed.

        * b3/air/AirOpcode.opcodes:
        ARM addressing is a bit different. Skip Addr to make things build.

        * b3/testb3.cpp:
        (JSC::B3::testPatchpointWithStackArgumentResult):
        Add on memory only exists on x86.

        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::macroScratchRegisters):
        Add the two scratch registers, useful for patchpoints.

2016-01-03  Khem Raj  <raj.khem@gmail.com>

        WebKit fails to build with musl libc library
        https://bugs.webkit.org/show_bug.cgi?id=152625

        Reviewed by Daniel Bates.

        Qualify isnan() calls with std namespace.

        * runtime/Options.cpp:
        (Option::operator==): Add std namespace qualifier.

2016-01-03  Andreas Kling  <akling@apple.com>

        Remove redundant StringImpl substring creation function.
        <https://webkit.org/b/152652>

        Reviewed by Daniel Bates.

        Remove jsSubstring8() and make the only call site use jsSubstring().

        * runtime/JSString.h:
        (JSC::jsSubstring8): Deleted.
        * runtime/StringPrototype.cpp:
        (JSC::replaceUsingRegExpSearch):

2016-01-02  Khem Raj  <raj.khem@gmail.com>

        Clang's builtin for clear_cache accepts char* and errors out
        when using void*, using char* work on both gcc and clang
        since char* is auto-converted to void* in gcc case.
        https://bugs.webkit.org/show_bug.cgi?id=152654

        Reviewed by Michael Saboff;

        * assembler/ARM64Assembler.h:
        (linuxPageFlush): Convert arguments to __builtin___clear_cache()
        to char*.

2015-12-31  Andy Estes  <aestes@apple.com>

        Replace WTF::move with WTFMove
        https://bugs.webkit.org/show_bug.cgi?id=152601

        Reviewed by Brady Eidson.

        * API/ObjCCallbackFunction.mm:
        (JSC::ObjCCallbackFunctionImpl::ObjCCallbackFunctionImpl):
        (JSC::ObjCCallbackFunction::ObjCCallbackFunction):
        (JSC::ObjCCallbackFunction::create):
        (objCCallbackFunctionForInvocation):
        * assembler/AssemblerBuffer.h:
        (JSC::AssemblerBuffer::releaseAssemblerData):
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::linkCode):
        * b3/B3BlockInsertionSet.cpp:
        (JSC::B3::BlockInsertionSet::insert):
        (JSC::B3::BlockInsertionSet::splitForward):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3OpaqueByproducts.cpp:
        (JSC::B3::OpaqueByproducts::add):
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::addBlock):
        (JSC::B3::Procedure::addDataSection):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::releaseByproducts):
        * b3/B3ProcedureInlines.h:
        (JSC::B3::Procedure::add):
        * b3/B3Value.h:
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::addBlock):
        (JSC::B3::Air::Code::addStackSlot):
        (JSC::B3::Air::Code::addSpecial):
        * b3/air/AirInst.h:
        (JSC::B3::Air::Inst::Inst):
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * b3/air/AirSimplifyCFG.cpp:
        (JSC::B3::Air::simplifyCFG):
        * bindings/ScriptValue.cpp:
        (Deprecated::jsToInspectorValue):
        * builtins/BuiltinExecutables.cpp:
        (JSC::createExecutableInternal):
        * bytecode/BytecodeBasicBlock.cpp:
        (JSC::computeBytecodeBasicBlocks):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::setCalleeSaveRegisters):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setJITCodeMap):
        (JSC::CodeBlock::livenessAnalysis):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        * bytecode/GetByIdVariant.cpp:
        (JSC::GetByIdVariant::GetByIdVariant):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::regenerateWithCases):
        (JSC::PolymorphicAccess::regenerateWithCase):
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeForStubInfo):
        * bytecode/PutByIdVariant.cpp:
        (JSC::PutByIdVariant::setter):
        * bytecode/StructureStubClearingWatchpoint.cpp:
        (JSC::StructureStubClearingWatchpoint::push):
        * bytecode/StructureStubClearingWatchpoint.h:
        (JSC::StructureStubClearingWatchpoint::StructureStubClearingWatchpoint):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::addAccessCase):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::setInstructions):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/SetForScope.h:
        (JSC::SetForScope::SetForScope):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::livenessFor):
        (JSC::DFG::Graph::killsFor):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::JITFinalizer):
        * dfg/DFGLivenessAnalysisPhase.cpp:
        (JSC::DFG::LivenessAnalysisPhase::process):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
        (JSC::DFG::SpeculativeJIT::compileIn):
        (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::finishCreation):
        * disassembler/Disassembler.cpp:
        (JSC::disassembleAsynchronously):
        * ftl/FTLB3Compile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::initializeB3Byproducts):
        * ftl/FTLJITFinalizer.h:
        (JSC::FTL::OutOfLineCodeInfo::OutOfLineCodeInfo):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
        * heap/Heap.cpp:
        (JSC::Heap::releaseDelayedReleasedObjects):
        (JSC::Heap::markRoots):
        (JSC::Heap::setIncrementalSweeper):
        * heap/HeapInlines.h:
        (JSC::Heap::releaseSoon):
        (JSC::Heap::registerWeakGCMap):
        * heap/WeakInlines.h:
        * inspector/ConsoleMessage.cpp:
        (Inspector::ConsoleMessage::addToFrontend):
        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::searchInTextByLines):
        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::getFunctionDetails):
        (Inspector::InjectedScript::getProperties):
        (Inspector::InjectedScript::getDisplayableProperties):
        (Inspector::InjectedScript::getInternalProperties):
        (Inspector::InjectedScript::getCollectionEntries):
        (Inspector::InjectedScript::wrapCallFrames):
        * inspector/InspectorAgentRegistry.cpp:
        (Inspector::AgentRegistry::append):
        (Inspector::AgentRegistry::appendExtraAgent):
        * inspector/InspectorBackendDispatcher.cpp:
        (Inspector::BackendDispatcher::CallbackBase::CallbackBase):
        (Inspector::BackendDispatcher::CallbackBase::sendSuccess):
        (Inspector::BackendDispatcher::BackendDispatcher):
        (Inspector::BackendDispatcher::create):
        (Inspector::BackendDispatcher::sendPendingErrors):
        * inspector/InspectorProtocolTypes.h:
        (Inspector::Protocol::Array::addItem):
        * inspector/InspectorValues.cpp:
        * inspector/InspectorValues.h:
        (Inspector::InspectorObjectBase::setValue):
        (Inspector::InspectorObjectBase::setObject):
        (Inspector::InspectorObjectBase::setArray):
        (Inspector::InspectorArrayBase::pushValue):
        (Inspector::InspectorArrayBase::pushObject):
        (Inspector::InspectorArrayBase::pushArray):
        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
        (Inspector::JSGlobalObjectConsoleClient::timeEnd):
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::JSInjectedScriptHost):
        * inspector/JSInjectedScriptHost.h:
        (Inspector::JSInjectedScriptHost::create):
        * inspector/agents/InspectorAgent.cpp:
        (Inspector::InspectorAgent::activateExtraDomain):
        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::addMessageToConsole):
        (Inspector::InspectorConsoleAgent::addConsoleMessage):
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
        (Inspector::InspectorDebuggerAgent::resolveBreakpoint):
        (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
        (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
        (Inspector::InspectorDebuggerAgent::breakProgram):
        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::didGarbageCollect):
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
        (Inspector::InspectorRuntimeAgent::getBasicBlocks):
        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::addEvent):
        (Inspector::buildInspectorObject):
        (Inspector::buildProfileInspectorObject):
        (Inspector::InspectorScriptProfilerAgent::trackingComplete):
        * inspector/augmentable/AlternateDispatchableAgent.h:
        * inspector/scripts/codegen/cpp_generator_templates.py:
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
        (CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
        (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
        (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (_generate_unchecked_setter_for_member):
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
        (ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
        * 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:
        * jit/CallFrameShuffler.cpp:
        (JSC::CallFrameShuffler::performSafeWrites):
        * jit/PolymorphicCallStubRoutine.cpp:
        (JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine):
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        (JSC::tryCachePutByID):
        (JSC::tryRepatchIn):
        (JSC::linkPolymorphicCall):
        * parser/Nodes.cpp:
        (JSC::ProgramNode::setClosedVariables):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/Parser.h:
        (JSC::Parser::closedVariables):
        * parser/SourceProviderCache.cpp:
        (JSC::SourceProviderCache::add):
        * profiler/ProfileNode.h:
        (JSC::CalculateProfileSubtreeDataFunctor::returnValue):
        * replay/EncodedValue.cpp:
        (JSC::EncodedValue::get<EncodedValue>):
        * replay/scripts/CodeGeneratorReplayInputs.py:
        (Generator.generate_member_move_expression):
        * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.cpp:
        (Test::HandleWheelEvent::HandleWheelEvent):
        (JSC::InputTraits<Test::HandleWheelEvent>::decode):
        * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.cpp:
        (Test::MapInput::MapInput):
        (JSC::InputTraits<Test::MapInput>::decode):
        * runtime/ConsoleClient.cpp:
        (JSC::ConsoleClient::internalMessageWithTypeAndLevel):
        (JSC::ConsoleClient::logWithLevel):
        (JSC::ConsoleClient::clear):
        (JSC::ConsoleClient::dir):
        (JSC::ConsoleClient::dirXML):
        (JSC::ConsoleClient::table):
        (JSC::ConsoleClient::trace):
        (JSC::ConsoleClient::assertCondition):
        (JSC::ConsoleClient::group):
        (JSC::ConsoleClient::groupCollapsed):
        (JSC::ConsoleClient::groupEnd):
        * runtime/JSNativeStdFunction.cpp:
        (JSC::JSNativeStdFunction::create):
        * runtime/JSString.h:
        (JSC::jsNontrivialString):
        * runtime/JSStringJoiner.cpp:
        (JSC::JSStringJoiner::join):
        * runtime/JSStringJoiner.h:
        (JSC::JSStringJoiner::append):
        * runtime/NativeStdFunctionCell.cpp:
        (JSC::NativeStdFunctionCell::create):
        (JSC::NativeStdFunctionCell::NativeStdFunctionCell):
        * runtime/ScopedArgumentsTable.cpp:
        (JSC::ScopedArgumentsTable::setLength):
        * runtime/StructureIDTable.cpp:
        (JSC::StructureIDTable::resize):
        * runtime/TypeSet.cpp:
        (JSC::StructureShape::inspectorRepresentation):
        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::set):
        * tools/CodeProfile.h:
        (JSC::CodeProfile::addChild):
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::ByteCompiler::compile):
        (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
        * yarr/YarrInterpreter.h:
        (JSC::Yarr::BytecodePattern::BytecodePattern):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
        (JSC::Yarr::YarrPatternConstructor::reset):
        (JSC::Yarr::YarrPatternConstructor::atomPatternCharacter):
        (JSC::Yarr::YarrPatternConstructor::atomCharacterClassEnd):
        (JSC::Yarr::YarrPatternConstructor::atomParenthesesSubpatternBegin):
        (JSC::Yarr::YarrPatternConstructor::atomParentheticalAssertionBegin):
        (JSC::Yarr::YarrPatternConstructor::copyDisjunction):

2016-01-01  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix copyright dates. It's super annoying when we forget to update these, and I
        just forgot to do so in the last commit. Also update the date of the last commit in the
        ChangeLog.

        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirTmpWidth.cpp:
        * b3/air/AirTmpWidth.h:
        * ftl/FTLB3Output.cpp:
        * ftl/FTLB3Output.h:

2016-01-01  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should be able to run all of the old V8v7 tests
        https://bugs.webkit.org/show_bug.cgi?id=152579

        Reviewed by Saam Barati.

        Fixes some silly bugs that were preventing us from running all of the old V8v7 tests.

        IRC's analysis of when to turn a Move into a Move32 when spilling is based on the premise
        that if the dst has a 32-bit def width, then the src must also have a 32-bit def width. But
        that doesn't happen if the src is an immediate.

        This changes that condition in IRC to use the combined use/def width of both src and dst
        rather than being clever. This is great because it's the combined width that determines the
        size of the spill slot.

        Also added some more debug support to TmpWidth.

        This also fixes Air's description of DivDouble; previously it claimed to be a 32-bit
        operation. Also implements Output::unsignedToDouble(), since we already had everything we
        needed to implement this optimally.

        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirTmpWidth.cpp:
        (JSC::B3::Air::TmpWidth::recompute):
        (JSC::B3::Air::TmpWidth::Widths::dump):
        * b3/air/AirTmpWidth.h:
        (JSC::B3::Air::TmpWidth::Widths::Widths):
        * ftl/FTLB3Output.cpp:
        (JSC::FTL::Output::doubleToUInt):
        (JSC::FTL::Output::unsignedToDouble):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::zeroExt):
        (JSC::FTL::Output::zeroExtPtr):
        (JSC::FTL::Output::intToDouble):
        (JSC::FTL::Output::castToInt32):
        (JSC::FTL::Output::unsignedToDouble): Deleted.

2016-01-01  Jeff Miller  <jeffm@apple.com>

        Update user-visible copyright strings to include 2016
        https://bugs.webkit.org/show_bug.cgi?id=152531

        Reviewed by Alexey Proskuryakov.

        * Info.plist:

2015-12-31  Andy Estes  <aestes@apple.com>

        Fix warnings uncovered by migrating to WTF_MOVE
        https://bugs.webkit.org/show_bug.cgi?id=152601

        Reviewed by Daniel Bates.

        * create_regex_tables: Moving a return value prevented copy elision.
        * ftl/FTLUnwindInfo.cpp:
        (JSC::FTL::parseUnwindInfo): Ditto.
        * replay/EncodedValue.h: Ditto.

2015-12-30  Aleksandr Skachkov  <gskachkov@gmail.com>

        [ES6] Arrow function syntax. Arrow function specific features. Lexical bind "super"
        https://bugs.webkit.org/show_bug.cgi?id=149615

        Reviewed by Saam Barati.

        Implemented lexical bind "super" property for arrow function. 'super' property can be accessed 
        inside of the arrow function in case if arrow function is nested in constructor, method, 
        getter or setter of class. In current patch using 'super' in arrow function, that declared out of the 
        class, lead to wrong type of error, should be SyntaxError(https://bugs.webkit.org/show_bug.cgi?id=150893) 
        and this will be fixed in separete patch.

        * builtins/BuiltinExecutables.cpp:
        (JSC::createExecutableInternal):
        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::getSlow):
        * bytecode/ExecutableInfo.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::derivedContextType):
        (JSC::ExecutableInfo::isClassContext):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::derivedContextType):
        (JSC::UnlinkedCodeBlock::isClassContext):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::derivedContextType):
        (JSC::BytecodeGenerator::isDerivedConstructorContext):
        (JSC::BytecodeGenerator::isDerivedClassContext):
        (JSC::BytecodeGenerator::isArrowFunction):
        (JSC::BytecodeGenerator::makeFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::emitHomeObjectForCallee):
        (JSC::FunctionCallValueNode::emitBytecode):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluate):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::ScriptExecutable):
        (JSC::EvalExecutable::create):
        (JSC::EvalExecutable::EvalExecutable):
        (JSC::ProgramExecutable::ProgramExecutable):
        (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
        (JSC::FunctionExecutable::FunctionExecutable):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::derivedContextType):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
        * tests/es6.yaml:
        * tests/stress/arrowfunction-lexical-bind-superproperty.js: Added.

2015-12-29  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, relax limitation in operationCreateThis
        https://bugs.webkit.org/show_bug.cgi?id=152383

        Unreviewed. operationCreateThis now can be called with non constructible function.

        * dfg/DFGOperations.cpp:

2015-12-29  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6][ES7] Drop Constructability of generator function
        https://bugs.webkit.org/show_bug.cgi?id=152383

        Reviewed by Saam Barati.

        We drop the constructability of generator functions.
        This functionality is already landed in ES 2016 draft[1].
        And this simplifies the existing JSC's generator implementation;
        dropping GeneratorThisMode flag.

        [1]: https://github.com/tc39/ecma262/releases/tag/es2016-draft-20151201

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinExecutables.cpp:
        (JSC::createExecutableInternal):
        * bytecode/ExecutableInfo.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::generatorThisMode): Deleted.
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted.
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::generatorThisMode): Deleted.
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::makeFunction):
        (JSC::BytecodeGenerator::generatorThisMode): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode):
        * interpreter/Interpreter.cpp:
        (JSC::eval): Deleted.
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/Executable.h:
        * runtime/GeneratorThisMode.h: Removed.
        * tests/stress/generator-eval-this.js:
        (shouldThrow):
        * tests/stress/generator-is-not-constructible.js: Added.
        (shouldThrow):
        (A.staticGen):
        (A.prototype.gen):
        (A):
        (TypeError):
        * tests/stress/generator-this.js:
        (shouldBe.g.next):
        * tests/stress/generator-with-new-target.js:
        (shouldThrow):

2015-12-27  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should know that used registers are not the same thing as used registers. Rename the
        latter to unavailable registers to avoid future confusion.
        https://bugs.webkit.org/show_bug.cgi?id=152572

        Reviewed by Saam Barati.

        Prior to this change, we used the term "used registers" in two different senses:

        - The set of registers that are live at some point in the current compilation unit. A
          register is live at some point if it is read after that point on some path through that
          point.

        - The set of registers that are not available for scratch register use at some point. A
          register may not be available if it is live or if it is a callee-save register but it is
          not being saved by the current compilation.

        In the old FTL LLVM code, we had some translations from the first sense into the second
        sense. We forgot to do those in FTL B3, and so we get crashes, for example in V8/splay. That
        benchmark highlighted this issue because it fired some lazy slow paths, and then used an
        unsaved callee-save for scratch.
 
        Curiously, we could merge these two definitions by observing that, in some sense, an unsaved
        callee save is live at every point in a compilation in the sense that it may contain a value
        that will be read when the compilation returns. That's pretty cool, but it feels strange to
        me. This isn't how we would normally define liveness of registers. It's not how the
        Air::TmpLiveness analysis would do it for any of its other clients.

        So, this changes B3 to have two different concepts:

        - Used registers. These are the registers that are live.

        - Unavailable registers. These are the registers that are not available for scratch. It's
          always a superset of used registers.

        This also changes FTLLower to use unavailableRegisters() pretty much everywhere that it
        previously used usedRegisters().

        This makes it possible to run V8/splay.

        * b3/B3StackmapGenerationParams.cpp:
        (JSC::B3::StackmapGenerationParams::usedRegisters):
        (JSC::B3::StackmapGenerationParams::unavailableRegisters):
        (JSC::B3::StackmapGenerationParams::proc):
        * b3/B3StackmapGenerationParams.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
        (JSC::FTL::DFG::LowerDFGToLLVM::getById):
        (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):

2015-12-25  Andy Estes  <aestes@apple.com>

        Stop moving local objects in return statements
        https://bugs.webkit.org/show_bug.cgi?id=152557

        Reviewed by Brady Eidson.

        Calling std::move() on a local object in a return statement prevents the compiler from applying the return value optimization.

        Clang can warn about these mistakes with -Wpessimizing-move, although only when std::move() is called directly.
        I found these issues by temporarily replacing WTF::move with std::move and recompiling.

        * inspector/ScriptCallStack.cpp:
        (Inspector::ScriptCallStack::buildInspectorArray):
        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::buildInspectorObject):
        * jit/CallFrameShuffler.h:
        (JSC::CallFrameShuffler::snapshot):
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::allStructureRepresentations):
        (JSC::StructureShape::inspectorRepresentation):

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

        Rename NodeMayOverflowInXXX to NodeMayOverflowInt32InXXX.
        https://bugs.webkit.org/show_bug.cgi?id=152555

        Reviewed by Alex Christensen.

        That's because the NodeMayOverflowInBaseline and NodeMayOverflowInDFG flags only
        indicates potential overflowing of Int32 values.  We'll be adding overflow
        profiling for Int52 values later, and we should disambiguate between the 2 types.

        This is purely a renaming patch.  There are no semantic changes.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::makeSafe):
        (JSC::DFG::ByteCodeParser::makeDivSafe):
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGNodeFlags.cpp:
        (JSC::DFG::dumpNodeFlags):
        * dfg/DFGNodeFlags.h:
        (JSC::DFG::nodeMayOverflowInt32):
        (JSC::DFG::nodeCanSpeculateInt32):
        (JSC::DFG::nodeMayOverflow): Deleted.

2015-12-23  Andreas Kling  <akling@apple.com>

        jsc CLI tool crashes on EOF.
        <https://webkit.org/b/152522>

        Reviewed by Benjamin Poulain.

        SourceProvider should treat String() like the empty string for hashing purposes.
        This was a subtle behavior change in r194017 due to how zero-length strings are
        treated by StringImpl::createSubstringSharingImpl().

        I made these SourceProviders store a Ref<StringImpl> internally instead of a
        String, to codify the fact that these strings can't be null strings.

        I couldn't find a way to cause this crash through the API.

        * API/JSScriptRef.cpp:
        (OpaqueJSScript::OpaqueJSScript):
        * parser/SourceProvider.h:
        (JSC::StringSourceProvider::StringSourceProvider):

2015-12-23  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should be able to run crypto-sha1 in eager mode
        https://bugs.webkit.org/show_bug.cgi?id=152539

        Reviewed by Saam Barati.

        This patch contains one real bug fix and some other fixes that are primarily there for sanity
        because I don't believe they are symptomatic.

        The real fix is the instruction selector's handling of Phi. It was assuming that the correct
        lowering of Phi is to do nothing and the correct lowering of Upsilon is to store into the tmp
        that the Phi uses. But this fails for code patterns like:

            @a = Phi()
            Upsilon(@x, ^a)
            use(@a) // this should see the value that @a had at the point that "@a = Phi()" executed.

        This arises when we have a lot of Upsilons in a row and they are trying to perform a
        shuffling. Prior to this change, "use(@a)" would see the new value of @a, i.e. @x. That's
        wrong. So, this changes the lowering to make each Phi have a special shadow Tmp, and Upsilon
        stores to it while Phi loads from it. Most of these assignments get copy-propagated by IRC,
        so it doesn't really hurt us. I couldn't find any benchmarks that slowed down because of
        this. In fact, I believe that the only time that this would lead to extra interference or
        extra assignments is when it's actually needed to be correct.

        This also contains other fixes, which are probably not for real bugs, but they make me feel
        all warm and fuzzy:

        - spillEverything() works again.  Previously, it didn't have all of IRC's smarts for handling
          a spill of a ZDef.  I fixed this by creating a helper phase that finds all subwidth ZDefs
          to spill slots and amends them with zero-fills of the top bits.

        - IRC no longer requires precise TmpWidth analysis.  Previously, if TmpWidth gave pessimistic
          results, the subwidth ZDef bug would return.  That probably means that it was never fixed
          to begin with, since it's totally cool for just a single def or use of a tmp to cause it
          to become pessimistic. But there may still have been some subwidth ZDefs.  The way that I
          fixed this bug is to have IRC also run the ZDef fixup code that spillEverything() uses.
          This is abstracted behind the beautifully named Air::fixSpillSlotZDef().

        - B3::validate() does dominance checks!  So, if you shoot yourself in the foot by using
          something before defining it, validate() will tell you.

        - Air::TmpWidth is now easy to "turn off" - i.e. to make it go fully conservative. It's not
          an Option; you have to hack code. But that's better than nothing, and it's consistent with
          what we do for other super-internal compiler options that we use rarely.

        - You can now run spillEverything() without hacking code.  Just use
          Options::airSpillSeverything().

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::LowerToAir):
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Validate.cpp:
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::specials):
        (JSC::B3::Air::Code::forAllTmps):
        (JSC::B3::Air::Code::isFastTmp):
        * b3/air/AirFixSpillSlotZDef.h: Added.
        (JSC::B3::Air::fixSpillSlotZDef):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * b3/air/AirSpillEverything.cpp:
        (JSC::B3::Air::spillEverything):
        * b3/air/AirTmpWidth.cpp:
        (JSC::B3::Air::TmpWidth::recompute):
        * jit/JITOperations.cpp:
        * runtime/Options.h:

2015-12-23  Filip Pizlo  <fpizlo@apple.com>

        Need a story for platform-specific Args
        https://bugs.webkit.org/show_bug.cgi?id=152529

        Reviewed by Michael Saboff.

        This teaches Arg that some Arg forms are not valid on some targets. The instruction selector now
        uses this to avoid immediates and addresses that the target wouldn't like.

        This shouldn't change code generation on X86, but is meant as a step towards ARM64 support.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::crossesInterference):
        (JSC::B3::Air::LowerToAir::effectiveAddr):
        (JSC::B3::Air::LowerToAir::addr):
        (JSC::B3::Air::LowerToAir::loadPromise):
        (JSC::B3::Air::LowerToAir::imm):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/air/AirAllocateStack.cpp:
        (JSC::B3::Air::allocateStack):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::Arg):
        (JSC::B3::Air::Arg::imm):
        (JSC::B3::Air::Arg::imm64):
        (JSC::B3::Air::Arg::callArg):
        (JSC::B3::Air::Arg::isValidScale):
        (JSC::B3::Air::Arg::tmpIndex):
        (JSC::B3::Air::Arg::withOffset):
        (JSC::B3::Air::Arg::isValidImmForm):
        (JSC::B3::Air::Arg::isValidAddrForm):
        (JSC::B3::Air::Arg::isValidIndexForm):
        (JSC::B3::Air::Arg::isValidForm):
        (JSC::B3::Air::Arg::forEachTmpFast):
        * b3/air/opcode_generator.rb:

2015-12-23  Keith Miller  <keith_miller@apple.com>

        [JSC] Bugfix for intrinsic getters with dictionary structures.
        https://bugs.webkit.org/show_bug.cgi?id=152538

        Reviewed by Mark Lam.

        Intrinsic getters did not check if an object was a dictionary. This meant, if a property on
        the prototype chain of a dictionary was an intrinsic getter we would IC it. Later, if a
        property is added to the dictionary the IC would still return the result of the intrinsic.
        The fix is to no longer IC intrinsic getters if the base object is a dictionary.

        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        * tests/stress/typedarray-length-dictionary.js: Added.
        (len):

2015-12-23  Andy VanWagoner  <andy@instructure.com>

        [INTL] Implement DateTime Format Functions
        https://bugs.webkit.org/show_bug.cgi?id=147606

        Reviewed by Benjamin Poulain.

        Initialize a UDateFormat from the generated pattern. Use udat_format()
        to format the value. Make sure that the UDateFormat is cleaned up when
        the DateTimeFormat is deconstructed.

        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::~IntlDateTimeFormat):
        (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
        (JSC::IntlDateTimeFormat::format):
        * runtime/IntlDateTimeFormat.h:

2015-12-23  Andy VanWagoner  <thetalecrafter@gmail.com>

        [INTL] Implement String.prototype.localeCompare in ECMA-402
        https://bugs.webkit.org/show_bug.cgi?id=147607

        Reviewed by Benjamin Poulain.

        Add localeCompare in builtin JavaScript that delegates comparing to Intl.Collator.
        Keep existing native implementation for use if INTL flag is disabled.
        For the common case where no locale or options are specified, avoid creating
        a new collator and just use the prototype which is initialized with the defaults.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/StringPrototype.js: Added.
        (localeCompare):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):

2015-12-23  Benjamin Poulain  <benjamin@webkit.org>

        Fix x86_64 after r194388

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::appendShift):
        (JSC::B3::Air::LowerToAir::lower):
        (JSC::B3::Air::LowerToAir::lowerX86Div):

2015-12-23  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Get the JavaScriptCore framework to build on ARM64 with B3 enabled
        https://bugs.webkit.org/show_bug.cgi?id=152503

        Reviewed by Filip Pizlo.

        It is not working but it builds.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::vand):
        (JSC::ARM64Assembler::vectorDataProcessing2Source):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::add32):
        (JSC::MacroAssemblerARM64::add64):
        (JSC::MacroAssemblerARM64::countLeadingZeros64):
        (JSC::MacroAssemblerARM64::not32):
        (JSC::MacroAssemblerARM64::not64):
        (JSC::MacroAssemblerARM64::zeroExtend16To32):
        (JSC::MacroAssemblerARM64::signExtend16To32):
        (JSC::MacroAssemblerARM64::zeroExtend8To32):
        (JSC::MacroAssemblerARM64::signExtend8To32):
        (JSC::MacroAssemblerARM64::addFloat):
        (JSC::MacroAssemblerARM64::ceilFloat):
        (JSC::MacroAssemblerARM64::branchDouble):
        (JSC::MacroAssemblerARM64::branchFloat):
        (JSC::MacroAssemblerARM64::divFloat):
        (JSC::MacroAssemblerARM64::moveZeroToDouble):
        (JSC::MacroAssemblerARM64::moveFloatTo32):
        (JSC::MacroAssemblerARM64::move32ToFloat):
        (JSC::MacroAssemblerARM64::moveConditionallyDouble):
        (JSC::MacroAssemblerARM64::moveConditionallyFloat):
        (JSC::MacroAssemblerARM64::moveConditionallyAfterFloatingPointCompare):
        (JSC::MacroAssemblerARM64::mulFloat):
        (JSC::MacroAssemblerARM64::andDouble):
        (JSC::MacroAssemblerARM64::andFloat):
        (JSC::MacroAssemblerARM64::sqrtFloat):
        (JSC::MacroAssemblerARM64::subFloat):
        (JSC::MacroAssemblerARM64::signExtend32ToPtr):
        (JSC::MacroAssemblerARM64::moveConditionally32):
        (JSC::MacroAssemblerARM64::moveConditionally64):
        (JSC::MacroAssemblerARM64::moveConditionallyTest32):
        (JSC::MacroAssemblerARM64::moveConditionallyTest64):
        (JSC::MacroAssemblerARM64::test32):
        (JSC::MacroAssemblerARM64::setCarry):
        (JSC::MacroAssemblerARM64::jumpAfterFloatingPointCompare):
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::moveDoubleToInts):
        (JSC::MacroAssemblerX86::moveIntsToDouble):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::move32ToFloat):
        (JSC::MacroAssemblerX86Common::moveFloatTo32):
        (JSC::MacroAssemblerX86Common::moveInt32ToPacked): Deleted.
        (JSC::MacroAssemblerX86Common::movePackedToInt32): Deleted.
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::appendShift):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::isX86DivHelperValid):
        * b3/air/AirOpcode.opcodes:
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitFunctionEpilogueWithEmptyFrame):
        (JSC::AssemblyHelpers::emitFunctionEpilogue):
        * jit/FPRInfo.h:
        (JSC::FPRInfo::toArgumentRegister):

2015-12-23  Andy VanWagoner  <andy@instructure.com>

        [INTL] Implement Intl.DateTimeFormat.prototype.resolvedOptions ()
        https://bugs.webkit.org/show_bug.cgi?id=147603

        Reviewed by Benjamin Poulain.

        Implements InitializeDateTimeFormat and related abstract operations
        using ICU. Lazy initialization is used for DateTimeFormat.prototype.
        Refactor to align with Collator work.

        * icu/unicode/udatpg.h: Added.
        * icu/unicode/unumsys.h: Added.
        * runtime/CommonIdentifiers.h:
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::defaultTimeZone):
        (JSC::canonicalizeTimeZoneName):
        (JSC::localeData):
        (JSC::toDateTimeOptions):
        (JSC::IntlDateTimeFormat::setFormatsFromPattern):
        (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
        (JSC::IntlDateTimeFormat::weekdayString):
        (JSC::IntlDateTimeFormat::eraString):
        (JSC::IntlDateTimeFormat::yearString):
        (JSC::IntlDateTimeFormat::monthString):
        (JSC::IntlDateTimeFormat::dayString):
        (JSC::IntlDateTimeFormat::hourString):
        (JSC::IntlDateTimeFormat::minuteString):
        (JSC::IntlDateTimeFormat::secondString):
        (JSC::IntlDateTimeFormat::timeZoneNameString):
        (JSC::IntlDateTimeFormat::resolvedOptions):
        (JSC::IntlDateTimeFormat::format):
        (JSC::IntlDateTimeFormatFuncFormatDateTime): Deleted.
        * runtime/IntlDateTimeFormat.h:
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::constructIntlDateTimeFormat):
        (JSC::callIntlDateTimeFormat):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatFuncFormatDateTime):
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
        * runtime/IntlObject.cpp:
        (JSC::resolveLocale):
        (JSC::getNumberingSystemsForLocale):
        * runtime/IntlObject.h:

2015-12-22  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(194382): FTL B3 no longer runs V8/encrypt
        https://bugs.webkit.org/show_bug.cgi?id=152519

        Reviewed by Saam Barati.

        A "Move Imm, Tmp" instruction should turn into "Move32 Imm, Tmp" if the Tmp is spilled to a
        32-bit slot. Changing where we check isTmp() achieves this. Since all of the logic is only
        relevant to when we spill without introducing a Tmp, and since a Move does not have a "Move Addr,
        Addr" form, this code ensures that the logic only happens for "Tmp, Tmp" and "Imm, Tmp".

        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * dfg/DFGOperations.cpp:

2015-12-22  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should use the right type for comparison slow paths
        https://bugs.webkit.org/show_bug.cgi?id=152521

        Reviewed by Saam Barati.

        Fixes a small goof that was leading to B3 validation failures.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::nonSpeculativeCompare):

2015-12-22  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should be able to run richards
        https://bugs.webkit.org/show_bug.cgi?id=152514

        Reviewed by Michael Saboff.

        This came down to a liveness bug and a register allocation bug.

        The liveness bug was that the code that determined whether we should go around the fixpoint
        assumed that BitVector::quickSet() would return true if the bit changed state from false to
        true. That's not how it works. It returns the old value of the bit, so it will return false
        if the bit changed from false to true. Since there is already a lot of code that relies on
        this behavior, I fixed Liveness instead of changing BitVector.

        The register allocation bug was that we weren't guarding some checks of tmp()'s with checks
        that the Arg isTmp().

        The liveness took a long time to track down, and I needed to add a lot of dumping to do it.
        It's now possible to dump more of the liveness states, including liveAtHead. I found this
        extremely helpful, so I removed the code that cleared liveAtHead.

        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * b3/air/AirLiveness.h:
        (JSC::B3::Air::AbstractLiveness::AbstractLiveness):
        (JSC::B3::Air::AbstractLiveness::Iterable::Iterable):
        (JSC::B3::Air::AbstractLiveness::Iterable::iterator::iterator):
        (JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator*):
        (JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator++):
        (JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator==):
        (JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator!=):
        (JSC::B3::Air::AbstractLiveness::Iterable::begin):
        (JSC::B3::Air::AbstractLiveness::Iterable::end):
        (JSC::B3::Air::AbstractLiveness::liveAtHead):
        (JSC::B3::Air::AbstractLiveness::liveAtTail):
        * b3/air/AirStackSlot.h:
        (WTF::printInternal):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileFTLOSRExit):

2015-12-22  Saam barati  <sbarati@apple.com>

        Cloop build fix after https://bugs.webkit.org/show_bug.cgi?id=152511.

        Unreviewed build fix.

        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

2015-12-22  Saam barati  <sbarati@apple.com>

        Work around issue in bug #152510
        https://bugs.webkit.org/show_bug.cgi?id=152511

        Reviewed by Filip Pizlo.

        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

2015-12-22  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 does not logicalNot correctly
        https://bugs.webkit.org/show_bug.cgi?id=152512

        Reviewed by Saam Barati.

        I'm working on a bug where V8/richards does not run correctly. I noticed that the codegen was
        doing a log of Not32's followed by branches, which smelled like badness. To debug this, I
        needed B3's origins to dump as something other than a hexed pointer to a node. The node index
        would be better. So, I added the notion of an origin printer to Procedure.

        The bug was easy enough to fix. This introduces Output::logicalNot(). In LLVM, it's the same
        as bitNot(). In B3, it's compiled to Equal(value, 0). We could have also compiled it to
        BitXor(value, 1), except that B3 will strength-reduce to that anyway whenever it's safe. It's
        sort of nice that right now, you could use logicalNot() on non-bool values and get C-like
        behavior.

        Richards still doesn't run, though. There are more bugs!

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3BasicBlock.cpp:
        (JSC::B3::BasicBlock::dump):
        (JSC::B3::BasicBlock::deepDump):
        * b3/B3BasicBlock.h:
        (JSC::B3::BasicBlock::frequency):
        (JSC::B3::DeepBasicBlockDump::DeepBasicBlockDump):
        (JSC::B3::DeepBasicBlockDump::dump):
        (JSC::B3::deepDump):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Origin.h:
        (JSC::B3::Origin::data):
        * b3/B3OriginDump.h: Added.
        (JSC::B3::OriginDump::OriginDump):
        (JSC::B3::OriginDump::dump):
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::~Procedure):
        (JSC::B3::Procedure::printOrigin):
        (JSC::B3::Procedure::addBlock):
        (JSC::B3::Procedure::dump):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::setOriginPrinter):
        * b3/B3Value.cpp:
        (JSC::B3::Value::dumpChildren):
        (JSC::B3::Value::deepDump):
        * b3/B3Value.h:
        (JSC::B3::DeepValueDump::DeepValueDump):
        (JSC::B3::DeepValueDump::dump):
        (JSC::B3::deepDump):
        * ftl/FTLB3Output.cpp:
        (JSC::FTL::Output::lockedStackSlot):
        (JSC::FTL::Output::bitNot):
        (JSC::FTL::Output::logicalNot):
        (JSC::FTL::Output::load):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::aShr):
        (JSC::FTL::Output::lShr):
        (JSC::FTL::Output::ctlz32):
        (JSC::FTL::Output::addWithOverflow32):
        (JSC::FTL::Output::lessThanOrEqual):
        (JSC::FTL::Output::doubleEqual):
        (JSC::FTL::Output::doubleEqualOrUnordered):
        (JSC::FTL::Output::doubleNotEqualOrUnordered):
        (JSC::FTL::Output::doubleLessThan):
        (JSC::FTL::Output::doubleLessThanOrEqual):
        (JSC::FTL::Output::doubleGreaterThan):
        (JSC::FTL::Output::doubleGreaterThanOrEqual):
        (JSC::FTL::Output::doubleNotEqualAndOrdered):
        (JSC::FTL::Output::doubleLessThanOrUnordered):
        (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered):
        (JSC::FTL::Output::doubleGreaterThanOrUnordered):
        (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered):
        (JSC::FTL::Output::isZero32):
        (JSC::FTL::Output::notZero32):
        (JSC::FTL::Output::addIncomingToPhi):
        (JSC::FTL::Output::bitCast):
        (JSC::FTL::Output::bitNot): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckArray):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetTypedArrayByteOffset):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileLogicalNot):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInstanceOfCustom):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCountExecution):
        (JSC::FTL::DFG::LowerDFGToLLVM::boolify):
        (JSC::FTL::DFG::LowerDFGToLLVM::isMisc):
        (JSC::FTL::DFG::LowerDFGToLLVM::isNotBoolean):
        (JSC::FTL::DFG::LowerDFGToLLVM::isBoolean):
        (JSC::FTL::DFG::LowerDFGToLLVM::unboxBoolean):
        (JSC::FTL::DFG::LowerDFGToLLVM::isNotType):
        (JSC::FTL::DFG::LowerDFGToLLVM::speculateObject):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::aShr):
        (JSC::FTL::Output::lShr):
        (JSC::FTL::Output::bitNot):
        (JSC::FTL::Output::logicalNot):
        (JSC::FTL::Output::insertElement):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):

2015-12-22  Keith Miller  <keith_miller@apple.com>

        Remove OverridesHasInstance from TypeInfoFlags
        https://bugs.webkit.org/show_bug.cgi?id=152005

        Reviewed by Saam Barati.

        Currently, we have three TypeInfo flags associated with instanceof behavior,
        ImplementsHasInstance, ImplementDefaultHasInstance, and OverridesHasInstance. This patch
        removes the third and moves the first to the out of line flags. In theory, we should only
        need one flag but removing ImplementsHasInstance is more involved and should be done in a
        separate patch.

        * API/JSCallbackConstructor.h:
        * API/JSCallbackObject.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_overrides_has_instance):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_overrides_has_instance):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * runtime/InternalFunction.h:
        * runtime/JSBoundFunction.h:
        * runtime/JSCallee.h:
        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::implementsHasInstance):
        (JSC::TypeInfo::TypeInfo): Deleted.
        (JSC::TypeInfo::overridesHasInstance): Deleted.
        * runtime/NumberConstructor.h:

2015-12-22  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should do tail calls
        https://bugs.webkit.org/show_bug.cgi?id=152494

        Reviewed by Michael Saboff.

        OMG this was so easy.

        The only shady part is that I broke a layering rule that we had so far been following: B3 was
        sitting below the JSC runtime, and did not use JS-specific types. No more, since B3::ValueRep
        can now turn itself into a ValueRecovery for a JSValue. This small feature makes a huge
        difference for the readability of tail call code: it makes it plain that the call frame
        shuffler is basically just directly consuming the stackmap generation params, and insofar as
        there is any data transformation, it's just because it uses different classes to say the same
        thing.

        I think we should avoid adding too many JS-specific things to B3. But, so long as it's still
        possible to use B3 to compile things that aren't JS, I think we'll be fine.

        * b3/B3ValueRep.cpp:
        (JSC::B3::ValueRep::dump):
        (JSC::B3::ValueRep::emitRestore):
        (JSC::B3::ValueRep::recoveryForJSValue):
        * b3/B3ValueRep.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
        * test/stress/ftl-tail-call.js: Added.

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

        Snippefy op_negate for the baseline JIT.
        https://bugs.webkit.org/show_bug.cgi?id=152447

        Reviewed by Benjamin Poulain.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_unsigned):
        (JSC::JIT::emit_op_negate):
        (JSC::JIT::emitSlow_op_negate):
        (JSC::JIT::emitBitBinaryOpFastPath):
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_compareAndJump):
        (JSC::JIT::emit_op_negate): Deleted.
        (JSC::JIT::emitSlow_op_negate): Deleted.
        * jit/JITNegGenerator.cpp: Added.
        (JSC::JITNegGenerator::generateFastPath):
        * jit/JITNegGenerator.h: Added.
        (JSC::JITNegGenerator::JITNegGenerator):
        (JSC::JITNegGenerator::didEmitFastPath):
        (JSC::JITNegGenerator::endJumpList):
        (JSC::JITNegGenerator::slowPathJumpList):

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

        Address review feedback from Saam.  I should have landed it in r194354.

        * b3/testb3.cpp:
        (JSC::B3::testStore16Arg):

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

        B3 should be able to compile Store16
        https://bugs.webkit.org/show_bug.cgi?id=152493

        Reviewed by Saam Barati.

        This adds comprehensive Store16 support to our assembler, Air, and B3->Air lowering.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::store16):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::movb_rm):
        (JSC::X86Assembler::movw_rm):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testStorePartial8BitRegisterOnX86):
        (JSC::B3::testStore16Arg):
        (JSC::B3::testStore16Imm):
        (JSC::B3::testTrunc):
        (JSC::B3::run):

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

        Unreviewed, remove highBitsAreZero(), it's unused.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::shouldCopyPropagate):
        (JSC::B3::Air::LowerToAir::highBitsAreZero): Deleted.

2015-12-21  Csaba Osztrogonác  <ossy@webkit.org>

        Unreviewed, fix the !FTL_USES_B3 build after r194334.

        * ftl/FTLLowerDFGToLLVM.cpp: Mark forwarding unused variable.
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):

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

        FTL B3 should do doubleToInt32
        https://bugs.webkit.org/show_bug.cgi?id=152484

        Reviewed by Saam Barati.

        We used to have a DToI32 opcode in B3 that we never implemented. This removes that opcode,
        since double-to-int conversion has dramatically different semantics on different
        architectures. We let FTL get the conversion instruction it wants by using a patchpoint.

        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::typeFor):
        * b3/B3ValueKey.cpp:
        (JSC::B3::ValueKey::materialize):
        * ftl/FTLB3Output.cpp:
        (JSC::FTL::Output::Output):
        (JSC::FTL::Output::appendTo):
        (JSC::FTL::Output::lockedStackSlot):
        (JSC::FTL::Output::load):
        (JSC::FTL::Output::doublePowi):
        (JSC::FTL::Output::hasSensibleDoubleToInt):
        (JSC::FTL::Output::doubleToInt):
        (JSC::FTL::Output::doubleToUInt):
        (JSC::FTL::Output::load8SignExt32):
        (JSC::FTL::Output::load8ZeroExt32):
        (JSC::FTL::Output::load16SignExt32):
        (JSC::FTL::Output::load16ZeroExt32):
        (JSC::FTL::Output::store):
        (JSC::FTL::Output::store32As8):
        (JSC::FTL::Output::store32As16):
        (JSC::FTL::Output::branch):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::doubleLog):
        (JSC::FTL::Output::signExt32To64):
        (JSC::FTL::Output::zeroExt):
        (JSC::FTL::Output::zeroExtPtr):
        (JSC::FTL::Output::intToDouble):
        (JSC::FTL::Output::unsignedToDouble):
        (JSC::FTL::Output::castToInt32):
        (JSC::FTL::Output::hasSensibleDoubleToInt): Deleted.
        (JSC::FTL::Output::sensibleDoubleToInt): Deleted.
        (JSC::FTL::Output::fpToInt32): Deleted.
        (JSC::FTL::Output::fpToUInt32): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithPow):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutByVal):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileSwitch):
        (JSC::FTL::DFG::LowerDFGToLLVM::doubleToInt32):
        (JSC::FTL::DFG::LowerDFGToLLVM::sensibleDoubleToInt32):
        (JSC::FTL::DFG::LowerDFGToLLVM::convertDoubleToInt32):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::hasSensibleDoubleToInt):
        (JSC::FTL::Output::doubleToInt):
        (JSC::FTL::Output::doubleToUInt):
        (JSC::FTL::Output::signExt32To64):
        (JSC::FTL::Output::zeroExt):

2015-12-21  Skachkov Oleksandr  <gskachkov@gmail.com>

        Unexpected exception assigning to this._property inside arrow function
        https://bugs.webkit.org/show_bug.cgi?id=152028

        Reviewed by Saam Barati.

        The issue appeared in case if in arrow function created base-level lexical envioronment, and in this case 
        |this| value was loaded from wrong scope. The problem was that loading of the |this| happened too early when
        compiling bytecode because the bytecode generators's scope stack wasn't in sync with runtime scope stack.
        To fix issue loading of |this| was moved after initializeDefaultParameterValuesAndSetupFunctionScopeStack 
        in BytecodeGenerator.cpp   

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * tests/stress/arrowfunction-lexical-bind-this-2.js:

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

        FTL B3 should do vararg calls
        https://bugs.webkit.org/show_bug.cgi?id=152468

        Reviewed by Benjamin Poulain.

        This adds FTL->B3 lowering of all kinds of varargs calls - forwarding or not, tail or not,
        and construct or not. Like all other such lowerings, all of the code is in one place in
        FTLLower.

        I removed code for varargs and exception spill slots from the B3 path, since it won't need
        it. The plan is to rely on B3 doing the spilling for us by using some combination of early
        clobber and late use.

        This adds ValueRep::emitRestore(), a helpful method for emitting code to restore any ValueRep
        into any 64-bit Reg (FPR or GPR).

        I wrote new tests for vararg calls, because I wasn't sure which of the existing ones we can
        run. These are short-running tests, so I'm not worried about bloating our test suite.

        * b3/B3ValueRep.cpp:
        (JSC::B3::ValueRep::dump):
        (JSC::B3::ValueRep::emitRestore):
        * b3/B3ValueRep.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
        * ftl/FTLState.h:
        * tests/stress/varargs-no-forward.js: Added.
        * tests/stress/varargs-simple.js: Added.
        * tests/stress/varargs-two-level.js: Added.

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

        Add unary operator tests to compare JIT and LLINT results.
        https://bugs.webkit.org/show_bug.cgi?id=152453

        Reviewed by Benjamin Poulain.

        Also fixed a few things in the binary-op-test.js.

        * tests/stress/op_negate.js: Added.
        (o1.valueOf):
        * tests/stress/op_postdec.js: Added.
        (o1.valueOf):
        * tests/stress/op_postinc.js: Added.
        (o1.valueOf):
        * tests/stress/op_predec.js: Added.
        (o1.valueOf):
        * tests/stress/op_preinc.js: Added.
        (o1.valueOf):
        * tests/stress/resources/binary-op-test.js:
        (stringifyIfNeeded):
        (isIdentical):
        (run):
        * tests/stress/resources/unary-op-test.js: Added.
        (stringifyIfNeeded):
        (generateBinaryTests):
        (isIdentical):
        (runTest):
        (run):

2015-12-21  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r194328.

        This change appears to have caused failures in JSC tests

        Reverted changeset:

        "[INTL] Implement String.prototype.localeCompare in ECMA-402"
        https://bugs.webkit.org/show_bug.cgi?id=147607
        http://trac.webkit.org/changeset/194328

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

        B3->Air lowering incorrectly copy-propagates over ZExt32's
        https://bugs.webkit.org/show_bug.cgi?id=152365

        Reviewed by Benjamin Poulain.

        The instruction selector thinks that Value's that return Int32's are going to always be lowered
        to instructions that zero-extend the destination. But this isn't actually true. If you have an
        Add32 with a destination on the stack (i.e. spilled) then it only writes 4 bytes. Then, the
        filler will load 8 bytes from the stack at the point of use. So, the use of the Add32 will see
        garbage in the high bits.

        The fact that the spiller chose to use 8 bytes for a Tmp that gets defined by an Add32 is a
        pretty sad bug, but:

        - It's entirely up to the spiller to decide how many bytes to use for a Tmp, since we do not
          ascribe a type to Tmps. We could ascribe types to Tmps, but then coalescing would become
          harder. Our goal is to fix the bug while still enabling coalescing in cases like "a[i]" where
          "i" is a 32-bit integer that is computed using operations that already do zero-extension.

        - More broadly, it's strange that the instruction selector decides whether a Value will be
          lowered to something that zero-extends. That's too constraining, since the most optimal
          instruction selection might involve something that doesn't zero-extend in cases of spilling, so
          the zero-extension should only happen if it's actually needed. This means that we need to
          understand which Air instructions cause zero-extensions.

        - If we know which Air instructions cause zero-extensions, then we don't need the instruction
          selector to copy-propagate ZExt32's. We have copy-propagation in Air thanks to the register
          allocator.

        In fact, the register allocator is exactly where all of the pieces come together. It's there that
        we want to know which operations zero-extend and which don't. It also wants to know how many bits
        of a Tmp each instruction reads. Armed with that information, the register allocator can emit
        more optimal spill code, use less stack space for spill slots, and coalesce Move32's. As a bonus,
        on X86, it replaces Move's with Move32's whenever it can. On X86, Move32 is cheaper.

        This fixes a crash bug in V8/encrypt. After fixing this, I only needed two minor fixes to get
        V8/encrypt to run. We're about 10% behind LLVM on steady state throughput on this test. It
        appears to be mostly due to excessive spilling caused by CCall slow paths. That's fixable: we
        could make CCalls on slow paths use a variant of CCallSpecial that promises not to clobber any
        registers, and then have it emit spill code around the call itself. LLVM probably gets this
        optimization from its live range splitting.

        I tried writing a regression test. The problem is that you need garbage on the stack for this to
        work, and I didn't feel like writing a flaky test. It appears that running V8/encrypt will cover
        this, so we do have coverage.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbstractMacroAssembler.h:
        (JSC::isX86):
        (JSC::isX86_64):
        (JSC::optimizeForARMv7IDIVSupported):
        (JSC::optimizeForX86):
        (JSC::optimizeForX86_64):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::highBitsAreZero):
        (JSC::B3::Air::LowerToAir::shouldCopyPropagate):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::forEachArg):
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        * b3/B3Value.h:
        * b3/air/AirAllocateStack.cpp:
        (JSC::B3::Air::allocateStack):
        * b3/air/AirArg.cpp:
        (WTF::printInternal):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::pointerWidth):
        (JSC::B3::Air::Arg::isAnyUse):
        (JSC::B3::Air::Arg::isColdUse):
        (JSC::B3::Air::Arg::isEarlyUse):
        (JSC::B3::Air::Arg::isDef):
        (JSC::B3::Air::Arg::isZDef):
        (JSC::B3::Air::Arg::widthForB3Type):
        (JSC::B3::Air::Arg::conservativeWidth):
        (JSC::B3::Air::Arg::minimumWidth):
        (JSC::B3::Air::Arg::bytes):
        (JSC::B3::Air::Arg::widthForBytes):
        (JSC::B3::Air::Arg::Arg):
        (JSC::B3::Air::Arg::forEachTmp):
        * b3/air/AirCCallSpecial.cpp:
        (JSC::B3::Air::CCallSpecial::forEachArg):
        * b3/air/AirEliminateDeadCode.cpp:
        (JSC::B3::Air::eliminateDeadCode):
        * b3/air/AirFixPartialRegisterStalls.cpp:
        (JSC::B3::Air::fixPartialRegisterStalls):
        * b3/air/AirInst.cpp:
        (JSC::B3::Air::Inst::hasArgEffects):
        * b3/air/AirInst.h:
        (JSC::B3::Air::Inst::forEachTmpFast):
        (JSC::B3::Air::Inst::forEachTmp):
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::forEachTmpWithExtraClobberedRegs):
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * b3/air/AirLiveness.h:
        (JSC::B3::Air::AbstractLiveness::AbstractLiveness):
        (JSC::B3::Air::AbstractLiveness::LocalCalc::execute):
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirSpillEverything.cpp:
        (JSC::B3::Air::spillEverything):
        * b3/air/AirTmpWidth.cpp: Added.
        (JSC::B3::Air::TmpWidth::TmpWidth):
        (JSC::B3::Air::TmpWidth::~TmpWidth):
        * b3/air/AirTmpWidth.h: Added.
        (JSC::B3::Air::TmpWidth::width):
        (JSC::B3::Air::TmpWidth::defWidth):
        (JSC::B3::Air::TmpWidth::useWidth):
        (JSC::B3::Air::TmpWidth::Widths::Widths):
        * b3/air/AirUseCounts.h:
        (JSC::B3::Air::UseCounts::UseCounts):
        * b3/air/opcode_generator.rb:
        * b3/testb3.cpp:
        (JSC::B3::testCheckMegaCombo):
        (JSC::B3::testCheckTrickyMegaCombo):
        (JSC::B3::testCheckTwoMegaCombos):
        (JSC::B3::run):

2015-12-21  Andy VanWagoner  <thetalecrafter@gmail.com>

        [INTL] Implement String.prototype.localeCompare in ECMA-402
        https://bugs.webkit.org/show_bug.cgi?id=147607

        Reviewed by Darin Adler.

        Add localeCompare in builtin JavaScript that delegates comparing to Intl.Collator.
        Keep existing native implementation for use if INTL flag is disabled.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/StringPrototype.js: Added.
        (localeCompare):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):

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

        Implement compareDouble in B3/Air
        https://bugs.webkit.org/show_bug.cgi?id=150903

        Reviewed by Benjamin Poulain.

        A hole in our coverage is that we don't fuse a double comparison into a branch, then we will
        crash in the instruction selector. Obviously, we *really* want to fuse double comparisons,
        but we can't guarantee that this will always happen.

        This also removes all uses of WTF::Dominators verification, since it's extremely slow even in
        a release build. This speeds up testb3 with validateGraphAtEachPhase=true by an order of
        magnitude.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::moveDoubleConditionallyFloat):
        (JSC::MacroAssembler::compareDouble):
        (JSC::MacroAssembler::compareFloat):
        (JSC::MacroAssembler::lea):
        * b3/B3Dominators.h:
        (JSC::B3::Dominators::Dominators):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createCompare):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testCompare):
        (JSC::B3::testEqualDouble):
        (JSC::B3::simpleFunction):
        (JSC::B3::run):
        * dfg/DFGDominators.h:
        (JSC::DFG::Dominators::Dominators):

2015-12-19  Dan Bernstein  <mitz@apple.com>

        [Mac] WebKit contains dead source code for OS X Mavericks and earlier
        https://bugs.webkit.org/show_bug.cgi?id=152462

        Reviewed by Alexey Proskuryakov.

        - Removed build setting definitions for OS X 10.9 and earlier, and simplified defintions
          that became uniform across all OS X versions as a result:

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

        * API/JSBase.h: Removed check against __MAC_OS_X_VERSION_MIN_REQUIRED that was always true.

2015-12-19  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Streamline Tmp indexing inside the register allocator
        https://bugs.webkit.org/show_bug.cgi?id=152420

        Reviewed by Filip Pizlo.

        AirIteratedRegisterCoalescing has been accumulating a bit of mess over time.

        When it started, every map addressed by Tmp was using Tmp hashing.
        That caused massive performance problems. Everything perf sensitive was moved
        to direct array addressing by the absolute Tmp index. This left the code
        with half of the function using Tmp, the other half using indices.

        With this patch, almost everything is moved to absolute indexing.
        There are a few advantages to this:
        -No more conversion churn for Floating Point registers.
        -Most of the functions can now be shared between GP and FP.
        -A bit of clean up since the core algorithm only deals with integers now.

        This patch also changes the index type to be a template argument.
        That will allow future specialization of "m_interferenceEdges" based
        on the expected problem size.

        Finally, the code related to the program modification (register assignment
        and spilling) was moved to the wrapper "IteratedRegisterCoalescing".

        The current split is:
        -AbstractColoringAllocator: common core. Share as much as possible between
         GP and FP.
        -ColoringAllocator: the remaining parts of the algorithm, everything that
         is specific to GP, FP.
        -IteratedRegisterCoalescing: the "iterated" part of the algorithm.
         Try to allocate and modify the code as needed.

        The long term plan is:
        -Move selectSpill() and the coloring loop to AbstractColoringAllocator.
        -Specialize m_interferenceEdges to make it faster.

        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * b3/air/AirTmpInlines.h:
        (JSC::B3::Air::AbsoluteTmpMapper<Arg::GP>::lastMachineRegisterIndex):
        (JSC::B3::Air::AbsoluteTmpMapper<Arg::FP>::lastMachineRegisterIndex):

2015-12-19  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] FTLB3Output generates some invalid ZExt32
        https://bugs.webkit.org/show_bug.cgi?id=151905

        Reviewed by Filip Pizlo.

        FTLLowerDFGToLLVM calls zeroExt() to int32 in some cases.
        We were generating ZExt32 with Int32 as return type :(

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::zeroExt):

2015-12-19  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add EqualOrUnordered to B3
        https://bugs.webkit.org/show_bug.cgi?id=152425

        Reviewed by Mark Lam.

        Add EqualOrUnordered to B3 and use it to implements
        FTL::Output's NotEqualAndOrdered.

        * b3/B3ConstDoubleValue.cpp:
        (JSC::B3::ConstDoubleValue::equalOrUnordered):
        * b3/B3ConstDoubleValue.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createGenericCompare):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3ReduceDoubleToFloat.cpp:
        (JSC::B3::reduceDoubleToFloat):
        * b3/B3ReduceStrength.cpp:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::equalOrUnordered):
        (JSC::B3::Value::returnsBool):
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h:
        * b3/testb3.cpp:
        (JSC::B3::testBranchEqualOrUnorderedArgs):
        (JSC::B3::testBranchNotEqualAndOrderedArgs):
        (JSC::B3::testBranchEqualOrUnorderedDoubleArgImm):
        (JSC::B3::testBranchEqualOrUnorderedFloatArgImm):
        (JSC::B3::testBranchEqualOrUnorderedDoubleImms):
        (JSC::B3::testBranchEqualOrUnorderedFloatImms):
        (JSC::B3::testBranchEqualOrUnorderedFloatWithUselessDoubleConversion):
        (JSC::B3::run):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::doubleNotEqualAndOrdered):
        (JSC::FTL::Output::doubleNotEqual): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::boolify):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::doubleNotEqualAndOrdered):
        (JSC::FTL::Output::doubleNotEqual): Deleted.

2015-12-19  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] B3: Add indexed addressing when lowering BitwiseCast
        https://bugs.webkit.org/show_bug.cgi?id=152432

        Reviewed by Geoffrey Garen.

        The MacroAssembler supports it, we should use it.

        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testBitwiseCastOnDoubleInMemoryIndexed):
        (JSC::B3::testBitwiseCastOnInt64InMemoryIndexed):

2015-12-18  Andreas Kling  <akling@apple.com>

        Make JSString::SafeView less of a footgun.
        <https://webkit.org/b/152376>

        Reviewed by Darin Adler.

        Remove the "operator StringView()" convenience helper on JSString::SafeString since that
        made it possible to casually turn the return value from JSString::view() into an unsafe
        StringView local on the stack with this pattern:

            StringView view = someJSValue.toString(exec)->view(exec);

        The JSString* returned by toString() above will go out of scope by the end of the statement
        and does not stick around to protect itself from garbage collection.

        It will now look like this instead:

            JSString::SafeView view = someJSValue.toString(exec)->view(exec);

        To be extra clear, the following is not safe:

            StringView view = someJSValue.toString(exec)->view(exec).get();

        By the end of that statement, the JSString::SafeView goes out of scope, and the JSString*
        is no longer protected from GC.

        I added a couple of forwarding helpers to the SafeView class, and if you need a StringView
        object from it, you can call .get() just like before.

        Finally I also removed the JSString::SafeView() constructor, since nobody was instantiating
        empty SafeView objects anyway. This way we don't have to worry about null members.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncJoin):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncJoin):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::decode):
        (JSC::globalFuncParseInt):
        (JSC::globalFuncParseFloat):
        (JSC::globalFuncEscape):
        (JSC::globalFuncUnescape):
        * runtime/JSONObject.cpp:
        (JSC::JSONProtoFuncParse):
        * runtime/JSString.cpp:
        (JSC::JSString::getPrimitiveNumber):
        (JSC::JSString::toNumber):
        * runtime/JSString.h:
        (JSC::JSString::SafeView::is8Bit):
        (JSC::JSString::SafeView::length):
        (JSC::JSString::SafeView::characters8):
        (JSC::JSString::SafeView::characters16):
        (JSC::JSString::SafeView::operator[]):
        (JSC::JSString::SafeView::SafeView):
        (JSC::JSString::SafeView::get):
        (JSC::JSString::SafeView::operator StringView): Deleted.
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncCharAt):
        (JSC::stringProtoFuncCharCodeAt):
        (JSC::stringProtoFuncIndexOf):
        (JSC::stringProtoFuncNormalize):

2015-12-18  Saam barati  <sbarati@apple.com>

        BytecodeGenerator::pushLexicalScopeInternal and pushLexicalScope should use enums instead of bools
        https://bugs.webkit.org/show_bug.cgi?id=152450

        Reviewed by Geoffrey Garen and Joseph Pecoraro.

        This makes comprehending the call sites of these functions
        easier without looking up the header of the function.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::emitPrefillStackTDZVariables):
        (JSC::BytecodeGenerator::pushLexicalScope):
        (JSC::BytecodeGenerator::pushLexicalScopeInternal):
        (JSC::BytecodeGenerator::emitPushFunctionNameScope):
        (JSC::BytecodeGenerator::emitPushCatchScope):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::lastOpcodeID):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BlockNode::emitBytecode):
        (JSC::ForNode::emitBytecode):
        (JSC::ForInNode::emitMultiLoopBytecode):
        (JSC::ForOfNode::emitBytecode):
        (JSC::SwitchNode::emitBytecode):
        (JSC::ClassExprNode::emitBytecode):

2015-12-18  Michael Catanzaro  <mcatanzaro@igalia.com>

        Avoid triggering clang's -Wundefined-bool-conversion
        https://bugs.webkit.org/show_bug.cgi?id=152408

        Reviewed by Mark Lam.

        Add ASSERT_THIS_GC_OBJECT_LOOKS_VALID and ASSERT_THIS_GC_OBJECT_INHERITS to avoid use of
        ASSERT(this) by ASSERT_GC_OBJECT_LOOKS_VALID and ASSERT_GC_OBJECT_INHERITS.

        * heap/GCAssertions.h:

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

        Replace SpecialFastCase profiles with ResultProfiles.
        https://bugs.webkit.org/show_bug.cgi?id=152433

        Reviewed by Saam Barati.

        This is in preparation for upcoming work to enhance the DFG predictions to deal
        with untyped operands.

        This patch also enhances some of the arithmetic slow paths (for the LLINT and
        baseline JIT) to collect result profiling info.  This profiling info is not put
        to use yet. 

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpRareCaseProfile):
        (JSC::CodeBlock::dumpResultProfile):
        (JSC::CodeBlock::printLocationAndOp):
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::shrinkToFit):
        (JSC::CodeBlock::dumpValueProfiles):
        (JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
        (JSC::CodeBlock::resultProfileForBytecodeOffset):
        (JSC::CodeBlock::updateResultProfileForBytecodeOffset):
        (JSC::CodeBlock::capabilityLevel):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::couldTakeSlowCase):
        (JSC::CodeBlock::addResultProfile):
        (JSC::CodeBlock::numberOfResultProfiles):
        (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
        (JSC::CodeBlock::couldTakeSpecialFastCase):
        (JSC::CodeBlock::addSpecialFastCaseProfile): Deleted.
        (JSC::CodeBlock::numberOfSpecialFastCaseProfiles): Deleted.
        (JSC::CodeBlock::specialFastCaseProfile): Deleted.
        (JSC::CodeBlock::specialFastCaseProfileForBytecodeOffset): Deleted.
        * bytecode/ValueProfile.cpp: Added.
        (WTF::printInternal):
        * bytecode/ValueProfile.h:
        (JSC::getRareCaseProfileBytecodeOffset):
        (JSC::ResultProfile::ResultProfile):
        (JSC::ResultProfile::bytecodeOffset):
        (JSC::ResultProfile::specialFastPathCount):
        (JSC::ResultProfile::didObserveNonInt32):
        (JSC::ResultProfile::didObserveDouble):
        (JSC::ResultProfile::didObserveNonNegZeroDouble):
        (JSC::ResultProfile::didObserveNegZeroDouble):
        (JSC::ResultProfile::didObserveNonNumber):
        (JSC::ResultProfile::didObserveInt32Overflow):
        (JSC::ResultProfile::setObservedNonNegZeroDouble):
        (JSC::ResultProfile::setObservedNegZeroDouble):
        (JSC::ResultProfile::setObservedNonNumber):
        (JSC::ResultProfile::setObservedInt32Overflow):
        (JSC::ResultProfile::addressOfFlags):
        (JSC::ResultProfile::addressOfSpecialFastPathCount):
        (JSC::ResultProfile::hasBits):
        (JSC::ResultProfile::setBit):
        (JSC::getResultProfileBytecodeOffset):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_div):
        (JSC::JIT::emit_op_mul):
        * jit/JITDivGenerator.cpp:
        (JSC::JITDivGenerator::generateFastPath):
        * jit/JITDivGenerator.h:
        (JSC::JITDivGenerator::JITDivGenerator):
        * jit/JITMulGenerator.cpp:
        (JSC::JITMulGenerator::generateFastPath):
        * jit/JITMulGenerator.h:
        (JSC::JITMulGenerator::JITMulGenerator):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):

2015-12-18  Keith Miller  <keith_miller@apple.com>

        verboseDFGByteCodeParsing option should show the bytecode it is parsing.
        https://bugs.webkit.org/show_bug.cgi?id=152434

        Reviewed by Michael Saboff.

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

2015-12-18  Csaba Osztrogonác  <ossy@webkit.org>

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

        Reviewed by Mark Lam.

        Relanding r194007 after r194248.

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

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

        Web Inspector: Remove "local" scope type from the protocol
        https://bugs.webkit.org/show_bug.cgi?id=152409

        Reviewed by Timothy Hatcher.

        After r194251 the backend no longer sends this scope type.
        So remove it from the protocol.

        The concept of a Local Scope should be calculatable by the
        frontend. In fact the way the backend used to do this could
        easily be done by the frontend. To be done in a follow-up.

        * inspector/InjectedScriptSource.js:
        * inspector/JSJavaScriptCallFrame.h:
        * inspector/protocol/Debugger.json:

2015-12-17  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        [INTL] Implement Collator Compare Functions
        https://bugs.webkit.org/show_bug.cgi?id=147604

        Reviewed by Darin Adler.

        This patch implements Intl.Collator.prototype.compare() according
        to the ECMAScript 2015 Internationalization API spec (ECMA-402 2nd edition.)

        * runtime/IntlCollator.cpp:
        (JSC::IntlCollator::~IntlCollator):
        (JSC::sortLocaleData):
        (JSC::searchLocaleData):
        (JSC::IntlCollator::initializeCollator):
        (JSC::IntlCollator::createCollator):
        (JSC::IntlCollator::compareStrings):
        (JSC::IntlCollator::usageString):
        (JSC::IntlCollator::sensitivityString):
        (JSC::IntlCollator::resolvedOptions):
        (JSC::IntlCollator::setBoundCompare):
        (JSC::IntlCollatorFuncCompare): Deleted.
        * runtime/IntlCollator.h:
        (JSC::IntlCollator::usage): Deleted.
        (JSC::IntlCollator::setUsage): Deleted.
        (JSC::IntlCollator::locale): Deleted.
        (JSC::IntlCollator::setLocale): Deleted.
        (JSC::IntlCollator::collation): Deleted.
        (JSC::IntlCollator::setCollation): Deleted.
        (JSC::IntlCollator::numeric): Deleted.
        (JSC::IntlCollator::setNumeric): Deleted.
        (JSC::IntlCollator::sensitivity): Deleted.
        (JSC::IntlCollator::setSensitivity): Deleted.
        (JSC::IntlCollator::ignorePunctuation): Deleted.
        (JSC::IntlCollator::setIgnorePunctuation): Deleted.
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::constructIntlCollator):
        (JSC::callIntlCollator):
        (JSC::sortLocaleData): Deleted.
        (JSC::searchLocaleData): Deleted.
        (JSC::initializeCollator): Deleted.
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorFuncCompare):
        (JSC::IntlCollatorPrototypeFuncResolvedOptions):
        * runtime/IntlObject.cpp:
        (JSC::defaultLocale):
        (JSC::convertICULocaleToBCP47LanguageTag):
        (JSC::intlStringOption):
        (JSC::resolveLocale):
        (JSC::supportedLocales):
        * runtime/IntlObject.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::intlCollatorAvailableLocales):
        (JSC::JSGlobalObject::intlDateTimeFormatAvailableLocales):
        (JSC::JSGlobalObject::intlNumberFormatAvailableLocales):

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

        Provide a way to distinguish a nested lexical block from a function's lexical block
        https://bugs.webkit.org/show_bug.cgi?id=152361

        Reviewed by Saam Barati.

        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::emitPushFunctionNameScope):
        (JSC::BytecodeGenerator::emitPushCatchScope):
        Each of these are specialized scopes. They are not nested lexical scopes.
        
        (JSC::BytecodeGenerator::pushLexicalScope):
        (JSC::BytecodeGenerator::pushLexicalScopeInternal):
        Include an extra parameter to mark the SymbolTable as a nested lexical or not.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::BlockNode::emitBytecode):
        (JSC::ForNode::emitBytecode):
        (JSC::ForInNode::emitMultiLoopBytecode):
        (JSC::ForOfNode::emitBytecode):
        (JSC::SwitchNode::emitBytecode):
        (JSC::ClassExprNode::emitBytecode):
        Each of these are cases of non-function nested lexical scopes.
        So mark the SymbolTable as nested.

        * inspector/protocol/Debugger.json:
        * inspector/InjectedScriptSource.js:
        Include a new scope type.

        * inspector/JSJavaScriptCallFrame.h:
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::scopeType):
        Use the new "NestedLexical" scope type for nested, non-function,
        lexical scopes. The Inspector can use this to better describe
        this scope in the frontend.

        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::isNestedLexicalScope):
        * debugger/DebuggerScope.h:
        * runtime/JSScope.cpp:
        (JSC::JSScope::isNestedLexicalScope):
        * runtime/JSScope.h:
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::SymbolTable):
        (JSC::SymbolTable::cloneScopePart):
        * runtime/SymbolTable.h:
        Access the isNestedLexicalScope bit.

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

        Unreviewed EFL Build Fix after r194247.

        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::friendlyFunctionName):
        Handle compilers that don't realize the switch handles all cases.

2015-12-17  Keith Miller  <keith_miller@apple.com>

        [ES6] Add support for Symbol.hasInstance
        https://bugs.webkit.org/show_bug.cgi?id=151839

        Reviewed by Saam Barati.

        Fixed version of r193986, r193983, and r193974.

        This patch adds support for Symbol.hasInstance, unfortunately in order to prevent
        regressions several new bytecodes and DFG IR nodes were necessary. Before, Symbol.hasInstance
        when executing an instanceof expression we would emit three bytecodes: overrides_has_instance, get_by_id,
        then instanceof. As the spec has changed, we emit a more complicated set of bytecodes in addition to some
        new ones. First the role of overrides_has_instance and its corresponding DFG node have changed. Now it returns
        a js-boolean indicating whether the RHS of the instanceof expression (from here on called the constructor for simplicity)
        needs non-default behavior for resolving the expression. i.e. The constructor has a Symbol.hasInstance that differs from the one on
        Function.prototype[Symbol.hasInstance] or is a bound/C-API function. Once we get to the DFG this node is generally eliminated as
        we can prove the value of Symbol.hasInstance is a constant. The second new bytecode is instanceof_custom. insntanceof_custom, just
        emits a call to slow path code that computes the result.

        In the DFG, there is also a new node, CheckTypeInfoFlags, which checks the type info flags are consistent with the ones provided and
        OSR exits if the flags are not. Additionally, we attempt to prove that the result of CheckHasValue will be a constant and transform
        it into a CheckTypeInfoFlags followed by a JSConstant.

        * API/JSCallbackObject.h:
        * builtins/FunctionPrototype.js:
        (symbolHasInstance):
        * bytecode/BytecodeBasicBlock.cpp:
        (JSC::isBranch): Deleted.
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/ExitKind.cpp:
        (JSC::exitKindToString):
        * bytecode/ExitKind.h:
        * bytecode/PreciseJumpTargets.cpp:
        (JSC::getJumpTargetsForBytecodeOffset): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitOverridesHasInstance):
        (JSC::BytecodeGenerator::emitInstanceOfCustom):
        (JSC::BytecodeGenerator::emitCheckHasInstance): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::InstanceOfNode::emitBytecode):
        * 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/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasCellOperand):
        (JSC::DFG::Node::hasTypeInfoOperand):
        (JSC::DFG::Node::typeInfoOperand):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCheckTypeInfoFlags):
        (JSC::DFG::SpeculativeJIT::compileInstanceOfCustom):
        * dfg/DFGSpeculativeJIT.h:
        (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::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileOverridesHasInstance):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckTypeInfoFlags):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInstanceOfCustom):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckHasInstance): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_overrides_has_instance):
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emit_op_instanceof_custom):
        (JSC::JIT::emitSlow_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof_custom):
        (JSC::JIT::emit_op_check_has_instance): Deleted.
        (JSC::JIT::emitSlow_op_check_has_instance): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_overrides_has_instance):
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emit_op_instanceof_custom):
        (JSC::JIT::emitSlow_op_instanceof_custom):
        (JSC::JIT::emit_op_check_has_instance): Deleted.
        (JSC::JIT::emitSlow_op_check_has_instance): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonIdentifiers.h:
        * runtime/ExceptionHelpers.cpp:
        (JSC::invalidParameterInstanceofSourceAppender):
        (JSC::invalidParameterInstanceofNotFunctionSourceAppender):
        (JSC::invalidParameterInstanceofhasInstanceValueNotFunctionSourceAppender):
        (JSC::createInvalidInstanceofParameterErrorNotFunction):
        (JSC::createInvalidInstanceofParameterErrorhasInstanceValueNotFunction):
        (JSC::createInvalidInstanceofParameterError): Deleted.
        * runtime/ExceptionHelpers.h:
        * runtime/FunctionPrototype.cpp:
        (JSC::FunctionPrototype::addFunctionProperties):
        * runtime/FunctionPrototype.h:
        * runtime/JSBoundFunction.cpp:
        (JSC::isBoundFunction):
        (JSC::hasInstanceBoundFunction):
        * runtime/JSBoundFunction.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::functionProtoHasInstanceSymbolFunction):
        * runtime/JSObject.cpp:
        (JSC::JSObject::hasInstance):
        (JSC::objectPrivateFuncInstanceOf):
        * runtime/JSObject.h:
        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::TypeInfo):
        (JSC::TypeInfo::overridesHasInstance):
        * runtime/WriteBarrier.h:
        (JSC::WriteBarrierBase<Unknown>::slot):
        * tests/es6.yaml:
        * tests/stress/instanceof-custom-hasinstancesymbol.js: Added.
        (Constructor):
        (value):
        (instanceOf):
        (body):
        * tests/stress/symbol-hasInstance.js: Added.
        (Constructor):
        (value):
        (ObjectClass.Symbol.hasInstance):
        (NumberClass.Symbol.hasInstance):

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

        Web Inspector: Improve names in Debugger Call Stack section when paused
        https://bugs.webkit.org/show_bug.cgi?id=152398

        Reviewed by Brian Burg.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::functionName):
        Provide a better name from the underlying CallFrame.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.CallFrameProxy):
        Just call functionName, it will provide a better
        than nothing function name.

        * runtime/JSFunction.cpp:
        (JSC::getCalculatedDisplayName):
        Use emptyString().

        * interpreter/CallFrame.h:
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::friendlyFunctionName):
        This is the third similiar implementation of this,
        but all other cases use other "StackFrame" objects.
        Use the expected names for program code.

2015-12-16  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Add JSContext Script Profiling
        https://bugs.webkit.org/show_bug.cgi?id=151899

        Reviewed by Brian Burg.

        Extend JSC::Debugger to include a profiling client interface
        that the Inspector can implement to be told about script execution
        entry and exit points. Add new profiledCall/Evaluate/Construct
        methods that are entry points that will notify the profiling
        client if it exists.

        By putting the profiling client on Debugger it avoids having
        special code paths for a JSGlobalObject being JSContext inspected
        or a JSGlobalObject in a Page being Web inspected. In either case
        the JSGlobalObject can go through its debugger() which always
        reaches the correct inspector instance.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        Handle new files.

        * runtime/CallData.cpp:
        (JSC::profiledCall):
        * runtime/CallData.h:
        * runtime/Completion.cpp:
        (JSC::profiledEvaluate):
        * runtime/Completion.h:
        (JSC::profiledEvaluate):
        * runtime/ConstructData.cpp:
        (JSC::profiledConstruct):
        * runtime/ConstructData.h:
        (JSC::profiledConstruct):
        Create profiled versions of interpreter entry points. If a profiler client is
        available, this will automatically inform it of entry/exit. Include a reason
        why this is being profiled. Currently all reasons in JavaScriptCore are enumerated
        (API, Microtask) and Other is to be used by WebCore or future clients.

        * debugger/ScriptProfilingScope.h: Added.
        (JSC::ScriptProfilingScope::ScriptProfilingScope):
        (JSC::ScriptProfilingScope::~ScriptProfilingScope):
        (JSC::ScriptProfilingScope::shouldStartProfile):
        (JSC::ScriptProfilingScope::shouldEndProfile):
        At profiled entry points inform the profiling client if needed.

        * API/JSBase.cpp:
        (JSEvaluateScript):
        * API/JSObjectRef.cpp:
        (JSObjectCallAsFunction):
        (JSObjectCallAsConstructor):
        * runtime/JSJob.cpp:
        (JSC::JSJobMicrotask::run):
        Use the profiled functions for API and Microtask execution entry points.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::hasProfiler):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::hasProfiler):
        Extend hasProfiler to also check the new Debugger script profiler.

        * debugger/Debugger.cpp:
        (JSC::Debugger::setProfilingClient):
        (JSC::Debugger::willEvaluateScript):
        (JSC::Debugger::didEvaluateScript):
        * debugger/Debugger.h:
        Pass through to the profiling client.

        * inspector/protocol/ScriptProfiler.json: Added.
        * inspector/agents/InspectorScriptProfilerAgent.cpp: Added.
        (Inspector::InspectorScriptProfilerAgent::InspectorScriptProfilerAgent):
        (Inspector::InspectorScriptProfilerAgent::~InspectorScriptProfilerAgent):
        (Inspector::InspectorScriptProfilerAgent::didCreateFrontendAndBackend):
        (Inspector::InspectorScriptProfilerAgent::willDestroyFrontendAndBackend):
        (Inspector::InspectorScriptProfilerAgent::startTracking):
        (Inspector::InspectorScriptProfilerAgent::stopTracking):
        (Inspector::InspectorScriptProfilerAgent::isAlreadyProfiling):
        (Inspector::InspectorScriptProfilerAgent::willEvaluateScript):
        (Inspector::InspectorScriptProfilerAgent::didEvaluateScript):
        (Inspector::toProtocol):
        (Inspector::InspectorScriptProfilerAgent::addEvent):
        (Inspector::buildAggregateCallInfoInspectorObject):
        (Inspector::buildInspectorObject):
        (Inspector::buildProfileInspectorObject):
        (Inspector::InspectorScriptProfilerAgent::trackingComplete):
        * inspector/agents/InspectorScriptProfilerAgent.h: Added.
        New ScriptProfiler domain to just turn on / off script profiling.
        It introduces a start/update/complete event model which we want
        to include in new domains.

        * inspector/InspectorEnvironment.h:
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled):
        Simplify this now that we want it to be the same for all clients.

        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        Create the new agent.

        * inspector/InspectorProtocolTypes.h:
        (Inspector::Protocol::Array::addItem):
        Allow pushing a double onto a Protocol::Array.

2015-12-17  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Handle new_generator_func / new_generator_func_exp in DFG / FTL
        https://bugs.webkit.org/show_bug.cgi?id=152227

        Reviewed by Saam Barati.

        This patch introduces new_generator_func / new_generator_func_exp into DFG and FTL.
        We add a new DFG Node, NewGeneratorFunction. It will construct a function with GeneratorFunction's structure.
        The structure of GeneratorFunction is different from one of Function because GeneratorFunction has the different __proto__.

        Instead of extending NewFunction / PhantomNewFunction, we just added new DFG nodes, NewGeneratorFunction and PhantomNewGeneratorFunction.
        This is because NewGeneratorFunction will generate an object that has different class info from JSFunction (And if JSGeneratorFunction is extended, its size will become different from JSFunction).
        So, rather than extending NewFunction with generator flag, just adding new DFG nodes seems cleaner.

        Object allocation sinking phase will change NewGeneratorFunction to PhantomNewGeneratorFunction and defer or eliminate its actual materialization.
        It is completely the same to NewFunction and PhantomNewFunction.
        And when OSR exit occurs, we need to execute deferred NewGeneratorFunction since Baseline JIT does not consider it.
        So in FTL operation, we should create JSGeneratorFunction if we see PhantomNewGeneratorFunction materialization.

        * 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/DFGClobbersExitState.cpp:
        (JSC::DFG::clobbersExitState):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToPhantomNewFunction):
        (JSC::DFG::Node::convertToPhantomNewGeneratorFunction):
        (JSC::DFG::Node::hasCellOperand):
        (JSC::DFG::Node::isFunctionAllocation):
        (JSC::DFG::Node::isPhantomFunctionAllocation):
        (JSC::DFG::Node::isPhantomAllocation):
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunction):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validateCPS):
        (JSC::DFG::Validate::validateSSA):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewFunction):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationPopulateObjectInOSR):
        (JSC::FTL::operationMaterializeObjectInOSR):
        * tests/stress/generator-function-create-optimized.js: Added.
        (shouldBe):
        (g):
        (test.return.gen):
        (test):
        (test2.gen):
        (test2):
        * tests/stress/generator-function-declaration-sinking-no-double-allocate.js: Added.
        (shouldBe):
        (GeneratorFunctionPrototype):
        (call):
        (f):
        (sink):
        * tests/stress/generator-function-declaration-sinking-osrexit.js: Added.
        (shouldBe):
        (GeneratorFunctionPrototype):
        (g):
        (f):
        (sink):
        * tests/stress/generator-function-declaration-sinking-put.js: Added.
        (shouldBe):
        (GeneratorFunctionPrototype):
        (g):
        (f):
        (sink):
        * tests/stress/generator-function-expression-sinking-no-double-allocate.js: Added.
        (shouldBe):
        (GeneratorFunctionPrototype):
        (call):
        (f):
        (sink):
        * tests/stress/generator-function-expression-sinking-osrexit.js: Added.
        (shouldBe):
        (GeneratorFunctionPrototype):
        (g):
        (sink):
        * tests/stress/generator-function-expression-sinking-put.js: Added.
        (shouldBe):
        (GeneratorFunctionPrototype):
        (g):
        (sink):

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

        ARM64 MacroAssembler improperly reuses data temp register in test32() and test8() calls
        https://bugs.webkit.org/show_bug.cgi?id=152370

        Reviewed by Benjamin Poulain.

        Changed the test8/32(Address, Register) flavors to use the memoryTempRegister for loading the value
        att Address so that it doesn't collide with the subsequent use of dataTempRegister by the
        test32(Register, Register) function.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::test32):
        (JSC::MacroAssemblerARM64::test8):

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

        FTL B3 should support switches
        https://bugs.webkit.org/show_bug.cgi?id=152360

        Reviewed by Geoffrey Garen.

        I implemented this because I was hoping it would less us run V8/crypto, but instead it just led
        me to file a fun bug: https://bugs.webkit.org/show_bug.cgi?id=152365.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::check):
        (JSC::FTL::Output::switchInstruction):
        (JSC::FTL::Output::ret):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::ftlUnreachable):
        (JSC::FTL::DFG::LowerDFGToLLVM::crash):

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

        Fix internal Windows build
        https://bugs.webkit.org/show_bug.cgi?id=152364

        Reviewed by Tim Horton.

        * JavaScriptCore.vcxproj/JavaScriptCore.proj:

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

        Improve JSObject::put performance
        https://bugs.webkit.org/show_bug.cgi?id=152347

        Reviewed by Geoffrey Garen.

        This adds a new benchmark called dynbench, which just uses the C++ API to create, modify, and
        query objects. This also adds some optimizations to make the JSObject::put code faster by making
        it inlinable in places that really need the performance, like JITOperations and LLIntSlowPaths.
        Inlining it is optional because the put() method is large. If you want it inlined, call
        putInline(). There's a putInline() variant of both JSObject::put() and JSValue::put().

        This is up to a 20% improvement for JSObject::put calls that get inlined all the way (like from
        JITOperations and the new benchmark) and it's also a speed-up, albeit a smaller one, for
        JSObject::put calls that don't get inlined (i.e. those from the DOM and the JSC C++ library code).
        Specific speed-ups are as follows. Note that "dynamic context" means that we told PutPropertySlot
        that we're not a static put_by_id, which turns off some type inference.

        Get By Id: 2% faster
        Put By Id Replace: 23% faster
        Put By Id Transition + object allocation: 11% faster
        Get By Id w/ dynamic context: 5% faster
        Put By Id Replace w/ dynamic context: 25% faster
        Put By Id Transition + object allocation w/ dynamic context: 10% faster

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dynbench.cpp: Added.
        (JSC::benchmarkImpl):
        (main):
        * jit/CallFrameShuffler32_64.cpp:
        * jit/CallFrameShuffler64.cpp:
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/ClassInfo.h:
        (JSC::ClassInfo::hasStaticProperties):
        * runtime/ConsoleClient.cpp:
        * runtime/CustomGetterSetter.h:
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::finishCreation):
        (JSC::addErrorInfoAndGetBytecodeOffset): Deleted.
        * runtime/GetterSetter.h:
        (JSC::asGetterSetter):
        * runtime/JSCInlines.h:
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::put):
        (JSC::JSValue::putInternal):
        (JSC::JSValue::putByIndex):
        * runtime/JSObject.cpp:
        (JSC::JSObject::put):
        (JSC::JSObject::putByIndex):
        * runtime/JSObject.h:
        (JSC::JSObject::getVectorLength):
        (JSC::JSObject::inlineGetOwnPropertySlot):
        (JSC::JSObject::get):
        (JSC::JSObject::putDirectInternal):

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

        Work around a bug in LLVM by flipping the unification order
        https://bugs.webkit.org/show_bug.cgi?id=152341
        rdar://problem/23920749

        Reviewed by Mark Lam.

        * dfg/DFGUnificationPhase.cpp:
        (JSC::DFG::UnificationPhase::run):

2015-12-16  Saam barati  <sbarati@apple.com>

        Add "explicit operator bool" to ScratchRegisterAllocator::PreservedState
        https://bugs.webkit.org/show_bug.cgi?id=152337

        Reviewed by Mark Lam.

        If we have a default constructor, we should also have a way
        to tell if a PreservedState is invalid.

        * jit/ScratchRegisterAllocator.cpp:
        (JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
        (JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
        * jit/ScratchRegisterAllocator.h:
        (JSC::ScratchRegisterAllocator::PreservedState::PreservedState):
        (JSC::ScratchRegisterAllocator::PreservedState::operator bool):

2015-12-16  Caitlin Potter  <caitp@igalia.com>

        [JSC] fix error message for eval/arguments CoverInitializedName in strict code
        https://bugs.webkit.org/show_bug.cgi?id=152304

        Reviewed by Darin Adler.

        Because the error was originally classified as indicating a Pattern, the
        error in AssignmentPattern parsing causes the reported message to revert to
        the original Expression error message, which in this case is incorrect.

        This change modifies the implementation of the strict code
        error slightly, and reclassifies the error to prevent the message revert,
        which improves the clarity of the message overall.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseAssignmentElement):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        * parser/Parser.h:
        (JSC::Parser::ExpressionErrorClassifier::reclassifyExpressionError):
        (JSC::Parser::reclassifyExpressionError):
        * tests/stress/destructuring-assignment-syntax.js:

2015-12-16  Joseph Pecoraro  <pecoraro@apple.com>

        Builtin source should be minified more
        https://bugs.webkit.org/show_bug.cgi?id=152290

        Reviewed by Darin Adler.

        * Scripts/builtins/builtins_model.py:
        (BuiltinFunction.fromString):
        Remove primarily empty lines that would just introduce clutter.
        We only do the minification in non-Debug configurations, which
        is determined by the CONFIGURATION environment variable. You can
        see how tests would generate differently, like so:
        shell> CONFIGURATION=Release ./Tools/Scripts/run-builtins-generator-tests

2015-12-16  Commit Queue  <commit-queue@webkit.org>

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

        due to missing OSR exit materialization support in FTL
        (Requested by yusukesuzuki on #webkit).

        Reverted changeset:

        "[ES6] Handle new_generator_func / new_generator_func_exp in
        DFG / FTL"
        https://bugs.webkit.org/show_bug.cgi?id=152227
        http://trac.webkit.org/changeset/194135

2015-12-16  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        [Fetch API] Add fetch API compile time flag
        https://bugs.webkit.org/show_bug.cgi?id=152254

        Reviewed by Darin Adler.

        * Configurations/FeatureDefines.xcconfig:

2015-12-16  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Handle new_generator_func / new_generator_func_exp in DFG / FTL
        https://bugs.webkit.org/show_bug.cgi?id=152227

        Reviewed by Saam Barati.

        This patch introduces new_generator_func / new_generator_func_exp into DFG and FTL.
        We add a new DFG Node, NewGeneratorFunction. It will construct a function with GeneratorFunction's structure.
        The structure of GeneratorFunction is different from one of Function because GeneratorFunction has the different __proto__.

        * 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/DFGClobbersExitState.cpp:
        (JSC::DFG::clobbersExitState):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToPhantomNewFunction):
        (JSC::DFG::Node::hasCellOperand):
        (JSC::DFG::Node::isFunctionAllocation):
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunction):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewFunction):
        * tests/stress/generator-function-create-optimized.js: Added.
        (shouldBe):
        (g):
        (test.return.gen):
        (test):
        (test2.gen):
        (test2):
        * tests/stress/generator-function-declaration-sinking-no-double-allocate.js: Added.
        (shouldBe):
        (GeneratorFunctionPrototype):
        (call):
        (f):
        (sink):
        * tests/stress/generator-function-declaration-sinking-osrexit.js: Added.
        (shouldBe):
        (GeneratorFunctionPrototype):
        (g):
        (f):
        (sink):
        * tests/stress/generator-function-declaration-sinking-put.js: Added.
        (shouldBe):
        (GeneratorFunctionPrototype):
        (g):
        (f):
        (sink):
        * tests/stress/generator-function-expression-sinking-no-double-allocate.js: Added.
        (shouldBe):
        (GeneratorFunctionPrototype):
        (call):
        (f):
        (sink):
        * tests/stress/generator-function-expression-sinking-osrexit.js: Added.
        (shouldBe):
        (GeneratorFunctionPrototype):
        (g):
        (sink):
        * tests/stress/generator-function-expression-sinking-put.js: Added.
        (shouldBe):
        (GeneratorFunctionPrototype):
        (g):
        (sink):

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

        Gardening: fix broken 32-bit JSC tests.  Just need to assign a scratch register.
        https://bugs.webkit.org/show_bug.cgi?id=152191 

        Not reviewed.

        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitBitBinaryOpFastPath):

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

        Introducing ScratchRegisterAllocator::PreservedState.
        https://bugs.webkit.org/show_bug.cgi?id=152315

        Reviewed by Geoffrey Garen.

        restoreReusedRegistersByPopping() should always be called with 2 values that
        matches the expectation of preserveReusedRegistersByPushing().  Those 2 values
        are the number of bytes preserved and the ExtraStackSpace requirement.  By
        encapsulating them in a ScratchRegisterAllocator::PreservedState, we can make
        it less error prone when calling restoreReusedRegistersByPopping().  Now, we only
        need to pass it the appropriate PreservedState that its matching
        preserveReusedRegistersByPushing() returned.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessGenerationState::restoreScratch):
        (JSC::AccessCase::generate):
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessGenerationState::AccessGenerationState):
        * ftl/FTLCompileBinaryOp.cpp:
        (JSC::FTL::generateBinaryBitOpFastPath):
        (JSC::FTL::generateRightShiftFastPath):
        (JSC::FTL::generateBinaryArithOpFastPath):
        * ftl/FTLLazySlowPath.cpp:
        (JSC::FTL::LazySlowPath::generate):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
        * jit/ScratchRegisterAllocator.cpp:
        (JSC::ScratchRegisterAllocator::allocateScratchGPR):
        (JSC::ScratchRegisterAllocator::allocateScratchFPR):
        (JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
        (JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
        * jit/ScratchRegisterAllocator.h:
        (JSC::ScratchRegisterAllocator::usedRegisters):
        (JSC::ScratchRegisterAllocator::PreservedState::PreservedState):

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

        Polymorphic operand types for DFG and FTL bit operators.
        https://bugs.webkit.org/show_bug.cgi?id=152191

        Reviewed by Saam Barati.

        * bytecode/SpeculatedType.h:
        (JSC::isUntypedSpeculationForBitOps):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::shouldSpeculateUntypedForBitOps):
        - Added check for types not supported by ValueToInt32, and therefore should be
          treated as untyped for bitops.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        - Handled untyped operands.

        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        - Added DFG slow path functions for bitops.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitUntypedBitOp):
        (JSC::DFG::SpeculativeJIT::compileBitwiseOp):
        (JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp):
        (JSC::DFG::SpeculativeJIT::compileShiftOp):
        * dfg/DFGSpeculativeJIT.h:
        - Added DFG backend support untyped operands for bitops.

        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        - Limit bitops strength reduction only to when we don't have untyped operands.
          This is because values that are not int32s need to be converted to int32.
          Without untyped operands, the ValueToInt32 node takes care of this.
          With untyped operands, we cannot use ValueToInt32, and need to do the conversion
          in the code emitted for the bitop node itself.  For example:

              5.5 | 0; // yields 5 because ValueToInt32 converts the 5.5 to a 5.
              "abc" | 0; // would yield "abc" instead of the expected 0 if we let
                         // strength reduction do its thing.

        * ftl/FTLCompileBinaryOp.cpp:
        (JSC::FTL::generateBinaryBitOpFastPath):
        (JSC::FTL::generateRightShiftFastPath):
        (JSC::FTL::generateBinaryOpFastPath):

        * ftl/FTLInlineCacheDescriptor.h:
        (JSC::FTL::BitAndDescriptor::BitAndDescriptor):
        (JSC::FTL::BitAndDescriptor::icSize):
        (JSC::FTL::BitAndDescriptor::nodeType):
        (JSC::FTL::BitAndDescriptor::opName):
        (JSC::FTL::BitAndDescriptor::slowPathFunction):
        (JSC::FTL::BitAndDescriptor::nonNumberSlowPathFunction):
        (JSC::FTL::BitOrDescriptor::BitOrDescriptor):
        (JSC::FTL::BitOrDescriptor::icSize):
        (JSC::FTL::BitOrDescriptor::nodeType):
        (JSC::FTL::BitOrDescriptor::opName):
        (JSC::FTL::BitOrDescriptor::slowPathFunction):
        (JSC::FTL::BitOrDescriptor::nonNumberSlowPathFunction):
        (JSC::FTL::BitXorDescriptor::BitXorDescriptor):
        (JSC::FTL::BitXorDescriptor::icSize):
        (JSC::FTL::BitXorDescriptor::nodeType):
        (JSC::FTL::BitXorDescriptor::opName):
        (JSC::FTL::BitXorDescriptor::slowPathFunction):
        (JSC::FTL::BitXorDescriptor::nonNumberSlowPathFunction):
        (JSC::FTL::BitLShiftDescriptor::BitLShiftDescriptor):
        (JSC::FTL::BitLShiftDescriptor::icSize):
        (JSC::FTL::BitLShiftDescriptor::nodeType):
        (JSC::FTL::BitLShiftDescriptor::opName):
        (JSC::FTL::BitLShiftDescriptor::slowPathFunction):
        (JSC::FTL::BitLShiftDescriptor::nonNumberSlowPathFunction):
        (JSC::FTL::BitRShiftDescriptor::BitRShiftDescriptor):
        (JSC::FTL::BitRShiftDescriptor::icSize):
        (JSC::FTL::BitRShiftDescriptor::nodeType):
        (JSC::FTL::BitRShiftDescriptor::opName):
        (JSC::FTL::BitRShiftDescriptor::slowPathFunction):
        (JSC::FTL::BitRShiftDescriptor::nonNumberSlowPathFunction):
        (JSC::FTL::BitURShiftDescriptor::BitURShiftDescriptor):
        (JSC::FTL::BitURShiftDescriptor::icSize):
        (JSC::FTL::BitURShiftDescriptor::nodeType):
        (JSC::FTL::BitURShiftDescriptor::opName):
        (JSC::FTL::BitURShiftDescriptor::slowPathFunction):
        (JSC::FTL::BitURShiftDescriptor::nonNumberSlowPathFunction):
        - Added support for bitop ICs.

        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfBitAnd):
        (JSC::FTL::sizeOfBitOr):
        (JSC::FTL::sizeOfBitXor):
        (JSC::FTL::sizeOfBitLShift):
        (JSC::FTL::sizeOfBitRShift):
        (JSC::FTL::sizeOfBitURShift):
        * ftl/FTLInlineCacheSize.h:
        - Added new bitop IC sizes.  These are just estimates for now that work adequately,
          and are shown to not impact performance on benchmarks.  We will re-tune these
          sizes values later in another patch once all snippet ICs have been added.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitAnd):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitOr):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitXor):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitRShift):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitLShift):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBitURShift):
        - Added support for bitop ICs.

        * jit/JITLeftShiftGenerator.cpp:
        (JSC::JITLeftShiftGenerator::generateFastPath):
        * jit/JITLeftShiftGenerator.h:
        (JSC::JITLeftShiftGenerator::JITLeftShiftGenerator):
        * jit/JITRightShiftGenerator.cpp:
        (JSC::JITRightShiftGenerator::generateFastPath):
        - The shift MASM operatons need to ensure that the shiftAmount is not in the same
          register as the destination register.  With the baselineJIT and DFG, this is
          ensured in how we allocate these registers, and hence, the bug does not manifest.
          With the FTL, these registers are not guaranteed to be unique.  Hence, we need
          to fix the shift op snippet code to compensate for this. 

2015-12-15  Caitlin Potter  <caitp@igalia.com>

        [JSC] SyntaxError if AssignmentElement is `eval` or `arguments` in strict code
        https://bugs.webkit.org/show_bug.cgi?id=152302

        Reviewed by Mark Lam.

        `eval` and `arguments` must not be assigned to in strict code. This
        change fixes `language/expressions/assignment/destructuring/obj-id-simple-strict.js`
        in Test262, as well as a variety of other similar tests.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseAssignmentElement):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        * tests/stress/destructuring-assignment-syntax.js:

2015-12-15  Csaba Osztrogonác  <ossy@webkit.org>

        URTBF after 194062.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::supportsFloatingPointCeil): Added.
        (JSC::MacroAssemblerARM::ceilDouble): Added.

2015-12-14  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should account for localsOffset
        https://bugs.webkit.org/show_bug.cgi?id=152288

        Reviewed by Saam Barati.

        The DFG will build up some data structures that expect to know about offsets from FP. Those data
        structures may slide by some offset when the low-level compiler (either LLVM or B3) does stack
        allocation. So, the LLVM FTL modifies those data structures based on the real offset that it gets
        from LLVM's stackmaps. The B3 code needs to do the same.

        I had previously vowed to never put more stuff into FTLB3Compile.cpp, because I didn't want it to
        look like FTLCompile.cpp. Up until now, I was successful because I used lambdas installed by
        FTLLower. But in this case, I actually think that having code that just does this explicitly in
        FTLB3Compile.cpp is least confusing. There is no particular place in FTLLower that would want to
        care about this, and we need to ensure that we do this fixup before we run any of the stackmap
        generators. In other words, it needs to happen before we call B3::generate(). The ordering
        constraints seem like a good reason to have this done explicitly rather than through lambdas.

        I wrote a test. The test was failing in trunk because the B3 meaning of anchor().value() is
        different from the LLVM meaning. This caused breakage when we used this idiom:

            ValueFromBlock foo = m_out.anchor(things);
            ...(foo.value()) // we were expecting that foo.value() == things

        I never liked this idiom to begin with, so instead of trying to change B3's anchor(), I changed
        the idiom to:

            LValue fooValue = things;
            ValueFromBlock foo = m_out.anchor(fooValue);
            ...(fooValue)

        This is probably a good idea, since eventually we want B3's anchor() to just return the
        UpsilonValue*. To get there, we want to eliminate any situations where code assumes that
        ValueFromBlock is an actual object and not just a typedef for a pointer.

        * ftl/FTLB3Compile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLB3Output.cpp:
        (JSC::FTL::Output::appendTo):
        (JSC::FTL::Output::lockedStackSlot):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::framePointer):
        (JSC::FTL::Output::constBool):
        (JSC::FTL::Output::constInt32):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetIndexedPropertyStorage):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCreateDirectArguments):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileStringCharAt):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileForwardVarargs):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileHasIndexedProperty):
        (JSC::FTL::DFG::LowerDFGToLLVM::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToLLVM::sensibleDoubleToInt32):
        * ftl/FTLState.h:
        (JSC::FTL::verboseCompilationEnabled):
        * tests/stress/ftl-function-dot-arguments-with-callee-saves.js: Added.

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

        Math.random should have an intrinsic thunk and it should be later handled as a DFG Node
        https://bugs.webkit.org/show_bug.cgi?id=152133

        Reviewed by Geoffrey Garen.

        In this patch, we implement new RandomIntrinsic. It emits a machine code to generate random numbers efficiently.
        And later it will be recognized by DFG and converted to ArithRandom node.
        It provides type information SpecDoubleReal since Math.random only generates a number within [0, 1.0).

        Currently, only 64bit version is supported. On 32bit environment, ArithRandom will be converted to callOperation.
        While it emits a function call, ArithRandom node on 32bit still represents SpecDoubleReal as a result type.

        * dfg/DFGAbstractHeap.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileArithRandom):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileArithRandom):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithRandom):
        * jit/AssemblyHelpers.cpp:
        (JSC::emitRandomThunkImpl):
        (JSC::AssemblyHelpers::emitRandomThunk):
        * jit/AssemblyHelpers.h:
        * jit/JITOperations.h:
        * jit/ThunkGenerators.cpp:
        (JSC::randomThunkGenerator):
        * jit/ThunkGenerators.h:
        * runtime/Intrinsic.h:
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::weakRandomOffset):
        * runtime/MathObject.cpp:
        (JSC::MathObject::finishCreation):
        * runtime/VM.cpp:
        (JSC::thunkGeneratorForIntrinsic):
        * tests/stress/random-53bit.js: Added.
        (test):
        * tests/stress/random-in-range.js: Added.
        (test):

2015-12-14  Benjamin Poulain  <benjamin@webkit.org>

        Rename FTL::Output's ceil64() to doubleCeil()

        Rubber-stamped by Filip Pizlo.

        ceil64() was a bad name, that's the name convention we use for integers.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::doubleCeil):
        (JSC::FTL::Output::ceil64): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithRound):

2015-12-14  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should be able to run n-body.js
        https://bugs.webkit.org/show_bug.cgi?id=152281

        Reviewed by Benjamin Poulain.

        Fix a bug where m_captured was pointing to the start of the captured vars slot rather than the
        end, like the rest of the FTL expected.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):

2015-12-14  Benjamin Poulain  <bpoulain@apple.com>

        Fix bad copy-paste in r194062

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::ceil64):

2015-12-14  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix cloop build.

        * jit/GPRInfo.cpp:

2015-12-14  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should do PutById
        https://bugs.webkit.org/show_bug.cgi?id=152268

        Reviewed by Saam Barati.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createGenericCompare): I realized that we were missing some useful matching rules.
        * b3/testb3.cpp: Added a bunch of tests.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById): Do the things.
        * jit/GPRInfo.cpp: Added. I had to do this yucky thing because clang was having issues compiling references to this from deeply nested lambdas.
        * jit/GPRInfo.h: Added a comment about how patchpointScratchRegister is bizarre and should probably die.

2015-12-14  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add ceil() support for x86 and expose it to B3
        https://bugs.webkit.org/show_bug.cgi?id=152231

        Reviewed by Geoffrey Garen.

        Most x86 CPUs we care about support ceil() natively
        with the round instruction.

        This patch expose that behind a runtime flag, use it
        in the Math.ceil() thunk and expose it to B3.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::supportsFloatingPointCeil):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::supportsFloatingPointCeil):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::supportsFloatingPointCeil):
        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::supportsFloatingPointCeil):
        * assembler/MacroAssemblerX86Common.cpp:
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::ceilDouble):
        (JSC::MacroAssemblerX86Common::ceilFloat):
        (JSC::MacroAssemblerX86Common::supportsFloatingPointCeil):
        (JSC::MacroAssemblerX86Common::supportsLZCNT):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::roundss_rr):
        (JSC::X86Assembler::roundss_mr):
        (JSC::X86Assembler::roundsd_rr):
        (JSC::X86Assembler::roundsd_mr):
        (JSC::X86Assembler::mfence):
        (JSC::X86Assembler::X86InstructionFormatter::threeByteOp):
        * b3/B3ConstDoubleValue.cpp:
        (JSC::B3::ConstDoubleValue::ceilConstant):
        * b3/B3ConstDoubleValue.h:
        * b3/B3ConstFloatValue.cpp:
        (JSC::B3::ConstFloatValue::ceilConstant):
        * b3/B3ConstFloatValue.h:
        * b3/B3LowerMacrosAfterOptimizations.cpp:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3ReduceDoubleToFloat.cpp:
        * b3/B3ReduceStrength.cpp:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::ceilConstant):
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testCeilArg):
        (JSC::B3::testCeilImm):
        (JSC::B3::testCeilMem):
        (JSC::B3::testCeilCeilArg):
        (JSC::B3::testCeilIToD64):
        (JSC::B3::testCeilIToD32):
        (JSC::B3::testCeilArgWithUselessDoubleConversion):
        (JSC::B3::testCeilArgWithEffectfulDoubleConversion):
        (JSC::B3::populateWithInterestingValues):
        (JSC::B3::run):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::ceil64):
        * jit/ThunkGenerators.cpp:
        (JSC::ceilThunkGenerator):

2015-12-14  Andreas Kling  <akling@apple.com>

        ResourceUsageOverlay should show GC timers.
        <https://webkit.org/b/152151>

        Reviewed by Darin Adler.

        Expose the next fire time (in WTF timestamp style) of a GCActivityCallback.

        * heap/GCActivityCallback.cpp:
        (JSC::GCActivityCallback::scheduleTimer):
        (JSC::GCActivityCallback::cancelTimer):
        * heap/GCActivityCallback.h:

2015-12-14  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix merge issue in a test.

        * b3/testb3.cpp:
        (JSC::B3::testCheckTwoMegaCombos):
        (JSC::B3::testCheckTwoNonRedundantMegaCombos):

2015-12-14  Filip Pizlo  <fpizlo@apple.com>

        B3 should not give ValueReps for the non-stackmap children of a CheckValue to the generator callback
        https://bugs.webkit.org/show_bug.cgi?id=152224

        Reviewed by Geoffrey Garen.

        Previously, a stackmap generator for a Check had to know how many children the B3 value for the
        Check had at the time of code generation. That meant that B3 could not change the kind of Check
        that it was - for example it cannot turn a Check into a Patchpoint and it cannot turn a CheckAdd
        into a Check. But just changing the contract so that the stackmap generation params only get the
        stackmap children of the check means that B3 can transform Checks as it likes.

        This is meant to aid sinking values into checks.

        Also, I found that the effects of a Check did not include HeapRange::top(). I think it's best if
        exitsSideways does not imply reading top, the way that it does in DFG. In the DFG, that makes
        sense because the exit analysis is orthogonal, so the clobber analysis tells you about the reads
        not counting OSR exit - if you need to you can conditionally merge that with World based on a
        separate exit analysis. But in B3, the Effects object tells you about both exiting and reading,
        and it's computed by one analysis. Prior to this change, Check was not setting reads to top() so
        we were effectively saying that Effects::reads is meaningless when exitsSideways is true. It
        seems more sensible to instead force the analysis to set reads to top() when setting
        exitsSideways to true, not least because we only have one such analysis and many users. But it
        also makes sense for another reason: it allows us to bound the set of things that the program
        will read after it exits. That might not be useful to us now, but it's a nice feature to get for
        free. I've seen language features that have behave like exitsSideways that don't also read top,
        like an array bounds check that causes sudden termination without making any promises about how
        pretty the crash dump will look.

        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::generate):
        * b3/B3Opcode.h:
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects):
        * b3/testb3.cpp:
        (JSC::B3::testSimpleCheck):
        (JSC::B3::testCheckLessThan):
        (JSC::B3::testCheckMegaCombo):
        (JSC::B3::testCheckAddImm):
        (JSC::B3::testCheckAddImmCommute):
        (JSC::B3::testCheckAddImmSomeRegister):
        (JSC::B3::testCheckAdd):
        (JSC::B3::testCheckAdd64):
        (JSC::B3::testCheckSubImm):
        (JSC::B3::testCheckSubBadImm):
        (JSC::B3::testCheckSub):
        (JSC::B3::testCheckSub64):
        (JSC::B3::testCheckNeg):
        (JSC::B3::testCheckNeg64):
        (JSC::B3::testCheckMul):
        (JSC::B3::testCheckMulMemory):
        (JSC::B3::testCheckMul2):
        (JSC::B3::testCheckMul64):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):

2015-12-14  Filip Pizlo  <fpizlo@apple.com>

        Air: Support Architecture-specific forms and Opcodes
        https://bugs.webkit.org/show_bug.cgi?id=151736

        Reviewed by Benjamin Poulain.

        This adds really awesome architecture selection to the AirOpcode.opcodes file. If an opcode or
        opcode form is unavailable on some architecture, you can still mention its name in C++ code (it'll
        still be a member of the enum) but isValidForm() and all other reflective queries will tell you
        that it doesn't exist. This will make the instruction selector steer clear of it, and it will
        also ensure that the spiller doesn't try to use any unavailable architecture-specific address
        forms.

        The new capability is documented extensively in a comment in AirOpcode.opcodes.

        * b3/air/AirOpcode.opcodes:
        * b3/air/opcode_generator.rb:

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

        Misc. small fixes in snippet related code.
        https://bugs.webkit.org/show_bug.cgi?id=152259

        Reviewed by Saam Barati.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithMul):
        - When loading a constant JSValue for a node, use the one that the node already
          provides instead of reconstructing it.  This is not a bug, but the fix makes
          the code cleaner.

        * jit/JITBitAndGenerator.cpp:
        (JSC::JITBitAndGenerator::generateFastPath):
        - No need to do a bitand with a constant int 0xffffffff operand.

        * jit/JITBitOrGenerator.cpp:
        (JSC::JITBitOrGenerator::generateFastPath):
        - Fix comments: bitor is '|', not '&'.
        - No need to do a bitor with a constant int 0 operand.

        * jit/JITBitXorGenerator.cpp:
        (JSC::JITBitXorGenerator::generateFastPath):
        - Fix comments: bitxor is '^', not '&'.

        * jit/JITRightShiftGenerator.cpp:
        (JSC::JITRightShiftGenerator::generateFastPath):
        - Renamed a jump target name to be clearer about its purpose.

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

        We should not employ the snippet code in the DFG if no OSR exit was previously encountered.
        https://bugs.webkit.org/show_bug.cgi?id=152255

        Reviewed by Saam Barati.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

2015-12-14  Filip Pizlo  <fpizlo@apple.com>

        B3->Air compare-branch fusion should fuse even if the result of the comparison is used more than once
        https://bugs.webkit.org/show_bug.cgi?id=152198

        Reviewed by Benjamin Poulain.

        If we have a comparison operation that is branched on from multiple places, then we were
        previously executing the comparison to get a boolean result in a register and then we were
        testing/branching on that register in multiple places. This is actually less efficient than
        just fusing the compare/branch multiple times, even though this means that the comparison
        executes multiple times. This would only be bad if the comparison fused loads multiple times,
        since duplicating loads is both wrong and inefficient. So, this adds the notion of sharing to
        compare/branch fusion. If a compare is shared by multiple branches, then we refuse to fuse
        the load.

        To write the test, I needed to zero-extend 8 to 32. In the process of thinking about how to
        do this, I realized that we needed lowerings for SExt8/SExt16. And I realized that the
        lowerings for the other extension operations were not fully fleshed out; for example they
        were incapable of load fusion. This patch fixes this and also adds some smart strength
        reductions for BitAnd(@x, 0xff/0xffff/0xffffffff) - all of which should be lowered to a zero
        extension.

        This is a big win on asm.js code. It's not enough to bridge the gap to LLVM, but it's a huge
        step in that direction.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::load8SignedExtendTo32):
        (JSC::MacroAssemblerX86Common::zeroExtend8To32):
        (JSC::MacroAssemblerX86Common::signExtend8To32):
        (JSC::MacroAssemblerX86Common::load16):
        (JSC::MacroAssemblerX86Common::load16SignedExtendTo32):
        (JSC::MacroAssemblerX86Common::zeroExtend16To32):
        (JSC::MacroAssemblerX86Common::signExtend16To32):
        (JSC::MacroAssemblerX86Common::store32WithAddressOffsetPatch):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::movzbl_rr):
        (JSC::X86Assembler::movsbl_rr):
        (JSC::X86Assembler::movzwl_rr):
        (JSC::X86Assembler::movswl_rr):
        (JSC::X86Assembler::cmovl_rr):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createGenericCompare):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3ReduceStrength.cpp:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testCheckMegaCombo):
        (JSC::B3::testCheckTwoMegaCombos):
        (JSC::B3::testCheckTwoNonRedundantMegaCombos):
        (JSC::B3::testCheckAddImm):
        (JSC::B3::testTruncSExt32):
        (JSC::B3::testSExt8):
        (JSC::B3::testSExt8Fold):
        (JSC::B3::testSExt8SExt8):
        (JSC::B3::testSExt8SExt16):
        (JSC::B3::testSExt8BitAnd):
        (JSC::B3::testBitAndSExt8):
        (JSC::B3::testSExt16):
        (JSC::B3::testSExt16Fold):
        (JSC::B3::testSExt16SExt16):
        (JSC::B3::testSExt16SExt8):
        (JSC::B3::testSExt16BitAnd):
        (JSC::B3::testBitAndSExt16):
        (JSC::B3::testSExt32BitAnd):
        (JSC::B3::testBitAndSExt32):
        (JSC::B3::testBasicSelect):
        (JSC::B3::run):

2015-12-14  Chris Dumez  <cdumez@apple.com>

        Roll out r193974 and follow-up fixes as it caused JSC crashes
        https://bugs.webkit.org/show_bug.cgi?id=152256

        Unreviewed, Roll out r193974 and follow-up fixes as it caused JSC crashes.

        * API/JSCallbackObject.h:
        * builtins/FunctionPrototype.js:
        * bytecode/BytecodeBasicBlock.cpp:
        (JSC::isBranch):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/ExitKind.cpp:
        (JSC::exitKindToString): Deleted.
        * bytecode/ExitKind.h:
        * bytecode/PreciseJumpTargets.cpp:
        (JSC::getJumpTargetsForBytecodeOffset):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCheckHasInstance):
        (JSC::BytecodeGenerator::emitGetById): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitTypeOf): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::InstanceOfNode::emitBytecode):
        (JSC::LogicalOpNode::emitBytecode): Deleted.
        (JSC::LogicalOpNode::emitBytecodeInConditionContext): Deleted.
        * 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/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasCellOperand): Deleted.
        (JSC::DFG::Node::hasTransition): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileInstanceOf): Deleted.
        (JSC::DFG::SpeculativeJIT::compileArithAdd): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation): Deleted.
        * 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::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckHasInstance):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInstanceOf): Deleted.
        (JSC::FTL::DFG::LowerDFGToLLVM::compileHasIndexedProperty): Deleted.
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArguments): Deleted.
        (JSC::CCallHelpers::setupArgumentsWithExecState): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperationNoExceptionCheck): Deleted.
        (JSC::JIT::callOperation): Deleted.
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_check_has_instance):
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_check_has_instance):
        (JSC::JIT::emitSlow_op_instanceof):
        (JSC::JIT::emit_op_is_undefined): Deleted.
        (JSC::JIT::emitSlow_op_to_number): Deleted.
        (JSC::JIT::emitSlow_op_to_string): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_check_has_instance):
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_check_has_instance):
        (JSC::JIT::emitSlow_op_instanceof):
        (JSC::JIT::emit_op_is_undefined): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions): Deleted.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonIdentifiers.h:
        * runtime/ExceptionHelpers.cpp:
        (JSC::invalidParameterInstanceofSourceAppender):
        (JSC::createInvalidInstanceofParameterError):
        (JSC::createError): Deleted.
        (JSC::createNotAFunctionError): Deleted.
        (JSC::createNotAnObjectError): Deleted.
        * runtime/ExceptionHelpers.h:
        * runtime/FunctionPrototype.cpp:
        (JSC::FunctionPrototype::addFunctionProperties):
        * runtime/FunctionPrototype.h:
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::create): Deleted.
        (JSC::JSBoundFunction::customHasInstance): Deleted.
        * runtime/JSBoundFunction.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::throwTypeErrorGetterSetter): Deleted.
        * runtime/JSObject.cpp:
        (JSC::JSObject::hasInstance):
        (JSC::JSObject::defaultHasInstance): Deleted.
        (JSC::JSObject::getPropertyNames): Deleted.
        (JSC::JSObject::getOwnPropertyNames): Deleted.
        * runtime/JSObject.h:
        (JSC::JSFinalObject::create): Deleted.
        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::TypeInfo):
        (JSC::TypeInfo::overridesHasInstance):
        * runtime/WriteBarrier.h:
        (JSC::WriteBarrierBase<Unknown>::slot):
        * tests/es6.yaml:
        * tests/stress/instanceof-custom-hasinstancesymbol.js: Removed.
        * tests/stress/symbol-hasInstance.js: Removed.

2015-12-13  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove FTL::Output's doubleEqualOrUnordered()
        https://bugs.webkit.org/show_bug.cgi?id=152234

        Reviewed by Sam Weinig.

        It is unused, one less thing to worry about.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::doubleEqualOrUnordered): Deleted.
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::doubleEqualOrUnordered): Deleted.

2015-12-13  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Should not emit get_by_id for indexed property access
        https://bugs.webkit.org/show_bug.cgi?id=151354

        Reviewed by Darin Adler.

        Before this patch, `a["1"]` is converted to `a.1` get_by_id operation in the bytecode compiler.
        get_by_id emits IC. IC rely on the fact that Structure transition occur when adding / removing object's properties.
        However, it's not true for indexed element properties. They are stored in the element storage and Structure transition does not occur.

        For example, in the following case,

             function getOne(a) { return a['1']; }

             for (var i = 0; i < 36; ++i)
                 getOne({2: true});

             if (!getOne({1: true}))
                 throw new Error("OUT");

        In this case, `a['1']` creates get_by_id. `getOne({2: true})` calls makes getOne's get_by_id to create IC says that,
        "when comming this structure chain, there is no property in "1", so we should return `undefined`".

        After that, we call `getOne({1: true})`. But in this case, `{2: true}` and `{1: true}` have the same structure chain,
        because indexed property addition does not occur structure transition.
        So previous IC fast path is used and return `undefined`. But the correct answer is returning `true`.

        This patch fixes the above issue. When there is string bracket access, we only emits get_by_id if the given string is not an index.
        There are bugs in get_by_id, put_by_id, put_by_id (direct). But only get_by_id poses user observable issue.
        Because in the put_by_id case, the generic path just says "this put is uncacheable".

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitGetById):
        (JSC::BytecodeGenerator::emitPutById):
        (JSC::BytecodeGenerator::emitDirectPutById):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::isNonIndexStringElement):
        (JSC::BracketAccessorNode::emitBytecode):
        (JSC::FunctionCallBracketNode::emitBytecode):
        (JSC::AssignBracketNode::emitBytecode):
        (JSC::ObjectPatternNode::bindValue):
        * tests/stress/element-property-get-should-not-handled-with-get-by-id.js: Added.
        (getOne):

2015-12-13  Andreas Kling  <akling@apple.com>

        CachedScript could have a copy-free path for all-ASCII scripts.
        <https://webkit.org/b/152203>

        Reviewed by Antti Koivisto.

        Make SourceProvider vend a StringView instead of a String.
        This relaxes the promises that providers have to make about string lifetimes.

        This means that on the WebCore side, CachedScript is free to cache a String
        internally, while only ever exposing it as a temporary StringView.

        A few extra copies (CPU, not memory) are introduced, none of them on hot paths.

        * API/JSScriptRef.cpp:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::sourceCodeForTools):
        (JSC::CodeBlock::dumpSource):
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::dispatchDidParseSource):
        (Inspector::ScriptDebugServer::dispatchFailedToParseSource):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * jsc.cpp:
        (functionFindTypeForExpression):
        (functionHasBasicBlockExecuted):
        (functionBasicBlockExecutionCount):
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::setCode):
        * parser/Lexer.h:
        (JSC::Lexer<LChar>::setCodeStart):
        (JSC::Lexer<UChar>::setCodeStart):
        * parser/Parser.h:
        (JSC::Parser::getToken):
        * parser/SourceCode.cpp:
        (JSC::SourceCode::toUTF8):
        * parser/SourceCode.h:
        (JSC::SourceCode::hash):
        (JSC::SourceCode::view):
        (JSC::SourceCode::toString): Deleted.
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::string):
        * parser/SourceProvider.h:
        (JSC::SourceProvider::getRange):
        * runtime/Completion.cpp:
        (JSC::loadAndEvaluateModule):
        (JSC::loadModule):
        * runtime/ErrorInstance.cpp:
        (JSC::appendSourceToError):
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):
        * tools/FunctionOverrides.cpp:
        (JSC::initializeOverrideInfo):
        (JSC::FunctionOverrides::initializeOverrideFor):

2015-12-12  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Add lowering for B3's Store8 opcode
        https://bugs.webkit.org/show_bug.cgi?id=152208

        Reviewed by Geoffrey Garen.

        B3 has an opcode to store 8bit values but it had
        no lowering.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createStore):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testStore8Arg):
        (JSC::B3::testStore8Imm):
        (JSC::B3::testStorePartial8BitRegisterOnX86):
        (JSC::B3::run):

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

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

        Reviewed by Mark Lam.

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

2015-12-11  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Too many derefs when RemoteInspectorXPCConnection fails to validate connection
        https://bugs.webkit.org/show_bug.cgi?id=152213

        Rubber-stamped by Ryosuke Niwa.

        * inspector/remote/RemoteInspectorXPCConnection.mm:
        (Inspector::RemoteInspectorXPCConnection::handleEvent):
        We should just close the XPC connection triggering XPC_ERROR_CONNECTION_INVALID
        which will then graceful teardown the connection as expected.

2015-12-11  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add Floating Point Abs() to B3
        https://bugs.webkit.org/show_bug.cgi?id=152176

        Reviewed by Geoffrey Garen.

        This patch adds an Abs() operation for floating point.

        On x86, Abs() is implemented by masking the top bit
        of the floating point value. On ARM64, there is a builtin
        abs opcode.

        To account for those differences, B3 use "Abs" as
        the cannonical operation. When we are about to lower
        to Air, Abs is extended on x86 to get a clean handling
        of the mask constants.

        This patch has one cool thing related to FTL.
        If you do:
           @1 = unboxDouble(@0)
           @2 = abs(@1)
           @3 = boxDouble(@2)

        B3ReduceStrength completely eliminate the Double-Integer
        conversion.

        The strength reduction of Abs is aware that it can do a bit
        mask over the bitcast used by unboxing.
        If even works if you use floats by forcing fround: reduceDoubleToFloat()
        elminiates the useless conversions, followed by ReduceStrength
        that removes the switch from GP to FP.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::andDouble):
        (JSC::MacroAssemblerX86Common::andFloat):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::andps_rr):
        * b3/B3ConstDoubleValue.cpp:
        (JSC::B3::ConstDoubleValue::bitAndConstant):
        (JSC::B3::ConstDoubleValue::absConstant):
        * b3/B3ConstDoubleValue.h:
        * b3/B3ConstFloatValue.cpp:
        (JSC::B3::ConstFloatValue::bitAndConstant):
        (JSC::B3::ConstFloatValue::absConstant):
        * b3/B3ConstFloatValue.h:
        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir):
        * b3/B3LowerMacrosAfterOptimizations.cpp: Added.
        (JSC::B3::lowerMacrosAfterOptimizations):
        * b3/B3LowerMacrosAfterOptimizations.h: Added.
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3ReduceDoubleToFloat.cpp:
        * b3/B3ReduceStrength.cpp:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::absConstant):
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::bitAndDouble):
        (JSC::B3::testBitAndArgDouble):
        (JSC::B3::testBitAndArgsDouble):
        (JSC::B3::testBitAndArgImmDouble):
        (JSC::B3::testBitAndImmsDouble):
        (JSC::B3::bitAndFloat):
        (JSC::B3::testBitAndArgFloat):
        (JSC::B3::testBitAndArgsFloat):
        (JSC::B3::testBitAndArgImmFloat):
        (JSC::B3::testBitAndImmsFloat):
        (JSC::B3::testBitAndArgsFloatWithUselessDoubleConversion):
        (JSC::B3::testAbsArg):
        (JSC::B3::testAbsImm):
        (JSC::B3::testAbsMem):
        (JSC::B3::testAbsAbsArg):
        (JSC::B3::testAbsBitwiseCastArg):
        (JSC::B3::testBitwiseCastAbsBitwiseCastArg):
        (JSC::B3::testAbsArgWithUselessDoubleConversion):
        (JSC::B3::testAbsArgWithEffectfulDoubleConversion):
        (JSC::B3::run):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::doubleAbs):

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

        Removed some dead code, and simplified some code in the baseline JIT.
        https://bugs.webkit.org/show_bug.cgi?id=152199

        Reviewed by Benjamin Poulain.

        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitBitBinaryOpFastPath):
        (JSC::JIT::emit_op_bitand):
        (JSC::JIT::emitSlow_op_lshift):
        (JSC::JIT::emitRightShiftFastPath):
        (JSC::JIT::emit_op_rshift):
        (JSC::JIT::emitSlow_op_rshift):
        (JSC::JIT::emit_op_urshift):
        (JSC::JIT::emitSlow_op_urshift):

2015-12-11  Filip Pizlo  <fpizlo@apple.com>

        B3::reduceStrength should remove redundant Phi's
        https://bugs.webkit.org/show_bug.cgi?id=152184

        Reviewed by Benjamin Poulain.

        This adds redundant Phi removal using Aycock and Horspools SSA simplification algorithm. This
        is needed because even in simple asm.js code, we see a lot of CFG simplification that leaves
        behind totally useless Phi's.

        * b3/B3PhiChildren.cpp:
        (JSC::B3::PhiChildren::PhiChildren):
        * b3/B3PhiChildren.h:
        (JSC::B3::PhiChildren::at):
        (JSC::B3::PhiChildren::operator[]):
        (JSC::B3::PhiChildren::phis):
        * b3/B3ReduceStrength.cpp:

2015-12-11  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Add an implementation of pow() taking an integer exponent to B3
        https://bugs.webkit.org/show_bug.cgi?id=152165

        Reviewed by Mark Lam.

        LLVM has this really neat optimized opcode for
        raising the power of something by an integer exponent.

        There is no such native instruction so we need to extend
        the existing FTLOutput API to something efficient.

        DFG has a pretty competitive implementation. In this patch,
        I added a version of it to B3.
        I created powDoubleInt32() instead of putting the code directly
        in FTL for easier testing and optimization.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3MathExtras.cpp: Added.
        (JSC::B3::powDoubleInt32):
        * b3/B3MathExtras.h: Added.
        * b3/B3MemoryValue.h:
        * b3/testb3.cpp:
        (JSC::B3::testPowDoubleByIntegerLoop):
        (JSC::B3::run):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::compileArithPowIntegerFastPath):
        * ftl/FTLB3Output.cpp:
        (JSC::FTL::Output::doublePowi):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::doublePowi): Deleted.

2015-12-11  Filip Pizlo  <fpizlo@apple.com>

        B3 should have CSE
        https://bugs.webkit.org/show_bug.cgi?id=150961

        Reviewed by Benjamin Poulain.

        This implements a very simple CSE for pure values. I need this as a prerequisite for other
        optimizations that I'm implementing. For now, this is neutral on imaging-gaussian-blur but a
        slow-down on asm.js code. I suspect that the asm.js slow-down is because of other things that are
        still going wrong, and anyway, I need CSE to be able to do even the most basic asm.js strength
        reductions.

        * b3/B3ReduceStrength.cpp:
        * b3/B3ReduceStrength.h:
        * b3/B3Value.cpp:
        (JSC::B3::Value::replaceWithIdentity):
        (JSC::B3::Value::key):

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

        Refactoring to reduce potential cut-paste errors with the FTL ICs.
        https://bugs.webkit.org/show_bug.cgi?id=152185

        Reviewed by Saam Barati.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:

        * ftl/FTLCompile.cpp:
        - ICs now have their own names.  GetById and PutByID fast path ICs no longer just
          say "inline cache fast path".

        * ftl/FTLCompileBinaryOp.cpp:
        (JSC::FTL::generateBinaryArithOpFastPath):
        - Fixed an indentation.

        * ftl/FTLInlineCacheDescriptor.h:
        (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
        (JSC::FTL::InlineCacheDescriptor::name):
        (JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
        (JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
        (JSC::FTL::CheckInDescriptor::CheckInDescriptor):
        (JSC::FTL::BinaryOpDescriptor::nodeType):
        (JSC::FTL::BinaryOpDescriptor::size):
        (JSC::FTL::BinaryOpDescriptor::slowPathFunction):
        (JSC::FTL::BinaryOpDescriptor::leftOperand):
        (JSC::FTL::BinaryOpDescriptor::BinaryOpDescriptor):
        (JSC::FTL::ArithDivDescriptor::ArithDivDescriptor):
        (JSC::FTL::ArithDivDescriptor::icSize):
        (JSC::FTL::ArithDivDescriptor::nodeType):
        (JSC::FTL::ArithDivDescriptor::opName):
        (JSC::FTL::ArithDivDescriptor::slowPathFunction):
        (JSC::FTL::ArithDivDescriptor::nonNumberSlowPathFunction):
        (JSC::FTL::ArithMulDescriptor::ArithMulDescriptor):
        (JSC::FTL::ArithMulDescriptor::icSize):
        (JSC::FTL::ArithMulDescriptor::nodeType):
        (JSC::FTL::ArithMulDescriptor::opName):
        (JSC::FTL::ArithMulDescriptor::slowPathFunction):
        (JSC::FTL::ArithMulDescriptor::nonNumberSlowPathFunction):
        (JSC::FTL::ArithSubDescriptor::ArithSubDescriptor):
        (JSC::FTL::ArithSubDescriptor::icSize):
        (JSC::FTL::ArithSubDescriptor::nodeType):
        (JSC::FTL::ArithSubDescriptor::opName):
        (JSC::FTL::ArithSubDescriptor::slowPathFunction):
        (JSC::FTL::ArithSubDescriptor::nonNumberSlowPathFunction):
        (JSC::FTL::ValueAddDescriptor::ValueAddDescriptor):
        (JSC::FTL::ValueAddDescriptor::icSize):
        (JSC::FTL::ValueAddDescriptor::nodeType):
        (JSC::FTL::ValueAddDescriptor::opName):
        (JSC::FTL::ValueAddDescriptor::slowPathFunction):
        (JSC::FTL::ValueAddDescriptor::nonNumberSlowPathFunction):
        (JSC::FTL::LazySlowPathDescriptor::LazySlowPathDescriptor):
        (JSC::FTL::ProbeDescriptor::ProbeDescriptor):
        (JSC::FTL::BinaryOpDescriptor::name): Deleted.
        (JSC::FTL::BinaryOpDescriptor::fastPathICName): Deleted.
        * ftl/FTLInlineCacheDescriptorInlines.h: Removed.
        - Consolidate the number of places where we have to fill in a data about new
          snippet ICs.  It is all done in FTLInlineCacheDescriptor.h now.   

        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileUntypedBinaryOp):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithDiv):
        - Introduced a compileUntypedBinaryOp() template and use that at all the FTL
          places that need to use a snippet.  This reduces the amount of cut and paste
          code.

        * ftl/FTLState.h:
        - Removed a bad #include.

2015-12-11  Keith Miller  <keith_miller@apple.com>

        Overrides has instance should not move ValueFalse to a register then immediately to the stack in the LLInt.
        https://bugs.webkit.org/show_bug.cgi?id=152188

        Reviewed by Mark Lam.

        This fixes a minor issue with the code for the overrides_has_instance in the LLInt. Old code had an extra move,
        which is both slow and breaks the build on cloop.

        * llint/LowLevelInterpreter64.asm:

2015-12-11  Keith Miller  <keith_miller@apple.com>

        [ES6] Add support for Symbol.hasInstance
        https://bugs.webkit.org/show_bug.cgi?id=151839

        Reviewed by Saam Barati.

        This patch adds support for Symbol.hasInstance, unfortunately in order to prevent
        regressions several new bytecodes and DFG IR nodes were necessary. Before, Symbol.hasInstance
        when executing an instanceof expression we would emit three bytecodes: overrides_has_instance, get_by_id,
        then instanceof. As the spec has changed, we emit a more complicated set of bytecodes in addition to some
        new ones. First the role of overrides_has_instance and its corresponding DFG node have changed. Now it returns
        a js-boolean indicating whether the RHS of the instanceof expression (from here on called the constructor for simplicity)
        needs non-default behavior for resolving the expression. i.e. The constructor has a Symbol.hasInstance that differs from the one on
        Function.prototype[Symbol.hasInstance] or is a bound/C-API function. Once we get to the DFG this node is generally eliminated as
        we can prove the value of Symbol.hasInstance is a constant. The second new bytecode is instanceof_custom. insntanceof_custom, just
        emits a call to slow path code that computes the result.

        In the DFG, there is also a new node, CheckTypeInfoFlags, which checks the type info flags are consistent with the ones provided and
        OSR exits if the flags are not. Additionally, we attempt to prove that the result of CheckHasValue will be a constant and transform
        it into a CheckTypeInfoFlags followed by a JSConstant.

        * API/JSCallbackObject.h:
        * builtins/FunctionPrototype.js:
        (symbolHasInstance):
        * bytecode/BytecodeBasicBlock.cpp:
        (JSC::isBranch): Deleted.
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/ExitKind.cpp:
        (JSC::exitKindToString):
        * bytecode/ExitKind.h:
        * bytecode/PreciseJumpTargets.cpp:
        (JSC::getJumpTargetsForBytecodeOffset): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitOverridesHasInstance):
        (JSC::BytecodeGenerator::emitInstanceOfCustom):
        (JSC::BytecodeGenerator::emitCheckHasInstance): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::InstanceOfNode::emitBytecode):
        * 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/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasCellOperand):
        (JSC::DFG::Node::hasTypeInfoOperand):
        (JSC::DFG::Node::typeInfoOperand):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCheckTypeInfoFlags):
        (JSC::DFG::SpeculativeJIT::compileInstanceOfCustom):
        * dfg/DFGSpeculativeJIT.h:
        (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::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileOverridesHasInstance):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckTypeInfoFlags):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInstanceOfCustom):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckHasInstance): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_overrides_has_instance):
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emit_op_instanceof_custom):
        (JSC::JIT::emitSlow_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof_custom):
        (JSC::JIT::emit_op_check_has_instance): Deleted.
        (JSC::JIT::emitSlow_op_check_has_instance): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_overrides_has_instance):
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emit_op_instanceof_custom):
        (JSC::JIT::emitSlow_op_instanceof_custom):
        (JSC::JIT::emit_op_check_has_instance): Deleted.
        (JSC::JIT::emitSlow_op_check_has_instance): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonIdentifiers.h:
        * runtime/ExceptionHelpers.cpp:
        (JSC::invalidParameterInstanceofSourceAppender):
        (JSC::invalidParameterInstanceofNotFunctionSourceAppender):
        (JSC::invalidParameterInstanceofhasInstanceValueNotFunctionSourceAppender):
        (JSC::createInvalidInstanceofParameterErrorNotFunction):
        (JSC::createInvalidInstanceofParameterErrorhasInstanceValueNotFunction):
        (JSC::createInvalidInstanceofParameterError): Deleted.
        * runtime/ExceptionHelpers.h:
        * runtime/FunctionPrototype.cpp:
        (JSC::FunctionPrototype::addFunctionProperties):
        * runtime/FunctionPrototype.h:
        * runtime/JSBoundFunction.cpp:
        (JSC::isBoundFunction):
        (JSC::hasInstanceBoundFunction):
        * runtime/JSBoundFunction.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::functionProtoHasInstanceSymbolFunction):
        * runtime/JSObject.cpp:
        (JSC::JSObject::hasInstance):
        (JSC::objectPrivateFuncInstanceOf):
        * runtime/JSObject.h:
        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::TypeInfo):
        (JSC::TypeInfo::overridesHasInstance):
        * runtime/WriteBarrier.h:
        (JSC::WriteBarrierBase<Unknown>::slot):
        * tests/es6.yaml:
        * tests/stress/instanceof-custom-hasinstancesymbol.js: Added.
        (Constructor):
        (value):
        (instanceOf):
        (body):
        * tests/stress/symbol-hasInstance.js: Added.
        (Constructor):
        (value):
        (ObjectClass.Symbol.hasInstance):
        (NumberClass.Symbol.hasInstance):

2015-12-11  Joseph Pecoraro  <pecoraro@apple.com>

        check-for-inappropriate-objc-class-names should check all class names, not just externally visible ones
        https://bugs.webkit.org/show_bug.cgi?id=152156

        Reviewed by Dan Bernstein.

        * llvm/InitializeLLVMMac.cpp:
        Remove stale comment. The ObjC class this comment referenced
        has already been removed.

2015-12-11  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Little cleanup of FTLOutput type casts and conversions
        https://bugs.webkit.org/show_bug.cgi?id=152166

        Reviewed by Geoffrey Garen.

        Clean up:
        -Change fpCast() to explicit conversion doubleToFloat() and floatToDouble()
         to match B3's opcodes.
        -Remove unused conversion functions.
        -Use the most specific cast function when possible.
        -Functions that are only used inside FTLOutput are made private.
         In FTLB3Output, those functions were removed.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::doubleToFloat):
        (JSC::FTL::Output::floatToDouble):
        (JSC::FTL::Output::fround):
        (JSC::FTL::Output::fpToInt): Deleted.
        (JSC::FTL::Output::fpToUInt): Deleted.
        (JSC::FTL::Output::intToFP): Deleted.
        (JSC::FTL::Output::unsignedToFP): Deleted.
        (JSC::FTL::Output::intCast): Deleted.
        (JSC::FTL::Output::fpCast): Deleted.
        (JSC::FTL::Output::intToPtr): Deleted.
        (JSC::FTL::Output::ptrToInt): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutByVal):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::doubleToFloat):
        (JSC::FTL::Output::floatToDouble):
        (JSC::FTL::Output::intCast):
        (JSC::FTL::Output::fpToInt):
        (JSC::FTL::Output::fpToUInt):
        (JSC::FTL::Output::fpCast):
        (JSC::FTL::Output::intToFP):
        (JSC::FTL::Output::unsignedToFP):

2015-12-10  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        Binding and builtin generators should lowercase RTCXX as rtcXX and not rTCXX
        https://bugs.webkit.org/show_bug.cgi?id=152121

        Reviewed by Darin Adler.

        * Scripts/builtins/builtins_generator.py:
        (WK_lcfirst): Added RTC special rule.

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

        FTL B3 should be able to run quicksort asm.js test
        https://bugs.webkit.org/show_bug.cgi?id=152105

        Reviewed by Geoffrey Garen.

        This covers making all of the changes needed to run quicksort.js from AsmBench.

        - Reintroduced float types to FTLLower since we now have B3::Float.

        - Gave FTL::Output the ability to speak of load types and store types separately from LValue
          types. This dodges the problem that B3 doesn't have types for Int8 and Int16 but supports loads
          and stores of that type.

        - Implemented Mod in B3 and wrote tests.

        I also fixed a pre-existing bug in a test that appeared to only manifest in release builds.

        Currently, B3's performance on asm.js tests is not good. It should be easy to fix:

        - B3 should strength-reduce the shifting madness that happens in asm.js memory accesses
          https://bugs.webkit.org/show_bug.cgi?id=152106

        - B3 constant hoisting should have a story for the asm.js heap constant
          https://bugs.webkit.org/show_bug.cgi?id=152107

        * b3/B3CCallValue.h:
        * b3/B3Const32Value.cpp:
        (JSC::B3::Const32Value::divConstant):
        (JSC::B3::Const32Value::modConstant):
        (JSC::B3::Const32Value::bitAndConstant):
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.cpp:
        (JSC::B3::Const64Value::divConstant):
        (JSC::B3::Const64Value::modConstant):
        (JSC::B3::Const64Value::bitAndConstant):
        * b3/B3Const64Value.h:
        * b3/B3ReduceStrength.cpp:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::divConstant):
        (JSC::B3::Value::modConstant):
        (JSC::B3::Value::bitAndConstant):
        * b3/B3Value.h:
        * b3/testb3.cpp:
        (JSC::B3::testChillDiv64):
        (JSC::B3::testMod):
        (JSC::B3::testSwitch):
        (JSC::B3::run):
        * ftl/FTLB3Output.cpp:
        (JSC::FTL::Output::load16ZeroExt32):
        (JSC::FTL::Output::store):
        (JSC::FTL::Output::store32As8):
        (JSC::FTL::Output::store32As16):
        (JSC::FTL::Output::loadFloatToDouble): Deleted.
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::mul):
        (JSC::FTL::Output::div):
        (JSC::FTL::Output::chillDiv):
        (JSC::FTL::Output::rem):
        (JSC::FTL::Output::neg):
        (JSC::FTL::Output::load32):
        (JSC::FTL::Output::load64):
        (JSC::FTL::Output::loadPtr):
        (JSC::FTL::Output::loadFloat):
        (JSC::FTL::Output::loadDouble):
        (JSC::FTL::Output::store32):
        (JSC::FTL::Output::store64):
        (JSC::FTL::Output::storePtr):
        (JSC::FTL::Output::storeFloat):
        (JSC::FTL::Output::storeDouble):
        (JSC::FTL::Output::addPtr):
        (JSC::FTL::Output::extractValue):
        (JSC::FTL::Output::call):
        (JSC::FTL::Output::operation):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutByVal):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArrayPush):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArrayPop):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::Output):
        (JSC::FTL::Output::store):
        (JSC::FTL::Output::check):
        (JSC::FTL::Output::load):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::load32):
        (JSC::FTL::Output::load64):
        (JSC::FTL::Output::loadPtr):
        (JSC::FTL::Output::loadFloat):
        (JSC::FTL::Output::loadDouble):
        (JSC::FTL::Output::store32As8):
        (JSC::FTL::Output::store32As16):
        (JSC::FTL::Output::store32):
        (JSC::FTL::Output::store64):
        (JSC::FTL::Output::storePtr):
        (JSC::FTL::Output::storeFloat):
        (JSC::FTL::Output::storeDouble):
        (JSC::FTL::Output::addPtr):
        (JSC::FTL::Output::loadFloatToDouble): Deleted.
        (JSC::FTL::Output::store16): Deleted.

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

        Consider still matching an address expression even if B3 has already assigned a Tmp to it
        https://bugs.webkit.org/show_bug.cgi?id=150777

        Reviewed by Geoffrey Garen.

        We need some heuristic for when an address should be computed as a separate instruction. It's
        usually profitable to sink the address into the memory access. The previous heuristic meant that
        the address would get separate instructions if it was in a separate block from the memory access.
        This was messing up codegen of things like PutByVal out-of-bounds, where the address is computed
        in one block and then used in another. I don't think that which block owns the address
        computation should factor into any heuristic here, since it's so fragile: the compiler may lower
        something by splitting blocks and we don't want this to ruin performance.

        So, this replaces that heuristic with a more sensible one: the address computation gets its own
        instruction if it has a lot of uses. In practice this means that we always sink the address
        computation into the memory access.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::effectiveAddr):

2015-12-10  Daniel Bates  <dabates@apple.com>

        [CSP] eval() is not blocked for stringified literals
        https://bugs.webkit.org/show_bug.cgi?id=152158
        <rdar://problem/15775625>

        Reviewed by Saam Barati.

        Fixes an issue where stringified literals can be eval()ed despite being disallowed by
        Content Security Policy of the page.

        * interpreter/Interpreter.cpp:
        (JSC::eval): Throw a JavaScript EvalError exception if eval() is disallowed for the page
        and return undefined.
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval): Ditto.

2015-12-10  Joseph Pecoraro  <pecoraro@apple.com>

        Fix jsc symlink creation on iOS
        https://bugs.webkit.org/show_bug.cgi?id=152155

        Reviewed by Dan Bernstein.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        Switch from INSTALL_PATH_ACTUAL to just INSTALL_PATH.
        Remove now unnecessary INSTALL_PATH_PREFIX use as well.

2015-12-10  Joseph Pecoraro  <pecoraro@apple.com>

        Remote Inspector: Verify the identity of the other side of XPC connections
        https://bugs.webkit.org/show_bug.cgi?id=152153

        Reviewed by Brian Burg.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        Link with the Security framework.

        * inspector/remote/RemoteInspectorXPCConnection.h:
        * inspector/remote/RemoteInspectorXPCConnection.mm:
        (auditTokenHasEntitlement):
        (Inspector::RemoteInspectorXPCConnection::handleEvent):
        (Inspector::RemoteInspectorXPCConnection::RemoteInspectorXPCConnection): Deleted.
        When receiving the first message, verify the XPC connection
        is connected to who we thought we were connected to and
        Bail if it isn't.

2015-12-10  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add a Modulo operator to B3, and a chill variant
        https://bugs.webkit.org/show_bug.cgi?id=152110

        Reviewed by Geoffrey Garen.

        It is basically refactoring the Div and ChillDiv
        code to be used by both opcodes.

        * b3/B3Common.h:
        (JSC::B3::chillDiv):
        (JSC::B3::chillMod):
        * b3/B3Const32Value.cpp:
        (JSC::B3::Const32Value::modConstant):
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.cpp:
        (JSC::B3::Const64Value::modConstant):
        * b3/B3Const64Value.h:
        * b3/B3ConstDoubleValue.cpp:
        (JSC::B3::ConstDoubleValue::modConstant):
        * b3/B3ConstDoubleValue.h:
        * b3/B3LowerMacros.cpp:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        (JSC::B3::Air::LowerToAir::lowerX86Div):
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3ReduceStrength.cpp:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::modConstant):
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h:
        * b3/testb3.cpp:
        (JSC::B3::testModArgDouble):
        (JSC::B3::testModArgsDouble):
        (JSC::B3::testModArgImmDouble):
        (JSC::B3::testModImmArgDouble):
        (JSC::B3::testModImmsDouble):
        (JSC::B3::testModArgFloat):
        (JSC::B3::testModArgsFloat):
        (JSC::B3::testModArgImmFloat):
        (JSC::B3::testModImmArgFloat):
        (JSC::B3::testModImmsFloat):
        (JSC::B3::testModArg):
        (JSC::B3::testModArgs):
        (JSC::B3::testModImms):
        (JSC::B3::testModArg32):
        (JSC::B3::testModArgs32):
        (JSC::B3::testModImms32):
        (JSC::B3::testChillModArg):
        (JSC::B3::testChillModArgs):
        (JSC::B3::testChillModImms):
        (JSC::B3::testChillModArg32):
        (JSC::B3::testChillModArgs32):
        (JSC::B3::testChillModImms32):
        (JSC::B3::run):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::mod):
        (JSC::FTL::Output::chillMod):
        (JSC::FTL::Output::doubleMod):
        (JSC::FTL::Output::rem): Deleted.
        (JSC::FTL::Output::doubleRem): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithMod):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::chillMod):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::mod):
        (JSC::FTL::Output::doubleMod):
        (JSC::FTL::Output::rem): Deleted.
        (JSC::FTL::Output::doubleRem): Deleted.

2015-12-10  Csaba Osztrogonác  <ossy@webkit.org>

        [B3] Add new files to the cmake build system
        https://bugs.webkit.org/show_bug.cgi?id=152120

        Reviewed by Filip Pizlo.

        * CMakeLists.txt:

2015-12-10  Csaba Osztrogonác  <ossy@webkit.org>

        [B3] Use mark pragmas only if it is supported
        https://bugs.webkit.org/show_bug.cgi?id=152123

        Reviewed by Mark Lam.

        * ftl/FTLB3Output.h:

2015-12-10  Csaba Osztrogonác  <ossy@webkit.org>

        [B3] Typo fix in testb3.cpp
        https://bugs.webkit.org/show_bug.cgi?id=152126

        Reviewed by Mark Lam.

        * b3/testb3.cpp:
        (JSC::B3::populateWithInterestingValues):

2015-12-10  Csaba Osztrogonác  <ossy@webkit.org>

        [B3] Fix unused-but-set-variable warning
        https://bugs.webkit.org/show_bug.cgi?id=152122

        Reviewed by Mark Lam.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):

2015-12-10  Csaba Osztrogonác  <ossy@webkit.org>

        [B3] Make GCC ignore warnings in FTLB3Output.h
        https://bugs.webkit.org/show_bug.cgi?id=152124

        Reviewed by Mark Lam.

        * ftl/FTLB3Output.h:

2015-12-10  Csaba Osztrogonác  <ossy@webkit.org>

        [EFL] Remove the unused IncrementalSweeper::m_isTimerFrozen member after r193749
        https://bugs.webkit.org/show_bug.cgi?id=152127

        Reviewed by Mark Lam.

        * heap/IncrementalSweeper.h:

2015-12-10  Csaba Osztrogonác  <ossy@webkit.org>

        Source/JavaScriptCore/create_hash_table shouldn't be too verbose
        https://bugs.webkit.org/show_bug.cgi?id=151861

        Reviewed by Darin Adler.

        * create_hash_table:

2015-12-10  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        JSC Builtins should use safe array methods
        https://bugs.webkit.org/show_bug.cgi?id=151501

        Reviewed by Darin Adler.

        Adding @push and @shift to Array prototype.
        Using @push in TypedArray built-in.

        Covered by added test in LayoutTests/js/builtins

        * builtins/TypedArray.prototype.js:
        (filter):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        * runtime/CommonIdentifiers.h:

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

        FTL B3 should have basic GetById support
        https://bugs.webkit.org/show_bug.cgi?id=152035

        Reviewed by Saam Barati.

        Adds basic GetById support. This was so easy to do. Unlike the LLVM code for this, the B3 code is
        entirely self-contained within the getById() method in LowerDFG.

        I discovered that we weren't folding Check(NotEqual(x, 0)) to Check(x). This was preventing us
        from generating good code for Check(NotEqual(BitAnd(x, tagMask), 0)), since the BitAnd was
        concealed. This was an easy strength reduction rule to add.

        Finally, I found it easier to say append(value, rep) than append(ConstrainedValue(value, rep)), so
        I added that API. The old ConstrainedValue form is still super useful in other places, like
        compileCallOrConstruct(), where the two-argument form would be awkward. It's great to have both
        APIs to pick from.

        * b3/B3ReduceStrength.cpp:
        * b3/B3StackmapValue.cpp:
        (JSC::B3::StackmapValue::~StackmapValue):
        (JSC::B3::StackmapValue::append):
        * b3/B3StackmapValue.h:
        * dfg/DFGCommon.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::getById):

2015-12-09  Saam barati  <sbarati@apple.com>

        Update generators' features.json to indicate that we have a spec compliant implementation
        https://bugs.webkit.org/show_bug.cgi?id=152085

        Reviewed by Joseph Pecoraro.

        * features.json:

2015-12-09  Saam barati  <sbarati@apple.com>

        Update features.json w.r.t tail calls
        https://bugs.webkit.org/show_bug.cgi?id=152072

        Reviewed by Michael Saboff.

        * features.json:

2015-12-09  Saam barati  <sbarati@apple.com>

        we should emit op_watchdog after op_enter
        https://bugs.webkit.org/show_bug.cgi?id=151972

        Reviewed by Mark Lam.

        This also solves the issue of watchdog not being
        observed when we loop purely through tail calls.

        * API/tests/ExecutionTimeLimitTest.cpp:
        (testExecutionTimeLimit):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitProfiledOpcode):
        (JSC::BytecodeGenerator::emitEnter):
        (JSC::BytecodeGenerator::emitLoopHint):
        * bytecompiler/BytecodeGenerator.h:

2015-12-08  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Improve how B3 lowers Add() and Sub() on x86
        https://bugs.webkit.org/show_bug.cgi?id=152026

        Reviewed by Geoffrey Garen.

        The assembler was missing some important x86 forms of
        ADD and SUB that were making our lowering
        unfriendly with register allocation.

        First, we were missing a 3 operand version of Add
        implement with LEA. As a result, an Add would
        be lowered as:
            Move op1->srcDest
            Add op2, srcDest
        The problem with such code is that op2 and srcDest
        interferes. It is impossible to assign them the same
        machine register.

        With the new Add form, we have:
            Add op1, op2, dest
        without interferences between any of those values.
        The add is implement by a LEA without scaling or displacement.

        This patch also adds missing forms of Add and Sub with
        direct addressing for arguments. This avoids dealing with Tmps
        that only exist for those operations.

        Finally, the lowering of adding something to itself was updated accordingly.
        Such operation is transformed in Shl by 2. The lowering of Shl
        was adding an explicit Move, preventing the use of LEA when it
        is useful.
        Instead of having an explicit move, I changed the direct addressing
        forms to only be selected if the two operands are different.
        A Move is then added by appendBinOp() if needed.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::add32):
        (JSC::MacroAssemblerX86Common::x86Lea32):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::add64):
        (JSC::MacroAssemblerX86_64::x86Lea64):
        (JSC::MacroAssemblerX86_64::sub64):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::addq_rm):
        (JSC::X86Assembler::subq_mr):
        (JSC::X86Assembler::subq_rm):
        (JSC::X86Assembler::subq_im):
        (JSC::X86Assembler::leal_mr):
        (JSC::X86Assembler::leaq_mr):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::appendBinOp):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testAddArgMem):
        (JSC::B3::testAddMemArg):
        (JSC::B3::testAddImmMem):
        (JSC::B3::testAddArg32):
        (JSC::B3::testAddArgMem32):
        (JSC::B3::testAddMemArg32):
        (JSC::B3::testAddImmMem32):
        (JSC::B3::testSubArgMem):
        (JSC::B3::testSubMemArg):
        (JSC::B3::testSubImmMem):
        (JSC::B3::testSubMemImm):
        (JSC::B3::testSubMemArg32):
        (JSC::B3::testSubArgMem32):
        (JSC::B3::testSubImmMem32):
        (JSC::B3::testSubMemImm32):
        (JSC::B3::run):

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

        Factoring out common DFG code for bitwise and shift operators.
        https://bugs.webkit.org/show_bug.cgi?id=152019

        Reviewed by Michael Saboff.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileBitwiseOp):
        (JSC::DFG::SpeculativeJIT::compileShiftOp):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

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

        DFG and FTL should be resilient against cases where both snippet operands are constant.
        https://bugs.webkit.org/show_bug.cgi?id=152017

        Reviewed by Michael Saboff.

        The DFG front end may not always constant fold cases where both operands are
        constant.  As a result, the DFG and FTL back ends needs to be resilient against
        this when using snippet generators since the generators do not support the case
        where both operands are constant.  The strategy for handling this 2 const operands
        case is to treat at least one of them as a variable if both are constant. 

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueAdd):
        - Also remove the case for folding 2 constant operands.  It is the front end's
          job to do so, not the back end here.

        (JSC::DFG::SpeculativeJIT::compileArithSub):
        (JSC::DFG::SpeculativeJIT::compileArithMul):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):

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

        Snippefy shift operators for the baseline JIT.
        https://bugs.webkit.org/show_bug.cgi?id=151875

        Reviewed by Geoffrey Garen.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/JIT.h:

        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitBitBinaryOpFastPath):
        - Don't need GPRInfo:: qualifiers.  Removed them to reduce verbosity.
        - Also removed the emitStoreInt32() case for storing the result on 32-bit ports.
          This is because:
          1. The client should not make assumptions about whether the snippet fast path
             only include cases where the result tag already contain the IntTag.
          2. The "(op1 == result || op2 == result)" condition for skipping the IntTag
             storage, is only valid for the bitand, bitor, and bitxor implementations.
             It is invalid for the lshift implementation that uses this code now.
          Instead, we'll always unconditionally store what the result tag that the
          snippet computed for us.

        (JSC::JIT::emit_op_lshift):
        (JSC::JIT::emitSlow_op_lshift):
        (JSC::JIT::emitRightShiftFastPath):
        (JSC::JIT::emit_op_rshift):
        (JSC::JIT::emitSlow_op_rshift):
        (JSC::JIT::emit_op_urshift):
        (JSC::JIT::emitSlow_op_urshift):

        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_op_lshift): Deleted.
        (JSC::JIT::emitSlow_op_lshift): Deleted.
        (JSC::JIT::emitRightShift): Deleted.
        (JSC::JIT::emitRightShiftSlowCase): Deleted.
        (JSC::JIT::emit_op_rshift): Deleted.
        (JSC::JIT::emitSlow_op_rshift): Deleted.
        (JSC::JIT::emit_op_urshift): Deleted.
        (JSC::JIT::emitSlow_op_urshift): Deleted.

        * jit/JITLeftShiftGenerator.cpp: Added.
        (JSC::JITLeftShiftGenerator::generateFastPath):
        * jit/JITLeftShiftGenerator.h: Added.
        (JSC::JITLeftShiftGenerator::JITLeftShiftGenerator):
        * jit/JITRightShiftGenerator.cpp: Added.
        (JSC::JITRightShiftGenerator::generateFastPath):
        * jit/JITRightShiftGenerator.h: Added.
        (JSC::JITRightShiftGenerator::JITRightShiftGenerator):

        * tests/stress/op_lshift.js:
        * tests/stress/op_rshift.js:
        * tests/stress/op_urshift.js:
        - Fixed some values and added others that are meaningful for testing shifts.

        * tests/stress/resources/binary-op-test.js:
        (stringifyIfNeeded):
        (generateBinaryTests):
        - Fixed the test generator to give unique names to all the generated test
          functions.  Without this, multiple tests may end up using the same global
          test function.  As a result, with enough test values to test, the function may
          get prematurely JITted, and the computed expected result which is supposed to
          be computed by the LLINT, may end up being computed by a JIT instead.

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

        Create a Sandbox SPI header
        https://bugs.webkit.org/show_bug.cgi?id=151981

        Reviewed by Andy Estes.

        * inspector/remote/RemoteInspector.mm:

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

        DFG::UnificationPhase should merge isProfitableToUnbox, since this may have been set in ByteCodeParser
        https://bugs.webkit.org/show_bug.cgi?id=152011
        rdar://problem/23777875

        Reviewed by Michael Saboff.

        Previously UnificationPhase did not merge this because we used to only set this in FixupPhase, which runs after unification. But now
        ByteCodeParser may set isProfitableToUnbox as part of how it handles the ArgumentCount of an inlined varargs call, so UnificationPhase
        needs to merge it after unifying.

        Also changed the order of unification since this makes the bug more obvious and easier to test.

        * dfg/DFGUnificationPhase.cpp:
        (JSC::DFG::UnificationPhase::run):
        * tests/stress/varargs-with-unused-count.js: Added.

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

        Polymorphic operand types for DFG and FTL div.
        https://bugs.webkit.org/show_bug.cgi?id=151747

        Reviewed by Geoffrey Garen.

        Perf on benchmarks is neutral.  The new JSRegress ftl-object-div test shows
        a speed up not from the div operator itself, but from the fact that the
        polymorphic operand types support now allow the test function to run without OSR
        exiting, thereby realizing the DFG and FTL's speed up on other work that the test
        function does.

        This patch has passed the layout tests on x86_64 with a debug build.
        It passed the JSC tests with x86 and x86_64 debug builds.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):

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

        * ftl/FTLCompileBinaryOp.cpp:
        (JSC::FTL::generateBinaryArithOpFastPath):
        (JSC::FTL::generateBinaryOpFastPath):

        * ftl/FTLInlineCacheDescriptor.h:
        * ftl/FTLInlineCacheDescriptorInlines.h:
        (JSC::FTL::ArithDivDescriptor::ArithDivDescriptor):
        (JSC::FTL::ArithDivDescriptor::icSize):

        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfArithDiv):
        * ftl/FTLInlineCacheSize.h:

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
        - Fixed a cut-paste bug where the op_mul IC was using the op_sub IC size.
          This bug is benign because the op_sub IC size turns out to be larger
          than op_mul needs.
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithDiv):

        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_div):
        - Fixed a bug where the scratchFPR was not allocated for the 64bit port.
          This bug is benign because the scratchFPR is only needed if we are
          using scratchGPR register (used for branchConvertDoubleToInt32()) is
          >= X86Registers::r8.  Since we're always using regT2 for the scratchT2,
          the scratchFPR is never needed.   However, we should fix this anyway to
          be correct.

        * tests/stress/op_div.js:
        - Fixed some test values.

2015-12-05 Aleksandr Skachkov   <gskachkov@gmail.com>

        [ES6] "super" and "this" should be lexically bound inside an arrow function and should live in a JSLexicalEnvironment
        https://bugs.webkit.org/show_bug.cgi?id=149338

        Reviewed by Saam Barati.

        Implemented new version of the lexically bound 'this' in arrow function. In current version 
        'this' is stored inside of the lexical environment of the function. To store and load we use
        op_get_from_scope and op_put_to_scope operations. Also new implementation prevent raising TDZ
        error for arrow functions that are declared before super() but invoke after.

        * builtins/BuiltinExecutables.cpp:
        (JSC::createExecutableInternal):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::getSlow):
        * bytecode/ExecutableInfo.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::isDerivedConstructorContext):
        (JSC::ExecutableInfo::isArrowFunctionContext):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::isArrowFunction):
        (JSC::UnlinkedCodeBlock::isDerivedConstructorContext):
        (JSC::UnlinkedCodeBlock::isArrowFunctionContext):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::variable):
        (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
        (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadThisFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::isDerivedConstructorContext):
        (JSC::BytecodeGenerator::usesArrowFunction):
        (JSC::BytecodeGenerator::needsToUpdateArrowFunctionContext):
        (JSC::BytecodeGenerator::usesEval):
        (JSC::BytecodeGenerator::usesThis):
        (JSC::BytecodeGenerator::newTarget):
        (JSC::BytecodeGenerator::makeFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode):
        (JSC::SuperNode::emitBytecode):
        (JSC::EvalFunctionCallNode::emitBytecode):
        (JSC::FunctionCallValueNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluate):
        * dfg/DFGAbstractInterpreterInlines.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        * dfg/DFGClobberize.h:
        * dfg/DFGDoesGC.cpp:
        * dfg/DFGFixupPhase.cpp:
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGPromotedHeapLocation.cpp:
        * dfg/DFGPromotedHeapLocation.h:
        * dfg/DFGSafeToExecute.h:
        * dfg/DFGSpeculativeJIT.cpp:
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        * dfg/DFGSpeculativeJIT64.cpp:
        * ftl/FTLCapabilities.cpp:
        * ftl/FTLLowerDFGToLLVM.cpp:
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * jit/JIT.cpp:
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitNewFuncExprCommon):
        * jit/JITOpcodes32_64.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createArrowFunctionExpr):
        (JSC::ASTBuilder::usesArrowFunction):
        * parser/Nodes.h:
        (JSC::ScopeNode::usesArrowFunction):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/ParserModes.h:
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::ScriptExecutable):
        (JSC::EvalExecutable::create):
        (JSC::EvalExecutable::EvalExecutable):
        (JSC::ProgramExecutable::ProgramExecutable):
        (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
        (JSC::FunctionExecutable::FunctionExecutable):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::isArrowFunctionContext):
        (JSC::ScriptExecutable::isDerivedConstructorContext):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createEvalCodeBlock):
        * runtime/JSGlobalObject.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
        * tests/es6.yaml:
        * tests/stress/arrowfunction-activation-sink-osrexit.js:
        * tests/stress/arrowfunction-activation-sink.js:
        * tests/stress/arrowfunction-lexical-bind-newtarget.js: Added.
        * tests/stress/arrowfunction-lexical-bind-supercall-1.js: Added.
        * tests/stress/arrowfunction-lexical-bind-supercall-2.js: Added.
        * tests/stress/arrowfunction-lexical-bind-supercall-3.js: Added.
        * tests/stress/arrowfunction-lexical-bind-supercall-4.js: Added.
        * tests/stress/arrowfunction-lexical-bind-this-1.js:
        * tests/stress/arrowfunction-lexical-bind-this-7.js: Added.
        * tests/stress/arrowfunction-tdz-1.js: Added.
        * tests/stress/arrowfunction-tdz-2.js: Added.
        * tests/stress/arrowfunction-tdz-3.js: Added.
        * tests/stress/arrowfunction-tdz-4.js: Added.
        * tests/stress/arrowfunction-tdz.js: Removed.

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

        Fix the !ENABLE(DFG_JIT) build after r193649
        https://bugs.webkit.org/show_bug.cgi?id=151985

        Reviewed by Saam Barati.

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitSlow_op_loop_hint):

2015-12-08  Alberto Garcia  <berto@igalia.com>

        Unreviewed. Remove unnecessary check for 0 in commitSize().

        Change suggested by Darin Adler in bug #130237.

        * interpreter/JSStack.cpp:
        (JSC::commitSize):

2015-12-08  Ryuan Choi  <ryuan.choi@navercorp.com>

        [EFL] Remove the flag to check timer state in IncrementalSweeper
        https://bugs.webkit.org/show_bug.cgi?id=151988

        Reviewed by Gyuyoung Kim.

        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::scheduleTimer):
        (JSC::IncrementalSweeper::IncrementalSweeper):
        (JSC::IncrementalSweeper::cancelTimer):

2015-12-08  Philippe Normand  <pnormand@igalia.com>

        [Mac][GTK] Fix JSC FTL build
        https://bugs.webkit.org/show_bug.cgi?id=151915

        Reviewed by Csaba Osztrogonác.

        * CMakeLists.txt: Don't pass version-script option to ld on Darwin because this platform's linker
        doesn't support this option.

2015-12-08  Alberto Garcia  <berto@igalia.com>

        Unreviewed. Use pageSize() instead of getpagesize() after r193648

        * interpreter/JSStack.cpp:
        (JSC::commitSize):

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

        Small style fixes in B3MoveConstants.cpp
        https://bugs.webkit.org/show_bug.cgi?id=151980

        Reviewed by Benjamin Poulain.

        * b3/B3MoveConstants.cpp:

2015-12-07  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] On x86, we should XOR registers instead of moving a zero immediate
        https://bugs.webkit.org/show_bug.cgi?id=151977

        Reviewed by Filip Pizlo.

        It is smaller and the frontend has special support
        for xor.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::move):
        (JSC::MacroAssemblerX86Common::signExtend32ToPtr):

2015-12-07  Benjamin Poulain  <bpoulain@apple.com>

        Fix a typo from r193683

        * ftl/FTLCommonValues.cpp:
        (JSC::FTL::CommonValues::CommonValues):

2015-12-07  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add Float support to B3
        https://bugs.webkit.org/show_bug.cgi?id=151974

        Reviewed by Filip Pizlo.

        This patch adds comprehensive float support to B3.

        The new phase reduceDoubleToFloat() gives us a primitive
        version of what LLVM was giving us on floats.
        It needs to support conversions accross Phis but that can
        be added later.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::moveDoubleConditionallyFloat):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::sqrtFloat):
        (JSC::MacroAssemblerX86Common::loadFloat):
        (JSC::MacroAssemblerX86Common::storeFloat):
        (JSC::MacroAssemblerX86Common::convertDoubleToFloat):
        (JSC::MacroAssemblerX86Common::convertFloatToDouble):
        (JSC::MacroAssemblerX86Common::addFloat):
        (JSC::MacroAssemblerX86Common::divFloat):
        (JSC::MacroAssemblerX86Common::subFloat):
        (JSC::MacroAssemblerX86Common::mulFloat):
        (JSC::MacroAssemblerX86Common::branchDouble):
        (JSC::MacroAssemblerX86Common::branchFloat):
        (JSC::MacroAssemblerX86Common::moveConditionallyDouble):
        (JSC::MacroAssemblerX86Common::moveConditionallyFloat):
        (JSC::MacroAssemblerX86Common::jumpAfterFloatingPointCompare):
        (JSC::MacroAssemblerX86Common::moveConditionallyAfterFloatingPointCompare):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::addss_rr):
        (JSC::X86Assembler::addss_mr):
        (JSC::X86Assembler::cvtsd2ss_mr):
        (JSC::X86Assembler::cvtss2sd_mr):
        (JSC::X86Assembler::movss_rm):
        (JSC::X86Assembler::movss_mr):
        (JSC::X86Assembler::mulss_rr):
        (JSC::X86Assembler::mulss_mr):
        (JSC::X86Assembler::subss_rr):
        (JSC::X86Assembler::subss_mr):
        (JSC::X86Assembler::ucomiss_rr):
        (JSC::X86Assembler::ucomiss_mr):
        (JSC::X86Assembler::divss_rr):
        (JSC::X86Assembler::divss_mr):
        (JSC::X86Assembler::sqrtss_rr):
        (JSC::X86Assembler::sqrtss_mr):
        * b3/B3Const32Value.cpp:
        (JSC::B3::Const32Value::bitwiseCastConstant):
        * b3/B3Const32Value.h:
        * b3/B3ConstDoubleValue.cpp:
        (JSC::B3::ConstDoubleValue::doubleToFloatConstant):
        (JSC::B3::ConstDoubleValue::sqrtConstant):
        * b3/B3ConstDoubleValue.h:
        * b3/B3ConstFloatValue.cpp: Added.
        (JSC::B3::ConstFloatValue::~ConstFloatValue):
        (JSC::B3::ConstFloatValue::negConstant):
        (JSC::B3::ConstFloatValue::addConstant):
        (JSC::B3::ConstFloatValue::subConstant):
        (JSC::B3::ConstFloatValue::mulConstant):
        (JSC::B3::ConstFloatValue::bitwiseCastConstant):
        (JSC::B3::ConstFloatValue::floatToDoubleConstant):
        (JSC::B3::ConstFloatValue::sqrtConstant):
        (JSC::B3::ConstFloatValue::divConstant):
        (JSC::B3::ConstFloatValue::equalConstant):
        (JSC::B3::ConstFloatValue::notEqualConstant):
        (JSC::B3::ConstFloatValue::lessThanConstant):
        (JSC::B3::ConstFloatValue::greaterThanConstant):
        (JSC::B3::ConstFloatValue::lessEqualConstant):
        (JSC::B3::ConstFloatValue::greaterEqualConstant):
        (JSC::B3::ConstFloatValue::dumpMeta):
        * b3/B3ConstFloatValue.h: Copied from Source/JavaScriptCore/b3/B3ConstDoubleValue.h.
        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::tryOpcodeForType):
        (JSC::B3::Air::LowerToAir::opcodeForType):
        (JSC::B3::Air::LowerToAir::appendUnOp):
        (JSC::B3::Air::LowerToAir::appendBinOp):
        (JSC::B3::Air::LowerToAir::appendShift):
        (JSC::B3::Air::LowerToAir::tryAppendStoreUnOp):
        (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
        (JSC::B3::Air::LowerToAir::moveForType):
        (JSC::B3::Air::LowerToAir::relaxedMoveForType):
        (JSC::B3::Air::LowerToAir::createGenericCompare):
        (JSC::B3::Air::LowerToAir::createBranch):
        (JSC::B3::Air::LowerToAir::createCompare):
        (JSC::B3::Air::LowerToAir::createSelect):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3MemoryValue.cpp:
        (JSC::B3::MemoryValue::accessByteSize): Deleted.
        * b3/B3MemoryValue.h:
        * b3/B3MoveConstants.cpp:
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::addIntConstant):
        * b3/B3ReduceDoubleToFloat.cpp: Added.
        (JSC::B3::reduceDoubleToFloat):
        * b3/B3ReduceDoubleToFloat.h: Copied from Source/JavaScriptCore/b3/B3Type.cpp.
        * b3/B3ReduceStrength.cpp:
        * b3/B3Type.cpp:
        (WTF::printInternal):
        * b3/B3Type.h:
        (JSC::B3::isFloat):
        (JSC::B3::sizeofType):
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::doubleToFloatConstant):
        (JSC::B3::Value::floatToDoubleConstant):
        (JSC::B3::Value::sqrtConstant):
        (JSC::B3::Value::asTriState):
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::checkOpcode):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h:
        * b3/B3ValueInlines.h:
        (JSC::B3::Value::isConstant):
        (JSC::B3::Value::hasFloat):
        (JSC::B3::Value::asFloat):
        (JSC::B3::Value::hasNumber):
        (JSC::B3::Value::isNegativeZero):
        (JSC::B3::Value::representableAs):
        (JSC::B3::Value::asNumber):
        * b3/B3ValueKey.cpp:
        (JSC::B3::ValueKey::materialize):
        * b3/B3ValueKey.h:
        (JSC::B3::ValueKey::ValueKey):
        (JSC::B3::ValueKey::floatValue):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::typeForB3Type):
        (JSC::B3::Air::Arg::widthForB3Type):
        * b3/air/AirFixPartialRegisterStalls.cpp:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testAddArgFloat):
        (JSC::B3::testAddArgsFloat):
        (JSC::B3::testAddArgImmFloat):
        (JSC::B3::testAddImmArgFloat):
        (JSC::B3::testAddImmsFloat):
        (JSC::B3::testAddArgFloatWithUselessDoubleConversion):
        (JSC::B3::testAddArgsFloatWithUselessDoubleConversion):
        (JSC::B3::testAddArgsFloatWithEffectfulDoubleConversion):
        (JSC::B3::testMulArgFloat):
        (JSC::B3::testMulArgsFloat):
        (JSC::B3::testMulArgImmFloat):
        (JSC::B3::testMulImmArgFloat):
        (JSC::B3::testMulImmsFloat):
        (JSC::B3::testMulArgFloatWithUselessDoubleConversion):
        (JSC::B3::testMulArgsFloatWithUselessDoubleConversion):
        (JSC::B3::testMulArgsFloatWithEffectfulDoubleConversion):
        (JSC::B3::testDivArgFloat):
        (JSC::B3::testDivArgsFloat):
        (JSC::B3::testDivArgImmFloat):
        (JSC::B3::testDivImmArgFloat):
        (JSC::B3::testDivImmsFloat):
        (JSC::B3::testDivArgFloatWithUselessDoubleConversion):
        (JSC::B3::testDivArgsFloatWithUselessDoubleConversion):
        (JSC::B3::testDivArgsFloatWithEffectfulDoubleConversion):
        (JSC::B3::testSubArgFloat):
        (JSC::B3::testSubArgsFloat):
        (JSC::B3::testSubArgImmFloat):
        (JSC::B3::testSubImmArgFloat):
        (JSC::B3::testSubImmsFloat):
        (JSC::B3::testSubArgFloatWithUselessDoubleConversion):
        (JSC::B3::testSubArgsFloatWithUselessDoubleConversion):
        (JSC::B3::testSubArgsFloatWithEffectfulDoubleConversion):
        (JSC::B3::testClzMem32):
        (JSC::B3::testSqrtArg):
        (JSC::B3::testSqrtImm):
        (JSC::B3::testSqrtMem):
        (JSC::B3::testSqrtArgWithUselessDoubleConversion):
        (JSC::B3::testSqrtArgWithEffectfulDoubleConversion):
        (JSC::B3::testDoubleArgToInt64BitwiseCast):
        (JSC::B3::testDoubleImmToInt64BitwiseCast):
        (JSC::B3::testTwoBitwiseCastOnDouble):
        (JSC::B3::testBitwiseCastOnDoubleInMemory):
        (JSC::B3::testInt64BArgToDoubleBitwiseCast):
        (JSC::B3::testInt64BImmToDoubleBitwiseCast):
        (JSC::B3::testTwoBitwiseCastOnInt64):
        (JSC::B3::testBitwiseCastOnInt64InMemory):
        (JSC::B3::testFloatImmToInt32BitwiseCast):
        (JSC::B3::testBitwiseCastOnFloatInMemory):
        (JSC::B3::testInt32BArgToFloatBitwiseCast):
        (JSC::B3::testInt32BImmToFloatBitwiseCast):
        (JSC::B3::testTwoBitwiseCastOnInt32):
        (JSC::B3::testBitwiseCastOnInt32InMemory):
        (JSC::B3::testConvertDoubleToFloatArg):
        (JSC::B3::testConvertDoubleToFloatImm):
        (JSC::B3::testConvertDoubleToFloatMem):
        (JSC::B3::testConvertFloatToDoubleArg):
        (JSC::B3::testConvertFloatToDoubleImm):
        (JSC::B3::testConvertFloatToDoubleMem):
        (JSC::B3::testConvertDoubleToFloatToDoubleToFloat):
        (JSC::B3::testLoadFloatConvertDoubleConvertFloatStoreFloat):
        (JSC::B3::testFroundArg):
        (JSC::B3::testFroundMem):
        (JSC::B3::testStore32):
        (JSC::B3::modelLoad):
        (JSC::B3::float>):
        (JSC::B3::double>):
        (JSC::B3::testLoad):
        (JSC::B3::testStoreFloat):
        (JSC::B3::testReturnFloat):
        (JSC::B3::simpleFunctionFloat):
        (JSC::B3::testCallSimpleFloat):
        (JSC::B3::functionWithHellaFloatArguments):
        (JSC::B3::testCallFunctionWithHellaFloatArguments):
        (JSC::B3::testSelectCompareFloat):
        (JSC::B3::testSelectCompareFloatToDouble):
        (JSC::B3::testSelectDoubleCompareFloat):
        (JSC::B3::testSelectFloatCompareFloat):
        (JSC::B3::populateWithInterestingValues):
        (JSC::B3::floatingPointOperands):
        (JSC::B3::int64Operands):
        (JSC::B3::run):
        (JSC::B3::testStore): Deleted.
        (JSC::B3::posInfinity): Deleted.
        (JSC::B3::negInfinity): Deleted.
        (JSC::B3::doubleOperands): Deleted.
        * ftl/FTLB3Output.cpp:
        (JSC::FTL::Output::loadFloatToDouble):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::fround):
        * ftl/FTLCommonValues.cpp:
        (JSC::FTL::CommonValues::CommonValues):
        * ftl/FTLCommonValues.h:

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

        FTL B3 should be able to flag the tag constants as being super important so that B3 can hoist them and Air can force them into registers
        https://bugs.webkit.org/show_bug.cgi?id=151955

        Reviewed by Geoffrey Garen.

        Taught B3 about the concept of "fast constants". A client of B3 can now tell B3 which
        constants are super important. B3 will not spill the constant in that case and will ensure
        that the constant is materialized only once: statically once, and dynamically once per
        procedure execution. The hoistFastConstants() algorithm in B3MoveConstants.cpp achieves this
        by first picking the lowest common dominator of all uses of each fast constant, and then
        picking the materialization point by finding the lowest dominator of that dominator that is
        tied for lowest block frequency. In practice, the second step ensures that this is the lowest
        point in the program that is not in a loop (i.e. executes no more than once dynamically per
        procedure invocation).

        Taught Air about the concept of "fast tmps". B3 tells Air that a tmp is fast if it is used to
        hold the materialization of a fast constant. IRC will use the lowest possible spill score for
        fast tmps. In practice, this ensures that fast constants are never spilled.

        Added a small snippet of code to FTL::LowerDFGToLLVM that makes both of the tag constants
        into fast constants.

        My hope is that this very brute-force heuristic is good enough that we don't have to think
        about constants for a while. Based on my experience with how LLVM's constant hoisting works
        out, the heuristic in this patch is going to be tough to beat. LLVM's constant hoisting does
        good things when it hoists the tags, and usually causes nothing but problems when it hoists
        anything else. This is because there is no way a low-level compiler to really understand how
        a constant materialization impacts some operation's contribution to the overall execution
        time of a procedure. But, in the FTL we know that constant materializations for type checks
        are a bummer because we are super comfortable placing type checks on the hottest of paths. So
        those are the last paths where extra instructions should be added by the compiler. On the
        other hand, all other large constant uses are on relatively cold paths, or paths that are
        already expensive for other reasons. For example, global variable accesses have to
        materialize a pointer to the global. But that's not really a big deal, since a load from a
        global involves first the load itself and then type checks on the result - so probably the
        constant materialization is just not interesting. A store to a global often involves a store
        barrier, so the constant materialization is really not interesting. This patch codifies this
        heuristic in a pact between Air, B3, and the FTL: FTL demands that B3 pin the two tags in
        registers, and B3 relays the demand to Air.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3CFG.h: Added.
        (JSC::B3::CFG::CFG):
        (JSC::B3::CFG::root):
        (JSC::B3::CFG::newMap):
        (JSC::B3::CFG::successors):
        (JSC::B3::CFG::predecessors):
        (JSC::B3::CFG::index):
        (JSC::B3::CFG::node):
        (JSC::B3::CFG::numNodes):
        (JSC::B3::CFG::dump):
        * b3/B3Dominators.h: Added.
        (JSC::B3::Dominators::Dominators):
        * b3/B3IndexMap.h:
        (JSC::B3::IndexMap::resize):
        (JSC::B3::IndexMap::size):
        (JSC::B3::IndexMap::operator[]):
        * b3/B3LowerMacros.cpp:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::tmp):
        * b3/B3MoveConstants.cpp:
        * b3/B3Opcode.h:
        (JSC::B3::constPtrOpcode):
        (JSC::B3::isConstant):
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::Procedure):
        (JSC::B3::Procedure::resetReachability):
        (JSC::B3::Procedure::invalidateCFG):
        (JSC::B3::Procedure::dump):
        (JSC::B3::Procedure::deleteValue):
        (JSC::B3::Procedure::dominators):
        (JSC::B3::Procedure::addFastConstant):
        (JSC::B3::Procedure::isFastConstant):
        (JSC::B3::Procedure::addDataSection):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::size):
        (JSC::B3::Procedure::cfg):
        (JSC::B3::Procedure::setLastPhaseName):
        * b3/B3ReduceStrength.cpp:
        * b3/B3ValueInlines.h:
        (JSC::B3::Value::isConstant):
        (JSC::B3::Value::isInteger):
        * b3/B3ValueKey.h:
        (JSC::B3::ValueKey::canMaterialize):
        (JSC::B3::ValueKey::isConstant):
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::findNextBlock):
        (JSC::B3::Air::Code::addFastTmp):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::specials):
        (JSC::B3::Air::Code::isFastTmp):
        (JSC::B3::Air::Code::setLastPhaseName):
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * dfg/DFGDominators.h:
        * dfg/DFGSSACalculator.cpp:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):

2015-12-07  Andy VanWagoner  <thetalecrafter@gmail.com>

        [INTL] Implement String.prototype.toLocaleUpperCase in ECMA-402
        https://bugs.webkit.org/show_bug.cgi?id=147609

        Reviewed by Benjamin Poulain.

        Refactor most of toLocaleLowerCase to static function used by both
        toLocaleUpperCase and toLocaleLowerCase.
        Add toLocaleUpperCase using icu u_strToUpper.

        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::toLocaleCase):
        (JSC::stringProtoFuncToLocaleLowerCase):
        (JSC::stringProtoFuncToLocaleUpperCase):

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

        CRASH: CodeBlock::setOptimizationThresholdBasedOnCompilationResult + 567
        https://bugs.webkit.org/show_bug.cgi?id=151892

        Reviewed by Geoffrey Garen.

        Reverted the change made in change set r193491.

        The updated change is to finish all concurrent compilations and install the resulting
        code blocks before we make any state changes due to debugger activity.  After all code
        blocks have been installed, we make the debugger state changes, including jettisoning
        all optimized code blocks.

        This means that we will discard the optimized code blocks we just installed,
        but we won't do that while on the install code block path.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult): Reverted r193491.
        * debugger/Debugger.cpp:
        (JSC::Debugger::setSteppingMode):
        (JSC::Debugger::registerCodeBlock):
        (JSC::Debugger::toggleBreakpoint):
        (JSC::Debugger::clearBreakpoints):
        (JSC::Debugger::clearDebuggerRequests):
        Call Heap::completeAllDFGPlans() before updating code blocks for debugging changes.

        * heap/Heap.h: Made completeAllDFGPlans() public.

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

        FTL lowering should tell B3 the right block frequencies
        https://bugs.webkit.org/show_bug.cgi?id=151531

        Reviewed by Geoffrey Garen.

        This glues together the DFG's view of basic block execution counts and B3's block frequencies.
        This further improves our performance on imaging-gaussian-blur. It appears to improve the steady
        state throughput by almost 4%.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::setFrequency):
        (JSC::FTL::Output::newBlock):
        (JSC::FTL::Output::insertNewBlocksBefore):
        (JSC::FTL::Output::callWithoutSideEffects):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBlock):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::setFrequency):
        (JSC::FTL::Output::insertNewBlocksBefore):

2015-12-07  Saam barati  <sbarati@apple.com>

        Update JSC feature list for rest parameters and generators
        https://bugs.webkit.org/show_bug.cgi?id=151740

        Reviewed by Joseph Pecoraro.

        * features.json:

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

        DFG ASSERTION FAILED: m_plan.weakReferences.contains(structure).
        https://bugs.webkit.org/show_bug.cgi?id=151952

        Reviewed by Mark Lam.

        Fix a bug revealed by the new ftl-has-a-bad-time.js test. It turns out that our handling of
        structures reachable from the compiler wasn't accounting for having a bad time.

        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):

2015-12-07  Saam barati  <sbarati@apple.com>

        Add op_watchdog opcode that is generated when VM has a watchdog
        https://bugs.webkit.org/show_bug.cgi?id=151954

        Reviewed by Mark Lam.

        This patch also makes watchdog a private member
        of VM and adds a getter function.

        * API/JSContextRef.cpp:
        (JSContextGroupClearExecutionTimeLimit):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitLoopHint):
        (JSC::BytecodeGenerator::emitWatchdog):
        (JSC::BytecodeGenerator::retrieveLastBinaryOp):
        * bytecompiler/BytecodeGenerator.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckWatchdogTimer):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_loop_hint):
        (JSC::JIT::emitSlow_op_loop_hint):
        (JSC::JIT::emit_op_watchdog):
        (JSC::JIT::emitSlow_op_watchdog):
        (JSC::JIT::emit_op_new_regexp):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * runtime/VM.cpp:
        (JSC::VM::ensureWatchdog):
        * runtime/VM.h:
        (JSC::VM::watchdog):
        * runtime/VMEntryScope.cpp:
        (JSC::VMEntryScope::VMEntryScope):
        (JSC::VMEntryScope::~VMEntryScope):
        * runtime/VMInlines.h:
        (JSC::VM::shouldTriggerTermination):

2015-12-07  Alberto Garcia  <berto@igalia.com>

        Crashes on PPC64 due to mprotect() on address not aligned to the page size
        https://bugs.webkit.org/show_bug.cgi?id=130237

        Reviewed by Mark Lam.

        Make sure that commitSize is at least as big as the page size.

        * interpreter/JSStack.cpp:
        (JSC::commitSize):
        (JSC::JSStack::JSStack):
        (JSC::JSStack::growSlowCase):
        * interpreter/JSStack.h:

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

        FTL B3 should be able to make JS->JS calls
        https://bugs.webkit.org/show_bug.cgi?id=151901

        Reviewed by Saam Barati.

        This adds support for the Call and InvalidationPoint opcodes in DFG IR. This required doing some
        clean-up in the OSR exit code. We don't want the B3 FTL to use a bunch of vectors to hold
        side-state, so the use of OSRExitDescriptorImpl is not right. It makes sense in the LLVM FTL
        because that code needs some way of saving some state from LowerDFGToLLVM to compile(), but
        that's not how B3 FTL works. It turns out that for B3 FTL, there isn't anything in
        OSRExitDescriptorImpl that the code in LowerDFGToLLVM can't just capture in a lambda.

        This also simplifies some stackmap-related APIs, since I got tired of writing boilerplate.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::replaceWithAddressComputation):
        (JSC::AbstractMacroAssembler::addLinkTask):
        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::generate):
        * b3/B3Effects.h:
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::generate):
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::addDataSection):
        (JSC::B3::Procedure::callArgAreaSize):
        (JSC::B3::Procedure::requestCallArgAreaSize):
        (JSC::B3::Procedure::frameSize):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::releaseByproducts):
        (JSC::B3::Procedure::code):
        * b3/B3StackmapGenerationParams.cpp: Added.
        (JSC::B3::StackmapGenerationParams::usedRegisters):
        (JSC::B3::StackmapGenerationParams::proc):
        (JSC::B3::StackmapGenerationParams::StackmapGenerationParams):
        * b3/B3StackmapGenerationParams.h: Added.
        (JSC::B3::StackmapGenerationParams::value):
        (JSC::B3::StackmapGenerationParams::reps):
        (JSC::B3::StackmapGenerationParams::size):
        (JSC::B3::StackmapGenerationParams::at):
        (JSC::B3::StackmapGenerationParams::operator[]):
        (JSC::B3::StackmapGenerationParams::begin):
        (JSC::B3::StackmapGenerationParams::end):
        (JSC::B3::StackmapGenerationParams::context):
        (JSC::B3::StackmapGenerationParams::addLatePath):
        * b3/B3StackmapValue.h:
        * b3/B3ValueRep.h:
        (JSC::B3::ValueRep::doubleValue):
        (JSC::B3::ValueRep::withOffset):
        * b3/air/AirGenerationContext.h:
        * b3/testb3.cpp:
        (JSC::B3::testSimplePatchpoint):
        (JSC::B3::testSimplePatchpointWithoutOuputClobbersGPArgs):
        (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
        (JSC::B3::testSimplePatchpointWithoutOuputClobbersFPArgs):
        (JSC::B3::testSimplePatchpointWithOuputClobbersFPArgs):
        (JSC::B3::testPatchpointWithEarlyClobber):
        (JSC::B3::testPatchpointCallArg):
        (JSC::B3::testPatchpointFixedRegister):
        (JSC::B3::testPatchpointAny):
        (JSC::B3::testPatchpointLotsOfLateAnys):
        (JSC::B3::testPatchpointAnyImm):
        (JSC::B3::testPatchpointManyImms):
        (JSC::B3::testPatchpointWithRegisterResult):
        (JSC::B3::testPatchpointWithStackArgumentResult):
        (JSC::B3::testPatchpointWithAnyResult):
        (JSC::B3::testSimpleCheck):
        (JSC::B3::testCheckLessThan):
        (JSC::B3::testCheckMegaCombo):
        (JSC::B3::testCheckAddImm):
        (JSC::B3::testCheckAddImmCommute):
        (JSC::B3::testCheckAddImmSomeRegister):
        (JSC::B3::testCheckAdd):
        (JSC::B3::testCheckAdd64):
        (JSC::B3::testCheckSubImm):
        (JSC::B3::testCheckSubBadImm):
        (JSC::B3::testCheckSub):
        (JSC::B3::testCheckSub64):
        (JSC::B3::testCheckNeg):
        (JSC::B3::testCheckNeg64):
        (JSC::B3::testCheckMul):
        (JSC::B3::testCheckMulMemory):
        (JSC::B3::testCheckMul2):
        (JSC::B3::testCheckMul64):
        (JSC::B3::genericTestCompare):
        * ftl/FTLExceptionHandlerManager.cpp:
        * ftl/FTLExceptionHandlerManager.h:
        * ftl/FTLJSCall.cpp:
        * ftl/FTLJSCall.h:
        * ftl/FTLJSCallBase.cpp:
        (JSC::FTL::JSCallBase::emit):
        * ftl/FTLJSCallBase.h:
        * ftl/FTLJSCallVarargs.cpp:
        * ftl/FTLJSCallVarargs.h:
        * ftl/FTLJSTailCall.cpp:
        (JSC::FTL::DFG::getRegisterWithAddend):
        (JSC::FTL::JSTailCall::emit):
        (JSC::FTL::JSTailCall::JSTailCall): Deleted.
        * ftl/FTLJSTailCall.h:
        (JSC::FTL::JSTailCall::stackmapID):
        (JSC::FTL::JSTailCall::estimatedSize):
        (JSC::FTL::JSTailCall::operator<):
        (JSC::FTL::JSTailCall::patchpoint): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
        (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
        (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitBranchToOSRExitIfWillCatchException):
        (JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
        (JSC::FTL::DFG::LowerDFGToLLVM::exitValueForNode):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
        (JSC::FTL::OSRExitDescriptor::emitOSRExit):
        (JSC::FTL::OSRExitDescriptor::emitOSRExitLater):
        (JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
        (JSC::FTL::OSRExit::OSRExit):
        (JSC::FTL::OSRExit::codeLocationForRepatch):
        (JSC::FTL::OSRExit::recoverRegistersFromSpillSlot):
        (JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck):
        (JSC::FTL::OSRExit::needsRegisterRecoveryOnGenericUnwindOSRExitPath):
        * ftl/FTLOSRExit.h:
        (JSC::FTL::OSRExitDescriptorImpl::OSRExitDescriptorImpl):
        (JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        (JSC::FTL::compileFTLOSRExit):
        * ftl/FTLState.h:

2015-12-07  Saam barati  <sbarati@apple.com>

        Rename Watchdog::didFire to Watchdog::shouldTerminate because that's what didFire really meant
        https://bugs.webkit.org/show_bug.cgi?id=151944

        Reviewed by Mark Lam.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * runtime/VMInlines.h:
        (JSC::VM::shouldTriggerTermination):
        * runtime/Watchdog.cpp:
        (JSC::Watchdog::terminateSoon):
        (JSC::Watchdog::shouldTerminateSlow):
        (JSC::Watchdog::didFireSlow): Deleted.
        * runtime/Watchdog.h:
        (JSC::Watchdog::shouldTerminate):
        (JSC::Watchdog::didFire): Deleted.

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

        Rename JITBitwiseBinaryOpGenerator to JITBitBinaryOpGenerator.
        https://bugs.webkit.org/show_bug.cgi?id=151945

        Reviewed by Saam Barati.

        The lshift operator also need to inherit from JITBitBinaryOpGenerator.  Calling
        it "BitBinaryOp" makes more sense than "BitwiseBinaryOp" in that case, and still
        makes sense for the bitand, bitor, and bitxor operators.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitBitBinaryOpFastPath):
        (JSC::JIT::emit_op_bitand):
        (JSC::JIT::emitSlow_op_bitand):
        (JSC::JIT::emit_op_bitor):
        (JSC::JIT::emitSlow_op_bitor):
        (JSC::JIT::emit_op_bitxor):
        (JSC::JIT::emitSlow_op_bitxor):
        (JSC::JIT::emitBitwiseBinaryOpFastPath): Deleted.
        * jit/JITBitAndGenerator.h:
        (JSC::JITBitAndGenerator::JITBitAndGenerator):
        * jit/JITBitBinaryOpGenerator.h: Copied from Source/JavaScriptCore/jit/JITBitwiseBinaryOpGenerator.h.
        (JSC::JITBitBinaryOpGenerator::JITBitBinaryOpGenerator):
        (JSC::JITBitwiseBinaryOpGenerator::JITBitwiseBinaryOpGenerator): Deleted.
        * jit/JITBitOrGenerator.h:
        (JSC::JITBitOrGenerator::JITBitOrGenerator):
        * jit/JITBitXorGenerator.h:
        (JSC::JITBitXorGenerator::JITBitXorGenerator):
        * jit/JITBitwiseBinaryOpGenerator.h: Removed.

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

        [B3] Typo fix after r193386 to fix the build
        https://bugs.webkit.org/show_bug.cgi?id=151860

        Reviewed by Filip Pizlo.

        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::isArgValidForValue):

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

        [EFL] Implement scheduleTimer and cancelTimer in IncrementalSweeper class
        https://bugs.webkit.org/show_bug.cgi?id=151656

        Reviewed by Csaba Osztrogonác.

        Support IncremntalSweeper using Ecore_Timer.

        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::IncrementalSweeper):
        (JSC::IncrementalSweeper::scheduleTimer):
        (JSC::IncrementalSweeper::cancelTimer):
        * heap/IncrementalSweeper.h:

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

        [INTL] Implement String.prototype.toLocaleLowerCase in ECMA-402
        https://bugs.webkit.org/show_bug.cgi?id=147608

        Reviewed by Benjamin Poulain.

        Add toLocaleLowerCase using icu u_strToLower.

        * runtime/IntlObject.cpp:
        (JSC::defaultLocale): Expose.
        (JSC::bestAvailableLocale): Expose.
        (JSC::removeUnicodeLocaleExtension): Expose.
        * runtime/IntlObject.h:
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::stringProtoFuncToLocaleLowerCase): Add.

2015-12-06  David Kilzer  <ddkilzer@apple.com>

        REGRESSION(r193584): Causes heap use-after-free crashes in Web Inspector tests with AddressSanitizer (Requested by ddkilzer on #webkit).
        https://bugs.webkit.org/show_bug.cgi?id=151929

        Reverted changeset:

        "[ES6] "super" and "this" should be lexically bound inside an
        arrow function and should live in a JSLexicalEnvironment"
        https://bugs.webkit.org/show_bug.cgi?id=149338
        http://trac.webkit.org/changeset/193584

2015-12-06  Skachkov Oleksandr  <gskachkov@gmail.com>

        [es6] Arrow function syntax. Fix tests after 149338 landing
        https://bugs.webkit.org/show_bug.cgi?id=151927

        Reviewed by Saam Barati.

        After landing patch for 149338 errors appear in for ES6 Generator. Current fix is removed assert 
        that was removed by patch with implemenation of ES6 Generator.
 
        * runtime/CommonSlowPaths.cpp:

2015-12-05 Aleksandr Skachkov   <gskachkov@gmail.com>

        [ES6] "super" and "this" should be lexically bound inside an arrow function and should live in a JSLexicalEnvironment
        https://bugs.webkit.org/show_bug.cgi?id=149338

        Reviewed by Saam Barati.

        Implemented new version of the lexically bound 'this' in arrow function. In current version 
        'this' is stored inside of the lexical environment of the function. To store and load we use
        op_get_from_scope and op_put_to_scope operations. Also new implementation prevent raising TDZ
        error for arrow functions that are declared before super() but invoke after.

        * builtins/BuiltinExecutables.cpp:
        (JSC::createExecutableInternal):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::getSlow):
        * bytecode/ExecutableInfo.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::isDerivedConstructorContext):
        (JSC::ExecutableInfo::isArrowFunctionContext):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::isArrowFunction):
        (JSC::UnlinkedCodeBlock::isDerivedConstructorContext):
        (JSC::UnlinkedCodeBlock::isArrowFunctionContext):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::variable):
        (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
        (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadThisFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::isDerivedConstructorContext):
        (JSC::BytecodeGenerator::usesArrowFunction):
        (JSC::BytecodeGenerator::needsToUpdateArrowFunctionContext):
        (JSC::BytecodeGenerator::usesEval):
        (JSC::BytecodeGenerator::usesThis):
        (JSC::BytecodeGenerator::newTarget):
        (JSC::BytecodeGenerator::makeFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode):
        (JSC::SuperNode::emitBytecode):
        (JSC::EvalFunctionCallNode::emitBytecode):
        (JSC::FunctionCallValueNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluate):
        * dfg/DFGAbstractInterpreterInlines.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        * dfg/DFGClobberize.h:
        * dfg/DFGDoesGC.cpp:
        * dfg/DFGFixupPhase.cpp:
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGPromotedHeapLocation.cpp:
        * dfg/DFGPromotedHeapLocation.h:
        * dfg/DFGSafeToExecute.h:
        * dfg/DFGSpeculativeJIT.cpp:
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        * dfg/DFGSpeculativeJIT64.cpp:
        * ftl/FTLCapabilities.cpp:
        * ftl/FTLLowerDFGToLLVM.cpp:
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * jit/JIT.cpp:
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitNewFuncExprCommon):
        * jit/JITOpcodes32_64.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createArrowFunctionExpr):
        (JSC::ASTBuilder::usesArrowFunction):
        * parser/Nodes.h:
        (JSC::ScopeNode::usesArrowFunction):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/ParserModes.h:
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::ScriptExecutable):
        (JSC::EvalExecutable::create):
        (JSC::EvalExecutable::EvalExecutable):
        (JSC::ProgramExecutable::ProgramExecutable):
        (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
        (JSC::FunctionExecutable::FunctionExecutable):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::isArrowFunctionContext):
        (JSC::ScriptExecutable::isDerivedConstructorContext):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createEvalCodeBlock):
        * runtime/JSGlobalObject.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
        * tests/es6.yaml:
        * tests/stress/arrowfunction-activation-sink-osrexit.js:
        * tests/stress/arrowfunction-activation-sink.js:
        * tests/stress/arrowfunction-lexical-bind-newtarget.js: Added.
        * tests/stress/arrowfunction-lexical-bind-supercall-1.js: Added.
        * tests/stress/arrowfunction-lexical-bind-supercall-2.js: Added.
        * tests/stress/arrowfunction-lexical-bind-supercall-3.js: Added.
        * tests/stress/arrowfunction-lexical-bind-supercall-4.js: Added.
        * tests/stress/arrowfunction-lexical-bind-this-1.js:
        * tests/stress/arrowfunction-lexical-bind-this-7.js: Added.
        * tests/stress/arrowfunction-tdz-1.js: Added.
        * tests/stress/arrowfunction-tdz-2.js: Added.
        * tests/stress/arrowfunction-tdz-3.js: Added.
        * tests/stress/arrowfunction-tdz-4.js: Added.
        * tests/stress/arrowfunction-tdz.js: Removed.

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

        [JSC] Remove FTLOutput's fence support
        https://bugs.webkit.org/show_bug.cgi?id=151909

        Reviewed by Sam Weinig.

        Unused code is unused.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::fence): Deleted.
        (JSC::FTL::Output::fenceAcqRel): Deleted.
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::fence): Deleted.
        (JSC::FTL::Output::fenceAcqRel): Deleted.

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

        [JSC] Some more cleanup of FTLB3Output
        https://bugs.webkit.org/show_bug.cgi?id=151834

        Reviewed by Filip Pizlo.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::trap):
        (JSC::FTL::Output::stackmapIntrinsic): Deleted.
        (JSC::FTL::Output::frameAddressIntrinsic): Deleted.
        (JSC::FTL::Output::patchpointInt64Intrinsic): Deleted.
        (JSC::FTL::Output::patchpointVoidIntrinsic): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::probe):

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

        [JSC] Fix Value::returnsBool() after r193436
        https://bugs.webkit.org/show_bug.cgi?id=151902

        Reviewed by Saam Barati.

        I forgot to carry a test from Branch and Select :(

        * b3/B3Value.cpp:
        (JSC::B3::Value::returnsBool):

2015-12-04  Andy VanWagoner  <thetalecrafter@gmail.com>

        [INTL] Implement Number.prototype.toLocaleString in ECMA-402
        https://bugs.webkit.org/show_bug.cgi?id=147610

        Reviewed by Benjamin Poulain.

        Add toLocaleString in builtin JavaScript that delegates formatting to Intl.NumberFormat.
        Keep exisiting native implementation for use if INTL flag is disabled.

        * CMakeLists.txt: Add NumberPrototype.js.
        * DerivedSources.make: Add NumberPrototype.js.
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/NumberPrototype.js: Added.
        (toLocaleString):
        * runtime/CommonIdentifiers.h: Add private names for Intl constructors.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Expose Intl constructors to builtin js.
        * runtime/NumberPrototype.cpp:
        (JSC::NumberPrototype::finishCreation): Replace toLocaleString implementation.

2015-12-04  Michael Saboff  <msaboff@apple.com>

        CRASH: CodeBlock::setOptimizationThresholdBasedOnCompilationResult + 567
        https://bugs.webkit.org/show_bug.cgi?id=151892

        Reviewed by Mark Lam.

        When the debugger is in the process of attaching and it recompiles functions
        for debugging, there can also be a DFG compilation running concurrently.
        When we go to update the optimization threshold and find that the replacement
        is also baseline code, we shouldn't update the threshold.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):

2015-12-04  Jonathan Davis  <jond@apple.com>

        Update feature status for up-to-date status information.
        https://bugs.webkit.org/show_bug.cgi?id=151821

        Reviewed by Timothy Hatcher.

        * features.json:

2015-12-04  Saam barati  <sbarati@apple.com>

        OSR exits that are exception handlers should emit less code eagerly in the thunk generator, and instead, should defer as much code generation as possible to be lazily generated in the exit itself
        https://bugs.webkit.org/show_bug.cgi?id=151406

        Reviewed by Filip Pizlo.

        We no longer emit any extra code eagerly for an OSRExit that
        is an exception handler. We emit all code lazily in the exit
        itself. This has one interesting consequence which is that the
        actual C call to compile the exit goes through an OSR exit generation
        thunk that must now be aware of resetting the call frame and the stack
        pointer to their proper values before making the compileOSRExit C
        call. This has one interesting consequence in the FTL because the
        FTL will do a pushToSaveImmediateWithoutTouchingRegisters with the
        OSR exit index. We must take care to preserve this exit index when
        we reset the stack pointer by re-pushing it onto the stack.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setJITCode):
        (JSC::CodeBlock::jitCode):
        (JSC::CodeBlock::jitCodeOffset):
        (JSC::CodeBlock::jitType):
        * dfg/DFGCommonData.h:
        (JSC::DFG::CommonData::frameRegisterCountOffset):
        * dfg/DFGJITCode.h:
        (JSC::DFG::JITCode::setOSREntryBlock):
        (JSC::DFG::JITCode::clearOSREntryBlock):
        (JSC::DFG::JITCode::commonDataOffset):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::linkOSRExits):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompilerCommon.h:
        (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrExitGenerationThunkGenerator):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLExitThunkGenerator.cpp:
        (JSC::FTL::ExitThunkGenerator::~ExitThunkGenerator):
        (JSC::FTL::ExitThunkGenerator::emitThunk):
        (JSC::FTL::ExitThunkGenerator::emitThunks):
        * ftl/FTLExitThunkGenerator.h:
        (JSC::FTL::ExitThunkGenerator::didThings):
        * ftl/FTLJITCode.h:
        (JSC::FTL::JITCode::commonDataOffset):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        (JSC::FTL::compileFTLOSRExit):
        * ftl/FTLThunks.cpp:
        (JSC::FTL::genericGenerationThunkGenerator):
        (JSC::FTL::osrExitGenerationThunkGenerator):
        (JSC::FTL::lazySlowPathGenerationThunkGenerator):
        (JSC::FTL::registerClobberCheck):

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

        Having a bad time has a really awful time when it runs at the same time as the JIT
        https://bugs.webkit.org/show_bug.cgi?id=151882
        rdar://problem/23547038

        Unreviewed, really adding the test this time.

        * tests/stress/ftl-has-a-bad-time.js: Added.
        (foo):

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

        Snippefy bitwise operators for the baseline JIT.
        https://bugs.webkit.org/show_bug.cgi?id=151680

        Reviewed by Geoffrey Garen.

        This patch has passed the JSC tests on x86 and x86_64.  It has also passed the
        layout tests on x86_64.

        With the DFG enabled, perf is neutral on x86_64 and x86.
        With the DFG disabled on x86_64, some AsmBench tests are showing progressions e.g.
            gcc-loops.cpp           1.0269x faster
            stepanov_container.cpp  1.0180x faster

        With the DFG disabled on x86, perf is neutral.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:

        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::moveValueRegs):
        (JSC::AssemblyHelpers::branchIfNotInt32):
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitBitwiseBinaryOpFastPath):
        - Template for the bitwise operations.
        (JSC::JIT::emit_op_bitand):
        (JSC::JIT::emit_op_bitor):
        (JSC::JIT::emit_op_bitxor):
        - Specializes emitBitwiseBinaryOpFastPath() with the respective snippet generators.
        (JSC::JIT::emitSlow_op_bitand):
        (JSC::JIT::emitSlow_op_bitor):
        (JSC::JIT::emitSlow_op_bitxor):
        - Implement respective slow paths.

        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_op_bitand): Deleted.
        (JSC::JIT::emitSlow_op_bitand): Deleted.
        (JSC::JIT::emit_op_bitor): Deleted.
        (JSC::JIT::emitSlow_op_bitor): Deleted.
        (JSC::JIT::emit_op_bitxor): Deleted.
        (JSC::JIT::emitSlow_op_bitxor): Deleted.
        - Now unified with the 64-bit version using snippets. 

        * jit/JITBitAndGenerator.cpp: Added.
        (JSC::JITBitAndGenerator::generateFastPath):
        * jit/JITBitAndGenerator.h: Added.
        (JSC::JITBitAndGenerator::JITBitAndGenerator):
        * jit/JITBitOrGenerator.cpp: Added.
        (JSC::JITBitOrGenerator::generateFastPath):
        * jit/JITBitOrGenerator.h: Added.
        (JSC::JITBitOrGenerator::JITBitOrGenerator):
        * jit/JITBitXorGenerator.cpp: Added.
        (JSC::JITBitXorGenerator::generateFastPath):
        * jit/JITBitXorGenerator.h: Added.
        (JSC::JITBitXorGenerator::JITBitXorGenerator):
        * jit/JITBitwiseBinaryOpGenerator.h: Added.
        (JSC::JITBitwiseBinaryOpGenerator::JITBitwiseBinaryOpGenerator):
        (JSC::JITBitwiseBinaryOpGenerator::didEmitFastPath):
        (JSC::JITBitwiseBinaryOpGenerator::endJumpList):
        (JSC::JITBitwiseBinaryOpGenerator::slowPathJumpList):

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_bitxor): Deleted.
        (JSC::JIT::emit_op_bitor): Deleted.
        (JSC::JIT::emitSlow_op_bitxor): Deleted.
        (JSC::JIT::emitSlow_op_bitor): Deleted.
        * jit/SnippetOperand.h:
        (JSC::SnippetOperand::SnippetOperand):

        * tests/stress/op_bitand.js:
        * tests/stress/op_bitor.js:
        * tests/stress/op_bitxor.js:
        - Fix a test value typo: it's supposed to be 0x7fffffff, not 0x7ffffff.

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

        Having a bad time has a really awful time when it runs at the same time as the JIT
        https://bugs.webkit.org/show_bug.cgi?id=151882
        rdar://problem/23547038

        Reviewed by Geoffrey Garen.

        The DFG's use of watchpoints for havingABadTime goes back a long time. We introduced this feature
        when we first introduced watchpoints. That left it open to a lot of bitrot. On top of that, this
        code doesn't get tested much because having a bad time is not something that is really supposed to
        happen.

        Well, now I've got reports that it does happen - or at least, we know that it is because of
        crashes in an assertion that could only be triggered if a bad time was had. In the meantime, we
        added two new features without adequately testing havingABadTime: concurrent JIT and FTL.
        Concurrency means that we have to worry about the havingABadTime watchpoint triggering during
        compilation. FTL means that we have new code and new optimizations that needs to deal with this
        feature correctly.

        The bug can arise via race condition or just goofy profiling. As in the newly added test, we could
        first profile an allocation thinking that it will allocate sane arrays. Then we might have a bad
        time, and then compile that function with the FTL. The ByteCodeParser will represent the
        allocation with a NewArray node that has a sane indexingType(). But when we go to lower the Node,
        we observe that the Structure* that the JSGlobalObject tells us to use has a different indexing
        type. This is a feature of havingABadTime that the DFG knew about, but the FTL didn't. The FTL
        didn't know about it because we didn't have adequate tests, and this code rarely gets triggered in
        the wild. So, the FTL had a silly assertion that the indexing types match. They absolutely don't
        have to match.

        There is another bug, a race condition, that remains even if we remove the bad assertion. We set
        the havingABadTime watchpoint late in compilation, and we do it based on whether the watchpoint is
        still OK. This means that we could parse a function before we have a bad time and then do
        optimizations (for example in AbstractInterpreter) like proving that the structure set associated
        with the value returned by the NewArray is the one with a sane indexing type. Then, after those
        optimizations have already been done, we will go to set the watchpoint. But just as we are doing
        this, we could haveABadTime on the main thread. Currently this sort of almost works because
        having a bad time requires doing a GC, and we can't GC until the watchpoint collection phase. But
        that feels too fragile. So, this phase moves the setting of the watchpoint to the FixupPhase. This
        is consistent with our long-term goal of removing the WatchpointCollectionPhase. Moving this to
        FixupPhase means that we set the watchpoint before doing any optimizations. So, if having a bad
        time happens before the FixupPhase then all optimizations will agree that we're having a bad time
        and so everything is fine; if we have a bad time after FixupPhase then we will cancel the
        compilation anyway.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::watchHavingABadTime):
        (JSC::DFG::FixupPhase::createToString):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasIndexingType):
        (JSC::DFG::Node::indexingType):
        * dfg/DFGWatchpointCollectionPhase.cpp:
        (JSC::DFG::WatchpointCollectionPhase::handle):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewArray):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayBuffer):
        * tests/stress/ftl-has-a-bad-time.js: Added.

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

        [JSC] Use Div and ChillDiv in FTL(B3)Output
        https://bugs.webkit.org/show_bug.cgi?id=151844

        Reviewed by Geoffrey Garen.

        I copied part of the code of compileArithDiv()
        to create a new function FTLOutput::childDiv().

        With childDiv() being a concept of FTLOutput,
        FTLB3Output was updated accordingly.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::div):
        (JSC::FTL::Output::chillDiv):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithDiv):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::chillDiv):
        * ftl/FTLOutput.h:

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

        [JSC] Extend the strength reduction of B3's BitAnd with booleans
        https://bugs.webkit.org/show_bug.cgi?id=151852

        Reviewed by Saam Barati.

        1) Masking a boolean with any pattern that has the lsb set
           remains a boolean.
        2) ReduceStrength on that particular pattern of BitAnd.

        * b3/B3ReduceStrength.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::returnsBool):
        * b3/testb3.cpp:
        (JSC::B3::testBitAndWithMaskReturnsBooleans):
        (JSC::B3::run):

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

        [JSC] Add doubleRem() to FTLB3Output
        https://bugs.webkit.org/show_bug.cgi?id=151851

        Reviewed by Geoffrey Garen.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::doubleRem):

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

        [JSC] Add signExt() to FTLB3Output
        https://bugs.webkit.org/show_bug.cgi?id=151853

        Reviewed by Geoffrey Garen.

        Rename signExt() to signExt32To64(). This is just to separate
        it explicitly from the remaining signExt() used inside FTLOutput.

        Then use the SExt32 for implementing that in B3.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::signExt32To64):
        (JSC::FTL::Output::signExt): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInt52Rep):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetDirectPname):
        (JSC::FTL::DFG::LowerDFGToLLVM::strictInt52ToInt32):
        (JSC::FTL::DFG::LowerDFGToLLVM::strictInt52ToJSValue):
        (JSC::FTL::DFG::LowerDFGToLLVM::jsValueToStrictInt52):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::signExt32To64):
        (JSC::FTL::Output::signExt):

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

        Web Inspector: Unskip many inspector/debugger tests
        https://bugs.webkit.org/show_bug.cgi?id=151843

        Reviewed by Timothy Hatcher.

        * bindings/ScriptFunctionCall.cpp:
        (Deprecated::ScriptFunctionCall::call):
        Ignore TerminationExceptions, as those aren't real execution
        exceptions and may be seen on Workers that have closed.

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

        Web Inspector: Remove untested and unused Worker inspection
        https://bugs.webkit.org/show_bug.cgi?id=151848

        Reviewed by Brian Burg.

        * CMakeLists.txt:
        * DerivedSources.make:
        * debugger/Debugger.cpp:
        (JSC::Debugger::Debugger):
        (JSC::Debugger::willExecuteProgram):
        * debugger/Debugger.h:
        * inspector/JSGlobalObjectScriptDebugServer.cpp:
        (Inspector::JSGlobalObjectScriptDebugServer::JSGlobalObjectScriptDebugServer):
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::ScriptDebugServer):
        * inspector/ScriptDebugServer.h:
        * inspector/agents/InspectorConsoleAgent.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::run): Deleted.
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/agents/JSGlobalObjectConsoleAgent.h:
        * inspector/protocol/Runtime.json:
        * inspector/protocol/Worker.json: Removed.

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

        Web Inspector: Specifically Identify the Global Lexical Environment Scope
        https://bugs.webkit.org/show_bug.cgi?id=151828

        Reviewed by Brian Burg.

        * inspector/InjectedScriptSource.js:
        Include the new scope type.

        * inspector/JSJavaScriptCallFrame.h:
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::scopeType):
        Set the new value for the new scope type.

        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation): Deleted.
        (Inspector::jsJavaScriptCallFrameConstantGLOBAL_SCOPE): Deleted.
        (Inspector::jsJavaScriptCallFrameConstantLOCAL_SCOPE): Deleted.
        (Inspector::jsJavaScriptCallFrameConstantWITH_SCOPE): Deleted.
        (Inspector::jsJavaScriptCallFrameConstantCLOSURE_SCOPE): Deleted.
        (Inspector::jsJavaScriptCallFrameConstantCATCH_SCOPE): Deleted.
        (Inspector::jsJavaScriptCallFrameConstantFUNCTION_NAME_SCOPE): Deleted.
        Remove unused constants on the JavaScriptCallFrame object.
        Currently they are just hardcoded in InjectedScriptSource
        and they don't make sense on instances anyways.

2015-12-04  Keith Miller  <keith_miller@apple.com>

        Add an option to emit instructions validating exceptions in the DFG rather than always emiting them.
        https://bugs.webkit.org/show_bug.cgi?id=151841

        Reviewed by Saam Barati.

        Add a new option that validates the DFG execption checking. The default value for the option is
        true in Debug builds and false in Release builds. Additionally, renamed jitAssertNoException to
        jitReleaseAssertNoException for consistency with our ASSERT naming convention.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::jitReleaseAssertNoException):
        (JSC::AssemblyHelpers::jitAssertNoException): Deleted.
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::jitAssertNoException): Deleted.
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:

2015-12-04  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the !ENABLE(DFG_JIT) build after r190735
        https://bugs.webkit.org/show_bug.cgi?id=151617

        Reviewed by Filip Pizlo.

        * jit/GCAwareJITStubRoutine.cpp:
        (JSC::GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount):

2015-12-04  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] Fix the B3 build after r192946
        https://bugs.webkit.org/show_bug.cgi?id=151857

        Reviewed by Michael Saboff.

        * CMakeLists.txt:

2015-12-04  Csaba Osztrogonác  <ossy@webkit.org>

        [AArch64] Typo fix after r189575
        https://bugs.webkit.org/show_bug.cgi?id=151855

        Reviewed by Michael Saboff.

        * ftl/FTLUnwindInfo.cpp:
        (JSC::FTL::parseUnwindInfo):

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

        B3 Patchpoint and Check opcodes should be able to specify WarmAny, ColdAny, and LateColdAny
        https://bugs.webkit.org/show_bug.cgi?id=151335

        Reviewed by Geoffrey Garen.

        This removes ValueRep::Any and replaces it with ValueRep::WarmAny, ValueRep::ColdAny, and
        ValueRep::LateColdAny. I think that conceptually the most obvious users of patchpoints are inline
        caches, which would use WarmAny for their non-OSR inputs. For this reason, I make WarmAny the
        default.

        However, the StackmapValue optimization that provides a default ValueRep for any that are missing
        was meant for OSR. So, this optimization now uses ColdAny.

        This patch wires this change through the whole compiler and adds some tests.

        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::Key::Key):
        (JSC::B3::CheckSpecial::Key::dump):
        (JSC::B3::CheckSpecial::CheckSpecial):
        * b3/B3CheckSpecial.h:
        (JSC::B3::CheckSpecial::Key::Key):
        (JSC::B3::CheckSpecial::Key::opcode):
        (JSC::B3::CheckSpecial::Key::numArgs):
        (JSC::B3::CheckSpecial::Key::stackmapRole):
        * b3/B3CheckValue.cpp:
        (JSC::B3::CheckValue::CheckValue):
        * b3/B3ConstrainedValue.h:
        (JSC::B3::ConstrainedValue::ConstrainedValue):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::fillStackmap):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3MoveConstants.cpp:
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::forEachArg):
        (JSC::B3::PatchpointSpecial::isValid):
        (JSC::B3::PatchpointSpecial::admitsStack):
        * b3/B3PatchpointValue.cpp:
        (JSC::B3::PatchpointValue::PatchpointValue):
        * b3/B3PatchpointValue.h:
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        (JSC::B3::StackmapSpecial::admitsStackImpl):
        (JSC::B3::StackmapSpecial::isArgValidForRep):
        (WTF::printInternal):
        * b3/B3StackmapSpecial.h:
        * b3/B3StackmapValue.cpp:
        (JSC::B3::StackmapValue::append):
        (JSC::B3::StackmapValue::setConstraint):
        * b3/B3StackmapValue.h:
        * b3/B3Validate.cpp:
        * b3/B3ValueRep.cpp:
        (JSC::B3::ValueRep::dump):
        (WTF::printInternal):
        * b3/B3ValueRep.h:
        (JSC::B3::ValueRep::ValueRep):
        (JSC::B3::ValueRep::reg):
        (JSC::B3::ValueRep::operator!=):
        (JSC::B3::ValueRep::operator bool):
        (JSC::B3::ValueRep::isAny):
        (JSC::B3::ValueRep::isSomeRegister):
        * b3/testb3.cpp:
        (JSC::B3::compileAndRun):
        (JSC::B3::add32):
        (JSC::B3::test42):
        (JSC::B3::testSimplePatchpoint):
        (JSC::B3::testPatchpointWithEarlyClobber):
        (JSC::B3::testPatchpointFixedRegister):
        (JSC::B3::testPatchpointAny):
        (JSC::B3::testPatchpointLotsOfLateAnys):
        (JSC::B3::testPatchpointAnyImm):
        (JSC::B3::testPatchpointManyImms):
        (JSC::B3::testPatchpointWithRegisterResult):
        (JSC::B3::testPatchpointWithAnyResult):
        (JSC::B3::run):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):

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

        B3 patchpoints should allow specifying output constraints
        https://bugs.webkit.org/show_bug.cgi?id=151809

        Reviewed by Benjamin Poulain.

        JS call patchpoints should put their result into the result register, while most other patchpoints
        should put their results into some register. I think that it's best if we just allow arbitrary
        constraints on the result of a patchpoint. And by "arbitrary" I mean allowing the same kinds of
        constraints as we allow on the stackmap children.

        This also adds a large comment in B3StackmapValue.h that lays out the philosophy of our stackmaps
        and patchpoints. I found it useful to write down the plan since it's pretty subtle.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::isValid):
        (JSC::B3::PatchpointSpecial::admitsStack):
        * b3/B3PatchpointValue.cpp:
        (JSC::B3::PatchpointValue::~PatchpointValue):
        (JSC::B3::PatchpointValue::dumpMeta):
        (JSC::B3::PatchpointValue::PatchpointValue):
        * b3/B3PatchpointValue.h:
        (JSC::B3::PatchpointValue::accepts):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::code):
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::isValidImpl):
        (JSC::B3::StackmapSpecial::appendRepsImpl):
        (JSC::B3::StackmapSpecial::isArgValidForValue):
        (JSC::B3::StackmapSpecial::isArgValidForRep):
        (JSC::B3::StackmapSpecial::repForArg):
        * b3/B3StackmapSpecial.h:
        * b3/B3StackmapValue.h:
        * b3/B3Validate.cpp:
        * b3/B3ValueRep.h:
        (JSC::B3::ValueRep::doubleValue):
        * b3/testb3.cpp:
        (JSC::B3::testPatchpointManyImms):
        (JSC::B3::testPatchpointWithRegisterResult):
        (JSC::B3::testPatchpointWithStackArgumentResult):
        (JSC::B3::testPatchpointWithAnyResult):
        (JSC::B3::testSimpleCheck):
        (JSC::B3::run):
        * jit/RegisterSet.h:

2015-12-03  Anders Carlsson  <andersca@apple.com>

        Remove Objective-C GC support
        https://bugs.webkit.org/show_bug.cgi?id=151819
        rdar://problem/23746991

        Reviewed by Dan Bernstein.

        * Configurations/Base.xcconfig:
        * Configurations/ToolExecutable.xcconfig:

2015-12-03  Benjamin Poulain  <bpoulain@apple.com>

        Attempt to fix GTK again after r193125

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::supportsLZCNT):

2015-12-03  Benjamin Poulain  <bpoulain@apple.com>

        Attempt to fix GTK after r193125

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::supportsLZCNT):
        GCC is unable to handle EBX correctly when clobbered by inline asm.

2015-12-03  Saam barati  <sbarati@apple.com>

        FTL::OSRExitDescriptor should use less memory by having a companion object that dies after compilation
        https://bugs.webkit.org/show_bug.cgi?id=151795

        Reviewed by Geoffrey Garen.

        There were a few fields on FTL::OSRExitDescriptor that are only
        needed during compilation. This patch introduces OSRExitDescriptorImpl 
        which is a struct that we create for each OSRExitDescriptor. The difference is 
        that OSRExitDescriptorImpl lives off of FTL::State so it dies after we compile.
        This way no unnecessary fields persist after the compilation.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLExceptionHandlerManager.cpp:
        (JSC::FTL::ExceptionHandlerManager::lazySlowPathExceptionTarget):
        (JSC::FTL::ExceptionHandlerManager::getCallOSRExitCommon):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
        (JSC::FTL::OSRExitDescriptor::validateReferences):
        (JSC::FTL::OSRExitDescriptor::emitOSRExit):
        (JSC::FTL::OSRExitDescriptor::emitOSRExitLater):
        (JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
        (JSC::FTL::OSRExit::OSRExit):
        (JSC::FTL::OSRExit::codeLocationForRepatch):
        (JSC::FTL::OSRExit::gatherRegistersToSpillForCallIfException):
        (JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck):
        (JSC::FTL::exceptionTypeWillArriveAtOSRExitFromGenericUnwind):
        (JSC::FTL::OSRExit::willArriveAtOSRExitFromGenericUnwind):
        (JSC::FTL::OSRExit::willArriveAtOSRExitFromCallOperation):
        (JSC::FTL::OSRExitDescriptor::isExceptionHandler): Deleted.
        * ftl/FTLOSRExit.h:
        (JSC::FTL::OSRExitDescriptorImpl::OSRExitDescriptorImpl):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileFTLOSRExit):
        * ftl/FTLState.h:

2015-12-03  Alex Christensen  <achristensen@webkit.org>

        Fix 64-bit Windows build after r193125.
        https://bugs.webkit.org/show_bug.cgi?id=151799

        Reviewed by Michael Saboff.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::supportsLZCNT):
        Use __cpuid intrinsic instead of inline assembly.

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

        FTL B3 should support OSR exit
        https://bugs.webkit.org/show_bug.cgi?id=151710

        Reviewed by Saam Barati.

        This adds OSR exit support using the same style that I established with lazy slow paths. All of
        the work is driven by FTL::LowerDFGToLLVM, and from there any work that needs to be deferred
        until after B3 finishes is attached to the stackmap generator. In order to make it easy to port
        all of the different forms of OSR exit - invalidation points, exceptions, etc. - the logic for
        registering an OSR exit is abstracted behind OSRExitDescriptor and OSRExitHandle.

        An issue that I encountered repeatedly in this patch is OSRExitDescriptor being passed as a
        reference (&) rather than pointer (*). The new code uses a lot of lambdas that run after the
        current frame pops, so the capture list cannot be [&]. I believe that always listing all of the
        captured variables is not scalable considering how sophisticated our use of lambdas is. So, it
        makes sense to use [=]. But anytime we captured a variable whose type was OSRExitDescriptor&, it
        would be captured by value, because that's how references work. One has to be mindful of these
        things whenever using [=]. Note that it's not enough to say that we should have listed the
        captured variables explicitly - in that case, we still could have made the mistake by forgetting
        to put & in front of the variant. The pattern that worked for me to reason about whether I'm
        capturing an object or a pointer to an object is to always use pointer types for pointers: either
        RefPtr<> when we also want the lambda to prolong the object's life, or * if we are confident that
        the object will stay alive. For this reason, this patch changes all code that references
        OSRExitDescriptor to use * instead of &. Consistency makes the code easier to grok, and it made
        it easier to introduce the required uses of * in places where there were lambdas.

        I tested this by running imaging-gaussian-blur, and running some tests that reqiure OSR exit. I'm
        not promising that all kinds of exits work, but we have to begin somewhere.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3Compilation.cpp:
        (JSC::B3::Compilation::Compilation):
        (JSC::B3::Compilation::~Compilation):
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::addDataSection):
        (JSC::B3::Procedure::frameSize):
        (JSC::B3::Procedure::calleeSaveRegisters):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::releaseByproducts):
        (JSC::B3::Procedure::code):
        (JSC::B3::Procedure::takeByproducts): Deleted.
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::setFrameSize):
        (JSC::B3::Air::Code::calleeSaveRegisters):
        * b3/air/AirGenerationContext.h:
        * ftl/FTLB3Compile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLExceptionHandlerManager.cpp:
        (JSC::FTL::ExceptionHandlerManager::lazySlowPathExceptionTarget):
        (JSC::FTL::ExceptionHandlerManager::getCallOSRExitCommon):
        * ftl/FTLExitThunkGenerator.cpp:
        * ftl/FTLExitThunkGenerator.h:
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::JITCode):
        (JSC::FTL::JITCode::initializeB3Code):
        (JSC::FTL::JITCode::initializeB3Byproducts):
        (JSC::FTL::JITCode::initializeExitThunks):
        (JSC::FTL::JITCode::validateReferences):
        (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
        * ftl/FTLJITCode.h:
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * ftl/FTLJITFinalizer.h:
        * ftl/FTLJSCall.cpp:
        (JSC::FTL::JSCall::emit):
        * ftl/FTLJSCallBase.cpp:
        (JSC::FTL::JSCallBase::emit):
        * ftl/FTLJSTailCall.cpp:
        (JSC::FTL::JSTailCall::JSTailCall):
        (JSC::FTL::JSTailCall::emit):
        (JSC::FTL::DFG::getRegisterWithAddend): Deleted.
        (JSC::FTL::m_instructionOffset): Deleted.
        * ftl/FTLJSTailCall.h:
        (JSC::FTL::JSTailCall::patchpoint):
        (JSC::FTL::JSTailCall::stackmapID):
        (JSC::FTL::JSTailCall::estimatedSize):
        (JSC::FTL::JSTailCall::operator<):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
        (JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
        (JSC::FTL::DFG::LowerDFGToLLVM::callStackmap):
        (JSC::FTL::lowerDFGToLLVM):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
        (JSC::FTL::OSRExitDescriptor::validateReferences):
        (JSC::FTL::OSRExitDescriptor::appendOSRExit):
        (JSC::FTL::OSRExitDescriptor::appendOSRExitLater):
        (JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
        (JSC::FTL::OSRExit::OSRExit):
        (JSC::FTL::OSRExit::codeLocationForRepatch):
        (JSC::FTL::OSRExit::gatherRegistersToSpillForCallIfException):
        (JSC::FTL::OSRExit::spillRegistersToSpillSlot):
        (JSC::FTL::OSRExit::recoverRegistersFromSpillSlot):
        (JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck):
        * ftl/FTLOSRExit.h:
        (JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
        * ftl/FTLOSRExitCompilationInfo.h:
        (JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::reboxAccordingToFormat):
        (JSC::FTL::compileRecovery):
        (JSC::FTL::compileStub):
        (JSC::FTL::compileFTLOSRExit):
        * ftl/FTLOSRExitHandle.cpp: Added.
        (JSC::FTL::OSRExitHandle::emitExitThunk):
        * ftl/FTLOSRExitHandle.h: Added.
        (JSC::FTL::OSRExitHandle::OSRExitHandle):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):
        (JSC::FTL::State::~State):

2015-12-03  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION:(r192753): Remote Web Inspector: RemoteInspector::sendMessageToRemote with null connection
        https://bugs.webkit.org/show_bug.cgi?id=151789

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::sendMessageToRemote):
        Bail if the connection is no longer available. It may have
        been closed remotely.

2015-12-03  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION:(r192753): Remote Web Inspector: Window immediately closes after opening
        https://bugs.webkit.org/show_bug.cgi?id=151788

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::pushListingsNow):
        The key at the outer level was not a string. Ensure it is a
        string for backwards compatibility. One day we may use
        non-numeric page identifiers as listing keys.

2015-12-03  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION(r192753): Remote Web Inspector: Enabling Remote Inspection on Auto Inspect candidate Debuggable doesn't show up in debuggers
        https://bugs.webkit.org/show_bug.cgi?id=151792

        Reviewed by Brian Burg.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
        When m_debuggablesMap was split into both m_targetMap and m_listingMap
        this particular case was missed in updating both the target and listing
        when the target is updated. We should match RemoteInspector::updateTarget
        and update the listing map as the debuggable may have changed to be
        allowed to debug.

2015-12-03  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add CLZ support to B3
        https://bugs.webkit.org/show_bug.cgi?id=151799

        Reviewed by Michael Saboff.

        Previously we were counting on LLVM to select LZCNT
        when its available.
        Since we have to do that ourself now, I added feature
        detection based on the CPUID. The MacroAssembler just
        pick the best available lowering based on the platform.

        * assembler/MacroAssemblerX86Common.cpp:
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::countLeadingZeros32):
        (JSC::MacroAssemblerX86Common::supportsLZCNT):
        (JSC::MacroAssemblerX86Common::clz32AfterBsr):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::countLeadingZeros64):
        (JSC::MacroAssemblerX86_64::clz64AfterBsr):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::lzcnt_rr):
        (JSC::X86Assembler::lzcnt_mr):
        (JSC::X86Assembler::lzcntq_rr):
        (JSC::X86Assembler::lzcntq_mr):
        (JSC::X86Assembler::bsr_mr):
        (JSC::X86Assembler::bsrq_rr):
        (JSC::X86Assembler::bsrq_mr):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::typeFor):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::countLeadingZero):
        (JSC::B3::testClzArg64):
        (JSC::B3::testClzMem64):
        (JSC::B3::testClzArg32):
        (JSC::B3::testClzMem32):
        (JSC::B3::doubleOperands):
        (JSC::B3::run):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::ctlz32):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithClz32):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::ctlz32):

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

        Polymorphic operand types for DFG and FTL mul.
        https://bugs.webkit.org/show_bug.cgi?id=151746

        Reviewed by Filip Pizlo.

        Perf on benchmarks is neutral except for the newly added JSRegress ftl-object-mul
        test which shows a 2.16x speed up on x86_64 FTL, 1.27x speed up on x86_64 DFG,
        and 1.56x on x86 DFG. 

        The speed up comes not from the mul operator itself, but from the fact that the
        polymorphic operand types support now allow the test function to run without OSR
        exiting, thereby realizing the DFG and FTL's speed up on other work that the test
        function does.

        This patch has passed the layout tests on x86_64 with a debug build.
        It passed the JSC tests with x86 and x86_64 debug builds.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithMul):
        * ftl/FTLCompile.cpp:
        - Changed to call generateBinaryOpFastPath() instead now, and let it dispatch to
          the appropriate snippet generator.

        * ftl/FTLCompileBinaryOp.cpp:
        (JSC::FTL::generateBinaryArithOpFastPath):
        (JSC::FTL::generateBinaryOpFastPath):
        (JSC::FTL::generateArithSubFastPath): Deleted.
        (JSC::FTL::generateValueAddFastPath): Deleted.
        - Refactored these functions to eliminate the need for copy-pasting every time
          we add support for another binary arithmetic snippet.

        * ftl/FTLCompileBinaryOp.h:
        * ftl/FTLInlineCacheDescriptor.h:
        * ftl/FTLInlineCacheDescriptorInlines.h:
        (JSC::FTL::ArithMulDescriptor::ArithMulDescriptor):
        (JSC::FTL::ArithMulDescriptor::icSize):
        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfArithMul):
        * ftl/FTLInlineCacheSize.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
        * jit/JITMulGenerator.h:
        (JSC::JITMulGenerator::JITMulGenerator):

        * tests/stress/op_mul.js:
        - Updated a test value: the interesting value for imminent overflow from an
          int32 is 0x7fffffff, not 0x7ffffff.

2015-12-02  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION(r192753): Remote Web Inspector: Applications and Debuggables not showing up in debuggers
        https://bugs.webkit.org/show_bug.cgi?id=151787

        Reviewed by Brian Burg.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::receivedIndicateMessage):
        Removed lock that was unnecessarily added in r192753. It was
        protecting nothing.

2015-12-02  Saam barati  <sbarati@apple.com>

        Insert a FIXME comment FTLLazySlowPath.h to remind us to remove/refactor the ScratchRegisterAllocator field.

        Rubber-stamped by Filip Pizlo.

        * ftl/FTLLazySlowPath.h:

2015-12-02  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Remove insertElement() from FTLB3Output
        https://bugs.webkit.org/show_bug.cgi?id=151781

        Reviewed by Sam Weinig.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::insertElement): Deleted.
        That's a LLVM concept.

2015-12-02  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove stuffs related to alloca from FTLB3Output
        https://bugs.webkit.org/show_bug.cgi?id=151780

        Reviewed by Mark Lam.

        We can use the Phis directly with B3 :)

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::alloca): Deleted.
        (JSC::FTL::Output::get): Deleted.
        (JSC::FTL::Output::set): Deleted.

2015-12-02  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Add sin(), cos(), pow() and log() to B3
        https://bugs.webkit.org/show_bug.cgi?id=151778

        Reviewed by Geoffrey Garen.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::doubleSin):
        (JSC::FTL::Output::doubleCos):
        (JSC::FTL::Output::doublePow):
        (JSC::FTL::Output::doubleLog):
        (JSC::FTL::Output::callWithoutSideEffects):

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

        Add a few obvious strength-reductions to Air
        https://bugs.webkit.org/show_bug.cgi?id=151777

        Reviewed by Mark Lam.

        The absence of these optimizations was obnoxious.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::add32): lea 1(reg), reg -> add 1, reg.
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate): Emit simpler prologue/epilogue if !frameSize.
        * b3/air/AirOpcode.opcodes: We have matching for BranchMul32 with immediate, but we forgot to add the instruction form.
        * jit/AssemblyHelpers.h: Support for the prologue/epilogue optimizations.
        (JSC::AssemblyHelpers::emitFunctionPrologue):
        (JSC::AssemblyHelpers::emitFunctionEpilogueWithEmptyFrame):
        (JSC::AssemblyHelpers::emitFunctionEpilogue):

2015-12-02  Benjamin Poulain  <bpoulain@apple.com>

        Update the interface added in r192967

        * b3/B3CCallValue.h:
        Filip prefers explicit effects.
        * b3/testb3.cpp:
        (JSC::B3::testCallSimplePure):

2015-12-02  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add a function attribute for Pure functions in B3
        https://bugs.webkit.org/show_bug.cgi?id=151741

        Reviewed by Geoffrey Garen.

        We have plenty of functions without side effects
        when lowering DFG.
        This patch adds the "PureCall" flag to B3's CCall
        to make sure those functions do not prevent optimizations.

        * b3/B3CCallValue.h:
        * b3/testb3.cpp:
        (JSC::B3::testCallSimplePure):
        (JSC::B3::run):

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

        Removed unnecessary #if USE(JSVALUE64).
        https://bugs.webkit.org/show_bug.cgi?id=151733

        Not reviewed.

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

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

        Use the JITAddGenerator snippet in the FTL.
        https://bugs.webkit.org/show_bug.cgi?id=151519

        Reviewed by Geoffrey Garen.

        One detail about how we choosing to handle operands to the binary snippets that
        may be constant: the slow path call to a C++ function still needs the constant
        operand loaded in a register.  To simplify things, we're choosing to always tell
        LLVM to load the operands into registers even if they may be constant.  However,
        even though a constant operand is preloaded in a register, the snippet generator
        will not be made aware of it.  It will continue to load the constant as an
        immediate.

        * ftl/FTLCompile.cpp:
        * ftl/FTLCompileBinaryOp.cpp:
        (JSC::FTL::generateArithSubFastPath):
        (JSC::FTL::generateValueAddFastPath):
        - generateValueAddFastPath() currently is an exact copy of generateArithSubFastPath()
          except that it uses JITAddGenerator instead of JITSubGenerator.  When we add
          support for JITMulGenerator later, the code will start to vary.  We'll refactor
          these functions then when we have more insight into what needs to vary between
          the implementations.

        * ftl/FTLCompileBinaryOp.h:
        * ftl/FTLInlineCacheDescriptor.h:
        * ftl/FTLInlineCacheDescriptorInlines.h:
        (JSC::FTL::ValueAddDescriptor::ValueAddDescriptor):
        (JSC::FTL::ValueAddDescriptor::icSize):
        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfValueAdd):
        * ftl/FTLInlineCacheSize.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd):

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

        Teach DFG that ArithSub can now clobber the heap (and other things).
        https://bugs.webkit.org/show_bug.cgi?id=151733

        Reviewed by Geoffrey Garen.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):

2015-12-02  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Handle x86 partial register stalls in Air
        https://bugs.webkit.org/show_bug.cgi?id=151735

        Reviewed by Filip Pizlo.

        This patch adds a primitive false-dependency breaking
        algorithm to Air. We look for redefinition of the same
        variable that is too close to a partial definition.

        There is not explicit dependency tracking going on,
        but it is pretty fast and the extra xorps added on false-positives
        are cheap anyway.

        Typically, partial register stalls appear from instructions
        interfering with themselves in small loops. Something like:

          Label0:
            cvtsi2sdq %eax, %xmm0
            ...
            jmp Label0

        Those are correctly detected by propagating the local distance
        information from block to block until no unsafe chain is found.

        The test testInt32ToDoublePartialRegisterStall() checks the kind
        of cases we typically find from JavaScript.
        The execution time is 20% faster with a register reset (which is
        astounding since the very next instruction has a real dependency).

        Future tweaks will be needed when we can run more JavaScript:
        -Handle function calls differently.
        -Anything with a special can have hidden instructions.
         We need to take them into account.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::moveZeroToDouble):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::xorps_rr):
        (JSC::X86Assembler::xorpd_rr):
        According to the documentation, starting with Sandy Bridge,
        registers reset can be done in the frontend with xorps.

        * b3/B3IndexSet.h:
        (JSC::B3::IndexSet::remove):
        * b3/air/AirFixPartialRegisterStalls.cpp: Added.
        (JSC::B3::Air::fixPartialRegisterStalls):
        * b3/air/AirFixPartialRegisterStalls.h: Added.
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        * b3/testb3.cpp:
        (JSC::B3::testInt32ToDoublePartialRegisterStall):
        (JSC::B3::run):
        * jit/FPRInfo.h:

2015-12-01  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement LLInt/Baseline Support for ES6 Generators and enable this feature
        https://bugs.webkit.org/show_bug.cgi?id=150792

        Reviewed by Saam Barati.

        This patch implements basic functionality of ES6 Generators in LLInt and Baseline tiers.
        While the implementation has some inefficient part, the implementation covers edge cases.
        Later, we will make this efficient.

            https://bugs.webkit.org/show_bug.cgi?id=151545
            https://bugs.webkit.org/show_bug.cgi?id=151546
            https://bugs.webkit.org/show_bug.cgi?id=151547
            https://bugs.webkit.org/show_bug.cgi?id=151552
            https://bugs.webkit.org/show_bug.cgi?id=151560
            https://bugs.webkit.org/show_bug.cgi?id=151586

        To encourage DFG / FTL later, we take the following design.

        1. Use switch_imm to jump to the save/resume points.

        Instead of saving / restoring instruction pointer to resume from it, we use switch_imm to jump to the resume point.
        This limits one entry point to a given generator function. This design makes inlining easy.
        The generated code becomes the following.

            function @generatorNext(@generator, @generatorState, @generatorValue, @generatorResumeMode)
            {
                switch (@generatorState) {
                case Initial:
                    ...
                    initial sequence.
                    ...


                    op_save(Yield_0);  // op_save contains *virtual* jump to Yield_0.
                                       // CFG shows a jump edge to Yield_0 point, but it won't be actually used.
                    return ...;

                case Yield_0:
                    op_resume();
                    if (@generatorResumeMode == Throw)
                        ...
                    else if (@generatorResumeMode == Return)
                        ...
                    ...
                    // sentValue is a value sent from a caller by `generator.next(sentValue)`.
                    sentValue = @generatorValue;
                    ...
                    op_save(Yield_1);
                    return ...;

                case Yield_1:
                    op_resume();
                    if (@generatorResumeMode == Throw)
                        ...
                    else if (@generatorResumeMode == Return)
                        ...
                    ...
                    sentValue = @generatorValue;
                    ...

                ...
                }
            }

            Resume sequence should not be emitted per yield.
            This should be done in https://bugs.webkit.org/show_bug.cgi?id=151552.

        2. Store live frame registers to GeneratorFrame

        To save and resume generator's state, we save all the live registers in GeneratorFrame.
        And when resuming, we refill registers with saved ones.
        Since saved register contains scope register, |this| etc., the environment including the scope chain will be recovered automatically.
        While saving and resuming callee registers, we don't save parameter registers.
        These registers will be used to control generator's resume behavior.

        We perform BytecodeLivenessAnalysis in CodeBlock to determine actually *def*ined registers at that resume point.

        3. GeneratorFunction will evaluate parameters before generating Generator

        Generator's parameter should be evaluated before entering Generator's body. For example,

            function hello() { ... }
            function *gen(a, b = hello())
            {
                yield b;
            }
            let g = gen(20);  // Now, hello should be called.

        To enable this, we evaluate parameters in GeneratorFunction, and after that, we create a Generator and return it.
        This can be explained by the following pseudo code.

            function *gen(a, b = hello())
            {
                // This is generator.
                return {
                    @generatorNext: function (@generator, @generatorState, @generatorValue, @generatorResumeMode)
                    {
                        ...
                    }
                }
            }

        4. op_save seems similar to conditional jump

        We won't jump to elsewhere from op_save actually. But we add a *virtual* jump edge (flow) from op_save to the point so called *merge point*.
        We construct the CFG as follows,

            (global generator switch) -> (initial sequence) -> (op_save) ----+-> (merge point) -> (next sequence)*
                   |                                              |          |
                   |                                              v          |
                   |                                           (op_ret)      |
                   |                                                         |
                   +------------------------------------------->(op_resume)--+

        By constructing such a graph,

            1. Since we have a flow from (op_save) to (merge point), at merge point, we can *use* locals that are defined before (op_save)
            2. op_save should claim that it does not define anything. And claim that it *use*s locals that are used in (merge point).
            3. at op_resume, we see *use*d locals at merge point and define all of them.

        We can do the above things in use-def analysis because use-def analysis is backward analysis.
        And after analyzing use-def chains, in op_save / op_resume, we only save / resume live registers at the head of merge point.

        * API/JSScriptRef.cpp:
        (parseScript):
        * CMakeLists.txt:
        * Configurations/FeatureDefines.xcconfig:
        * DerivedSources.make:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinExecutables.cpp:
        (JSC::createExecutableInternal):
        * builtins/GeneratorPrototype.js: Added.
        (generatorResume):
        (next):
        (return):
        (throw):
        * bytecode/BytecodeBasicBlock.cpp:
        (JSC::isBranch):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::stepOverInstruction):
        (JSC::computeLocalLivenessForBytecodeOffset):
        (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
        (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
        (JSC::BytecodeLivenessAnalysis::computeKills):
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::shrinkToFit):
        (JSC::CodeBlock::validate):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::numCalleeLocals):
        (JSC::CodeBlock::liveCalleeLocalsAtYield):
        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::tryGet):
        (JSC::EvalCodeCache::getSlow):
        (JSC::EvalCodeCache::isCacheable):
        * bytecode/ExecutableInfo.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::generatorThisMode):
        (JSC::ExecutableInfo::superBinding):
        (JSC::ExecutableInfo::parseMode):
        (JSC::ExecutableInfo::isArrowFunction): Deleted.
        * bytecode/PreciseJumpTargets.cpp:
        (JSC::getJumpTargetsForBytecodeOffset):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::parseMode):
        (JSC::UnlinkedCodeBlock::generatorThisMode):
        (JSC::UnlinkedCodeBlock::superBinding):
        (JSC::UnlinkedCodeBlock::isArrowFunction): Deleted.
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeParameters):
        (JSC::BytecodeGenerator::newRegister):
        (JSC::BytecodeGenerator::reclaimFreeRegisters):
        (JSC::BytecodeGenerator::createVariable):
        (JSC::BytecodeGenerator::emitCreateThis):
        (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
        (JSC::BytecodeGenerator::emitNewFunctionExpression):
        (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
        (JSC::BytecodeGenerator::emitNewFunction):
        (JSC::BytecodeGenerator::emitIteratorNextWithValue):
        (JSC::BytecodeGenerator::emitYieldPoint):
        (JSC::BytecodeGenerator::emitSave):
        (JSC::BytecodeGenerator::emitResume):
        (JSC::BytecodeGenerator::emitYield):
        (JSC::BytecodeGenerator::emitDelegateYield):
        (JSC::BytecodeGenerator::emitGeneratorStateChange):
        (JSC::BytecodeGenerator::emitGeneratorStateLabel):
        (JSC::BytecodeGenerator::beginGenerator):
        (JSC::BytecodeGenerator::endGenerator):
        (JSC::BytecodeGenerator::emitNewFunctionInternal): Deleted.
        (JSC::BytecodeGenerator::emitNewFunctionCommon): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::generatorThisMode):
        (JSC::BytecodeGenerator::superBinding):
        (JSC::BytecodeGenerator::generatorRegister):
        (JSC::BytecodeGenerator::generatorStateRegister):
        (JSC::BytecodeGenerator::generatorValueRegister):
        (JSC::BytecodeGenerator::generatorResumeModeRegister):
        (JSC::BytecodeGenerator::parseMode):
        (JSC::BytecodeGenerator::registerFor):
        (JSC::BytecodeGenerator::makeFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode):
        (JSC::emitHomeObjectForCallee):
        (JSC::emitSuperBaseForCallee):
        (JSC::ReturnNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode):
        (JSC::YieldExprNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::ByteCodeParser):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::handlePutById):
        * dfg/DFGForAllKills.h:
        (JSC::DFG::forAllKilledOperands):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
        * dfg/DFGOSREntrypointCreationPhase.cpp:
        (JSC::DFG::OSREntrypointCreationPhase::run):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::reconstruct):
        * ftl/FTLForOSREntryJITCode.cpp:
        (JSC::FTL::ForOSREntryJITCode::initializeEntryBuffer):
        * ftl/FTLForOSREntryJITCode.h:
        * ftl/FTLOSREntry.cpp:
        (JSC::FTL::prepareOSREntry):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::isAtom):
        (JSC::MarkedBlock::isLiveCell):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        (JSC::Interpreter::dumpRegisters):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::frameRegisterCountFor):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitNewFuncCommon):
        (JSC::JIT::emit_op_new_func):
        (JSC::JIT::emit_op_new_generator_func):
        (JSC::JIT::emitNewFuncExprCommon):
        (JSC::JIT::emit_op_new_func_exp):
        (JSC::JIT::emit_op_new_generator_func_exp):
        (JSC::JIT::emit_op_save):
        (JSC::JIT::emit_op_resume):
        * jit/JITOperations.cpp:
        (JSC::operationNewFunctionCommon):
        * jit/JITOperations.h:
        * llint/LLIntEntrypoint.cpp:
        (JSC::LLInt::frameRegisterCountFor):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::traceFunctionPrologue):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createYield):
        (JSC::ASTBuilder::createFunctionMetadata):
        (JSC::ASTBuilder::propagateArgumentsUse):
        * parser/Nodes.cpp:
        (JSC::FunctionMetadataNode::FunctionMetadataNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
        (JSC::Parser<LexerType>::parseFunctionBody):
        (JSC::stringForFunctionMode):
        (JSC::Parser<LexerType>::createGeneratorParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseYieldExpression):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parseFunctionExpression):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::setSourceParseMode):
        (JSC::Scope::hasArguments):
        (JSC::Scope::collectFreeVariables):
        (JSC::Scope::setIsFunction):
        (JSC::Scope::setIsGeneratorFunction):
        (JSC::Scope::setIsGenerator):
        (JSC::parse):
        * parser/ParserModes.h:
        (JSC::isFunctionParseMode):
        (JSC::isModuleParseMode):
        (JSC::isProgramParseMode):
        * parser/SourceCodeKey.h: Added.
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::isHashTableDeletedValue):
        (JSC::SourceCodeKey::hash):
        (JSC::SourceCodeKey::length):
        (JSC::SourceCodeKey::isNull):
        (JSC::SourceCodeKey::string):
        (JSC::SourceCodeKey::operator==):
        (JSC::SourceCodeKeyHash::hash):
        (JSC::SourceCodeKeyHash::equal):
        (JSC::SourceCodeKeyHashTraits::isEmptyValue):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createYield):
        (JSC::SyntaxChecker::createFunctionMetadata):
        (JSC::SyntaxChecker::operatorStackPop):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        (JSC::SourceCodeKey::SourceCodeKey): Deleted.
        (JSC::SourceCodeKey::isHashTableDeletedValue): Deleted.
        (JSC::SourceCodeKey::hash): Deleted.
        (JSC::SourceCodeKey::length): Deleted.
        (JSC::SourceCodeKey::isNull): Deleted.
        (JSC::SourceCodeKey::string): Deleted.
        (JSC::SourceCodeKey::operator==): Deleted.
        (JSC::SourceCodeKeyHash::hash): Deleted.
        (JSC::SourceCodeKeyHash::equal): Deleted.
        (JSC::SourceCodeKeyHashTraits::isEmptyValue): Deleted.
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        (JSC::checkModuleSyntax):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ProgramExecutable::checkSyntax):
        * runtime/Executable.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunction):
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionConstructor.h:
        * runtime/GeneratorFrame.cpp: Added.
        (JSC::GeneratorFrame::GeneratorFrame):
        (JSC::GeneratorFrame::finishCreation):
        (JSC::GeneratorFrame::createStructure):
        (JSC::GeneratorFrame::create):
        (JSC::GeneratorFrame::save):
        (JSC::GeneratorFrame::resume):
        (JSC::GeneratorFrame::visitChildren):
        * runtime/GeneratorFrame.h: Added.
        (JSC::GeneratorFrame::locals):
        (JSC::GeneratorFrame::localAt):
        (JSC::GeneratorFrame::offsetOfLocals):
        (JSC::GeneratorFrame::allocationSizeForLocals):
        * runtime/GeneratorFunctionConstructor.cpp: Added.
        (JSC::GeneratorFunctionConstructor::GeneratorFunctionConstructor):
        (JSC::GeneratorFunctionConstructor::finishCreation):
        (JSC::callGeneratorFunctionConstructor):
        (JSC::constructGeneratorFunctionConstructor):
        (JSC::GeneratorFunctionConstructor::getCallData):
        (JSC::GeneratorFunctionConstructor::getConstructData):
        * runtime/GeneratorFunctionConstructor.h: Added.
        (JSC::GeneratorFunctionConstructor::create):
        (JSC::GeneratorFunctionConstructor::createStructure):
        * runtime/GeneratorFunctionPrototype.cpp: Added.
        (JSC::GeneratorFunctionPrototype::GeneratorFunctionPrototype):
        (JSC::GeneratorFunctionPrototype::finishCreation):
        * runtime/GeneratorFunctionPrototype.h: Added.
        (JSC::GeneratorFunctionPrototype::create):
        (JSC::GeneratorFunctionPrototype::createStructure):
        * runtime/GeneratorPrototype.cpp: Copied from Source/JavaScriptCore/ftl/FTLForOSREntryJITCode.cpp.
        (JSC::GeneratorPrototype::finishCreation):
        (JSC::GeneratorPrototype::getOwnPropertySlot):
        * runtime/GeneratorPrototype.h: Copied from Source/JavaScriptCore/ftl/FTLForOSREntryJITCode.cpp.
        (JSC::GeneratorPrototype::create):
        (JSC::GeneratorPrototype::createStructure):
        (JSC::GeneratorPrototype::GeneratorPrototype):
        * runtime/GeneratorThisMode.h: Added.
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertySlot):
        * runtime/JSGeneratorFunction.cpp: Added.
        (JSC::JSGeneratorFunction::JSGeneratorFunction):
        (JSC::JSGeneratorFunction::createImpl):
        (JSC::JSGeneratorFunction::create):
        (JSC::JSGeneratorFunction::createWithInvalidatedReallocationWatchpoint):
        * runtime/JSGeneratorFunction.h: Added.
        (JSC::JSGeneratorFunction::allocationSize):
        (JSC::JSGeneratorFunction::createStructure):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::generatorFunctionPrototype):
        (JSC::JSGlobalObject::generatorPrototype):
        (JSC::JSGlobalObject::generatorFunctionStructure):
        * runtime/ModuleLoaderObject.cpp:
        (JSC::moduleLoaderObjectParseModule):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * tests/es6.yaml:
        * tests/es6/generators_yield_star_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/generators_yield_star_instances_of_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/generators_yield_star_iterator_closing.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/generators_yield_star_iterator_closing_via_throw.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/stress/generator-arguments-from-function.js: Added.
        (shouldBe):
        (test):
        * tests/stress/generator-arguments.js: Added.
        (shouldBe):
        (g1):
        * tests/stress/generator-class-methods-syntax.js: Added.
        (testSyntax):
        (testSyntaxError):
        (testSyntaxError.Cocoa):
        (testSyntax.Cocoa.prototype.ok):
        (testSyntax.Cocoa):
        (testSyntax.Cocoa.ok):
        * tests/stress/generator-class-methods.js: Added.
        (shouldBe):
        (prototype.gen):
        (staticGen):
        (shouldBe.g.next):
        * tests/stress/generator-eval-this.js: Added.
        (shouldBe):
        (shouldThrow):
        (B):
        (A):
        (C.prototype.generator):
        (C):
        (TypeError):
        * tests/stress/generator-function-constructor.js: Added.
        (shouldBe):
        (generatorFunctionConstructor):
        * tests/stress/generator-function-name.js: Added.
        (shouldBe):
        (ok):
        * tests/stress/generator-methods-with-non-generator.js: Added.
        (shouldThrow):
        * tests/stress/generator-relations.js: Added.
        (shouldBe):
        (generatorFunction):
        * tests/stress/generator-return-before-first-call.js: Added.
        (shouldBe):
        (shouldBeIteratorResult):
        * tests/stress/generator-return.js: Added.
        (shouldBe):
        (shouldBeIteratorResult):
        * tests/stress/generator-this.js: Added.
        (shouldBe):
        (shouldThrow):
        (gen):
        (shouldBe.g.next):
        * tests/stress/generator-throw-before-first-call.js: Added.
        (unreachable):
        (gen):
        (catch):
        * tests/stress/generator-throw.js: Added.
        (shouldBe):
        (shouldBeIteratorResult):
        * tests/stress/generator-with-new-target.js: Added.
        (shouldBe):
        (gen):
        * tests/stress/generator-with-super.js: Added.
        (shouldThrow):
        (test):
        (B.prototype.gen):
        (B):
        (A.prototype.gen):
        (A):
        * tests/stress/generator-yield-star.js: Added.
        (shouldBe):
        (shouldThrow):
        (prototype.call):
        (Arrays):
        (Arrays.prototype.Symbol.iterator):
        (Iterator.prototype.next):
        (Iterator.prototype.string_appeared_here):
        (Iterator.prototype.Symbol.iterator):
        (Iterator):
        (gen):

2015-12-01  Commit Queue  <commit-queue@webkit.org>

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

        JSC tests for this change are failing on 32 and 64-bit bots
        (Requested by ryanhaddad on #webkit).

        Reverted changeset:

        "[ES6] Implement LLInt/Baseline Support for ES6 Generators and
        enable this feature"
        https://bugs.webkit.org/show_bug.cgi?id=150792
        http://trac.webkit.org/changeset/192914

2015-12-01  Caitlin Potter  <caitpotter88@gmail.com>

        [JSC] support CoverInitializedName in nested AssignmentPatterns
        https://bugs.webkit.org/show_bug.cgi?id=151595

        Reviewed by Geoffrey Garen.

        A regression introduced in bug https://bugs.webkit.org/show_bug.cgi?id=151026
        causes the parser to fail when attempting to parse nested
        ObjectAssignmentPatterns with CoverInitializedName destructuring targets.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseAssignmentExpressionOrPropagateErrorClass):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parseArrayLiteral):
        * parser/Parser.h:
        (JSC::Parser::ExpressionErrorClassifier::propagateExpressionErrorClass):
        * tests/es6.yaml:
        * tests/es6/destructuring_assignment_nested_cover_initialized_name.js: Added.
        (test1):
        (test2):

2015-12-01  Juergen Ributzka  <juergen@apple.com>

        Add new library dependency for LLVMForJavaScriptCore dylib
        https://bugs.webkit.org/show_bug.cgi?id=151687
        
        Changes on open source LLVM added a new dependency to libLLVMInstrumentation.a.
        Adding this dependency should be backwards compatible, since LLVM has built and
        shipped this library even before the creation of FTL.

        Reviewed by Geoffrey Garen.

        * Configurations/LLVMForJSC.xcconfig:

2015-12-01  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement LLInt/Baseline Support for ES6 Generators and enable this feature
        https://bugs.webkit.org/show_bug.cgi?id=150792

        Reviewed by Saam Barati.

        This patch implements basic functionality of ES6 Generators in LLInt and Baseline tiers.
        While the implementation has some inefficient part, the implementation covers edge cases.
        Later, we will make this efficient.

            https://bugs.webkit.org/show_bug.cgi?id=151545
            https://bugs.webkit.org/show_bug.cgi?id=151546
            https://bugs.webkit.org/show_bug.cgi?id=151547
            https://bugs.webkit.org/show_bug.cgi?id=151552
            https://bugs.webkit.org/show_bug.cgi?id=151560
            https://bugs.webkit.org/show_bug.cgi?id=151586

        To encourage DFG / FTL later, we take the following design.

        1. Use switch_imm to jump to the save/resume points.

        Instead of saving / restoring instruction pointer to resume from it, we use switch_imm to jump to the resume point.
        This limits one entry point to a given generator function. This design makes inlining easy.
        The generated code becomes the following.

            function @generatorNext(@generator, @generatorState, @generatorValue, @generatorResumeMode)
            {
                switch (@generatorState) {
                case Initial:
                    ...
                    initial sequence.
                    ...


                    op_save(Yield_0);  // op_save contains *virtual* jump to Yield_0.
                                       // CFG shows a jump edge to Yield_0 point, but it won't be actually used.
                    return ...;

                case Yield_0:
                    op_resume();
                    if (@generatorResumeMode == Throw)
                        ...
                    else if (@generatorResumeMode == Return)
                        ...
                    ...
                    // sentValue is a value sent from a caller by `generator.next(sentValue)`.
                    sentValue = @generatorValue;
                    ...
                    op_save(Yield_1);
                    return ...;

                case Yield_1:
                    op_resume();
                    if (@generatorResumeMode == Throw)
                        ...
                    else if (@generatorResumeMode == Return)
                        ...
                    ...
                    sentValue = @generatorValue;
                    ...

                ...
                }
            }

            Resume sequence should not be emitted per yield.
            This should be done in https://bugs.webkit.org/show_bug.cgi?id=151552.

        2. Store live frame registers to GeneratorFrame

        To save and resume generator's state, we save all the live registers in GeneratorFrame.
        And when resuming, we refill registers with saved ones.
        Since saved register contains scope register, |this| etc., the environment including the scope chain will be recovered automatically.
        While saving and resuming callee registers, we don't save parameter registers.
        These registers will be used to control generator's resume behavior.

        We perform BytecodeLivenessAnalysis in CodeBlock to determine actually *def*ined registers at that resume point.

        3. GeneratorFunction will evaluate parameters before generating Generator

        Generator's parameter should be evaluated before entering Generator's body. For example,

            function hello() { ... }
            function *gen(a, b = hello())
            {
                yield b;
            }
            let g = gen(20);  // Now, hello should be called.

        To enable this, we evaluate parameters in GeneratorFunction, and after that, we create a Generator and return it.
        This can be explained by the following pseudo code.

            function *gen(a, b = hello())
            {
                // This is generator.
                return {
                    @generatorNext: function (@generator, @generatorState, @generatorValue, @generatorResumeMode)
                    {
                        ...
                    }
                }
            }

        4. op_save seems similar to conditional jump

        We won't jump to elsewhere from op_save actually. But we add a *virtual* jump edge (flow) from op_save to the point so called *merge point*.
        We construct the CFG as follows,

            (global generator switch) -> (initial sequence) -> (op_save) ----+-> (merge point) -> (next sequence)*
                   |                                              |          |
                   |                                              v          |
                   |                                           (op_ret)      |
                   |                                                         |
                   +------------------------------------------->(op_resume)--+

        By constructing such a graph,

            1. Since we have a flow from (op_save) to (merge point), at merge point, we can *use* locals that are defined before (op_save)
            2. op_save should claim that it does not define anything. And claim that it *use*s locals that are used in (merge point).
            3. at op_resume, we see *use*d locals at merge point and define all of them.

        We can do the above things in use-def analysis because use-def analysis is backward analysis.
        And after analyzing use-def chains, in op_save / op_resume, we only save / resume live registers at the head of merge point.

        * API/JSScriptRef.cpp:
        (parseScript):
        * CMakeLists.txt:
        * Configurations/FeatureDefines.xcconfig:
        * DerivedSources.make:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinExecutables.cpp:
        (JSC::createExecutableInternal):
        * builtins/GeneratorPrototype.js: Added.
        (generatorResume):
        (next):
        (return):
        (throw):
        * bytecode/BytecodeBasicBlock.cpp:
        (JSC::isBranch):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::stepOverInstruction):
        (JSC::computeLocalLivenessForBytecodeOffset):
        (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
        (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
        (JSC::BytecodeLivenessAnalysis::computeKills):
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::shrinkToFit):
        (JSC::CodeBlock::validate):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::numCalleeLocals):
        (JSC::CodeBlock::liveCalleeLocalsAtYield):
        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::tryGet):
        (JSC::EvalCodeCache::getSlow):
        (JSC::EvalCodeCache::isCacheable):
        * bytecode/ExecutableInfo.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::generatorThisMode):
        (JSC::ExecutableInfo::superBinding):
        (JSC::ExecutableInfo::parseMode):
        (JSC::ExecutableInfo::isArrowFunction): Deleted.
        * bytecode/PreciseJumpTargets.cpp:
        (JSC::getJumpTargetsForBytecodeOffset):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::parseMode):
        (JSC::UnlinkedCodeBlock::generatorThisMode):
        (JSC::UnlinkedCodeBlock::superBinding):
        (JSC::UnlinkedCodeBlock::isArrowFunction): Deleted.
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeParameters):
        (JSC::BytecodeGenerator::newRegister):
        (JSC::BytecodeGenerator::reclaimFreeRegisters):
        (JSC::BytecodeGenerator::createVariable):
        (JSC::BytecodeGenerator::emitCreateThis):
        (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
        (JSC::BytecodeGenerator::emitNewFunctionExpression):
        (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
        (JSC::BytecodeGenerator::emitNewFunction):
        (JSC::BytecodeGenerator::emitIteratorNextWithValue):
        (JSC::BytecodeGenerator::emitYieldPoint):
        (JSC::BytecodeGenerator::emitSave):
        (JSC::BytecodeGenerator::emitResume):
        (JSC::BytecodeGenerator::emitYield):
        (JSC::BytecodeGenerator::emitDelegateYield):
        (JSC::BytecodeGenerator::emitGeneratorStateChange):
        (JSC::BytecodeGenerator::emitGeneratorStateLabel):
        (JSC::BytecodeGenerator::beginGenerator):
        (JSC::BytecodeGenerator::endGenerator):
        (JSC::BytecodeGenerator::emitNewFunctionInternal): Deleted.
        (JSC::BytecodeGenerator::emitNewFunctionCommon): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::generatorThisMode):
        (JSC::BytecodeGenerator::superBinding):
        (JSC::BytecodeGenerator::generatorRegister):
        (JSC::BytecodeGenerator::generatorStateRegister):
        (JSC::BytecodeGenerator::generatorValueRegister):
        (JSC::BytecodeGenerator::generatorResumeModeRegister):
        (JSC::BytecodeGenerator::parseMode):
        (JSC::BytecodeGenerator::registerFor):
        (JSC::BytecodeGenerator::makeFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode):
        (JSC::emitHomeObjectForCallee):
        (JSC::emitSuperBaseForCallee):
        (JSC::ReturnNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode):
        (JSC::YieldExprNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::ByteCodeParser):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::handlePutById):
        * dfg/DFGForAllKills.h:
        (JSC::DFG::forAllKilledOperands):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
        * dfg/DFGOSREntrypointCreationPhase.cpp:
        (JSC::DFG::OSREntrypointCreationPhase::run):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::reconstruct):
        * ftl/FTLForOSREntryJITCode.cpp:
        (JSC::FTL::ForOSREntryJITCode::initializeEntryBuffer):
        * ftl/FTLForOSREntryJITCode.h:
        * ftl/FTLOSREntry.cpp:
        (JSC::FTL::prepareOSREntry):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::isAtom):
        (JSC::MarkedBlock::isLiveCell):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        (JSC::Interpreter::dumpRegisters):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::frameRegisterCountFor):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitNewFuncCommon):
        (JSC::JIT::emit_op_new_func):
        (JSC::JIT::emit_op_new_generator_func):
        (JSC::JIT::emitNewFuncExprCommon):
        (JSC::JIT::emit_op_new_func_exp):
        (JSC::JIT::emit_op_new_generator_func_exp):
        (JSC::JIT::emit_op_save):
        (JSC::JIT::emit_op_resume):
        * jit/JITOperations.cpp:
        (JSC::operationNewFunctionCommon):
        * jit/JITOperations.h:
        * llint/LLIntEntrypoint.cpp:
        (JSC::LLInt::frameRegisterCountFor):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::traceFunctionPrologue):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createYield):
        (JSC::ASTBuilder::createFunctionMetadata):
        (JSC::ASTBuilder::propagateArgumentsUse):
        * parser/Nodes.cpp:
        (JSC::FunctionMetadataNode::FunctionMetadataNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
        (JSC::Parser<LexerType>::parseFunctionBody):
        (JSC::stringForFunctionMode):
        (JSC::Parser<LexerType>::createGeneratorParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseYieldExpression):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parseFunctionExpression):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::setSourceParseMode):
        (JSC::Scope::hasArguments):
        (JSC::Scope::collectFreeVariables):
        (JSC::Scope::setIsFunction):
        (JSC::Scope::setIsGeneratorFunction):
        (JSC::Scope::setIsGenerator):
        (JSC::parse):
        * parser/ParserModes.h:
        (JSC::isFunctionParseMode):
        (JSC::isModuleParseMode):
        (JSC::isProgramParseMode):
        * parser/SourceCodeKey.h: Added.
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::isHashTableDeletedValue):
        (JSC::SourceCodeKey::hash):
        (JSC::SourceCodeKey::length):
        (JSC::SourceCodeKey::isNull):
        (JSC::SourceCodeKey::string):
        (JSC::SourceCodeKey::operator==):
        (JSC::SourceCodeKeyHash::hash):
        (JSC::SourceCodeKeyHash::equal):
        (JSC::SourceCodeKeyHashTraits::isEmptyValue):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createYield):
        (JSC::SyntaxChecker::createFunctionMetadata):
        (JSC::SyntaxChecker::operatorStackPop):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        (JSC::SourceCodeKey::SourceCodeKey): Deleted.
        (JSC::SourceCodeKey::isHashTableDeletedValue): Deleted.
        (JSC::SourceCodeKey::hash): Deleted.
        (JSC::SourceCodeKey::length): Deleted.
        (JSC::SourceCodeKey::isNull): Deleted.
        (JSC::SourceCodeKey::string): Deleted.
        (JSC::SourceCodeKey::operator==): Deleted.
        (JSC::SourceCodeKeyHash::hash): Deleted.
        (JSC::SourceCodeKeyHash::equal): Deleted.
        (JSC::SourceCodeKeyHashTraits::isEmptyValue): Deleted.
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        (JSC::checkModuleSyntax):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ProgramExecutable::checkSyntax):
        * runtime/Executable.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunction):
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionConstructor.h:
        * runtime/GeneratorFrame.cpp: Added.
        (JSC::GeneratorFrame::GeneratorFrame):
        (JSC::GeneratorFrame::finishCreation):
        (JSC::GeneratorFrame::createStructure):
        (JSC::GeneratorFrame::create):
        (JSC::GeneratorFrame::save):
        (JSC::GeneratorFrame::resume):
        (JSC::GeneratorFrame::visitChildren):
        * runtime/GeneratorFrame.h: Added.
        (JSC::GeneratorFrame::locals):
        (JSC::GeneratorFrame::localAt):
        (JSC::GeneratorFrame::offsetOfLocals):
        (JSC::GeneratorFrame::allocationSizeForLocals):
        * runtime/GeneratorFunctionConstructor.cpp: Added.
        (JSC::GeneratorFunctionConstructor::GeneratorFunctionConstructor):
        (JSC::GeneratorFunctionConstructor::finishCreation):
        (JSC::callGeneratorFunctionConstructor):
        (JSC::constructGeneratorFunctionConstructor):
        (JSC::GeneratorFunctionConstructor::getCallData):
        (JSC::GeneratorFunctionConstructor::getConstructData):
        * runtime/GeneratorFunctionConstructor.h: Added.
        (JSC::GeneratorFunctionConstructor::create):
        (JSC::GeneratorFunctionConstructor::createStructure):
        * runtime/GeneratorFunctionPrototype.cpp: Added.
        (JSC::GeneratorFunctionPrototype::GeneratorFunctionPrototype):
        (JSC::GeneratorFunctionPrototype::finishCreation):
        * runtime/GeneratorFunctionPrototype.h: Added.
        (JSC::GeneratorFunctionPrototype::create):
        (JSC::GeneratorFunctionPrototype::createStructure):
        * runtime/GeneratorPrototype.cpp: Copied from Source/JavaScriptCore/ftl/FTLForOSREntryJITCode.cpp.
        (JSC::GeneratorPrototype::finishCreation):
        (JSC::GeneratorPrototype::getOwnPropertySlot):
        * runtime/GeneratorPrototype.h: Copied from Source/JavaScriptCore/ftl/FTLForOSREntryJITCode.cpp.
        (JSC::GeneratorPrototype::create):
        (JSC::GeneratorPrototype::createStructure):
        (JSC::GeneratorPrototype::GeneratorPrototype):
        * runtime/GeneratorThisMode.h: Added.
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertySlot):
        * runtime/JSGeneratorFunction.cpp: Added.
        (JSC::JSGeneratorFunction::JSGeneratorFunction):
        (JSC::JSGeneratorFunction::createImpl):
        (JSC::JSGeneratorFunction::create):
        (JSC::JSGeneratorFunction::createWithInvalidatedReallocationWatchpoint):
        * runtime/JSGeneratorFunction.h: Added.
        (JSC::JSGeneratorFunction::allocationSize):
        (JSC::JSGeneratorFunction::createStructure):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::generatorFunctionPrototype):
        (JSC::JSGlobalObject::generatorPrototype):
        (JSC::JSGlobalObject::generatorFunctionStructure):
        * runtime/ModuleLoaderObject.cpp:
        (JSC::moduleLoaderObjectParseModule):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * tests/es6.yaml:
        * tests/es6/generators_yield_star_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/generators_yield_star_instances_of_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/generators_yield_star_iterator_closing.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/generators_yield_star_iterator_closing_via_throw.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/stress/generator-arguments-from-function.js: Added.
        (shouldBe):
        (test):
        * tests/stress/generator-arguments.js: Added.
        (shouldBe):
        (g1):
        * tests/stress/generator-class-methods-syntax.js: Added.
        (testSyntax):
        (testSyntaxError):
        (testSyntaxError.Cocoa):
        (testSyntax.Cocoa.prototype.ok):
        (testSyntax.Cocoa):
        (testSyntax.Cocoa.ok):
        * tests/stress/generator-class-methods.js: Added.
        (shouldBe):
        (prototype.gen):
        (staticGen):
        (shouldBe.g.next):
        * tests/stress/generator-eval-this.js: Added.
        (shouldBe):
        (shouldThrow):
        (B):
        (A):
        (C.prototype.generator):
        (C):
        (TypeError):
        * tests/stress/generator-function-constructor.js: Added.
        (shouldBe):
        (generatorFunctionConstructor):
        * tests/stress/generator-function-name.js: Added.
        (shouldBe):
        (ok):
        * tests/stress/generator-methods-with-non-generator.js: Added.
        (shouldThrow):
        * tests/stress/generator-relations.js: Added.
        (shouldBe):
        (generatorFunction):
        * tests/stress/generator-return-before-first-call.js: Added.
        (shouldBe):
        (shouldBeIteratorResult):
        * tests/stress/generator-return.js: Added.
        (shouldBe):
        (shouldBeIteratorResult):
        * tests/stress/generator-this.js: Added.
        (shouldBe):
        (shouldThrow):
        (gen):
        (shouldBe.g.next):
        * tests/stress/generator-throw-before-first-call.js: Added.
        (unreachable):
        (gen):
        (catch):
        * tests/stress/generator-throw.js: Added.
        (shouldBe):
        (shouldBeIteratorResult):
        * tests/stress/generator-with-new-target.js: Added.
        (shouldBe):
        (gen):
        * tests/stress/generator-with-super.js: Added.
        (shouldThrow):
        (test):
        (B.prototype.gen):
        (B):
        (A.prototype.gen):
        (A):
        * tests/stress/generator-yield-star.js: Added.
        (shouldBe):
        (shouldThrow):
        (prototype.call):
        (Arrays):
        (Arrays.prototype.Symbol.iterator):
        (Iterator.prototype.next):
        (Iterator.prototype.string_appeared_here):
        (Iterator.prototype.Symbol.iterator):
        (Iterator):
        (gen):

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

        Remove repetitive cruft from FTL OSR exit code in LowerDFGToLLVM
        https://bugs.webkit.org/show_bug.cgi?id=151718

        Reviewed by Geoffrey Garen.

        * b3/B3StackmapValue.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
        (JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
        (JSC::FTL::DFG::LowerDFGToLLVM::callStackmap):

2015-12-01  Caitlin Potter  <caitp@igalia.com>

        [JSC] add missing RequireObjectCoercible() step in destructuring
        https://bugs.webkit.org/show_bug.cgi?id=151596

        Reviewed by Darin Adler.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitRequireObjectCoercible):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ObjectPatternNode::bindValue):
        * tests/stress/destructuring-assignment-require-object-coercible.js: Added.
        (testTypeError):
        (testOK):

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

        Refactor FTL sub snippet code to support general binary op snippets.
        https://bugs.webkit.org/show_bug.cgi?id=151706

        Reviewed by Geoffrey Garen.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:

        * ftl/FTLCompile.cpp:
        - Moved the BinarySnippetRegisterContext to FTLCompileBinaryOp.cpp verbatim.
        - Generalize generateArithSubICFastPath() to generateBinaryOpICFastPath().
          It now uses snippet specific helpers in FTLCompileBinaryOp.cpp to generate
          the fast paths.

        * ftl/FTLCompileBinaryOp.cpp: Added.
        (JSC::FTL::BinarySnippetRegisterContext::BinarySnippetRegisterContext):
        (JSC::FTL::BinarySnippetRegisterContext::initializeRegisters):
        (JSC::FTL::BinarySnippetRegisterContext::restoreRegisters):
        - Moved here without changed from FTLCompile.cpp.
        (JSC::FTL::generateArithSubFastPath):
        * ftl/FTLCompileBinaryOp.h: Added.

        * ftl/FTLInlineCacheDescriptor.h:
        (JSC::FTL::BinaryOpDescriptor::nodeType):
        (JSC::FTL::BinaryOpDescriptor::size):
        (JSC::FTL::BinaryOpDescriptor::name):
        (JSC::FTL::BinaryOpDescriptor::fastPathICName):
        (JSC::FTL::BinaryOpDescriptor::slowPathFunction):
        (JSC::FTL::BinaryOpDescriptor::leftOperand):
        (JSC::FTL::BinaryOpDescriptor::rightOperand):
        (JSC::FTL::BinaryOpDescriptor::BinaryOpDescriptor):
        (JSC::FTL::ArithSubDescriptor::ArithSubDescriptor): Deleted.
        (JSC::FTL::ArithSubDescriptor::leftType): Deleted.
        (JSC::FTL::ArithSubDescriptor::rightType): Deleted.
        - Refactor ArithSubDescriptor into BinaryOpDescriptor, and re-add a sub-class
          ArithSubDescriptor as specializations of BinaryOpDescriptor.

        * ftl/FTLInlineCacheDescriptorInlines.h: Added.
        (JSC::FTL::ArithSubDescriptor::ArithSubDescriptor):
        (JSC::FTL::ArithSubDescriptor::icSize):

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck):
        (JSC::FTL::OSRExit::willArriveAtOSRExitFromCallOperation):
        * ftl/FTLOSRExit.h:
        * ftl/FTLState.h:

2015-12-01  Carlos Garcia Campos  <cgarcia@igalia.com>

        Unreviewed, rolling out r192876.

        It broke a lot of JSC and layout tests for GTK and EFL

        Reverted changeset:

        "[ES6] "super" and "this" should be lexically bound inside an
        arrow function and should live in a JSLexicalEnvironment"
        https://bugs.webkit.org/show_bug.cgi?id=149338
        http://trac.webkit.org/changeset/192876

2015-12-01 Aleksandr Skachkov   <gskachkov@gmail.com>

        [ES6] "super" and "this" should be lexically bound inside an arrow function and should live in a JSLexicalEnvironment
        https://bugs.webkit.org/show_bug.cgi?id=149338

        Reviewed by Saam Barati.

        Implemented new version of the lexically bound 'this' in arrow function. In current version 
        'this' is stored inside of the lexical environment of the function. To store and load we use
        op_get_from_scope and op_put_to_scope operations. Also new implementation prevent raising TDZ
        error for arrow functions that are declared before super() but invoke after.

        * builtins/BuiltinExecutables.cpp:
        (JSC::createExecutableInternal):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::getSlow):
        * bytecode/ExecutableInfo.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::isDerivedConstructorContext):
        (JSC::ExecutableInfo::isArrowFunctionContext):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::isDerivedConstructorContext):
        (JSC::UnlinkedCodeBlock::isArrowFunctionContext):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::variable):
        (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadThisFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::isDerivedConstructorContext):
        (JSC::BytecodeGenerator::usesArrowFunction):
        (JSC::BytecodeGenerator::needsToUpdateArrowFunctionContext):
        (JSC::BytecodeGenerator::usesEval):
        (JSC::BytecodeGenerator::usesThis):
        (JSC::BytecodeGenerator::newTarget):
        (JSC::BytecodeGenerator::makeFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode):
        (JSC::SuperNode::emitBytecode):
        (JSC::EvalFunctionCallNode::emitBytecode):
        (JSC::FunctionCallValueNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluate):
        * dfg/DFGAbstractInterpreterInlines.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        * dfg/DFGClobberize.h:
        * dfg/DFGDoesGC.cpp:
        * dfg/DFGFixupPhase.cpp:
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGPromotedHeapLocation.cpp:
        * dfg/DFGPromotedHeapLocation.h:
        * dfg/DFGSafeToExecute.h:
        * dfg/DFGSpeculativeJIT.cpp:
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        * dfg/DFGSpeculativeJIT64.cpp:
        * ftl/FTLCapabilities.cpp:
        * ftl/FTLLowerDFGToLLVM.cpp:
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * jit/JIT.cpp:
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitNewFuncExprCommon):
        * jit/JITOpcodes32_64.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createArrowFunctionExpr):
        (JSC::ASTBuilder::usesArrowFunction):
        * parser/Nodes.h:
        (JSC::ScopeNode::usesArrowFunction):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/ParserModes.h:
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::ScriptExecutable):
        (JSC::EvalExecutable::create):
        (JSC::EvalExecutable::EvalExecutable):
        (JSC::ProgramExecutable::ProgramExecutable):
        (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
        (JSC::FunctionExecutable::FunctionExecutable):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::isArrowFunctionContext):
        (JSC::ScriptExecutable::isDerivedConstructorContext):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createEvalCodeBlock):
        * runtime/JSGlobalObject.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
        * tests/es6.yaml:
        * tests/stress/arrowfunction-activation-sink-osrexit.js:
        * tests/stress/arrowfunction-activation-sink.js:
        * tests/stress/arrowfunction-lexical-bind-newtarget.js: Added.
        * tests/stress/arrowfunction-lexical-bind-supercall-1.js: Added.
        * tests/stress/arrowfunction-lexical-bind-supercall-2.js: Added.
        * tests/stress/arrowfunction-lexical-bind-supercall-3.js: Added.
        * tests/stress/arrowfunction-lexical-bind-supercall-4.js: Added.
        * tests/stress/arrowfunction-lexical-bind-this-1.js:
        * tests/stress/arrowfunction-lexical-bind-this-7.js: Added.
        * tests/stress/arrowfunction-tdz-1.js: Added.
        * tests/stress/arrowfunction-tdz-2.js: Added.
        * tests/stress/arrowfunction-tdz-3.js: Added.
        * tests/stress/arrowfunction-tdz-4.js: Added.
        * tests/stress/arrowfunction-tdz.js: Removed.

2015-12-01  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        [Streams API] streams should not directly use Number and related methods
        https://bugs.webkit.org/show_bug.cgi?id=151499

        Reviewed by Darin Adler.

        * runtime/CommonIdentifiers.h: Adding isNaN as private symbol.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Adding @isNaN function.

2015-12-01  Csaba Osztrogonác  <ossy@webkit.org>

        Don't hide the argument name inside for block in AirIteratedRegisterCoalescing.cpp
        https://bugs.webkit.org/show_bug.cgi?id=151622

        Reviewed by Darin Adler.

        * b3/air/AirIteratedRegisterCoalescing.cpp:
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdges):

2015-12-01  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        [Streams API] Remove use of @catch for exposed promises
        https://bugs.webkit.org/show_bug.cgi?id=151625

        Reviewed by Darin Adler.

        * runtime/JSPromisePrototype.cpp:
        (JSC::JSPromisePrototype::addOwnInternalSlots): Removing @catch from the prototype as it is not safe.

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

        B3::ValueRep::Any should translate into a Arg::ColdUse role in Air
        https://bugs.webkit.org/show_bug.cgi?id=151174

        Reviewed by Geoffrey Garen and Benjamin Poulain.

        This teaches the register allocator that it should pick spills based on whichever tmp has the
        highest score:

            score(tmp) = degree(tmp) / sum(for each use of tmp, block->frequency)

        In other words, the numerator is the number of edges in the inteference graph and the denominator
        is an estimate of the dynamic number of uses.

        This also extends Arg::Role to know that there is such a thing as ColdUse, i.e. a Use that
        doesn't count as such for the above formula. Because LateUse is always used in contexts where we
        want it to be Cold, I've defined LateUse to imply ColdUse.

        This gets rid of all spilling inside the hot loop in Kraken/imaging-gaussian-blur. But more
        importantly, it makes our register allocator use a well-known heuristic based on reusable
        building blocks like the new Air::UseCounts. Even if the heuristic is slightly wrong, the right
        heuristic probably uses the same building blocks.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        * b3/B3ValueRep.h:
        * b3/air/AirArg.cpp:
        (WTF::printInternal):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isAnyUse):
        (JSC::B3::Air::Arg::isColdUse):
        (JSC::B3::Air::Arg::isWarmUse):
        (JSC::B3::Air::Arg::isEarlyUse):
        (JSC::B3::Air::Arg::isDef):
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        (JSC::B3::Air::iteratedRegisterCoalescing):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::IteratedRegisterCoalescingAllocator): Deleted.
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::allocatedReg): Deleted.
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::tmpArraySize): Deleted.
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::initializeDegrees): Deleted.
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::build): Deleted.
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::selectSpill): Deleted.
        (JSC::B3::Air::isUselessMoveInst): Deleted.
        (JSC::B3::Air::assignRegisterToTmpInProgram): Deleted.
        (JSC::B3::Air::addSpillAndFillToProgram): Deleted.
        (JSC::B3::Air::iteratedRegisterCoalescingOnType): Deleted.
        * b3/air/AirLiveness.h:
        * b3/air/AirSpillEverything.cpp:
        (JSC::B3::Air::spillEverything):
        * b3/air/AirUseCounts.h: Added.
        (JSC::B3::Air::UseCounts::Counts::dump):
        (JSC::B3::Air::UseCounts::UseCounts):
        (JSC::B3::Air::UseCounts::operator[]):
        (JSC::B3::Air::UseCounts::dump):
        * runtime/Options.h:

2015-11-30  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the !ENABLE(DFG_JIT) build after r192699
        https://bugs.webkit.org/show_bug.cgi?id=151616

        Reviewed by Darin Adler.

        * assembler/MacroAssembler.h:

2015-11-30  Yusuke Suzuki  <utatane.tea@gmail.com>

        Object::{freeze, seal} perform preventExtensionsTransition twice
        https://bugs.webkit.org/show_bug.cgi?id=151606

        Reviewed by Darin Adler.

        In Structure::{freezeTransition, sealTransition}, we perform preventExtensionsTransition.
        So it is unnecessary to perform preventExtensionsTransition before executing Structure::{freezeTransition, sealTransition}.

        * runtime/JSObject.cpp:
        (JSC::JSObject::seal):
        (JSC::JSObject::freeze):
        (JSC::JSObject::preventExtensions):
        * tests/stress/freeze-and-seal-should-prevent-extensions.js: Added.
        (shouldBe):
        (shouldThrow):

2015-11-30  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add Sqrt to B3
        https://bugs.webkit.org/show_bug.cgi?id=151692

        Reviewed by Geoffrey Garen.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::sqrtDouble):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::sqrtsd_mr):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::typeFor):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testSqrtArg):
        (JSC::B3::testSqrtImm):
        (JSC::B3::testSqrtMem):
        (JSC::B3::run):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::doubleSqrt):

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

        FTL lazy slow paths should work with B3
        https://bugs.webkit.org/show_bug.cgi?id=151667

        Reviewed by Geoffrey Garen.

        This adds all of the glue necessary to make FTL::LazySlowPath work with B3. The B3 approach
        allows us to put all of the code in FTL::LowerDFGToLLVM, instead of having supporting data
        structures on the side and a bunch of complex code in FTLCompile.cpp.

        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::generate):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::run):
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::generate):
        * b3/B3StackmapValue.h:
        * ftl/FTLJSTailCall.cpp:
        (JSC::FTL::DFG::recoveryFor):
        (JSC::FTL::JSTailCall::emit):
        * ftl/FTLLazySlowPath.cpp:
        (JSC::FTL::LazySlowPath::LazySlowPath):
        (JSC::FTL::LazySlowPath::generate):
        * ftl/FTLLazySlowPath.h:
        (JSC::FTL::LazySlowPath::createGenerator):
        (JSC::FTL::LazySlowPath::patchableJump):
        (JSC::FTL::LazySlowPath::done):
        (JSC::FTL::LazySlowPath::patchpoint):
        (JSC::FTL::LazySlowPath::usedRegisters):
        (JSC::FTL::LazySlowPath::callSiteIndex):
        (JSC::FTL::LazySlowPath::stub):
        * ftl/FTLLocation.cpp:
        (JSC::FTL::Location::forValueRep):
        (JSC::FTL::Location::forStackmaps):
        (JSC::FTL::Location::dump):
        (JSC::FTL::Location::isGPR):
        (JSC::FTL::Location::gpr):
        (JSC::FTL::Location::isFPR):
        (JSC::FTL::Location::fpr):
        (JSC::FTL::Location::restoreInto):
        * ftl/FTLLocation.h:
        (JSC::FTL::Location::Location):
        (JSC::FTL::Location::forRegister):
        (JSC::FTL::Location::forIndirect):
        (JSC::FTL::Location::forConstant):
        (JSC::FTL::Location::kind):
        (JSC::FTL::Location::hasReg):
        (JSC::FTL::Location::reg):
        (JSC::FTL::Location::hasOffset):
        (JSC::FTL::Location::offset):
        (JSC::FTL::Location::hash):
        (JSC::FTL::Location::hasDwarfRegNum): Deleted.
        (JSC::FTL::Location::dwarfRegNum): Deleted.
        (JSC::FTL::Location::hasDwarfReg): Deleted.
        (JSC::FTL::Location::dwarfReg): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::LowerDFGToLLVM):
        (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::stubUnavailableRegisters):
        (JSC::RegisterSet::macroScratchRegisters):
        (JSC::RegisterSet::calleeSaveRegisters):
        * jit/RegisterSet.h:

2015-11-30  Geoffrey Garen  <ggaren@apple.com>

        Use a better RNG for Math.random()
        https://bugs.webkit.org/show_bug.cgi?id=151641

        Reviewed by Anders Carlsson.

        Updated for interface change.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::setInputCursor):

2015-11-30  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Speed up Air Liveness Analysis on Tmps
        https://bugs.webkit.org/show_bug.cgi?id=151556

        Reviewed by Filip Pizlo.

        Liveness Analysis scales poorly on large graphs like the ones
        generated by testComplex().
        This patch introduces a faster of Liveness using the continuous indices
        of values instead of the values themselves.

        There are two main areas of improvements:
        1) Reduce the cost of doing a LocalCalc over a BasicBlock.
        2) Reduce how many LocalCalc are needed to converge to a solution.

        Most of the costs of LocalCalc are from HashSet manipulations.
        The HashSet operations are O(1) but the constant is large enough
        to be a problem.

        I used a similar trick as the Register Allocator to remove hashing
        and collision handling: the absolute value of the Tmp is used as an index
        into a flat array.

        I used Briggs's Sparse Set implementation for the local live information
        at each instruction. It has great properties for doing the local calculation:
        -No memory reallocation.
        -O(1) add() and remove() with a small constant.
        -Strict O(n) iteration.
        -O(1) clear().

        The values Live-At-Head are now stored into a Vector. The Sparse Set
        is used to maintain the Tmp uniqueness.

        When forwarding new liveness at head to the predecessor, I start by removing
        everything that was already in live-at-head. We can assume that any value
        in that list has already been added to the predecessors.
        This leaves us with a small-ish number of Tmps to add to live-at-head
        and to the predecessors.

        The speed up convergence, I used the same trick as DFG's liveness: keep
        a set of dirty blocks to process. In practice, all the blocks without
        back-edges converge quickly, and we only propagate liveness as needed.

        This patch reduces the time taken by "testComplex(64, 384)" by another 5%.

        The remaining things to do for Liveness are:
        -Skip the first block for the fix point (it is often large and doing a local
         calc on it is useless).
        -Find a better Data Structure for live-at-tail (updating the HashSet takes
         > 50% of the total convergence time).

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::build):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::getAlias):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::getAliasWhenSpilling):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::allocatedReg):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::tmpArraySize):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::initializeDegrees):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdges):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdge):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::makeWorkList):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::simplify):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::forEachAdjacent):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::hasBeenSimplified):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::decrementDegree):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::forEachNodeMoves):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::isMoveRelated):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::enableMovesOnValue):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::precoloredCoalescingHeuristic):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::conservativeHeuristic):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::addWorkList):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::combine):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::freezeMoves):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::selectSpill):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::assignColors):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::dumpInterferenceGraphInDot):
        (JSC::B3::Air::iteratedRegisterCoalescingOnType):
        (JSC::B3::Air::iteratedRegisterCoalescing):
        (JSC::B3::Air::AbsoluteTmpHelper<Arg::GP>::absoluteIndex): Deleted.
        (JSC::B3::Air::AbsoluteTmpHelper<Arg::GP>::tmpFromAbsoluteIndex): Deleted.
        (JSC::B3::Air::AbsoluteTmpHelper<Arg::FP>::absoluteIndex): Deleted.
        (JSC::B3::Air::AbsoluteTmpHelper<Arg::FP>::tmpFromAbsoluteIndex): Deleted.
        * b3/air/AirReportUsedRegisters.cpp:
        (JSC::B3::Air::reportUsedRegisters):
        * b3/air/AirTmpInlines.h:
        (JSC::B3::Air::AbsoluteTmpMapper<Arg::GP>::absoluteIndex):
        (JSC::B3::Air::AbsoluteTmpMapper<Arg::GP>::tmpFromAbsoluteIndex):
        (JSC::B3::Air::AbsoluteTmpMapper<Arg::FP>::absoluteIndex):
        (JSC::B3::Air::AbsoluteTmpMapper<Arg::FP>::tmpFromAbsoluteIndex):
        * b3/air/AirLiveness.h: Added.

2015-11-30  Saam barati  <sbarati@apple.com>

        FTL OSR Exits that are exception handlers should not have two different entrances. Instead, we should have two discrete OSR exits that do different things.
        https://bugs.webkit.org/show_bug.cgi?id=151404

        Reviewed by Filip Pizlo.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLExceptionHandlerManager.cpp:
        (JSC::FTL::ExceptionHandlerManager::addNewExit):
        (JSC::FTL::ExceptionHandlerManager::addNewCallOperationExit):
        (JSC::FTL::ExceptionHandlerManager::callOperationExceptionTarget):
        (JSC::FTL::ExceptionHandlerManager::lazySlowPathExceptionTarget):
        (JSC::FTL::ExceptionHandlerManager::callOperationOSRExit):
        (JSC::FTL::ExceptionHandlerManager::getByIdOSRExit): Deleted.
        (JSC::FTL::ExceptionHandlerManager::subOSRExit): Deleted.
        * ftl/FTLExceptionHandlerManager.h:
        * ftl/FTLExitThunkGenerator.cpp:
        (JSC::FTL::ExitThunkGenerator::emitThunk):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
        (JSC::FTL::OSRExitDescriptor::isExceptionHandler):
        (JSC::FTL::OSRExit::OSRExit):
        (JSC::FTL::OSRExit::spillRegistersToSpillSlot):
        (JSC::FTL::OSRExit::recoverRegistersFromSpillSlot):
        (JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck):
        (JSC::FTL::OSRExit::willArriveAtOSRExitFromGenericUnwind):
        (JSC::FTL::OSRExit::willArriveAtOSRExitFromCallOperation):
        (JSC::FTL::OSRExit::needsRegisterRecoveryOnGenericUnwindOSRExitPath):
        (JSC::FTL::OSRExitDescriptor::willArriveAtExitFromIndirectExceptionCheck): Deleted.
        (JSC::FTL::OSRExitDescriptor::mightArriveAtOSRExitFromGenericUnwind): Deleted.
        (JSC::FTL::OSRExitDescriptor::mightArriveAtOSRExitFromCallOperation): Deleted.
        (JSC::FTL::OSRExitDescriptor::needsRegisterRecoveryOnGenericUnwindOSRExitPath): Deleted.
        * ftl/FTLOSRExit.h:
        * ftl/FTLOSRExitCompilationInfo.h:
        (JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileFTLOSRExit):

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

        Refactor the op_add, op_sub, and op_mul snippets to use the SnippetOperand class.
        https://bugs.webkit.org/show_bug.cgi?id=151678

        Reviewed by Geoffrey Garen.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueAdd):
        (JSC::DFG::SpeculativeJIT::compileArithSub):
        * ftl/FTLCompile.cpp:
        * jit/JITAddGenerator.cpp:
        (JSC::JITAddGenerator::generateFastPath):
        * jit/JITAddGenerator.h:
        (JSC::JITAddGenerator::JITAddGenerator):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emit_op_mul):
        (JSC::JIT::emit_op_sub):
        * jit/JITMulGenerator.cpp:
        (JSC::JITMulGenerator::generateFastPath):
        * jit/JITMulGenerator.h:
        (JSC::JITMulGenerator::JITMulGenerator):
        * jit/JITSubGenerator.cpp:
        (JSC::JITSubGenerator::generateFastPath):
        * jit/JITSubGenerator.h:
        (JSC::JITSubGenerator::JITSubGenerator):
        * jit/SnippetOperand.h:
        (JSC::SnippetOperand::isPositiveConstInt32):

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

        B3 stackmaps should support early clobber
        https://bugs.webkit.org/show_bug.cgi?id=151668

        Reviewed by Geoffrey Garen.

        While starting work on FTL lazy slow paths, I realized that we needed some way to say that r11 is
        off limits. Not just that it's clobbered, but that it cannot be used for any input values to a
        stackmap.

        In LLVM we do this by having the AnyRegCC forbid r11.

        In B3, we want something more flexible. In this and other cases, what we really want is an early
        clobber set. B3 already supported a late clobber set for every stackmap value. Late clobber means
        that the act of performing the operation will cause garbage to be written into those registers.
        But here we want: assume that garbage magically appears in those registers in the moment before
        the operation executes. Any registers in that set will be off-limits to the inputs to the
        stackmap. This should be great for other things, like the way the we handle exceptions.

        For the simple r11 issue, what we want is to call the StackmapValue::clobber() method, which now
        means both early and late clobber. It's the weapon of choice whenever you're unsure.

        This adds the early clobber feature, does some minor Inst refactoring to make this less scary,
        and adds a test. The test is simple but it's very comprehensive - for example it tests the
        early-clobber-after-Move special case.

        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::extraClobberedRegs):
        (JSC::B3::StackmapSpecial::extraEarlyClobberedRegs):
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        * b3/B3StackmapSpecial.h:
        * b3/B3StackmapValue.cpp:
        (JSC::B3::StackmapValue::dumpMeta):
        (JSC::B3::StackmapValue::StackmapValue):
        * b3/B3StackmapValue.h:
        * b3/air/AirCCallSpecial.cpp:
        (JSC::B3::Air::CCallSpecial::extraClobberedRegs):
        (JSC::B3::Air::CCallSpecial::extraEarlyClobberedRegs):
        (JSC::B3::Air::CCallSpecial::dumpImpl):
        * b3/air/AirCCallSpecial.h:
        * b3/air/AirInst.h:
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::extraClobberedRegs):
        (JSC::B3::Air::Inst::extraEarlyClobberedRegs):
        (JSC::B3::Air::Inst::forEachTmpWithExtraClobberedRegs):
        (JSC::B3::Air::Inst::reportUsedRegisters):
        (JSC::B3::Air::Inst::forEachDefAndExtraClobberedTmp): Deleted.
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::IteratedRegisterCoalescingAllocator):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::build):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::allocate):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::initializeDegrees):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdges):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdge):
        (JSC::B3::Air::iteratedRegisterCoalescingOnType):
        (JSC::B3::Air::iteratedRegisterCoalescing):
        * b3/air/AirSpecial.h:
        * b3/air/AirSpillEverything.cpp:
        (JSC::B3::Air::spillEverything):
        * b3/testb3.cpp:
        (JSC::B3::testSimplePatchpointWithoutOuputClobbersGPArgs):
        (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
        (JSC::B3::testSimplePatchpointWithoutOuputClobbersFPArgs):
        (JSC::B3::testSimplePatchpointWithOuputClobbersFPArgs):
        (JSC::B3::testPatchpointWithEarlyClobber):
        (JSC::B3::testPatchpointCallArg):
        (JSC::B3::run):
        * dfg/DFGCommon.h:

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

        Snippefy op_div for the baseline JIT.
        https://bugs.webkit.org/show_bug.cgi?id=151607

        Reviewed by Geoffrey Garen.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:

        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_div):
        (JSC::JIT::emitSlow_op_div):
        (JSC::JIT::compileBinaryArithOpSlowCase): Deleted.

        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emitBinaryDoubleOp):
        (JSC::JIT::emit_op_div): Deleted.
        (JSC::JIT::emitSlow_op_div): Deleted.
        - Removed the 32-bit specific op_div implementation.  The 64-bit version with the
          op_div snippet can now service both 32-bit and 64-bit.
 
        * jit/JITDivGenerator.cpp: Added.
        (JSC::JITDivGenerator::loadOperand):
        (JSC::JITDivGenerator::generateFastPath):
        * jit/JITDivGenerator.h: Added.
        (JSC::JITDivGenerator::JITDivGenerator):
        (JSC::JITDivGenerator::didEmitFastPath):
        (JSC::JITDivGenerator::endJumpList):
        (JSC::JITDivGenerator::slowPathJumpList):
 
        * jit/JITInlines.h:
        (JSC::JIT::getOperandConstantDouble): Added.
 
        * jit/SnippetOperand.h: Added.
        (JSC::SnippetOperand::SnippetOperand):
        (JSC::SnippetOperand::mightBeNumber):
        (JSC::SnippetOperand::definitelyIsNumber):
        (JSC::SnippetOperand::isConst):
        (JSC::SnippetOperand::isConstInt32):
        (JSC::SnippetOperand::isConstDouble):
        (JSC::SnippetOperand::asRawBits):
        (JSC::SnippetOperand::asConstInt32):
        (JSC::SnippetOperand::asConstDouble):
        (JSC::SnippetOperand::setConstInt32):
        (JSC::SnippetOperand::setConstDouble):
        - The SnippetOperand encapsulates operand constness, const type, and profiling
          information.  As a result:
          1. The argument list to the JITDivGenerator constructor is now more concise.
          2. The logic of the JITDivGenerator is now less verbose and easier to express.

        * parser/ResultType.h:
        (JSC::ResultType::isInt32):
        (JSC::ResultType::definitelyIsNumber):
        (JSC::ResultType::definitelyIsString):
        (JSC::ResultType::definitelyIsBoolean):
        (JSC::ResultType::mightBeNumber):
        (JSC::ResultType::isNotNumber):
        - Made these functions const because they were always meant to be const.
          This also allows me to enforce constness in the SnippetOperand.

2015-11-30  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Fix coding style of Intl code
        https://bugs.webkit.org/show_bug.cgi?id=151491

        Reviewed by Darin Adler.

        This patch does three things:
        1. Rename pointers and references to ExecState from "exec" to "state".
        2. Pass parameters by references instead of pointers if the parameters
           are required.
        3. Remove the word "get" from the names of functions that don't return
           values through out arguments.

        * runtime/IntlCollator.cpp:
        (JSC::IntlCollatorFuncCompare):
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::initializeCollator):
        (JSC::constructIntlCollator):
        (JSC::callIntlCollator):
        (JSC::IntlCollatorConstructor::getOwnPropertySlot):
        (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormatFuncFormatDateTime):
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::constructIntlDateTimeFormat):
        (JSC::callIntlDateTimeFormat):
        (JSC::IntlDateTimeFormatConstructor::getOwnPropertySlot):
        (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototype::getOwnPropertySlot):
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormatFuncFormatNumber):
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::constructIntlNumberFormat):
        (JSC::callIntlNumberFormat):
        (JSC::IntlNumberFormatConstructor::getOwnPropertySlot):
        (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototype::getOwnPropertySlot):
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
        * runtime/IntlObject.cpp:
        (JSC::intlBooleanOption):
        (JSC::intlStringOption):
        (JSC::privateUseLangTag):
        (JSC::canonicalLangTag):
        (JSC::grandfatheredLangTag):
        (JSC::canonicalizeLanguageTag):
        (JSC::canonicalizeLocaleList):
        (JSC::lookupSupportedLocales):
        (JSC::bestFitSupportedLocales):
        (JSC::supportedLocales):
        (JSC::getIntlBooleanOption): Deleted.
        (JSC::getIntlStringOption): Deleted.
        (JSC::getPrivateUseLangTag): Deleted.
        (JSC::getCanonicalLangTag): Deleted.
        (JSC::getGrandfatheredLangTag): Deleted.
        * runtime/IntlObject.h:

2015-11-30  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Simplify the loop that remove useless Air instructions
        https://bugs.webkit.org/show_bug.cgi?id=151652

        Reviewed by Andreas Kling.

        * b3/air/AirEliminateDeadCode.cpp:
        (JSC::B3::Air::eliminateDeadCode):
        Use Vector's removeAllMatching() instead of custom code.

        It is likely faster too since we remove few values and Vector
        is good at doing that.

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

        B3 should be be clever about choosing which child to reuse for result in two-operand commutative operations
        https://bugs.webkit.org/show_bug.cgi?id=151321

        Reviewed by Geoffrey Garen.

        When lowering a commutative operation to a two-operand instruction, you have a choice of which
        child value to move into the result tmp. For example we might have:

            @x = Add(@y, @z)

        Assuming no three-operand add is available, we could either lower it to this:

            Move %y, %x
            Add %z, %x

        or to this:

            Move %z, %x
            Add %y, %x

        Which is better depends on the likelihood of coalescing with %x. If it's more likely that %y will
        coalesce with %x, then we want to use the first form. Otherwise, we should use the second form.

        This implements two heuristics for selecting the right form, and makes those heuristics reusable
        within the B3->Air lowering by abstracting it as preferRightForResult(). For non-commutative
        operations we must use the first form, so the first form is the default. The heuristics are:

        - If the right child has only one user, then use the second form instead. This is profitable because
          that means that @z dies at the Add, so using the second form means that the Move will be coalesced
          away.

        - If one of the children is a Phi that this operation (the Add in this case) flows into via some
          Upsilon - possibly transitively through other Phis - then use the form that cases a Move on that
          child. This overrides everything else, and is meant to optimize variables that accumulate in a
          loop.

        This required adding a reusable PhiChildren analysis, so I wrote one. It has an API that is mostly
        based on iterators, and a higher-level API for looking at transitive children that is based on
        functors.

        I was originally implementing this for completeness, but when looking at how it interacted with
        imaging-gaussian-blur, I realized the need for some heuristic for the loop-accumulator case. This
        helps a lot on that benchmark. This widens the overall lead that B3 has on imaging-gaussian-blur, but
        steady-state runs that exclude compile latency still show a slight deficit. That will most likely get
        fixed by https://bugs.webkit.org/show_bug.cgi?id=151174.

        No new tests because the commutativity appears to be covered by existing tests, and anyway, there are
        no correctness implications to commuting a commutative operation.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::LowerToAir):
        (JSC::B3::Air::LowerToAir::canBeInternal):
        (JSC::B3::Air::LowerToAir::appendUnOp):
        (JSC::B3::Air::LowerToAir::preferRightForResult):
        (JSC::B3::Air::LowerToAir::appendBinOp):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3PhiChildren.cpp: Added.
        (JSC::B3::PhiChildren::PhiChildren):
        (JSC::B3::PhiChildren::~PhiChildren):
        * b3/B3PhiChildren.h: Added.
        (JSC::B3::PhiChildren::ValueCollection::ValueCollection):
        (JSC::B3::PhiChildren::ValueCollection::size):
        (JSC::B3::PhiChildren::ValueCollection::at):
        (JSC::B3::PhiChildren::ValueCollection::operator[]):
        (JSC::B3::PhiChildren::ValueCollection::contains):
        (JSC::B3::PhiChildren::ValueCollection::iterator::iterator):
        (JSC::B3::PhiChildren::ValueCollection::iterator::operator*):
        (JSC::B3::PhiChildren::ValueCollection::iterator::operator++):
        (JSC::B3::PhiChildren::ValueCollection::iterator::operator==):
        (JSC::B3::PhiChildren::ValueCollection::iterator::operator!=):
        (JSC::B3::PhiChildren::ValueCollection::begin):
        (JSC::B3::PhiChildren::ValueCollection::end):
        (JSC::B3::PhiChildren::UpsilonCollection::UpsilonCollection):
        (JSC::B3::PhiChildren::UpsilonCollection::size):
        (JSC::B3::PhiChildren::UpsilonCollection::at):
        (JSC::B3::PhiChildren::UpsilonCollection::operator[]):
        (JSC::B3::PhiChildren::UpsilonCollection::contains):
        (JSC::B3::PhiChildren::UpsilonCollection::begin):
        (JSC::B3::PhiChildren::UpsilonCollection::end):
        (JSC::B3::PhiChildren::UpsilonCollection::values):
        (JSC::B3::PhiChildren::UpsilonCollection::forAllTransitiveIncomingValues):
        (JSC::B3::PhiChildren::UpsilonCollection::transitivelyUses):
        (JSC::B3::PhiChildren::at):
        (JSC::B3::PhiChildren::operator[]):
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::Procedure):
        * b3/B3Procedure.h:
        * b3/B3UseCounts.cpp:
        (JSC::B3::UseCounts::UseCounts):
        * b3/B3UseCounts.h:
        (JSC::B3::UseCounts::numUses):
        (JSC::B3::UseCounts::numUsingInstructions):
        (JSC::B3::UseCounts::operator[]): Deleted.

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

        REGRESSION(r192812): This change seems to have broken the iOS builds (Requested by ryanhaddad on #webkit).
        https://bugs.webkit.org/show_bug.cgi?id=151669

        Unreviewed, fix build.

        * dfg/DFGCommon.h:

2015-11-30  Saam barati  <sbarati@apple.com>

        implement op_get_rest_length so that we can allocate the rest array with the right size from the start
        https://bugs.webkit.org/show_bug.cgi?id=151467

        Reviewed by Geoffrey Garen and Mark Lam.

        This patch implements op_get_rest_length which returns the length
        that the rest parameter array will be. We're implementing this because
        it might be a constant value in the presence of inlining in the DFG.
        We will take advantage of this optimization opportunity in a future patch:
        https://bugs.webkit.org/show_bug.cgi?id=151454
        to emit better code for op_copy_rest.

        op_get_rest_length has two operands: 
        1) a destination
        2) A constant indicating the number of parameters to skip when copying the rest array.

        op_get_rest_length lowers to a JSConstant node when we're inlined
        and not a varargs call (in this case, we statically know the arguments
        length). When that condition isn't met, we lower op_get_rest_length to 
        GetRestArray. GetRestArray produces its result as an int32.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitNewArray):
        (JSC::BytecodeGenerator::emitNewArrayWithSize):
        (JSC::BytecodeGenerator::emitNewFunction):
        (JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
        (JSC::BytecodeGenerator::emitRestParameter):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::RestParameterNode::emit):
        * 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/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::numberOfArgumentsToSkip):
        * 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::compileCopyRest):
        (JSC::DFG::SpeculativeJIT::compileGetRestLength):
        (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):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCopyRest):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetRestLength):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewObject):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_copy_rest):
        (JSC::JIT::emit_op_get_rest_length):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):

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

        MacroAssembler needs an API for disabling scratch registers
        https://bugs.webkit.org/show_bug.cgi?id=151010

        Reviewed by Saam Barati and Michael Saboff.

        This adds two scope classes, DisallowMacroScratchRegisterUsage and
        AllowMacroScratchRegisterUsage. The default is that the scratch registers are enabled. Air
        disables them before generation.

        Henceforth the pattern inside B3 stackmap generator callbacks will be that you can only use
        AllowMacroScratchRegisterUsage if you've either supplied the scratch register as a clobbered
        register and arranged for all of the stackmap values to be late uses, or you're writing a test
        and you're OK with it being fragile with respect to scratch registers. The latter holds in most
        of testb3.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbstractMacroAssembler.h:
        (JSC::optimizeForX86):
        (JSC::AbstractMacroAssembler::setTempRegisterValid):
        * assembler/AllowMacroScratchRegisterUsage.h: Added.
        (JSC::AllowMacroScratchRegisterUsage::AllowMacroScratchRegisterUsage):
        (JSC::AllowMacroScratchRegisterUsage::~AllowMacroScratchRegisterUsage):
        * assembler/DisallowMacroScratchRegisterUsage.h: Added.
        (JSC::DisallowMacroScratchRegisterUsage::DisallowMacroScratchRegisterUsage):
        (JSC::DisallowMacroScratchRegisterUsage::~DisallowMacroScratchRegisterUsage):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::scratchRegister):
        (JSC::MacroAssemblerX86Common::loadDouble):
        (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::add32):
        (JSC::MacroAssemblerX86_64::and32):
        (JSC::MacroAssemblerX86_64::or32):
        (JSC::MacroAssemblerX86_64::sub32):
        (JSC::MacroAssemblerX86_64::load8):
        (JSC::MacroAssemblerX86_64::addDouble):
        (JSC::MacroAssemblerX86_64::convertInt32ToDouble):
        (JSC::MacroAssemblerX86_64::store32):
        (JSC::MacroAssemblerX86_64::store8):
        (JSC::MacroAssemblerX86_64::callWithSlowPathReturnType):
        (JSC::MacroAssemblerX86_64::call):
        (JSC::MacroAssemblerX86_64::jump):
        (JSC::MacroAssemblerX86_64::tailRecursiveCall):
        (JSC::MacroAssemblerX86_64::makeTailRecursiveCall):
        (JSC::MacroAssemblerX86_64::branchAdd32):
        (JSC::MacroAssemblerX86_64::add64):
        (JSC::MacroAssemblerX86_64::addPtrNoFlags):
        (JSC::MacroAssemblerX86_64::and64):
        (JSC::MacroAssemblerX86_64::lshift64):
        (JSC::MacroAssemblerX86_64::or64):
        (JSC::MacroAssemblerX86_64::sub64):
        (JSC::MacroAssemblerX86_64::store64):
        (JSC::MacroAssemblerX86_64::store64WithAddressOffsetPatch):
        (JSC::MacroAssemblerX86_64::branch64):
        (JSC::MacroAssemblerX86_64::branchPtr):
        (JSC::MacroAssemblerX86_64::branchTest64):
        (JSC::MacroAssemblerX86_64::test64):
        (JSC::MacroAssemblerX86_64::branchPtrWithPatch):
        (JSC::MacroAssemblerX86_64::branch32WithPatch):
        (JSC::MacroAssemblerX86_64::storePtrWithPatch):
        (JSC::MacroAssemblerX86_64::branch8):
        (JSC::MacroAssemblerX86_64::branchTest8):
        (JSC::MacroAssemblerX86_64::convertInt64ToDouble):
        (JSC::MacroAssemblerX86_64::readCallTarget):
        (JSC::MacroAssemblerX86_64::haveScratchRegisterForBlinding):
        (JSC::MacroAssemblerX86_64::scratchRegisterForBlinding):
        (JSC::MacroAssemblerX86_64::canJumpReplacePatchableBranchPtrWithPatch):
        (JSC::MacroAssemblerX86_64::canJumpReplacePatchableBranch32WithPatch):
        (JSC::MacroAssemblerX86_64::revertJumpReplacementToPatchableBranchPtrWithPatch):
        (JSC::MacroAssemblerX86_64::revertJumpReplacementToPatchableBranch32WithPatch):
        (JSC::MacroAssemblerX86_64::revertJumpReplacementToBranchPtrWithPatch):
        (JSC::MacroAssemblerX86_64::repatchCall):
        (JSC::MacroAssemblerX86_64::add64AndSetFlags):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * b3/testb3.cpp:
        (JSC::B3::testSimplePatchpoint):
        (JSC::B3::testSimplePatchpointWithoutOuputClobbersGPArgs):
        (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
        (JSC::B3::testSimplePatchpointWithoutOuputClobbersFPArgs):
        (JSC::B3::testSimplePatchpointWithOuputClobbersFPArgs):
        (JSC::B3::testPatchpointCallArg):
        (JSC::B3::testPatchpointFixedRegister):
        (JSC::B3::testPatchpointAny):
        (JSC::B3::testPatchpointAnyImm):
        (JSC::B3::testSimpleCheck):
        (JSC::B3::testCheckLessThan):
        (JSC::B3::testCheckMegaCombo):
        (JSC::B3::testCheckAddImm):
        (JSC::B3::testCheckAddImmCommute):
        (JSC::B3::testCheckAddImmSomeRegister):
        (JSC::B3::testCheckAdd):
        (JSC::B3::testCheckAdd64):
        (JSC::B3::testCheckAddFoldFail):
        (JSC::B3::testCheckSubImm):
        (JSC::B3::testCheckSubBadImm):
        (JSC::B3::testCheckSub):
        (JSC::B3::testCheckSub64):
        (JSC::B3::testCheckSubFoldFail):
        (JSC::B3::testCheckNeg):
        (JSC::B3::testCheckNeg64):
        (JSC::B3::testCheckMul):
        (JSC::B3::testCheckMulMemory):
        (JSC::B3::testCheckMul2):
        (JSC::B3::testCheckMul64):
        (JSC::B3::testCheckMulFoldFail):
        (JSC::B3::genericTestCompare):
        * dfg/DFGCommon.h:
        * jit/GPRInfo.h:
        (JSC::GPRInfo::toRegister):
        (JSC::GPRInfo::reservedRegisters):

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

        [ARM64] stress/op_div.js is failing on some divide by 0 cases.
        https://bugs.webkit.org/show_bug.cgi?id=151515

        Reviewed by Saam Barati.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithDiv):
        - Added a check for the divide by zero case.
        * tests/stress/op_div.js:
        - Un-skipped the test.

2015-11-27  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] Add testb3 to the build system
        https://bugs.webkit.org/show_bug.cgi?id=151619

        Reviewed by Gyuyoung Kim.

        * shell/CMakeLists.txt:

2015-11-27  Csaba Osztrogonác  <ossy@webkit.org>

        Use mark pragmas only if it is supported
        https://bugs.webkit.org/show_bug.cgi?id=151621

        Reviewed by Mark Lam.

        * b3/air/AirIteratedRegisterCoalescing.cpp:

2015-11-27  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the ENABLE(B3_JIT) build with GCC in B3Procedure.h
        https://bugs.webkit.org/show_bug.cgi?id=151620

        Reviewed by Mark Lam.

        * b3/B3Procedure.h:

2015-11-27  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] Add new B3 source files to the build system
        https://bugs.webkit.org/show_bug.cgi?id=151618

        Reviewed by Gyuyoung Kim.

        * CMakeLists.txt:

2015-11-26  Carlos Garcia Campos  <cgarcia@igalia.com>

        [GLIB] Implement garbage collector timers
        https://bugs.webkit.org/show_bug.cgi?id=151391

        Reviewed by Žan Doberšek.

        Add GLib implementation using GSource.

        * heap/EdenGCActivityCallback.cpp:
        * heap/FullGCActivityCallback.cpp:
        * heap/GCActivityCallback.cpp:
        (JSC::GCActivityCallback::GCActivityCallback):
        (JSC::GCActivityCallback::scheduleTimer):
        (JSC::GCActivityCallback::cancelTimer):
        * heap/GCActivityCallback.h:
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        * heap/HeapTimer.cpp:
        (JSC::HeapTimer::HeapTimer):
        (JSC::HeapTimer::~HeapTimer):
        (JSC::HeapTimer::timerDidFire):
        * heap/HeapTimer.h:
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::IncrementalSweeper):
        (JSC::IncrementalSweeper::scheduleTimer):
        (JSC::IncrementalSweeper::cancelTimer):
        * heap/IncrementalSweeper.h:

2015-11-24  Caitlin Potter  <caitp@igalia.com>

        [JSC] support Computed Property Names in destructuring Patterns
        https://bugs.webkit.org/show_bug.cgi?id=151494

        Reviewed by Saam Barati.

        Add support for computed property names in destructuring BindingPatterns
        and AssignmentPatterns.

        Productions BindingProperty(1) and AssignmentProperty(2) allow for any valid
        PropertName(3), including ComputedPropertyName(4)

        1: http://tc39.github.io/ecma262/#prod-BindingProperty
        2: http://tc39.github.io/ecma262/#prod-AssignmentProperty
        3: http://tc39.github.io/ecma262/#prod-PropertyName
        4: http://tc39.github.io/ecma262/#prod-ComputedPropertyName

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ObjectPatternNode::bindValue):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::appendObjectPatternEntry):
        * parser/Nodes.h:
        (JSC::ObjectPatternNode::appendEntry):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::operatorStackPop):
        * tests/es6.yaml:
        * tests/es6/destructuring_assignment_computed_properties.js: Added.
        (test):
        (test.computeName):
        (test.loadValue):
        (test.out.get a):
        (test.out.set a):
        (test.out.get b):
        (test.out.set b):
        (test.out.get c):
        (test.out.set c):
        (test.get var):

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

        Unreviewed, rolling out r192536, r192722, and r192743.
        https://bugs.webkit.org/show_bug.cgi?id=151593

        Still causing trouble. (Requested by kling on #webkit).

        Reverted changesets:

        "[JSC] JSPropertyNameEnumerator could be destructorless."
        https://bugs.webkit.org/show_bug.cgi?id=151242
        http://trac.webkit.org/changeset/192536

        "REGRESSION(r192536): Null pointer dereference in
        JSPropertyNameEnumerator::visitChildren()."
        https://bugs.webkit.org/show_bug.cgi?id=151495
        http://trac.webkit.org/changeset/192722

        "REGRESSION(r192536): Null pointer dereference in
        JSPropertyNameEnumerator::visitChildren()."
        https://bugs.webkit.org/show_bug.cgi?id=151495
        http://trac.webkit.org/changeset/192743

2015-11-23  Brian Burg  <bburg@apple.com>

        Unreviewed, fix the Mac CMake build after r192793.

        * PlatformMac.cmake:

2015-11-20  Brian Burg  <bburg@apple.com>

        Web Inspector: RemoteInspector should track targets and connections for remote automation
        https://bugs.webkit.org/show_bug.cgi?id=151042

        Reviewed by Joseph Pecoraro.

        Refactor RemoteInspector so it can be used to send listings of different target types.
        First, rename Debuggable to RemoteInspectionTarget, and pull things not specific to
        remote inspection into the base class RemoteControllableTarget and its Connection class.

        Add a new RemoteControllableTarget called RemoteAutomationTarget, used by UIProcess
        to support remote UI automation via webinspectord. On the protocol side, this target
        uses a new WIRTypeKey called WIRTypeAutomation to distiguish the listing from
        Web and JavaScript listings and avoid inventing a new listing mechanism.

        * API/JSContextRef.cpp:
        (JSGlobalContextGetDebuggerRunLoop):
        (JSGlobalContextSetDebuggerRunLoop):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/InspectorFrontendChannel.h:
        * inspector/remote/RemoteAutomationTarget.cpp: Added.
        (Inspector::RemoteAutomationTarget::setAutomationAllowed): Added.
        * inspector/remote/RemoteAutomationTarget.h: Added.
        * inspector/remote/RemoteConnectionToTarget.h: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorDebuggableConnection.h.
        (Inspector::RemoteTargetBlock::RemoteTargetBlock):
        (Inspector::RemoteTargetBlock::~RemoteTargetBlock):
        (Inspector::RemoteTargetBlock::operator=):
        (Inspector::RemoteTargetBlock::operator()):
        * inspector/remote/RemoteConnectionToTarget.mm: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorDebuggableConnection.mm.
        (Inspector::RemoteTargetHandleRunSourceGlobal):
        (Inspector::RemoteTargetQueueTaskOnGlobalQueue):
        (Inspector::RemoteTargetInitializeGlobalQueue):
        (Inspector::RemoteTargetHandleRunSourceWithInfo):
        (Inspector::RemoteConnectionToTarget::RemoteConnectionToTarget):
        (Inspector::RemoteConnectionToTarget::~RemoteConnectionToTarget):
        (Inspector::RemoteConnectionToTarget::destination):
        (Inspector::RemoteConnectionToTarget::connectionIdentifier):
        (Inspector::RemoteConnectionToTarget::dispatchAsyncOnTarget):
        (Inspector::RemoteConnectionToTarget::setup):
        (Inspector::RemoteConnectionToTarget::targetClosed):
        (Inspector::RemoteConnectionToTarget::close):
        (Inspector::RemoteConnectionToTarget::sendMessageToTarget):
        (Inspector::RemoteConnectionToTarget::sendMessageToFrontend):
        (Inspector::RemoteConnectionToTarget::setupRunLoop):
        (Inspector::RemoteConnectionToTarget::teardownRunLoop):
        (Inspector::RemoteConnectionToTarget::queueTaskOnPrivateRunLoop):
        * inspector/remote/RemoteControllableTarget.cpp: Added.
        (Inspector::RemoteControllableTarget::~RemoteControllableTarget):
        (Inspector::RemoteControllableTarget::init):
        (Inspector::RemoteControllableTarget::update):
        * inspector/remote/RemoteControllableTarget.h: Added.
        * inspector/remote/RemoteInspectionTarget.cpp: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorDebuggable.cpp.
        (Inspector::RemoteInspectionTarget::remoteControlAllowed):
        (Inspector::RemoteInspectionTarget::setRemoteDebuggingAllowed):
        (Inspector::RemoteInspectionTarget::pauseWaitingForAutomaticInspection):
        (Inspector::RemoteInspectionTarget::unpauseForInitializedInspector):
        * inspector/remote/RemoteInspectionTarget.h: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorDebuggable.h.
        (isType):
        * inspector/remote/RemoteInspector.h:

            Code to manage Debuggables now works with RemoteControllableTargets and doesn't
            care whether the target is for Inspection or Automation. Listing data with target-
            and type-specific information are captured when clients call into RemoteInspector
            since that's the easiest time to gather this information on the right thread.
            Use the is<> / downcast<> machinery when we need a concrete Target type.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::nextAvailableIdentifier):
        (Inspector::RemoteInspector::registerTarget): renamed from registerDebuggable.
        (Inspector::RemoteInspector::unregisterTarget): renamed from unregisterDebuggable.
        (Inspector::RemoteInspector::updateTarget): renamed from updateDebuggable.
        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
        (Inspector::RemoteInspector::sendMessageToRemote):
        (Inspector::RemoteInspector::setupFailed):
        (Inspector::RemoteInspector::stopInternal):
        (Inspector::RemoteInspector::setupXPCConnectionIfNeeded):
        (Inspector::RemoteInspector::xpcConnectionFailed):
        (Inspector::RemoteInspector::listingForTarget):
        (Inspector::RemoteInspector::listingForInspectionTarget):
        (Inspector::RemoteInspector::listingForAutomationTarget):
        (Inspector::RemoteInspector::pushListingsNow):
        (Inspector::RemoteInspector::pushListingsSoon):
        (Inspector::RemoteInspector::receivedSetupMessage):
        (Inspector::RemoteInspector::receivedDataMessage):
        (Inspector::RemoteInspector::receivedDidCloseMessage):
        (Inspector::RemoteInspector::receivedGetListingMessage):
        (Inspector::RemoteInspector::receivedIndicateMessage):
        (Inspector::RemoteInspector::receivedConnectionDiedMessage):
        (Inspector::RemoteInspector::RemoteInspector): Deleted.
        (Inspector::RemoteInspector::registerDebuggable): Deleted.
        (Inspector::RemoteInspector::unregisterDebuggable): Deleted.
        (Inspector::RemoteInspector::updateDebuggable): Deleted.
        (Inspector::RemoteInspector::updateDebuggableAutomaticInspectCandidate): Deleted.
        (Inspector::RemoteInspector::sendMessageToRemoteFrontend): Deleted.
        (Inspector::RemoteInspector::listingForDebuggable): Deleted.
        (Inspector::RemoteInspector::pushListingNow): Deleted.
        (Inspector::RemoteInspector::pushListingSoon): Deleted.
        * inspector/remote/RemoteInspectorConstants.h:
        * runtime/JSGlobalObjectDebuggable.cpp:
        (JSC::JSGlobalObjectDebuggable::dispatchMessageFromRemote):
        (JSC::JSGlobalObjectDebuggable::pauseWaitingForAutomaticInspection):
        (JSC::JSGlobalObjectDebuggable::dispatchMessageFromRemoteFrontend): Deleted.
        * runtime/JSGlobalObjectDebuggable.h:

2015-11-23  Brian Burg  <bburg@apple.com>

        Rename JavaScriptCore builtins files to match exposed object names
        https://bugs.webkit.org/show_bug.cgi?id=151549

        Reviewed by Youenn Fablet.

        As a subtask of unifying code generation for WebCore and JSC builtins, we need to get rid of
        differences between builtins filenames (e.g., Promise.prototype.js) and the name of the
        generated Builtin object (PromisePrototype).

        If we don't do this, then both build systems need special hacks to normalize the object name
        from the file name. It's easier to just normalize the filename.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ArrayIteratorPrototype.js: Renamed from Source/JavaScriptCore/builtins/ArrayIterator.prototype.js.
        * builtins/ArrayPrototype.js: Renamed from Source/JavaScriptCore/builtins/Array.prototype.js.
        * builtins/FunctionPrototype.js: Renamed from Source/JavaScriptCore/builtins/Function.prototype.js.
        * builtins/IteratorPrototype.js: Renamed from Source/JavaScriptCore/builtins/Iterator.prototype.js.
        * builtins/PromiseOperations.js: Renamed from Source/JavaScriptCore/builtins/Operations.Promise.js.
        * builtins/PromisePrototype.js: Renamed from Source/JavaScriptCore/builtins/Promise.prototype.js.
        * builtins/StringIteratorPrototype.js: Renamed from Source/JavaScriptCore/builtins/StringIterator.prototype.js.
        * builtins/TypedArrayPrototype.js: Renamed from Source/JavaScriptCore/builtins/TypedArray.prototype.js.

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

        REGRESSION(r192536): Null pointer dereference in JSPropertyNameEnumerator::visitChildren().
        <https://webkit.org/b/151495>

        Reviewed by Mark Lam

        The test I added when fixing this bug the first time caught another bug when
        run on 32-bit: jsString() can also cause GC, so we have to make sure that
        JSPropertyNameEnumerator::m_propertyNames is null until after the array it
        points to has been populated.

        Test: property-name-enumerator-gc-151495.js

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

== Rolled over to ChangeLog-2015-11-21 ==