X-Git-Url: https://git.saurik.com/apple/javascriptcore.git/blobdiff_plain/ef99ff287df9046eb88937225e0554eabb00e33c..2656c66b5b30d5597e842a751c7f19ad6c2fe31a:/ChangeLog diff --git a/ChangeLog b/ChangeLog index bbda15d..097cfa1 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,681 @@ +2015-03-06 Lucas Forschler + + Merge r180234 + + 2015-02-17 Filip Pizlo + + Throwing from an FTL call IC slow path may result in tag registers being clobbered on 64-bit CPUs + https://bugs.webkit.org/show_bug.cgi?id=141717 + rdar://problem/19863382 + + Reviewed by Geoffrey Garen. + + The best solution is to ensure that the engine catching an exception restores tag registers. + + Each of these new test cases reliably crashed prior to this patch and they don't crash at all now. + + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_catch): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter64.asm: + * tests/stress/throw-from-ftl-call-ic-slow-path-cells.js: Added. + * tests/stress/throw-from-ftl-call-ic-slow-path-undefined.js: Added. + * tests/stress/throw-from-ftl-call-ic-slow-path.js: Added. + +2015-03-06 Lucas Forschler + + Merge r181030 + + 2015-03-04 Filip Pizlo + + [FTL] inlined GetMyArgumentByVal with no arguments passed causes instant crash + https://bugs.webkit.org/show_bug.cgi?id=141180 + rdar://problem/19677552 + + Reviewed by Benjamin Poulain. + + If we do a GetMyArgumentByVal on an inlined call frame that has no arguments, then the + bounds check already terminates execution. This means we can skip the part where we + previously did an out-of-bound array access on the inlined call frame arguments vector. + + * ftl/FTLLowerDFGToLLVM.cpp: + (JSC::FTL::LowerDFGToLLVM::safelyInvalidateAfterTermination): + (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal): + (JSC::FTL::LowerDFGToLLVM::terminate): + (JSC::FTL::LowerDFGToLLVM::didAlreadyTerminate): + (JSC::FTL::LowerDFGToLLVM::crash): + * tests/stress/get-my-argument-by-val-inlined-no-formal-parameters.js: Added. + (foo): + (bar): + +2015-03-04 Matthew Hanson + + Merge r180101. rdar://problem/19913017 + + 2015-02-13 Joseph Pecoraro + + JSContext Inspector: Do not stash console messages for non-debuggable JSContext + https://bugs.webkit.org/show_bug.cgi?id=141589 + + Reviewed by Timothy Hatcher. + + Consider developer extras disabled for JSContext inspection if the + RemoteInspector server is not enabled (typically a non-debuggable + process rejected by webinspectord) or if remote debugging on the + JSContext was explicitly disabled via SPI. + + When developer extras are disabled, console message will not be stashed. + + * inspector/JSGlobalObjectInspectorController.cpp: + (Inspector::JSGlobalObjectInspectorController::developerExtrasEnabled): + * inspector/JSGlobalObjectInspectorController.h: + +2015-02-26 Lucas Forschler + + Merge r180452 + + 2015-02-20 Mark Lam + + [JSObjCClassInfo reallocateConstructorAndOrPrototype] should also reallocate super class prototype chain. + + + Reviewed by Geoffrey Garen. + + A ObjC class that implement the JSExport protocol will have a JS prototype + chain and constructor automatically synthesized for its JS wrapper object. + However, if there are no more instances of that ObjC class reachable by a + JS GC root scan, then its synthesized prototype chain and constructors may + be released by the GC. If a new instance of that ObjC class is subsequently + instantiated, then [JSObjCClassInfo reallocateConstructorAndOrPrototype] + should re-construct the prototype chain and constructor (if they were + previously released). However, the current implementation only + re-constructs the immediate prototype, but not every other prototype + object upstream in the prototype chain. + + To fix this, we do the following: + 1. We no longer allocate the JSObjCClassInfo's prototype and constructor + eagerly. Hence, -initWithContext:forClass: will no longer call + -allocateConstructorAndPrototypeWithSuperClassInfo:. + 2. Instead, we'll always access the prototype and constructor thru + accessor methods. The accessor methods will call + -allocateConstructorAndPrototype: if needed. + 3. -allocateConstructorAndPrototype: will fetch the needed superClassInfo + from the JSWrapperMap itself. This makes it so that we no longer + need to pass the superClassInfo all over. + 4. -allocateConstructorAndPrototype: will get the super class prototype + by invoking -prototype: on the superClassInfo, thereby allowing the + super class to allocate its prototype and constructor if needed and + fixing the issue in this bug. + + 5. Also removed the GC warning comments, and ensured that needed JS + objects are kept alive by having a local var pointing to it from the + stack (which makes a GC root). + + * API/JSWrapperMap.mm: + (-[JSObjCClassInfo initWithContext:forClass:]): + (-[JSObjCClassInfo allocateConstructorAndPrototype]): + (-[JSObjCClassInfo wrapperForObject:]): + (-[JSObjCClassInfo constructor]): + (-[JSObjCClassInfo prototype]): + (-[JSWrapperMap classInfoForClass:]): + (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]): Deleted. + (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): Deleted. + (-[JSObjCClassInfo reallocateConstructorAndOrPrototype]): Deleted. + * API/tests/Regress141809.h: Added. + * API/tests/Regress141809.mm: Added. + (-[TestClassB name]): + (-[TestClassC name]): + (runRegress141809): + * API/tests/testapi.mm: + * JavaScriptCore.xcodeproj/project.pbxproj: + +2015-02-25 Babak Shafiei + + Merge patch for r180247 and r180249. + + 2015-02-20 Michael Saboff + + CrashTracer: DFG_CRASH beneath JSC::FTL::LowerDFGToLLVM::compileNode + https://bugs.webkit.org/show_bug.cgi?id=141730 + + Reviewed by Geoffrey Garen. + + Added a new failure handler, loweringFailed(), to LowerDFGToLLVM that reports failures + while processing DFG lowering. For debug builds, the failures are logged identical + to the way the DFG_CRASH() reports them. For release builds, the failures are reported + and that FTL compilation is terminated, but the process is allowed to continue. + Wrapped calls to loweringFailed() in a macro LOWERING_FAILED so the function and + line number are reported at the point of the inconsistancy. + + Converted instances of DFG_CRASH to LOWERING_FAILED. + + * dfg/DFGPlan.cpp: + (JSC::DFG::Plan::compileInThreadImpl): Added lowerDFGToLLVM() failure check that + will fail the FTL compile. + + * ftl/FTLLowerDFGToLLVM.cpp: + (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM): + Added new member variable, m_loweringSucceeded, to stop compilation on the first + reported failure. + + * ftl/FTLLowerDFGToLLVM.cpp: + (JSC::FTL::LowerDFGToLLVM::lower): + * ftl/FTLLowerDFGToLLVM.h: + Added check for compilation failures and now report those failures via a boolean + return value. + + * ftl/FTLLowerDFGToLLVM.cpp: + (JSC::FTL::LowerDFGToLLVM::createPhiVariables): + (JSC::FTL::LowerDFGToLLVM::compileNode): + (JSC::FTL::LowerDFGToLLVM::compileUpsilon): + (JSC::FTL::LowerDFGToLLVM::compilePhi): + (JSC::FTL::LowerDFGToLLVM::compileDoubleRep): + (JSC::FTL::LowerDFGToLLVM::compileValueRep): + (JSC::FTL::LowerDFGToLLVM::compileValueToInt32): + (JSC::FTL::LowerDFGToLLVM::compilePutLocal): + (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub): + (JSC::FTL::LowerDFGToLLVM::compileArithMul): + (JSC::FTL::LowerDFGToLLVM::compileArithDiv): + (JSC::FTL::LowerDFGToLLVM::compileArithMod): + (JSC::FTL::LowerDFGToLLVM::compileArithMinOrMax): + (JSC::FTL::LowerDFGToLLVM::compileArithAbs): + (JSC::FTL::LowerDFGToLLVM::compileArithNegate): + (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure): + (JSC::FTL::LowerDFGToLLVM::compileGetById): + (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal): + (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength): + (JSC::FTL::LowerDFGToLLVM::compileGetByVal): + (JSC::FTL::LowerDFGToLLVM::compilePutByVal): + (JSC::FTL::LowerDFGToLLVM::compileArrayPush): + (JSC::FTL::LowerDFGToLLVM::compileArrayPop): + (JSC::FTL::LowerDFGToLLVM::compileNewArray): + (JSC::FTL::LowerDFGToLLVM::compileToString): + (JSC::FTL::LowerDFGToLLVM::compileMakeRope): + (JSC::FTL::LowerDFGToLLVM::compileCompareEq): + (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq): + (JSC::FTL::LowerDFGToLLVM::compileSwitch): + (JSC::FTL::LowerDFGToLLVM::compare): + (JSC::FTL::LowerDFGToLLVM::boolify): + (JSC::FTL::LowerDFGToLLVM::opposite): + (JSC::FTL::LowerDFGToLLVM::lowJSValue): + (JSC::FTL::LowerDFGToLLVM::speculate): + (JSC::FTL::LowerDFGToLLVM::isArrayType): + (JSC::FTL::LowerDFGToLLVM::exitValueForAvailability): + (JSC::FTL::LowerDFGToLLVM::exitValueForNode): + (JSC::FTL::LowerDFGToLLVM::setInt52): + Changed DFG_CRASH() to LOWERING_FAILED(). Updated related control flow as appropriate. + + (JSC::FTL::LowerDFGToLLVM::loweringFailed): New error reporting member function. + +2015-02-25 Babak Shafiei + + Merge r180516. + + 2015-02-23 Matthew Mirman + + r9 is volatile on ARMv7 for iOS 3 and up. + https://bugs.webkit.org/show_bug.cgi?id=141489 + rdar://problem/19432916 + + Reviewed by Michael Saboff. + + * jit/RegisterSet.cpp: + (JSC::RegisterSet::calleeSaveRegisters): removed r9 from the list of ARMv7 callee save registers. + * tests/stress/regress-141489.js: Added. + (foo): + +2015-02-20 Lucas Forschler + + Merge r180237 + + 2015-02-17 Filip Pizlo + + StackLayoutPhase should use CodeBlock::usesArguments rather than FunctionExecutable::usesArguments + https://bugs.webkit.org/show_bug.cgi?id=141721 + rdar://problem/17198633 + + Reviewed by Michael Saboff. + + I've seen cases where the two are out of sync. We know we can trust the CodeBlock::usesArguments because + we use it everywhere else. + + No test because I could never reproduce the crash. + + * dfg/DFGGraph.h: + (JSC::DFG::Graph::usesArguments): + * dfg/DFGStackLayoutPhase.cpp: + (JSC::DFG::StackLayoutPhase::run): + +2015-02-20 Babak Shafiei + + Merge r178224. + + 2015-01-09 Joseph Pecoraro + + Web Inspector: Uncaught Exception in ProbeManager deleting breakpoint + https://bugs.webkit.org/show_bug.cgi?id=140279 + rdar://problem/19422299 + + Reviewed by Oliver Hunt. + + * runtime/MapData.cpp: + (JSC::MapData::replaceAndPackBackingStore): + The cell table also needs to have its values fixed. + +2015-02-20 Babak Shafiei + + Merge patch for rdar://problem/19828630. + + 2015-02-13 Filip Pizlo + + Effectful calls to length should only happen once on the varargs path. + rdar://problem/19828518 + + Reviewed by Michael Saboff. + + * interpreter/Interpreter.cpp: + (JSC::sizeFrameForVarargs): + (JSC::loadVarargs): + * runtime/VM.cpp: + (JSC::VM::VM): + * runtime/VM.h: + +2015-02-10 Babak Shafiei + + Merge r179576, r179648. + + 2015-02-04 Mark Lam + + r179576 introduce a deadlock potential during GC thread suspension. + + + Reviewed by Michael Saboff. + + http://trac.webkit.org/r179576 introduced a potential for deadlocking. + In the GC thread suspension loop, we currently delete + MachineThreads::Thread that we detect to be invalid. This is unsafe + because we may have already suspended some threads, and one of those + suspended threads may still be holding the C heap lock which we need + for deleting the invalid thread. + + The fix is to put the invalid threads in a separate toBeDeleted list, + and delete them only after GC has resumed all threads. + + * heap/MachineStackMarker.cpp: + (JSC::MachineThreads::removeCurrentThread): + - Undo refactoring removeThreadWithLockAlreadyAcquired() out of + removeCurrentThread() since it is no longer needed. + + (JSC::MachineThreads::tryCopyOtherThreadStacks): + - Put invalid Threads on a threadsToBeDeleted list, and delete those + Threads only after all threads have been resumed. + + (JSC::MachineThreads::removeThreadWithLockAlreadyAcquired): Deleted. + * heap/MachineStackMarker.h: + + 2015-02-03 Mark Lam + + Workaround a thread library bug where thread destructors may not get called. + + + Reviewed by Michael Saboff. + + There's a bug where thread destructors may not get called. As far as + we know, this only manifests on darwin ports. We will work around this + by checking at GC time if the platform thread is still valid. If not, + we'll purge it from the VM's registeredThreads list before proceeding + with thread scanning activity. + + Note: it is important that we do this invalid thread detection during + suspension, because the validity (and liveness) of the other thread is + only guaranteed while it is suspended. + + * API/tests/testapi.mm: + (threadMain): + - Added a test to enter the VM from another thread before we GC on + the main thread. + + * heap/MachineStackMarker.cpp: + (JSC::MachineThreads::removeThreadWithLockAlreadyAcquired): + (JSC::MachineThreads::removeCurrentThread): + - refactored removeThreadWithLockAlreadyAcquired() out from + removeCurrentThread() so that we can also call it for purging invalid + threads. + (JSC::suspendThread): + - Added a return status to tell if the suspension succeeded or not. + (JSC::MachineThreads::tryCopyOtherThreadStacks): + - Check if the suspension failed, and purge the thread if we can't + suspend it. Failure to suspend implies that the thread has + terminated without calling its destructor. + * heap/MachineStackMarker.h: + +2015-02-10 Babak Shafiei + + Merge r179187. + + 2015-01-27 Csaba Osztrogonác + + [ARM] Typo fix after r176083 + https://bugs.webkit.org/show_bug.cgi?id=140937 + + Reviewed by Anders Carlsson. + + * assembler/ARMv7Assembler.h: + (JSC::ARMv7Assembler::ldrh): + +2015-02-10 Babak Shafiei + + Merge r176083. + + 2014-11-13 Benjamin Poulain + + ARMv7(s) Assembler: LDRH with immediate offset is loading from the wrong offset + https://bugs.webkit.org/show_bug.cgi?id=136914 + + Reviewed by Michael Saboff. + + TLDR: the immediate offset of half-word load was divided by 2. + + Story time: So I started getting those weird reports of :nth-child() behaving bizarrely + on ARMv7 and ARMv7s. To make things worse, the behavior changes depending on style updates. + + I started looking the disassembly on the tests cases... + + The first thing I noticed was that the computation of An+B looked wrong. For example, + in the case of n+6, the instruction should have been: + subs r1, r1, #6 + but was + subs r1, r1, #2 + + After spending a lot of time trying to find the error in the assembler, I discovered + the problem was not real, but just a bug in the disassembler. + This is the first fix: ARMv7DOpcodeAddSubtractImmediate3's immediate3() was truncating + the value to 2 bits instead of 3 bits. + + The disassembler being fixed, I still have no lead on the weird bug. Some disassembly later, + I realize the LDRH instruction is not decoded at all. The reason is that both LDRH and STRH + were under the umbrella ARMv7DOpcodeLoadStoreRegisterImmediateHalfWord but the pattern + only matched SRTH. + + I fix that next, ARMv7DOpcodeLoadStoreRegisterImmediateHalfWord is split into + ARMv7DOpcodeStoreRegisterImmediateHalfWord and ARMv7DOpcodeLoadRegisterImmediateHalfWord, + each with their own pattern and their instruction group. + + Now that I can see the LDRHs correctly, there is something fishy about them, their offset + is way too small for the data I load. + + This time, looking at the binary, the generated code is indeed incorrect. It turns out that + the ARMv7 assembler shifted the offset of half-word load as if they were byte load: divided by 4. + As a result, all the load of half-words with more than zero offset were loading + values with a smaller offset than what they should have. + + That being fixed, I dump the assembly: still wrong. I am ready to throw my keyboard through + my screen at that point. + + Looking at the disassembler, there is yet again a bug. The computation of the scale() adjustment + of the offset was incorrect for anything but word loads. + I replaced it by a switch-case to make it explicit. + + STRH is likely incorrect too. I'll fix that in a follow up, I want to survey all the 16 bits cases + that are not directly used by the CSS JIT. + + * assembler/ARMv7Assembler.h: + (JSC::ARMv7Assembler::ldrh): + Fix the immediate scaling. Add an assertion to make sure the alignment of the input is correct. + + * disassembler/ARMv7/ARMv7DOpcode.cpp: + (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::scale): + Fix the scaling code. Just hardcode instruction-to-scale table. + + * disassembler/ARMv7/ARMv7DOpcode.h: + (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::immediate3): + The mask for a 3 bits immediate is not 3 :) + + (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::scale): Deleted. + +2015-02-05 Lucas Forschler + + Merge r178953 + + 2015-01-21 Joseph Pecoraro + + Web Inspector: ASSERT expanding objects in console PrimitiveBindingTraits::assertValueHasExpectedType + https://bugs.webkit.org/show_bug.cgi?id=140746 + + Reviewed by Timothy Hatcher. + + * inspector/InjectedScriptSource.js: + Do not add impure properties to the descriptor object that will + eventually be sent to the frontend. + +2015-02-05 Lucas Forschler + + Merge r178768 + + 2015-01-20 Joseph Pecoraro + + Web Inspector: Expanding event objects in console shows undefined for most values, it should have real values + https://bugs.webkit.org/show_bug.cgi?id=137306 + + Reviewed by Timothy Hatcher. + + Provide another optional parameter to getProperties, to gather a list + of all own and getter properties. + + * inspector/InjectedScript.cpp: + (Inspector::InjectedScript::getProperties): + * inspector/InjectedScript.h: + * inspector/InjectedScriptSource.js: + * inspector/agents/InspectorRuntimeAgent.cpp: + (Inspector::InspectorRuntimeAgent::getProperties): + * inspector/agents/InspectorRuntimeAgent.h: + * inspector/protocol/Runtime.json: + +2015-02-04 Lucas Forschler + + Merge r179329 + + 2015-01-13 Geoffrey Garen + + Out of bounds access in BytecodeGenerator::emitGetById under DotAccessorNode::emitBytecode + https://bugs.webkit.org/show_bug.cgi?id=140397 + + Reviewed by Geoffrey Garen. + + Patch by Alexey Proskuryakov. + + Reviewed, performance tested, and ChangeLogged by Geoffrey Garen. + + No performance change. + + No test, since this is a small past-the-end read, which is very + difficult to turn into a reproducible failing test -- and existing tests + crash reliably using ASan. + + * bytecompiler/NodesCodegen.cpp: + (JSC::BracketAccessorNode::emitBytecode): + (JSC::DotAccessorNode::emitBytecode): + (JSC::FunctionCallBracketNode::emitBytecode): + (JSC::PostfixNode::emitResolve): + (JSC::DeleteBracketNode::emitBytecode): + (JSC::DeleteDotNode::emitBytecode): + (JSC::PrefixNode::emitResolve): + (JSC::UnaryOpNode::emitBytecode): + (JSC::BitwiseNotNode::emitBytecode): + (JSC::BinaryOpNode::emitBytecode): + (JSC::EqualNode::emitBytecode): + (JSC::StrictEqualNode::emitBytecode): + (JSC::ThrowableBinaryOpNode::emitBytecode): + (JSC::AssignDotNode::emitBytecode): + (JSC::AssignBracketNode::emitBytecode): Use RefPtr in more places. Any + register used across a call to a function that might allocate a new + temporary register must be held in a RefPtr. + +2015-02-04 Lucas Forschler + + Merge r178311 + + 2015-01-12 Geoffrey Garen + + Out of bounds read in IdentifierArena::makeIdentifier + https://bugs.webkit.org/show_bug.cgi?id=140376 + + Patch by Alexey Proskuryakov. + + Reviewed and ChangeLogged by Geoffrey Garen. + + No test, since this is a small past-the-end read, which is very + difficult to turn into a reproducible failing test -- and existing tests + crash reliably using ASan. + + * parser/ParserArena.h: + (JSC::IdentifierArena::makeIdentifier): + (JSC::IdentifierArena::makeIdentifierLCharFromUChar): Check for a + zero-length string input, like we do in the literal parser, since it is + not valid to dereference characters in a zero-length string. + + A zero-length string is allowed in JavaScript -- for example, "". + +2015-01-28 Lucas Forschler + + Merge r178364 + + 2015-01-12 Michael Saboff + + Local JSArray* "keys" in objectConstructorKeys() is not marked during garbage collection + https://bugs.webkit.org/show_bug.cgi?id=140348 + + Reviewed by Mark Lam. + + We used to read registers in MachineThreads::gatherFromCurrentThread(), but that is too late + because those registers may have been spilled on the stack and replaced with other values by + the time we call down to gatherFromCurrentThread(). + + Now we get the register contents at the same place that we demarcate the current top of + stack using the address of a local variable, in Heap::markRoots(). The register contents + buffer is passed along with the demarcation pointer. These need to be done at this level + in the call tree and no lower, as markRoots() calls various functions that visit object + pointers that may be latter proven dead. Any of those pointers that are left on the + stack or in registers could be incorrectly marked as live if we scan the stack contents + from a called function or one of its callees. The stack demarcation pointer and register + saving need to be done in the same function so that we have a consistent stack, active + and spilled registers. + + Because we don't want to make unnecessary calls to get the register contents, we use + a macro to allocated, and possibly align, the register structure and get the actual + register contents. + + + * heap/Heap.cpp: + (JSC::Heap::markRoots): + (JSC::Heap::gatherStackRoots): + * heap/Heap.h: + * heap/MachineStackMarker.cpp: + (JSC::MachineThreads::gatherFromCurrentThread): + (JSC::MachineThreads::gatherConservativeRoots): + * heap/MachineStackMarker.h: + +2015-01-27 Lucas Forschler + + Merge r177455 + + 2014-12-17 Chris Dumez + + [iOS] Make it possible to toggle FeatureCounter support at runtime + https://bugs.webkit.org/show_bug.cgi?id=139688 + + + Reviewed by Andreas Kling. + + Stop linking against AppSupport framework as the functionality is no + longer in WTF (it was moved to WebCore). + + * Configurations/JavaScriptCore.xcconfig: + +2015-01-26 Lucas Forschler + + Merge r177328 + + 2014-12-15 Chris Dumez + + [iOS] Add feature counting support + https://bugs.webkit.org/show_bug.cgi?id=139652 + + + Reviewed by Gavin Barraclough. + + Link against AppSupport framework on iOS as we need it to implement + the new FeatureCounter API in WTF. + + * Configurations/JavaScriptCore.xcconfig: + +2015-01-21 Babak Shafiei + + Merge r176972. + + 2014-12-08 Mark Lam + + CFA wrongly assumes that a speculation for SlowPutArrayStorageShape disallows ArrayStorageShape arrays. + + + Reviewed by Michael Saboff. + + The code generator and runtime slow paths expects otherwise. This patch fixes + CFA to match the code generator's expectation. + + * dfg/DFGArrayMode.h: + (JSC::DFG::ArrayMode::arrayModesThatPassFiltering): + (JSC::DFG::ArrayMode::arrayModesWithIndexingShapes): + +2015-01-20 Babak Shafiei + + Merge r171691. + + 2014-07-28 Mark Hahnenberg + + REGRESSION: JSObjectSetPrototype() does not work on result of JSGetGlobalObject() + https://bugs.webkit.org/show_bug.cgi?id=135322 + + Reviewed by Oliver Hunt. + + The prototype chain of the JSProxy object should match that of the JSGlobalObject. + + This is a separate but related issue with JSObjectSetPrototype which doesn't correctly + account for JSProxies. I also audited the rest of the C API to check that we correctly + handle JSProxies in all other situations where we expect a JSCallbackObject of some sort + and found some SPI calls (JSObject*PrivateProperty) that didn't behave correctly when + passed a JSProxy. + + I also added some new tests for these cases. + + * API/JSObjectRef.cpp: + (JSObjectSetPrototype): + (JSObjectGetPrivateProperty): + (JSObjectSetPrivateProperty): + (JSObjectDeletePrivateProperty): + * API/JSWeakObjectMapRefPrivate.cpp: + * API/tests/CustomGlobalObjectClassTest.c: + (globalObjectSetPrototypeTest): + (globalObjectPrivatePropertyTest): + * API/tests/CustomGlobalObjectClassTest.h: + * API/tests/testapi.c: + (main): + +2015-01-11 Mark Lam + + Update WebKit branch to build with newer LLVM. + + + Reviewed by Filip Pizlo. + + * Configurations/LLVMForJSC.xcconfig: + - Add the ability to pick up LLVM_LIBS_iphoneos from AspenLLVM.xcconfig. + * llvm/LLVMAPIFunctions.h: + - Removed some erroneous and unused APIs. + * llvm/library/LLVMExports.cpp: + (initializeAndGetJSCLLVMAPI): + - Removed an unneeded option that is also not supported by the new LLVM. + 2014-12-10 Babak Shafiei Merge r176803.