Re-enable generate-xcfilelists
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
index 3128631..82d5cfe 100644 (file)
@@ -1,3 +1,133 @@
+2019-05-17  Keith Rollin  <krollin@apple.com>
+
+        Re-enable generate-xcfilelists
+        https://bugs.webkit.org/show_bug.cgi?id=197933
+        <rdar://problem/50831677>
+
+        Reviewed by Jonathan Bedard.
+
+        The following two tasks have been completed, and we can re-enable
+        generate-xcfilelists:
+
+        Bug 197619 <rdar://problem/50507392> Temporarily disable generate-xcfilelists (197619)
+        Bug 197622 <rdar://problem/50508222> Rewrite generate-xcfilelists in Python (197622)
+
+        * Scripts/check-xcfilelists.sh:
+
+2019-05-16  Keith Miller  <keith_miller@apple.com>
+
+        Wasm should cage the memory base pointers in structs
+        https://bugs.webkit.org/show_bug.cgi?id=197620
+
+        Reviewed by Saam Barati.
+
+        Currently, we use cageConditionally; this only matters for API
+        users since the web content process cannot disable primitive
+        gigacage. This patch also adds a set helper for union/intersection
+        of RegisterSets.
+
+        * assembler/CPU.h:
+        (JSC::isARM64E):
+        * jit/RegisterSet.h:
+        (JSC::RegisterSet::set):
+        * wasm/WasmAirIRGenerator.cpp:
+        (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
+        (JSC::Wasm::AirIRGenerator::addCallIndirect):
+        * wasm/WasmB3IRGenerator.cpp:
+        (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
+        (JSC::Wasm::B3IRGenerator::addCallIndirect):
+        * wasm/WasmBinding.cpp:
+        (JSC::Wasm::wasmToWasm):
+        * wasm/WasmInstance.h:
+        (JSC::Wasm::Instance::cachedMemory const):
+        (JSC::Wasm::Instance::updateCachedMemory):
+        * wasm/WasmMemory.cpp:
+        (JSC::Wasm::Memory::grow):
+        * wasm/WasmMemory.h:
+        (JSC::Wasm::Memory::memory const):
+        * wasm/js/JSToWasm.cpp:
+        (JSC::Wasm::createJSToWasmWrapper):
+        * wasm/js/WebAssemblyFunction.cpp:
+        (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
+
+2019-05-16  David Kilzer  <ddkilzer@apple.com>
+
+        REGRESSION (r15133): Fix leak of JSStringRef in minidom
+        <https://webkit.org/b/197968>
+        <rdar://problem/50872430>
+
+        Reviewed by Joseph Pecoraro.
+
+        * API/tests/minidom.c:
+        (print): Call JSStringRelease() to fix the leak.
+
+2019-05-16  Ross Kirsling  <ross.kirsling@sony.com>
+
+        [JSC] Invalid AssignmentTargetType should be an early error.
+        https://bugs.webkit.org/show_bug.cgi?id=197603
+
+        Reviewed by Keith Miller.
+
+        Since ES6, expressions like 0++, ++0, 0 = 0, and 0 += 0 are all specified as early errors:
+          https://tc39.github.io/ecma262/#sec-update-expressions-static-semantics-early-errors
+          https://tc39.github.io/ecma262/#sec-assignment-operators-static-semantics-early-errors
+
+        We currently throw late ReferenceErrors for these -- let's turn them into early SyntaxErrors.
+        (This is based on the expectation that https://github.com/tc39/ecma262/pull/1527 will be accepted;
+        if that doesn't come to pass, we can subsequently introduce early ReferenceError and revise these.)
+
+        * bytecompiler/NodesCodegen.cpp:
+        (JSC::PostfixNode::emitBytecode): Add an assert for "function call LHS" case.
+        (JSC::PrefixNode::emitBytecode): Add an assert for "function call LHS" case.
+
+        * parser/ASTBuilder.h:
+        (JSC::ASTBuilder::isLocation): Added.
+        (JSC::ASTBuilder::isAssignmentLocation): Fix misleading parameter name.
+        (JSC::ASTBuilder::isFunctionCall): Added.
+        (JSC::ASTBuilder::makeAssignNode): Add an assert for "function call LHS" case.
+        * parser/SyntaxChecker.h:
+        (JSC::SyntaxChecker::isLocation): Added.
+        (JSC::SyntaxChecker::isAssignmentLocation): Fix incorrect definition and align with ASTBuilder.
+        (JSC::SyntaxChecker::isFunctionCall): Added.
+        * parser/Nodes.h:
+        (JSC::ExpressionNode::isFunctionCall const): Added.
+        Ensure that the parser can check whether an expression node is a function call.
+
+        * parser/Parser.cpp:
+        (JSC::Parser<LexerType>::isSimpleAssignmentTarget): Added.
+        (JSC::Parser<LexerType>::parseAssignmentExpression):
+        (JSC::Parser<LexerType>::parseUnaryExpression): See below.
+        * parser/Parser.h:
+        Throw SyntaxError whenever an assignment or update expression's target is invalid.
+        Unfortunately, it seems that web compatibility obliges us to exempt the "function call LHS" case in sloppy mode.
+        (https://github.com/tc39/ecma262/issues/257#issuecomment-195106880)
+
+        Additional cleanup items:
+          - Make use of `semanticFailIfTrue` for `isMetaProperty` checks, as it's equivalent.
+          - Rename `requiresLExpr` to `hasPrefixUpdateOp` since it's now confusing,
+            and get rid of `modifiesExpr` since it refers to the exact same condition.
+          - Stop setting `lastOperator` near the end -- one case was incorrect and regardless neither is used.
+
+2019-05-15  Saam Barati  <sbarati@apple.com>
+
+        Bound liveness of SetArgumentMaybe nodes when maximal flush insertion phase is enabled
+        https://bugs.webkit.org/show_bug.cgi?id=197855
+        <rdar://problem/50236506>
+
+        Reviewed by Michael Saboff.
+
+        Maximal flush insertion phase assumes it can extend the live range of
+        variables. However, this is not true with SetArgumentMaybe nodes, because
+        they are not guaranteed to demarcate the birth of a variable in the way
+        that SetArgumentDefinitely does. This caused things to break in SSA conversion
+        when we wanted to use the result of a SetArgumentMaybe node. To obviate this,
+        when we're done inlining something with SetArgumentMaybes, we SetLocal(undefined)
+        to the same set of locals. This caps the live range of the SetArgumentMaybe
+        and makes it so that extending the live range of the SetLocal is valid.
+
+        * dfg/DFGByteCodeParser.cpp:
+        (JSC::DFG::ByteCodeParser::handleVarargsInlining):
+
 2019-05-14  Keith Miller  <keith_miller@apple.com>
 
         Fix issue with byteOffset on ARM64E