Release pointer lock when page state is reset for any reason, not just for process...
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-01-04  Saam Barati  <sbarati@apple.com>
2
3         We don't properly handle exceptions inside the nativeCallTrampoline macro in the LLInt
4         https://bugs.webkit.org/show_bug.cgi?id=163720
5
6         Reviewed by Mark Lam.
7
8         In the LLInt, we were incorrectly doing the exception check after the call.
9         Before the exception check, we were unwinding to our caller's
10         frame under the assumption that our caller was always a JS frame.
11         This is incorrect, however, because our caller might be a C frame.
12         One way that it can be a C frame is when C calls to JS, and JS tail
13         calls to native. This patch fixes this bug by doing unwinding from
14         the native callee's frame instead of its callers.
15
16         * llint/LowLevelInterpreter32_64.asm:
17         * llint/LowLevelInterpreter64.asm:
18
19 2017-01-03  JF Bastien  <jfbastien@apple.com>
20
21         REGRESSION (r210244): Release JSC Stress test failure: wasm.yaml/wasm/js-api/wasm-to-wasm.js.default-wasm
22         https://bugs.webkit.org/show_bug.cgi?id=166669
23         <rdar://problem/29856455>
24
25         Reviewed by Saam Barati.
26
27         Bug #165282 added wasm -> wasm calls, but caused crashes in
28         release builds because the pinned registers are also callee-saved
29         and were being clobbered. B3 didn't see itself clobbering them
30         when no memory was used, and therefore omitted a restore.
31
32         This was causing the C++ code in callWebAssemblyFunction to crash
33         because $r12 was 0, and it expected it to have its value prior to
34         the call.
35
36         * wasm/WasmB3IRGenerator.cpp:
37         (JSC::Wasm::createJSToWasmWrapper):
38
39 2017-01-03  Joseph Pecoraro  <pecoraro@apple.com>
40
41         Web Inspector: Address failures under LayoutTests/inspector/debugger/stepping
42         https://bugs.webkit.org/show_bug.cgi?id=166300
43
44         Reviewed by Brian Burg.
45
46         * debugger/Debugger.cpp:
47         (JSC::Debugger::continueProgram):
48         When continuing, clear states that would have had us pause again.
49
50         * inspector/agents/InspectorDebuggerAgent.cpp:
51         (Inspector::InspectorDebuggerAgent::didBecomeIdle):
52         When resuming after becoming idle, be sure to clear Debugger state.
53
54 2017-01-03  JF Bastien  <jfbastien@apple.com>
55
56         WebAssembly JS API: check and test in-call / out-call values
57         https://bugs.webkit.org/show_bug.cgi?id=164876
58         <rdar://problem/29844107>
59
60         Reviewed by Saam Barati.
61
62         * wasm/WasmBinding.cpp:
63         (JSC::Wasm::wasmToJs): fix the wasm -> JS call coercions for f32 /
64         f64 which the assotiated tests inadvertently tripped on: the
65         previous code wasn't correctly performing JSValue boxing for
66         "double" values. This change is slightly involved because it
67         requires two scratch registers to materialize the
68         `DoubleEncodeOffset` value. This change therefore reorganizes the
69         code to first generate traps, then handle all integers (freeing
70         all GPRs), and then all the floating-point values.
71         * wasm/js/WebAssemblyFunction.cpp:
72         (JSC::callWebAssemblyFunction): Implement the defined semantics
73         for mismatched arities when JS calls wasm:
74         https://github.com/WebAssembly/design/blob/master/JS.md#exported-function-exotic-objects
75           - i32 is 0, f32 / f64 are NaN.
76           - wasm functions which return "void" are "undefined" in JS.
77
78 2017-01-03  Per Arne Vollan  <pvollan@apple.com>
79
80         [Win] jsc.exe sometimes never exits.
81         https://bugs.webkit.org/show_bug.cgi?id=158073
82
83         Reviewed by Darin Adler.
84
85         On Windows the thread specific destructor is also called when the main thread is exiting.
86         This may lead to the main thread waiting forever for the machine thread lock when exiting,
87         if the sampling profiler thread was terminated by the system while holding the machine
88         thread lock.
89
90         * heap/MachineStackMarker.cpp:
91         (JSC::MachineThreads::removeThread):
92
93 2017-01-02  Julien Brianceau  <jbriance@cisco.com>
94
95         Remove sh4 specific code from JavaScriptCore
96         https://bugs.webkit.org/show_bug.cgi?id=166640
97
98         Reviewed by Filip Pizlo.
99
100         sh4-specific code does not compile for a while (r189884 at least).
101         As nobody seems to have interest in this architecture anymore, let's
102         remove this dead code and thus ease the burden for JSC maintainers.
103
104         * CMakeLists.txt:
105         * JavaScriptCore.xcodeproj/project.pbxproj:
106         * assembler/AbstractMacroAssembler.h:
107         (JSC::AbstractMacroAssembler::Jump::Jump):
108         (JSC::AbstractMacroAssembler::Jump::link):
109         * assembler/MacroAssembler.h:
110         * assembler/MacroAssemblerSH4.h: Removed.
111         * assembler/MaxFrameExtentForSlowPathCall.h:
112         * assembler/SH4Assembler.h: Removed.
113         * bytecode/DOMJITAccessCasePatchpointParams.cpp:
114         (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
115         * dfg/DFGSpeculativeJIT.h:
116         (JSC::DFG::SpeculativeJIT::callOperation):
117         * jit/AssemblyHelpers.h:
118         (JSC::AssemblyHelpers::debugCall):
119         * jit/CCallHelpers.h:
120         (JSC::CCallHelpers::setupArgumentsWithExecState):
121         (JSC::CCallHelpers::prepareForTailCallSlow):
122         * jit/CallFrameShuffler.cpp:
123         (JSC::CallFrameShuffler::prepareForTailCall):
124         * jit/ExecutableAllocator.h:
125         * jit/FPRInfo.h:
126         * jit/GPRInfo.h:
127         * jit/JITInlines.h:
128         (JSC::JIT::callOperation):
129         * jit/JITOpcodes32_64.cpp:
130         (JSC::JIT::privateCompileCTINativeCall):
131         * jit/JITOperations.cpp:
132         * jit/RegisterSet.cpp:
133         (JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
134         (JSC::RegisterSet::dfgCalleeSaveRegisters):
135         * jit/ThunkGenerators.cpp:
136         (JSC::nativeForGenerator):
137         * llint/LLIntData.cpp:
138         (JSC::LLInt::Data::performAssertions):
139         * llint/LLIntOfflineAsmConfig.h:
140         * llint/LowLevelInterpreter.asm:
141         * llint/LowLevelInterpreter32_64.asm:
142         * offlineasm/backends.rb:
143         * offlineasm/instructions.rb:
144         * offlineasm/sh4.rb: Removed.
145         * yarr/YarrJIT.cpp:
146         (JSC::Yarr::YarrGenerator::generateEnter):
147         (JSC::Yarr::YarrGenerator::generateReturn):
148
149 2017-01-02  JF Bastien  <jfbastien@apple.com>
150
151         WebAssembly: handle and optimize wasm export → wasm import calls
152         https://bugs.webkit.org/show_bug.cgi?id=165282
153
154         Reviewed by Saam Barati.
155
156           - Add a new JSType for WebAssemblyFunction, and use it when creating its
157             structure. This will is used to quickly detect from wasm whether the import
158             call is to another wasm module, or whether it's to JS.
159           - Generate two stubs from the import stub generator: one for wasm->JS and one
160             for wasm -> wasm. This is done at Module time. Which is called will only be
161             known at Instance time, once we've received the import object. We want to
162             avoid codegen at Instance time, so having both around is great.
163           - Restore the WebAssembly global state (VM top Instance, and pinned registers)
164             after call / call_indirect, and in the JS->wasm entry stub.
165           - Pinned registers are now a global thing, not per-Memory, because the wasm ->
166             wasm stubs are generated at Module time where we don't really have enough
167             information to do the right thing (doing so would generate too much code).
168
169         * CMakeLists.txt:
170         * JavaScriptCore.xcodeproj/project.pbxproj:
171         * runtime/JSType.h: add WebAssemblyFunctionType as a JSType
172         * wasm/WasmB3IRGenerator.cpp: significantly rework how calls which
173         could be external work, and how we save / restore global state:
174         VM's top Instance, and pinned registers
175         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
176         (JSC::Wasm::getMemoryBaseAndSize):
177         (JSC::Wasm::restoreWebAssemblyGlobalState):
178         (JSC::Wasm::createJSToWasmWrapper):
179         (JSC::Wasm::parseAndCompile):
180         * wasm/WasmB3IRGenerator.h:
181         * wasm/WasmBinding.cpp:
182         (JSC::Wasm::materializeImportJSCell):
183         (JSC::Wasm::wasmToJS):
184         (JSC::Wasm::wasmToWasm): the main goal of this patch was adding this function
185         (JSC::Wasm::exitStubGenerator):
186         * wasm/WasmBinding.h:
187         * wasm/WasmFormat.h: Get rid of much of the function index space:
188         we already have all of its information elsewhere, and as-is it
189         provides no extra efficiency.
190         (JSC::Wasm::ModuleInformation::functionIndexSpaceSize):
191         (JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace):
192         (JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace):
193         * wasm/WasmFunctionParser.h:
194         (JSC::Wasm::FunctionParser<Context>::FunctionParser):
195         * wasm/WasmMemory.cpp: Add some logging.
196         (JSC::Wasm::Memory::dump): this was nice when debugging
197         (JSC::Wasm::Memory::makeString):
198         (JSC::Wasm::Memory::Memory):
199         (JSC::Wasm::Memory::~Memory):
200         (JSC::Wasm::Memory::grow):
201         * wasm/WasmMemory.h: don't use extra indirection, it wasn't
202         needed. Reorder some of the fields which are looked up at runtime
203         so they're more cache-friendly.
204         (JSC::Wasm::Memory::Memory):
205         (JSC::Wasm::Memory::mode):
206         (JSC::Wasm::Memory::offsetOfSize):
207         * wasm/WasmMemoryInformation.cpp: Pinned registers are now a
208         global thing for all of JSC, not a per-Memory thing
209         anymore. wasm->wasm calls are more complex otherwise: they have to
210         figure out how to bridge between the caller and callee's
211         special-snowflake pinning.
212         (JSC::Wasm::PinnedRegisterInfo::get):
213         (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
214         (JSC::Wasm::MemoryInformation::MemoryInformation):
215         * wasm/WasmMemoryInformation.h:
216         * wasm/WasmModuleParser.cpp:
217         * wasm/WasmModuleParser.h:
218         * wasm/WasmPageCount.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
219         (JSC::Wasm::PageCount::dump): nice for debugging
220         * wasm/WasmPageCount.h:
221         * wasm/WasmPlan.cpp:
222         (JSC::Wasm::Plan::parseAndValidateModule):
223         (JSC::Wasm::Plan::run):
224         * wasm/WasmPlan.h:
225         (JSC::Wasm::Plan::takeWasmExitStubs):
226         * wasm/WasmSignature.cpp:
227         (JSC::Wasm::Signature::toString):
228         (JSC::Wasm::Signature::dump):
229         * wasm/WasmSignature.h:
230         * wasm/WasmValidate.cpp:
231         (JSC::Wasm::validateFunction):
232         * wasm/WasmValidate.h:
233         * wasm/js/JSWebAssemblyInstance.h:
234         (JSC::JSWebAssemblyInstance::offsetOfTable):
235         (JSC::JSWebAssemblyInstance::offsetOfImportFunctions):
236         (JSC::JSWebAssemblyInstance::offsetOfImportFunction):
237         * wasm/js/JSWebAssemblyMemory.cpp:
238         (JSC::JSWebAssemblyMemory::create):
239         (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
240         (JSC::JSWebAssemblyMemory::buffer):
241         (JSC::JSWebAssemblyMemory::grow):
242         * wasm/js/JSWebAssemblyMemory.h:
243         (JSC::JSWebAssemblyMemory::memory):
244         (JSC::JSWebAssemblyMemory::offsetOfMemory):
245         (JSC::JSWebAssemblyMemory::offsetOfSize):
246         * wasm/js/JSWebAssemblyModule.cpp:
247         (JSC::JSWebAssemblyModule::create):
248         (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
249         * wasm/js/JSWebAssemblyModule.h:
250         (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace):
251         (JSC::JSWebAssemblyModule::functionImportCount):
252         * wasm/js/WebAssemblyFunction.cpp:
253         (JSC::callWebAssemblyFunction):
254         (JSC::WebAssemblyFunction::create):
255         (JSC::WebAssemblyFunction::createStructure):
256         (JSC::WebAssemblyFunction::WebAssemblyFunction):
257         (JSC::WebAssemblyFunction::finishCreation):
258         * wasm/js/WebAssemblyFunction.h:
259         (JSC::WebAssemblyFunction::wasmEntrypoint):
260         (JSC::WebAssemblyFunction::offsetOfInstance):
261         (JSC::WebAssemblyFunction::offsetOfWasmEntryPointCode):
262         * wasm/js/WebAssemblyInstanceConstructor.cpp:
263         (JSC::constructJSWebAssemblyInstance): always start with a dummy
264         memory, so wasm->wasm calls don't need to null-check
265         * wasm/js/WebAssemblyMemoryConstructor.cpp:
266         (JSC::constructJSWebAssemblyMemory):
267         * wasm/js/WebAssemblyModuleConstructor.cpp:
268         (JSC::WebAssemblyModuleConstructor::createModule):
269         * wasm/js/WebAssemblyModuleRecord.cpp:
270         (JSC::WebAssemblyModuleRecord::link):
271         (JSC::WebAssemblyModuleRecord::evaluate):
272         * wasm/js/WebAssemblyModuleRecord.h:
273
274 2017-01-02  Saam Barati  <sbarati@apple.com>
275
276         WebAssembly: Some loads don't take into account the offset
277         https://bugs.webkit.org/show_bug.cgi?id=166616
278         <rdar://problem/29841541>
279
280         Reviewed by Keith Miller.
281
282         * wasm/WasmB3IRGenerator.cpp:
283         (JSC::Wasm::B3IRGenerator::emitLoadOp):
284
285 2017-01-01  Jeff Miller  <jeffm@apple.com>
286
287         Update user-visible copyright strings to include 2017
288         https://bugs.webkit.org/show_bug.cgi?id=166278
289
290         Reviewed by Dan Bernstein.
291
292         * Info.plist:
293
294 2016-12-28  Saam Barati  <sbarati@apple.com>
295
296         WebAssembly: Don't allow duplicate export names
297         https://bugs.webkit.org/show_bug.cgi?id=166490
298         <rdar://problem/29815000>
299
300         Reviewed by Keith Miller.
301
302         * wasm/WasmModuleParser.cpp:
303
304 2016-12-28  Saam Barati  <sbarati@apple.com>
305
306         Unreviewed. Fix jsc.cpp build error.
307
308         * jsc.cpp:
309         (functionTestWasmModuleFunctions):
310
311 2016-12-28  Saam Barati  <sbarati@apple.com>
312
313         WebAssembly: Implement grow_memory and current_memory
314         https://bugs.webkit.org/show_bug.cgi?id=166448
315         <rdar://problem/29803676>
316
317         Reviewed by Keith Miller.
318
319         This patch implements grow_memory, current_memory, and WebAssembly.prototype.grow.
320         See relevant spec texts here:
321         
322         https://github.com/WebAssembly/design/blob/master/Semantics.md#linear-memory-accesses
323         https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymemoryprototypegrow
324         
325         I also fix a couple miscellaneous bugs:
326         
327         1. Data section now understands full init_exprs. 
328         2. parseVarUint1 no longer has a bug where we allow values larger than 1 if
329         their bottom 8 bits are zero.
330         
331         Since the JS API can now grow memory, we need to make calling an import
332         and call_indirect refresh the base memory register and the size registers.
333
334         * jsc.cpp:
335         (functionTestWasmModuleFunctions):
336         * runtime/Options.h:
337         * runtime/VM.h:
338         * wasm/WasmB3IRGenerator.cpp:
339         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
340         (JSC::Wasm::reloadPinnedRegisters):
341         (JSC::Wasm::B3IRGenerator::emitReloadPinnedRegisters):
342         (JSC::Wasm::createJSToWasmWrapper):
343         (JSC::Wasm::parseAndCompile):
344         * wasm/WasmFormat.cpp:
345         (JSC::Wasm::Segment::create):
346         * wasm/WasmFormat.h:
347         (JSC::Wasm::I32InitExpr::I32InitExpr):
348         (JSC::Wasm::I32InitExpr::globalImport):
349         (JSC::Wasm::I32InitExpr::constValue):
350         (JSC::Wasm::I32InitExpr::isConst):
351         (JSC::Wasm::I32InitExpr::isGlobalImport):
352         (JSC::Wasm::I32InitExpr::globalImportIndex):
353         (JSC::Wasm::Segment::byte):
354         (JSC::Wasm::ModuleInformation::importFunctionCount):
355         (JSC::Wasm::ModuleInformation::hasMemory):
356         * wasm/WasmFunctionParser.h:
357         * wasm/WasmMemory.cpp:
358         (JSC::Wasm::Memory::Memory):
359         (JSC::Wasm::Memory::grow):
360         * wasm/WasmMemory.h:
361         (JSC::Wasm::Memory::size):
362         (JSC::Wasm::Memory::sizeInPages):
363         (JSC::Wasm::Memory::offsetOfMemory):
364         (JSC::Wasm::Memory::isValid): Deleted.
365         (JSC::Wasm::Memory::grow): Deleted.
366         * wasm/WasmModuleParser.cpp:
367         (JSC::Wasm::makeI32InitExpr):
368         * wasm/WasmModuleParser.h:
369         * wasm/WasmPageCount.h:
370         (JSC::Wasm::PageCount::bytes):
371         (JSC::Wasm::PageCount::pageCount):
372         (JSC::Wasm::PageCount::fromBytes):
373         (JSC::Wasm::PageCount::operator+):
374         * wasm/WasmParser.h:
375         (JSC::Wasm::Parser<SuccessType>::parseVarUInt1):
376         * wasm/WasmValidate.cpp:
377         * wasm/js/JSWebAssemblyInstance.h:
378         (JSC::JSWebAssemblyInstance::offsetOfMemory):
379         * wasm/js/JSWebAssemblyMemory.cpp:
380         (JSC::JSWebAssemblyMemory::~JSWebAssemblyMemory):
381         (JSC::JSWebAssemblyMemory::grow):
382         * wasm/js/JSWebAssemblyMemory.h:
383         (JSC::JSWebAssemblyMemory::offsetOfMemory):
384         * wasm/js/JSWebAssemblyModule.h:
385         (JSC::JSWebAssemblyModule::functionImportCount):
386         (JSC::JSWebAssemblyModule::jsEntrypointCalleeFromFunctionIndexSpace):
387         (JSC::JSWebAssemblyModule::wasmEntrypointCalleeFromFunctionIndexSpace):
388         (JSC::JSWebAssemblyModule::importCount): Deleted.
389         * wasm/js/WebAssemblyFunction.cpp:
390         (JSC::callWebAssemblyFunction):
391         * wasm/js/WebAssemblyInstanceConstructor.cpp:
392         (JSC::constructJSWebAssemblyInstance):
393         * wasm/js/WebAssemblyMemoryConstructor.cpp:
394         (JSC::constructJSWebAssemblyMemory):
395         * wasm/js/WebAssemblyMemoryPrototype.cpp:
396         (JSC::getMemory):
397         (JSC::webAssemblyMemoryProtoFuncBuffer):
398         (JSC::webAssemblyMemoryProtoFuncGrow):
399         * wasm/js/WebAssemblyModuleRecord.cpp:
400         (JSC::WebAssemblyModuleRecord::link):
401         (JSC::dataSegmentFail):
402         (JSC::WebAssemblyModuleRecord::evaluate):
403         * wasm/wasm.json:
404
405 2016-12-26  Yusuke Suzuki  <utatane.tea@gmail.com>
406
407         Use variadic templates in JSC Parser to clean up
408         https://bugs.webkit.org/show_bug.cgi?id=166482
409
410         Reviewed by Saam Barati.
411
412         * parser/Parser.cpp:
413         (JSC::Parser<LexerType>::logError):
414         * parser/Parser.h:
415
416 2016-12-25  Yusuke Suzuki  <utatane.tea@gmail.com>
417
418         Propagate the source origin as much as possible
419         https://bugs.webkit.org/show_bug.cgi?id=166348
420
421         Reviewed by Darin Adler.
422
423         This patch introduces CallFrame::callerSourceOrigin, SourceOrigin class
424         and SourceProvider::m_sourceOrigin. CallFrame::callerSourceOrigin returns
425         an appropriate SourceOrigin if possible. If we cannot find the appropriate
426         one, we just return null SourceOrigin.
427
428         This paves the way for implementing the module dynamic-import[1].
429         When the import operator is evaluated, it will resolve the module
430         specifier with this propagated source origin of the caller function.
431
432         To support import operator inside the dynamic code generation
433         functions (like `eval`, `new Function`, indirect call to `eval`),
434         we need to propagate the caller's source origin to the generated
435         source code.
436
437         We do not use sourceURL for that purpose. This is because we
438         would like to keep sourceURL for `eval` / `new Function` null.
439         This sourceURL will be used for the stack dump for errors with line/column
440         numbers. Dumping the caller's sourceURL with line/column numbers are
441         meaningless. So we would like to keep it null while we would like
442         to propagate SourceOrigin for dynamic imports.
443
444         [1]: https://github.com/tc39/proposal-dynamic-import
445
446         * API/JSBase.cpp:
447         (JSEvaluateScript):
448         (JSCheckScriptSyntax):
449         * API/JSObjectRef.cpp:
450         (JSObjectMakeFunction):
451         * API/JSScriptRef.cpp:
452         (OpaqueJSScript::create):
453         (OpaqueJSScript::vm):
454         (OpaqueJSScript::OpaqueJSScript):
455         (parseScript):
456         * JavaScriptCore.xcodeproj/project.pbxproj:
457         * Scripts/builtins/builtins_templates.py:
458         * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
459         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
460         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
461         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
462         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
463         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
464         * builtins/BuiltinExecutables.cpp:
465         (JSC::BuiltinExecutables::BuiltinExecutables):
466         (JSC::BuiltinExecutables::createDefaultConstructor):
467         * debugger/DebuggerCallFrame.cpp:
468         (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
469         * inspector/InjectedScriptManager.cpp:
470         (Inspector::InjectedScriptManager::createInjectedScript):
471         * inspector/JSInjectedScriptHost.cpp:
472         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
473         * inspector/agents/InspectorRuntimeAgent.cpp:
474         (Inspector::InspectorRuntimeAgent::parse):
475         * interpreter/CallFrame.cpp:
476         (JSC::CallFrame::callerSourceOrigin):
477         * interpreter/CallFrame.h:
478         * interpreter/Interpreter.cpp:
479         (JSC::eval):
480         * jsc.cpp:
481         (jscSource):
482         (GlobalObject::finishCreation):
483         (extractDirectoryName):
484         (currentWorkingDirectory):
485         (GlobalObject::moduleLoaderResolve):
486         (functionRunString):
487         (functionLoadString):
488         (functionCallerSourceOrigin):
489         (functionCreateBuiltin):
490         (functionCheckModuleSyntax):
491         (runInteractive):
492         * parser/SourceCode.h:
493         (JSC::makeSource):
494         * parser/SourceProvider.cpp:
495         (JSC::SourceProvider::SourceProvider):
496         * parser/SourceProvider.h:
497         (JSC::SourceProvider::sourceOrigin):
498         (JSC::StringSourceProvider::create):
499         (JSC::StringSourceProvider::StringSourceProvider):
500         (JSC::WebAssemblySourceProvider::create):
501         (JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
502         * runtime/FunctionConstructor.cpp:
503         (JSC::constructFunction):
504         (JSC::constructFunctionSkippingEvalEnabledCheck):
505         * runtime/FunctionConstructor.h:
506         * runtime/JSGlobalObjectFunctions.cpp:
507         (JSC::globalFuncEval):
508         * runtime/ModuleLoaderPrototype.cpp:
509         (JSC::moduleLoaderPrototypeParseModule):
510         * runtime/ScriptExecutable.h:
511         (JSC::ScriptExecutable::sourceOrigin):
512         * runtime/SourceOrigin.h: Added.
513         (JSC::SourceOrigin::SourceOrigin):
514         (JSC::SourceOrigin::string):
515         (JSC::SourceOrigin::isNull):
516         * tools/FunctionOverrides.cpp:
517         (JSC::initializeOverrideInfo):
518
519 2016-12-24  Caio Lima  <ticaiolima@gmail.com>
520
521         [test262] Fixing mapped arguments object property test case
522         https://bugs.webkit.org/show_bug.cgi?id=159398
523
524         Reviewed by Saam Barati.
525
526         This patch changes GenericArguments' override mechanism to
527         implement corret behavior on ECMAScript test262 suite test cases of
528         mapped arguments object with non-configurable and non-writable
529         property. Also it is ensuring that arguments[i]
530         cannot be deleted when argument "i" is {configurable: false}.
531         
532         The previous implementation is against to the specification for 2 reasons:
533
534         1. Every argument in arguments object are {writable: true} by default
535            (http://www.ecma-international.org/ecma-262/7.0/index.html#sec-createunmappedargumentsobject).
536            It means that we have to stop mapping a defined property index
537            if the new property descriptor contains writable (i.e writable is
538            present) and its value is false (also check
539            https://tc39.github.io/ecma262/#sec-arguments-exotic-objects-defineownproperty-p-desc).
540            Previous implementation considers {writable: false} if writable is
541            not present.
542
543         2. When a property is overriden, "delete" operation is always returning true. However
544            delete operations should follow the specification.
545
546         We created an auxilary boolean array named m_modifiedArgumentsDescriptor
547         to store which arguments[i] descriptor was changed from its default
548         property descriptor. This modification was necessary because m_overrides
549         was responsible to keep this information at the same time
550         of keeping information about arguments mapping. The problem of this apporach was
551         that we needed to call overridesArgument(i) as soon as the ith argument's property
552         descriptor was changed and it stops the argument's mapping as sideffect, producing
553         wrong behavior.
554         To keep tracking arguments mapping status, we renamed DirectArguments::m_overrides to
555         DirectArguments::m_mappedArguments and now we it is responsible to manage if an
556         argument[i] is mapped or not.
557         With these 2 structures, now it is possible to an argument[i] have its property 
558         descriptor modified and don't stop the mapping as soon as it happens. One example
559         of that wrong behavior can be found on arguments-bizarre-behaviour-disable-enumerability
560         test case, that now is fixed by this new mechanism.
561
562         * bytecode/PolymorphicAccess.cpp:
563         (JSC::AccessCase::generateWithGuard):
564         * dfg/DFGSpeculativeJIT.cpp:
565         (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
566         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
567         (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
568         * ftl/FTLAbstractHeapRepository.h:
569         * ftl/FTLLowerDFGToB3.cpp:
570         (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
571         (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
572         (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
573         * jit/JITOperations.cpp:
574         (JSC::canAccessArgumentIndexQuickly):
575         * jit/JITPropertyAccess.cpp:
576         (JSC::JIT::emitDirectArgumentsGetByVal):
577         * runtime/DirectArguments.cpp:
578         (JSC::DirectArguments::estimatedSize):
579         (JSC::DirectArguments::visitChildren):
580         (JSC::DirectArguments::overrideThings):
581         (JSC::DirectArguments::overrideThingsIfNecessary):
582         (JSC::DirectArguments::unmapArgument):
583         (JSC::DirectArguments::copyToArguments):
584         (JSC::DirectArguments::overridesSize):
585         (JSC::DirectArguments::overrideArgument): Deleted.
586         * runtime/DirectArguments.h:
587         (JSC::DirectArguments::length):
588         (JSC::DirectArguments::isMappedArgument):
589         (JSC::DirectArguments::isMappedArgumentInDFG):
590         (JSC::DirectArguments::getIndexQuickly):
591         (JSC::DirectArguments::setIndexQuickly):
592         (JSC::DirectArguments::overrodeThings):
593         (JSC::DirectArguments::initModifiedArgumentsDescriptorIfNecessary):
594         (JSC::DirectArguments::setModifiedArgumentDescriptor):
595         (JSC::DirectArguments::isModifiedArgumentDescriptor):
596         (JSC::DirectArguments::offsetOfMappedArguments):
597         (JSC::DirectArguments::offsetOfModifiedArgumentsDescriptor):
598         (JSC::DirectArguments::canAccessIndexQuickly): Deleted.
599         (JSC::DirectArguments::canAccessArgumentIndexQuicklyInDFG): Deleted.
600         (JSC::DirectArguments::offsetOfOverrides): Deleted.
601         * runtime/GenericArguments.h:
602         * runtime/GenericArgumentsInlines.h:
603         (JSC::GenericArguments<Type>::visitChildren):
604         (JSC::GenericArguments<Type>::getOwnPropertySlot):
605         (JSC::GenericArguments<Type>::getOwnPropertySlotByIndex):
606         (JSC::GenericArguments<Type>::getOwnPropertyNames):
607         (JSC::GenericArguments<Type>::put):
608         (JSC::GenericArguments<Type>::putByIndex):
609         (JSC::GenericArguments<Type>::deleteProperty):
610         (JSC::GenericArguments<Type>::deletePropertyByIndex):
611         (JSC::GenericArguments<Type>::defineOwnProperty):
612         (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
613         (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptorIfNecessary):
614         (JSC::GenericArguments<Type>::setModifiedArgumentDescriptor):
615         (JSC::GenericArguments<Type>::isModifiedArgumentDescriptor):
616         (JSC::GenericArguments<Type>::copyToArguments):
617         * runtime/ScopedArguments.cpp:
618         (JSC::ScopedArguments::visitChildren):
619         (JSC::ScopedArguments::unmapArgument):
620         (JSC::ScopedArguments::overrideArgument): Deleted.
621         * runtime/ScopedArguments.h:
622         (JSC::ScopedArguments::isMappedArgument):
623         (JSC::ScopedArguments::isMappedArgumentInDFG):
624         (JSC::ScopedArguments::getIndexQuickly):
625         (JSC::ScopedArguments::setIndexQuickly):
626         (JSC::ScopedArguments::initModifiedArgumentsDescriptorIfNecessary):
627         (JSC::ScopedArguments::setModifiedArgumentDescriptor):
628         (JSC::ScopedArguments::isModifiedArgumentDescriptor):
629         (JSC::ScopedArguments::canAccessIndexQuickly): Deleted.
630         (JSC::ScopedArguments::canAccessArgumentIndexQuicklyInDFG): Deleted.
631
632 2016-12-23  Mark Lam  <mark.lam@apple.com>
633
634         Using Option::breakOnThrow() shouldn't crash while printing a null CodeBlock.
635         https://bugs.webkit.org/show_bug.cgi?id=166466
636
637         Reviewed by Keith Miller.
638
639         * runtime/VM.cpp:
640         (JSC::VM::throwException):
641
642 2016-12-23  Mark Lam  <mark.lam@apple.com>
643
644         Enhance LLInt tracing to dump the codeBlock signature instead of just a pointer where appropriate.
645         https://bugs.webkit.org/show_bug.cgi?id=166465
646
647         Reviewed by Keith Miller.
648
649         * llint/LLIntSlowPaths.cpp:
650         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
651         (JSC::LLInt::traceFunctionPrologue):
652
653 2016-12-23  Keith Miller  <keith_miller@apple.com>
654
655         WebAssembly: trap on bad division.
656         https://bugs.webkit.org/show_bug.cgi?id=164786
657
658         Reviewed by Mark Lam.
659
660         This patch adds traps for division / modulo by zero and for
661         division by int_min / -1.
662
663         * wasm/WasmB3IRGenerator.cpp:
664         (JSC::Wasm::B3IRGenerator::emitChecksForModOrDiv):
665         * wasm/WasmExceptionType.h:
666         * wasm/WasmPlan.cpp:
667         (JSC::Wasm::Plan::run):
668         * wasm/wasm.json:
669
670 2016-12-23  Mark Lam  <mark.lam@apple.com>
671
672         Fix broken LLINT_SLOW_PATH_TRACING build.
673         https://bugs.webkit.org/show_bug.cgi?id=166463
674
675         Reviewed by Keith Miller.
676
677         * llint/LLIntExceptions.cpp:
678         (JSC::LLInt::returnToThrow):
679         (JSC::LLInt::callToThrow):
680         * runtime/CommonSlowPathsExceptions.cpp:
681         (JSC::CommonSlowPaths::interpreterThrowInCaller):
682
683 2016-12-22  Keith Miller  <keith_miller@apple.com>
684
685         WebAssembly: Make spec-tests/f32.wast.js and spec-tests/f64.wast.js pass
686         https://bugs.webkit.org/show_bug.cgi?id=166447
687
688         Reviewed by Saam Barati.
689
690         We needed to treat -0.0 < 0.0 for floating point min/max. For min,
691         the algorithm works because if a == b then a and b are not NaNs so
692         either they are the same or they are some zero. When we or a and b
693         either we get the same number back or we get -0.0. Similarly for
694         max we use an and and the sign bit gets dropped if one is 0.0 and
695         the other is -0.0, otherwise, we get the same number back.
696
697         * wasm/wasm.json:
698
699 2016-12-22  Saam Barati  <sbarati@apple.com>
700
701         WebAssembly: Make calling Wasm functions that returns or takes an i64 as a parameter an early exception
702         https://bugs.webkit.org/show_bug.cgi?id=166437
703         <rdar://problem/29793949>
704
705         Reviewed by Keith Miller.
706
707         This patch makes it so that we throw an exception before we do
708         anything else if we call a wasm function that either takes an
709         i64 as an argument or returns an i64.
710
711         * wasm/js/WebAssemblyFunction.cpp:
712         (JSC::callWebAssemblyFunction):
713         (JSC::WebAssemblyFunction::WebAssemblyFunction):
714         (JSC::WebAssemblyFunction::call): Deleted.
715         * wasm/js/WebAssemblyFunction.h:
716         (JSC::WebAssemblyFunction::signatureIndex):
717         (JSC::WebAssemblyFunction::jsEntrypoint):
718
719 2016-12-22  Keith Miller  <keith_miller@apple.com>
720
721         Add BitOr for floating points to B3
722         https://bugs.webkit.org/show_bug.cgi?id=166446
723
724         Reviewed by Saam Barati.
725
726         This patch does some slight refactoring to the ARM assembler,
727         which groups all the vector floating point instructions together.
728
729         * assembler/ARM64Assembler.h:
730         (JSC::ARM64Assembler::vand):
731         (JSC::ARM64Assembler::vorr):
732         (JSC::ARM64Assembler::vectorDataProcessingLogical):
733         (JSC::ARM64Assembler::vectorDataProcessing2Source): Deleted.
734         * assembler/MacroAssemblerARM64.h:
735         (JSC::MacroAssemblerARM64::orDouble):
736         (JSC::MacroAssemblerARM64::orFloat):
737         * assembler/MacroAssemblerX86Common.h:
738         (JSC::MacroAssemblerX86Common::orDouble):
739         (JSC::MacroAssemblerX86Common::orFloat):
740         * assembler/X86Assembler.h:
741         (JSC::X86Assembler::orps_rr):
742         * b3/B3ConstDoubleValue.cpp:
743         (JSC::B3::ConstDoubleValue::bitOrConstant):
744         (JSC::B3::ConstDoubleValue::bitXorConstant):
745         * b3/B3ConstDoubleValue.h:
746         * b3/B3ConstFloatValue.cpp:
747         (JSC::B3::ConstFloatValue::bitOrConstant):
748         (JSC::B3::ConstFloatValue::bitXorConstant):
749         * b3/B3ConstFloatValue.h:
750         * b3/B3LowerToAir.cpp:
751         (JSC::B3::Air::LowerToAir::lower):
752         * b3/B3Validate.cpp:
753         * b3/air/AirInstInlines.h:
754         (JSC::B3::Air::Inst::shouldTryAliasingDef):
755         * b3/air/AirOpcode.opcodes:
756         * b3/testb3.cpp:
757         (JSC::B3::bitOrDouble):
758         (JSC::B3::testBitOrArgDouble):
759         (JSC::B3::testBitOrArgsDouble):
760         (JSC::B3::testBitOrArgImmDouble):
761         (JSC::B3::testBitOrImmsDouble):
762         (JSC::B3::bitOrFloat):
763         (JSC::B3::testBitOrArgFloat):
764         (JSC::B3::testBitOrArgsFloat):
765         (JSC::B3::testBitOrArgImmFloat):
766         (JSC::B3::testBitOrImmsFloat):
767         (JSC::B3::testBitOrArgsFloatWithUselessDoubleConversion):
768         (JSC::B3::run):
769
770 2016-12-22  Mark Lam  <mark.lam@apple.com>
771
772         BytecodeGenerator::m_finallyDepth should be unsigned.
773         https://bugs.webkit.org/show_bug.cgi?id=166438
774
775         Reviewed by Saam Barati.
776
777         Also removed FinallyContext::m_finallyDepth because it is not used.
778
779         * bytecompiler/BytecodeGenerator.cpp:
780         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
781         (JSC::BytecodeGenerator::labelScopeDepth):
782         * bytecompiler/BytecodeGenerator.h:
783         (JSC::FinallyContext::FinallyContext):
784         (JSC::FinallyContext::finallyLabel):
785         (JSC::FinallyContext::depth): Deleted.
786
787 2016-12-22  Mark Lam  <mark.lam@apple.com>
788
789         De-duplicate finally blocks.
790         https://bugs.webkit.org/show_bug.cgi?id=160168
791
792         Reviewed by Saam Barati.
793
794         JS execution can arrive at a finally block when there are abrupt completions from
795         its try or catch block.  The abrupt completion types include Break,
796         Continue, Return, and Throw.  The non-abrupt completion type is called Normal
797         (i.e. the case of a try block falling through to the finally block).
798
799         Previously, we enable each of these paths for abrupt completion (except for Throw)
800         to run the finally block code by duplicating the finally block code at each of
801         the sites that trigger those completions.  This patch fixes the implementation so
802         that each of these abrupt completions will set a completionTypeRegister (plus a
803         completionValueRegister for CompletionType::Return) and then jump to the
804         relevant finally blocks, and continue to thread through subsequent outer finally
805         blocks until execution reaches the outermost finally block that the completion
806         type dictates.  We no longer duplicate the finally block code.
807
808         The implementation details:
809         1. We allocate a pair of registers (completionTypeRegister and completionValueRegister)
810            just before entering the outermost try-catch-finally scope.
811
812            On allocating the registers, we initialize the completionTypeRegister to
813            CompletionType::Normal, and set the completionValueRegister to the empty
814            JSValue.
815
816         2. The completionTypeRegister will hold a CompletionType value.  This is how we
817            encode the CompletionType value to be set:
818
819            a. For Normal, Return, and Throw completion types: 
820               - The completionTypeRegister is set to CompletionType::Normal,
821                 CompletionType::Return, and CompletionType::Throw respectively.
822
823            b. For Break and Continue completion types:
824               - The completionTypeRegister is set to a unique jumpID where the jumpID is
825                 computed as:
826
827                 jumpID = CompletionType::NumberOfTypes + bytecodeOffset
828
829                 The bytecodeOffset used here is the bytecodeOffset of the break or continue
830                 statement that triggered this completion.
831
832         3. Each finally block will have 2 entries:
833            a. the catch entry.
834            b. the normal entry.
835
836            The catch entry is recorded in the codeBlock's exception handler table,
837            and can only be jumped to by the VM's exception handling mechanism.
838
839            The normal entry is recorded in a FinallyContext (at bytecode generation time
840            only) and is jumped to when we want enter the finally block due any of the
841            other CompletionTypes.
842
843         4. How each completion type works?
844
845            CompletionType::Normal
846            ======================
847            We normally encounter this when falling through from a try or catch block to
848            the finally block.  
849           
850            For the try block case, since completionTypeRegister is set to Normal by default,
851            there's nothing more that needs to be done.
852
853            For the catch block case, since we entered the catch block with an exception,
854            completionTypeRegister may be set to Throw.  We'll need to set it to Normal
855            before jumping to the finally block's normal entry.
856
857            CompletionType::Break
858            =====================
859            When we emit bytecode for the BreakNode, we check if we have any FinallyContexts
860            that we need to service before jumping to the breakTarget.  If we don't, then
861            emit op_jump to the breakTarget as usual.  Otherwise:
862
863            a. we'll register a jumpID and the breakTarget with the FinallyContext for the
864               outermost finally block that we're supposed to run through.
865            b. we'll also increment the numberOfBreaksOrContinues count in each FinallyContext
866               from the innermost to the one for that outermost finally block.
867            c. emit bytecode to set the completionTypeRegister to the jumpID.
868            d. emit bytecode to jump to the normal entry of the innermost finally block.
869
870            Each finally block will take care of cascading to the next outer finally block
871            as needed (see (5) below).
872
873            CompletionType::Continue
874            ========================
875            Since continues and breaks work the same way (i.e. with a jump), we handle this
876            exactly the same way as CompletionType::Break, except that we use the
877            continueTarget instead of the breakTarget.
878
879            CompletionType::Return
880            ======================
881            When we emit bytecode for the ReturnNode, we check if we have any FinallyContexts
882            at all on the m_controlFlowScopeStack.  If we don't, then emit op_ret as usual.
883            Otherwise:
884
885            a. emit bytecode to set the completionTypeRegister to CompletionType::Return.
886            b. emit bytecode to move the return value into the completionValueRegister.
887            c. emit bytecode to jump to the normal entry of the innermost finally block.
888
889            Each finally block will take care of cascading to the next outer finally block
890            as needed (see (5) below).
891
892            CompletionType::Throw
893            ======================
894            At the catch entry a finally block, we:
895            1. emit an op_catch that stores the caught Exception object in the
896               completionValueRegister.
897            2. emit bytecode to set the completionTypeRegister to CompletionType::Throw.
898            3. Fall through or jump to the finally block's normal entry.
899
900         5. What happens in each finally block?
901            ==================================
902            For details on the finally block's catch entry, see "CompletionType::Throw" in
903            (4) above.
904
905            The finally block's normal entry will:
906            1. restore the scope of the finally block.
907            2. save the completionTypeRegister in a savedCompletionTypeRegister.
908            3. proceed to execute the body of the finally block.
909
910            At the end of the finally block, we will emit bytecode check the
911            savedCompletionTypeRegister for each completion type see emitFinallyCompletion())
912            in the following order:
913           
914            a. Check for CompletionType::Normal
915               ================================
916               If savedCompletionTypeRegister is CompletionType::Normal, jump to the
917               designated normalCompletion label.  We only need this check this finally
918               block also needs to check for Break, Continue, or Return.  If not, the
919               completion type check for CompletionType::Throw below will make this check
920               redundant.
921
922            b. Check for CompletionType::Break and Continue
923               ============================================
924               If the FinallyContext for this block has registered FinallyJumps, we'll
925               check the jumpIDs against the savedCompletionTypeRegister.  If the jumpID
926               matches, jump to the corresponding jumpTarget.
927
928               If no jumpIDs match but the FinallyContext's numberOfBreaksOrContinues is
929               greater than the number of registered FinallyJumps, then this means that
930               we have a Break or Continue that needs to be handled by an outer finally
931               block.  In that case, jump to the next outer finally block's normal entry.
932              
933            c. Check for CompletionType::Return
934               ================================
935               If this finally block is not the outermost and the savedCompletionTypeRegister
936               is set to CompletionType::Return, then jump to the next outer finally
937               block's normal entry.
938
939               Otherwise, if this finally block is the outermost and the savedCompletionTypeRegister
940               is set to CompletionType::Return, then execute op_ret and return the value
941               in the completionValueRegister.
942
943            d. CompletionType::Throw
944               =====================
945               If savedCompletionTypeRegister is CompletionType::Throw, then just re-throw the
946               Exception object in the completionValueRegister.
947
948            Detail 1: that we check the savedCompletionTypeRegister (and not the
949            completionTypeRegister).  This is because the finally block may itself contain
950            a try-finally, and this inner try-finally may have trashed the completionTypeRegister.
951            Here's an example:
952
953                try {
954                    return "r1"; // Sets completionTypeRegister to CompletionType::Return;
955                } finally {
956                    // completionTypeRegister is CompletionType::Return here.
957
958                    try {
959                        ... // do stuff.
960                    } finally {
961                        ... // do more stuff.
962                    }
963
964                    // completionTypeRegister may be anything here depending on what
965                    // was executed in the inner try-finally block above.
966
967                    // Hence, finally completion here must be based on a saved copy of the
968                    // completionTypeRegister when we entered this finally block.
969                }
970
971            Detail 2: the finally completion for CompletionType::Throw must always explicitly
972            check if the savedCompletionTypeRegister is CompletionType::Throw before throwing.
973            We cannot imply that it is so from the Throw case being last.  Here's why:
974
975                // completionTypeRegister is CompletionType::Normal here.
976                try {
977                    return "r1"; // Sets completionTypeRegister to CompletionType::Return;
978                } finally {
979                    // completionTypeRegister is CompletionType::Return here.
980
981                    try {
982                        ... // do stuff.  No abrupt completions.
983                    } finally {
984                        // completionTypeRegister is CompletionType::Return here (from the outer try-finally).
985                        // savedCompletionTypeRegister is set to completionTypeRegister (i.e. CompletionType::Return) here.
986
987                        ... // do more stuff.  No abrupt completions.
988
989                        // Unless there's an abrupt completion since entering the outer
990                        // finally block, the savedCompletionTypeRegister will remain set
991                        // to CompletionType::Return.  If we don't explicitly check if the
992                        // savedCompletionTypeRegister is CompletionType::Throw before
993                        // throwing here, we'll end up erroneously throwing "r1".
994                    }
995
996                    ...
997                }
998
999         6. restoreScopeRegister()
1000        
1001            Since the needed scope objects are always stored in a local, we can restore
1002            the scope register by simply moving from that local instead of going through
1003            op_get_parent_scope.
1004
1005         7. m_controlFlowScopeStack needs to be a SegmentedVector instead of a Vector.
1006            This makes it easier to keep a pointer to the FinallyContext on that stack,
1007            and not have to worry about the vector being realloc'ed due to resizing. 
1008
1009         Performance appears to be neutral both on ES6SampleBench (run via cli) and the
1010         JSC benchmarks.
1011
1012         Relevant spec references:
1013         https://tc39.github.io/ecma262/#sec-completion-record-specification-type
1014         https://tc39.github.io/ecma262/#sec-try-statement-runtime-semantics-evaluation
1015
1016         * bytecode/HandlerInfo.h:
1017         (JSC::HandlerInfoBase::typeName):
1018         * bytecompiler/BytecodeGenerator.cpp:
1019         (JSC::BytecodeGenerator::generate):
1020         (JSC::BytecodeGenerator::BytecodeGenerator):
1021         (JSC::BytecodeGenerator::emitReturn):
1022         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
1023         (JSC::BytecodeGenerator::popFinallyControlFlowScope):
1024         (JSC::BytecodeGenerator::allocateAndEmitScope):
1025         (JSC::BytecodeGenerator::pushTry):
1026         (JSC::BytecodeGenerator::popTry):
1027         (JSC::BytecodeGenerator::emitCatch):
1028         (JSC::BytecodeGenerator::restoreScopeRegister):
1029         (JSC::BytecodeGenerator::labelScopeDepthToLexicalScopeIndex):
1030         (JSC::BytecodeGenerator::labelScopeDepth):
1031         (JSC::BytecodeGenerator::pushLocalControlFlowScope):
1032         (JSC::BytecodeGenerator::popLocalControlFlowScope):
1033         (JSC::BytecodeGenerator::emitEnumeration):
1034         (JSC::BytecodeGenerator::emitIsNumber):
1035         (JSC::BytecodeGenerator::emitYield):
1036         (JSC::BytecodeGenerator::emitDelegateYield):
1037         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
1038         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
1039         (JSC::BytecodeGenerator::emitFinallyCompletion):
1040         (JSC::BytecodeGenerator::allocateCompletionRecordRegisters):
1041         (JSC::BytecodeGenerator::releaseCompletionRecordRegisters):
1042         (JSC::BytecodeGenerator::emitJumpIf):
1043         (JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope): Deleted.
1044         (JSC::BytecodeGenerator::popIteratorCloseControlFlowScope): Deleted.
1045         (JSC::BytecodeGenerator::emitComplexPopScopes): Deleted.
1046         (JSC::BytecodeGenerator::emitPopScopes): Deleted.
1047         (JSC::BytecodeGenerator::popTryAndEmitCatch): Deleted.
1048         * bytecompiler/BytecodeGenerator.h:
1049         (JSC::bytecodeOffsetToJumpID):
1050         (JSC::FinallyJump::FinallyJump):
1051         (JSC::FinallyContext::FinallyContext):
1052         (JSC::FinallyContext::outerContext):
1053         (JSC::FinallyContext::finallyLabel):
1054         (JSC::FinallyContext::depth):
1055         (JSC::FinallyContext::numberOfBreaksOrContinues):
1056         (JSC::FinallyContext::incNumberOfBreaksOrContinues):
1057         (JSC::FinallyContext::handlesReturns):
1058         (JSC::FinallyContext::setHandlesReturns):
1059         (JSC::FinallyContext::registerJump):
1060         (JSC::FinallyContext::numberOfJumps):
1061         (JSC::FinallyContext::jumps):
1062         (JSC::ControlFlowScope::ControlFlowScope):
1063         (JSC::ControlFlowScope::isLabelScope):
1064         (JSC::ControlFlowScope::isFinallyScope):
1065         (JSC::BytecodeGenerator::currentLexicalScopeIndex):
1066         (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope):
1067         (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope):
1068         (JSC::BytecodeGenerator::completionTypeRegister):
1069         (JSC::BytecodeGenerator::completionValueRegister):
1070         (JSC::BytecodeGenerator::emitSetCompletionType):
1071         (JSC::BytecodeGenerator::emitSetCompletionValue):
1072         (JSC::BytecodeGenerator::isInFinallyBlock): Deleted.
1073         * bytecompiler/NodesCodegen.cpp:
1074         (JSC::ContinueNode::emitBytecode):
1075         (JSC::BreakNode::emitBytecode):
1076         (JSC::ReturnNode::emitBytecode):
1077         (JSC::TryNode::emitBytecode):
1078
1079 2016-12-22  Saam Barati  <sbarati@apple.com>
1080
1081         WebAssembly: Make the spec-tests/address.wast.js test pass
1082         https://bugs.webkit.org/show_bug.cgi?id=166429
1083         <rdar://problem/29793220>
1084
1085         Reviewed by Keith Miller.
1086
1087         Right now, provably out of bound loads/stores (given a load/store's constant
1088         offset) are not a validation error. However, we were failing to catch uint32_t
1089         overflows in release builds (we did have a debug assertion). To fix this,
1090         I now detect when uint32_t addition will overflow, and instead of emitting
1091         a normal load/store, I emit code that throws an out of bounds memory exception.
1092
1093         * wasm/WasmB3IRGenerator.cpp:
1094
1095 2016-12-22  Keith Miller  <keith_miller@apple.com>
1096
1097         WebAssembly: The validator should not allow unused stack entries at the end of a block
1098         https://bugs.webkit.org/show_bug.cgi?id=166411
1099
1100         Reviewed by Saam Barati.
1101
1102         This patch also cleans up some of the verbose mode logging.
1103
1104         * wasm/WasmB3IRGenerator.cpp:
1105         (JSC::Wasm::dumpExpressionStack):
1106         (JSC::Wasm::B3IRGenerator::dump):
1107         * wasm/WasmFunctionParser.h:
1108         * wasm/WasmValidate.cpp:
1109         (JSC::Wasm::dumpExpressionStack):
1110         (JSC::Wasm::Validate::dump):
1111
1112 2016-12-22  Saam Barati  <sbarati@apple.com>
1113
1114         WebAssembly: Make the spec-tests/start.wast.js test pass
1115         https://bugs.webkit.org/show_bug.cgi?id=166416
1116         <rdar://problem/29784532>
1117
1118         Reviewed by Yusuke Suzuki.
1119
1120         To make the test run, I had to fix two bugs:
1121         
1122         1. We weren't properly finding the start function. There was code
1123         that would try to find the start function from the list of *exported*
1124         functions. This is wrong; the start function is an index into the
1125         function index space, which is the space for *imports* and *local*
1126         functions. So the code was just wrong in this respect, and I've
1127         fixed it do the right thing. We weren't sure if this was originally
1128         allowed or not in the spec, but it has been decided that it is allowed
1129         and the spec-tests test for it: https://github.com/WebAssembly/design/issues/896
1130         
1131         2. We were emitting a breakpoint for Unreachable. Instead of crashing,
1132         this opcode needs to throw an exception when executing.
1133
1134         * wasm/WasmB3IRGenerator.cpp:
1135         * wasm/WasmExceptionType.h:
1136         * wasm/js/WebAssemblyModuleRecord.cpp:
1137         (JSC::WebAssemblyModuleRecord::link):
1138         (JSC::WebAssemblyModuleRecord::evaluate):
1139         * wasm/js/WebAssemblyModuleRecord.h:
1140
1141 2016-12-21  Keith Miller  <keith_miller@apple.com>
1142
1143         WebAssembly: Fix decode floating point constants in unreachable code
1144         https://bugs.webkit.org/show_bug.cgi?id=166400
1145
1146         Reviewed by Saam Barati.
1147
1148         We decoded these as variable length but they should be fixed length.
1149
1150         * wasm/WasmFunctionParser.h:
1151
1152 2016-12-21  Keith Miller  <keith_miller@apple.com>
1153
1154         WebAssembly: Allow br, br_if, and br_table to act as a return
1155         https://bugs.webkit.org/show_bug.cgi?id=166393
1156
1157         Reviewed by Saam Barati.
1158
1159         This patch allows br, br_if, and br_table to treat branching to
1160         the size of the control stack to act as a return. This change was
1161         made by adding a new block type to the wasm function parser,
1162         TopLevel. Adding this new block eliminates a lot of the special
1163         case code we had in the parser previously. The only special case
1164         we need is when the end opcode is parsed from the top level.  The
1165         B3 IR generator needs to automatically emit a return at that
1166         point.
1167
1168         Also, this patch adds the function number to validation errors
1169         in the function parser. The current error message is not helpful
1170         otherwise.
1171
1172         * wasm/WasmB3IRGenerator.cpp:
1173         (JSC::Wasm::B3IRGenerator::ControlData::dump):
1174         (JSC::Wasm::B3IRGenerator::addTopLevel):
1175         * wasm/WasmFunctionParser.h:
1176         * wasm/WasmPlan.cpp:
1177         (JSC::Wasm::Plan::parseAndValidateModule):
1178         (JSC::Wasm::Plan::run):
1179         * wasm/WasmValidate.cpp:
1180         (JSC::Wasm::Validate::ControlData::dump):
1181         (JSC::Wasm::Validate::Validate):
1182         (JSC::Wasm::Validate::addTopLevel):
1183         (JSC::Wasm::validateFunction):
1184
1185 2016-12-21  JF Bastien  <jfbastien@apple.com>
1186
1187         WebAssembly JS API: cleanup & pass VM around to {Compile/Runtime}Error
1188         https://bugs.webkit.org/show_bug.cgi?id=166295
1189         <rdar://problem/29762017>
1190
1191         Reviewed by Mark Lam.
1192
1193         Rename the create* functions, and pass VM around, as suggested for
1194         LinkError in #165805.
1195
1196         At the same time, use the default source appender when
1197         constructing these error types, which gives a nice map back to the
1198         original source as part of the error message. This is clearer when
1199         using the current frame, so add that as well.
1200
1201         * jit/ThunkGenerators.cpp:
1202         (JSC::throwExceptionFromWasmThunkGenerator):
1203         * wasm/js/JSWebAssemblyCompileError.cpp:
1204         (JSC::JSWebAssemblyCompileError::create):
1205         (JSC::createJSWebAssemblyCompileError):
1206         (JSC::createWebAssemblyCompileError): Deleted.
1207         * wasm/js/JSWebAssemblyCompileError.h:
1208         (JSC::JSWebAssemblyCompileError::create):
1209         * wasm/js/JSWebAssemblyRuntimeError.cpp:
1210         (JSC::JSWebAssemblyRuntimeError::create):
1211         * wasm/js/JSWebAssemblyRuntimeError.h:
1212         (JSC::JSWebAssemblyRuntimeError::create):
1213         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
1214         (JSC::constructJSWebAssemblyCompileError):
1215         * wasm/js/WebAssemblyModuleConstructor.cpp:
1216         (JSC::WebAssemblyModuleConstructor::createModule):
1217         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
1218         (JSC::constructJSWebAssemblyRuntimeError):
1219
1220 2016-12-21  Yusuke Suzuki  <utatane.tea@gmail.com>
1221
1222         [ES6] Fix modules document in features.json
1223         https://bugs.webkit.org/show_bug.cgi?id=166313
1224
1225         Reviewed by Saam Barati.
1226
1227         * features.json:
1228
1229 2016-12-20  Taras Tsugrii  <ttsugrii@fb.com>
1230
1231         Fix undefined behavior caused by macro expansion producing 'defined'
1232         https://bugs.webkit.org/show_bug.cgi?id=166047
1233
1234         Reviewed by Darin Adler.
1235
1236         * API/JSBase.h:
1237
1238 2016-12-20  Keith Miller  <keith_miller@apple.com>
1239
1240         Add support for global
1241         https://bugs.webkit.org/show_bug.cgi?id=165171
1242
1243         Reviewed by Filip Pizlo.
1244
1245         This patch adds spport for the global property on the global object.
1246         The global property spec is in stage three and is quite simple.
1247         For reference: http://tc39.github.io/proposal-global/
1248
1249         * runtime/JSGlobalObject.cpp:
1250
1251 2016-12-20  Saam Barati  <sbarati@apple.com>
1252
1253         WebAssembly: We should compile wasm functions in parallel
1254         https://bugs.webkit.org/show_bug.cgi?id=165993
1255
1256         Reviewed by Keith Miller.
1257
1258         This patch adds a very simple parallel compiler for Wasm code.
1259         This patch speeds up compiling the Unity headless benchmark by
1260         slightly more than 4x on my MBP. To make this safe, I perform
1261         all linking on the main thread. I also had to change some code
1262         inside Wasmb3IRGenerator to be thread safe.
1263
1264         * b3/air/AirCustom.h:
1265         (JSC::B3::Air::WasmBoundsCheckCustom::generate):
1266         * b3/air/AirGenerationContext.h:
1267         * wasm/WasmB3IRGenerator.cpp:
1268         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1269         (JSC::Wasm::B3IRGenerator::emitExceptionCheck):
1270         (JSC::Wasm::createJSToWasmWrapper):
1271         (JSC::Wasm::parseAndCompile):
1272         * wasm/WasmB3IRGenerator.h:
1273         * wasm/WasmCallingConvention.h:
1274         (JSC::Wasm::CallingConvention::setupFrameInPrologue):
1275         * wasm/WasmPlan.cpp:
1276         (JSC::Wasm::Plan::parseAndValidateModule):
1277         (JSC::Wasm::Plan::run):
1278         * wasm/WasmPlan.h:
1279
1280 2016-12-20  Brent Fulgham  <bfulgham@apple.com>
1281
1282         Address some style problems found by static analysis
1283         https://bugs.webkit.org/show_bug.cgi?id=165975
1284
1285         Reviewed by Alex Christensen.
1286
1287         Correct the const-correctness of functions that are implemented using stricter
1288         const declarations.
1289
1290         * inspector/agents/InspectorDebuggerAgent.h:
1291         * inspector/agents/InspectorHeapAgent.cpp:
1292         * inspector/agents/InspectorHeapAgent.h:
1293         * inspector/agents/InspectorRuntimeAgent.h:
1294         * inspector/agents/InspectorScriptProfilerAgent.cpp:
1295         * inspector/agents/InspectorScriptProfilerAgent.h:
1296         * inspector/scripts/codegen/cpp_generator.py:
1297         (cpp_type_for_unchecked_formal_in_parameter): Update to match const declarations of
1298         implementation files.
1299         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
1300         Rebaselined results for "const Ptr* const" syntax.
1301
1302 2016-12-20  JF Bastien  <jfbastien@apple.com>
1303
1304         WebAssembly: construct 32-bit encodedJSValue properly
1305         https://bugs.webkit.org/show_bug.cgi?id=166199
1306
1307         Reviewed by Mark Lam.
1308
1309         Constructing an encodedJSValue using `{ }` yields the wrong value
1310         on 32-bit platforms. WebAssembly doesn't currently target 32-bit
1311         platforms, but we may as well get it right.
1312
1313         * wasm/JSWebAssembly.cpp:
1314         (JSC::webAssemblyCompileFunc):
1315         (JSC::webAssemblyValidateFunc):
1316         * wasm/js/JSWebAssemblyHelpers.h:
1317         (JSC::toNonWrappingUint32):
1318         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
1319         (JSC::constructJSWebAssemblyCompileError):
1320         * wasm/js/WebAssemblyFunction.cpp:
1321         (JSC::callWebAssemblyFunction):
1322         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1323         (JSC::constructJSWebAssemblyInstance):
1324         * wasm/js/WebAssemblyMemoryConstructor.cpp:
1325         (JSC::constructJSWebAssemblyMemory):
1326         * wasm/js/WebAssemblyModuleConstructor.cpp:
1327         (JSC::constructJSWebAssemblyModule):
1328         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
1329         (JSC::constructJSWebAssemblyRuntimeError):
1330         * wasm/js/WebAssemblyTableConstructor.cpp:
1331         (JSC::constructJSWebAssemblyTable):
1332         * wasm/js/WebAssemblyTablePrototype.cpp:
1333         (JSC::webAssemblyTableProtoFuncLength):
1334         (JSC::webAssemblyTableProtoFuncGrow):
1335         (JSC::webAssemblyTableProtoFuncGet):
1336         (JSC::webAssemblyTableProtoFuncSet):
1337
1338 2016-12-20  Dean Jackson  <dino@apple.com>
1339
1340         Remove INDIE_UI
1341         https://bugs.webkit.org/show_bug.cgi?id=165881
1342         <rdar://problem/29672532>
1343
1344         Reviewed by Simon Fraser.
1345
1346         The Indie UI work has been discontinued.
1347
1348         * Configurations/FeatureDefines.xcconfig:
1349
1350 2016-12-20  JF Bastien  <jfbastien@apple.com>
1351
1352         WebAssembly API: implement WebAssembly.LinkError
1353         https://bugs.webkit.org/show_bug.cgi?id=165805
1354         <rdar://problem/29747874>
1355
1356         Reviewed by Mark Lam.
1357
1358         As described here: https://github.com/WebAssembly/design/pull/901
1359         Some TypeError and RangeError are now converted to WebAssembly.LinkError.
1360
1361         * CMakeLists.txt: add files
1362         * DerivedSources.make: add autoget .lut.h files
1363         * JavaScriptCore.xcodeproj/project.pbxproj: add files
1364         * builtins/BuiltinNames.h: new name LinkError
1365         * runtime/JSGlobalObject.h: auto-register LinkError using existing macro magic
1366         * wasm/JSWebAssembly.h: make the new includes available
1367         * wasm/js/JSWebAssemblyLinkError.cpp: Copied from Source/JavaScriptCore/wasm/JSWebAssemblyCompileError.cpp.
1368         (JSC::JSWebAssemblyLinkError::create):
1369         (JSC::JSWebAssemblyLinkError::JSWebAssemblyLinkError):
1370         (JSC::createWebAssemblyLinkError):
1371         * wasm/js/JSWebAssemblyLinkError.h: Copied from Source/JavaScriptCore/wasm/JSWebAssemblyCompileError.h.
1372         (JSC::JSWebAssemblyLinkError::create):
1373         * wasm/js/WebAssemblyInstanceConstructor.cpp: update as per spec change
1374         (JSC::constructJSWebAssemblyInstance):
1375         * wasm/js/WebAssemblyLinkErrorConstructor.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorConstructor.cpp.
1376         (JSC::constructJSWebAssemblyLinkError):
1377         (JSC::callJSWebAssemblyLinkError):
1378         (JSC::WebAssemblyLinkErrorConstructor::create):
1379         (JSC::WebAssemblyLinkErrorConstructor::createStructure):
1380         (JSC::WebAssemblyLinkErrorConstructor::finishCreation):
1381         (JSC::WebAssemblyLinkErrorConstructor::WebAssemblyLinkErrorConstructor):
1382         (JSC::WebAssemblyLinkErrorConstructor::getConstructData):
1383         (JSC::WebAssemblyLinkErrorConstructor::getCallData):
1384         * wasm/js/WebAssemblyLinkErrorConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorConstructor.h.
1385         * wasm/js/WebAssemblyLinkErrorPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorPrototypr.cpp.
1386         (JSC::WebAssemblyLinkErrorPrototype::create):
1387         (JSC::WebAssemblyLinkErrorPrototype::createStructure):
1388         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
1389         (JSC::WebAssemblyLinkErrorPrototype::WebAssemblyLinkErrorPrototype):
1390         * wasm/js/WebAssemblyLinkErrorPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorPrototypr.h.
1391         * wasm/js/WebAssemblyModuleRecord.cpp: update as per spec change
1392         (JSC::dataSegmentFail):
1393         (JSC::WebAssemblyModuleRecord::evaluate):
1394
1395 2016-12-20  JF Bastien  <jfbastien@apple.com>
1396
1397         WebAssembly: unique function signatures
1398         https://bugs.webkit.org/show_bug.cgi?id=165957
1399         <rdar://problem/29735737>
1400
1401         Reviewed by Saam Barati.
1402
1403         Signatures in a Module's Type section can be duplicated, we
1404         therefore need to unique them so that call_indirect only needs to
1405         do a single integer compare to check that a callee's Signature is
1406         the same as the Signature declared at the call site. Without
1407         uniquing we'd either trap when duplicate Signatures are used, or
1408         we'd need to do multiple comparisons. This patch makes that narrow
1409         usecase function correctly.
1410
1411         There's further complication when calling from wasm to
1412         wasm, in which case the Signatures must also match. Such
1413         cross-instance calls will be improved in bug #165282, but this
1414         patch sets the groundwork for it:
1415
1416         - Signatures are now owned by SignatureInformation which lives on
1417           VM, and is shared by all Modules.
1418         - When parsing a Module, a Signature is created for every Type
1419           entry, and then uniqued by SignatureInformation's adopt
1420           method. Duplicate Signatures are dropped and the previous
1421           SignatureIndex is returned, new Signatures are adopted and a new
1422           SignatureIndex is created.
1423         - The SignatureIndex values are monotonic. 0 is used to represent
1424           invalid indices, which trap. This can only occur through Table.
1425         - SignatureInformation is used while generating code to map a
1426           SignatureIndex back to the Signature* when return / argument
1427           information is needed. This is a simple lookup into a Vector. It
1428           isn't used at runtime.
1429         - These Signatures live forever on VM because the bookkeeping
1430           likely isn't worth it. We may want to empty things out if all
1431           Modules die, this is tracked in bug #166037.
1432         - We can further improve things by bit-packing SignatureIndex with
1433           Code*, which is tracked by bug #165511.
1434
1435         * CMakeLists.txt:
1436         * JavaScriptCore.xcodeproj/project.pbxproj:
1437         * runtime/VM.h: wasm signatures are uniqued here, but aren't accessed frequently (only during parsing) so indirection is fine
1438         * wasm/WasmB3IRGenerator.cpp: use SignatureIndex instead of Signature* when appropriate, and when still using Signature* do so with its new API
1439         (JSC::Wasm::createJSToWasmWrapper):
1440         (JSC::Wasm::parseAndCompile):
1441         * wasm/WasmBinding.cpp:
1442         (JSC::Wasm::importStubGenerator): use SignatureIndex
1443         * wasm/WasmBinding.h:
1444         * wasm/WasmCallingConvention.h:
1445         (JSC::Wasm::CallingConvention::loadArguments):
1446         * wasm/WasmFormat.cpp: drive-by move of alloc/free functions to the implementation file, allows the .h file to drop an FastMalloc.h
1447         (JSC::Wasm::Segment::create):
1448         (JSC::Wasm::Segment::destroy):
1449         (JSC::Wasm::Segment::createPtr):
1450         * wasm/WasmFormat.h: move Signature to its own file
1451         (JSC::Wasm::CallableFunction::CallableFunction):
1452         * wasm/WasmFunctionParser.h:
1453         (JSC::Wasm::FunctionParser<Context>::FunctionParser):
1454         * wasm/WasmModuleParser.cpp:
1455         * wasm/WasmModuleParser.h:
1456         (JSC::Wasm::ModuleParser::ModuleParser):
1457         * wasm/WasmParser.h:
1458         (JSC::Wasm::Parser<SuccessType>::Parser):
1459         * wasm/WasmPlan.cpp:
1460         (JSC::Wasm::Plan::parseAndValidateModule):
1461         (JSC::Wasm::Plan::run):
1462         * wasm/WasmSignature.cpp: Added.
1463         (JSC::Wasm::Signature::dump):
1464         (JSC::Wasm::Signature::hash):
1465         (JSC::Wasm::Signature::create):
1466         (JSC::Wasm::Signature::createInvalid):
1467         (JSC::Wasm::Signature::destroy):
1468         (JSC::Wasm::SignatureInformation::~SignatureInformation):
1469         (JSC::Wasm::SignatureInformation::adopt):
1470         (JSC::Wasm::SignatureInformation::get):
1471         * wasm/WasmSignature.h: Added.
1472         (JSC::Wasm::Signature::Signature):
1473         (JSC::Wasm::Signature::storage):
1474         (JSC::Wasm::Signature::allocatedSize):
1475         (JSC::Wasm::Signature::returnType):
1476         (JSC::Wasm::Signature::returnCount):
1477         (JSC::Wasm::Signature::argumentCount):
1478         (JSC::Wasm::Signature::argument):
1479         (JSC::Wasm::Signature::operator==):
1480         (JSC::Wasm::SignatureHash::empty):
1481         (JSC::Wasm::SignatureHash::deleted):
1482         (JSC::Wasm::SignatureHash::SignatureHash):
1483         (JSC::Wasm::SignatureHash::operator==):
1484         (JSC::Wasm::SignatureHash::equal):
1485         (JSC::Wasm::SignatureHash::hash):
1486         (JSC::Wasm::SignatureHash::isHashTableDeletedValue):
1487         * wasm/WasmValidate.cpp:
1488         (JSC::Wasm::validateFunction):
1489         * wasm/WasmValidate.h:
1490         * wasm/js/JSWebAssemblyInstance.cpp:
1491         (JSC::JSWebAssemblyInstance::create):
1492         * wasm/js/JSWebAssemblyModule.h:
1493         (JSC::JSWebAssemblyModule::signatureForFunctionIndexSpace):
1494         * wasm/js/JSWebAssemblyTable.cpp:
1495         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
1496         (JSC::JSWebAssemblyTable::clearFunction):
1497         (JSC::JSWebAssemblyTable::setFunction):
1498         * wasm/js/WebAssemblyFunction.cpp:
1499         (JSC::callWebAssemblyFunction):
1500         (JSC::WebAssemblyFunction::call):
1501         (JSC::WebAssemblyFunction::create):
1502         (JSC::WebAssemblyFunction::WebAssemblyFunction):
1503         (JSC::WebAssemblyFunction::finishCreation):
1504         * wasm/js/WebAssemblyFunction.h:
1505         (JSC::WebAssemblyFunction::signatureIndex):
1506         * wasm/js/WebAssemblyModuleRecord.cpp:
1507         (JSC::WebAssemblyModuleRecord::link):
1508         (JSC::WebAssemblyModuleRecord::evaluate):
1509
1510 2016-12-20  Konstantin Tokarev  <annulen@yandex.ru>
1511
1512         Modernize for loops in JSC
1513         https://bugs.webkit.org/show_bug.cgi?id=166060
1514
1515         Reviewed by Yusuke Suzuki.
1516
1517         * API/JSCallbackObject.h:
1518         (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
1519         * bytecode/CodeBlock.cpp:
1520         (JSC::CodeBlock::dumpBytecode):
1521         (JSC::CodeBlock::propagateTransitions):
1522         (JSC::CodeBlock::stronglyVisitStrongReferences):
1523         (JSC::CodeBlock::stronglyVisitWeakReferences):
1524         (JSC::CodeBlock::jettison):
1525         (JSC::CodeBlock::getArrayProfile):
1526         (JSC::CodeBlock::tallyFrequentExitSites):
1527         (JSC::CodeBlock::nameForRegister):
1528         * bytecompiler/BytecodeGenerator.cpp:
1529         (JSC::BytecodeGenerator::generate):
1530         (JSC::BytecodeGenerator::BytecodeGenerator):
1531         * bytecompiler/NodesCodegen.cpp:
1532         (JSC::ObjectPatternNode::bindValue):
1533         * debugger/Debugger.cpp:
1534         (JSC::Debugger::applyBreakpoints):
1535         * dfg/DFGCPSRethreadingPhase.cpp:
1536         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
1537         * dfg/DFGClobberSet.cpp:
1538         (JSC::DFG::ClobberSet::setOf):
1539         * dfg/DFGDesiredIdentifiers.cpp:
1540         (JSC::DFG::DesiredIdentifiers::reallyAdd):
1541         * dfg/DFGGraph.cpp:
1542         (JSC::DFG::Graph::visitChildren):
1543         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1544         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
1545         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
1546         * dfg/DFGJITCompiler.cpp:
1547         (JSC::DFG::JITCompiler::link):
1548         * dfg/DFGLICMPhase.cpp:
1549         (JSC::DFG::LICMPhase::run):
1550         * dfg/DFGMaximalFlushInsertionPhase.cpp:
1551         (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
1552         * dfg/DFGPutStackSinkingPhase.cpp:
1553         * dfg/DFGSpeculativeJIT.cpp:
1554         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
1555         (JSC::DFG::SpeculativeJIT::linkBranches):
1556         * dfg/DFGStructureRegistrationPhase.cpp:
1557         (JSC::DFG::StructureRegistrationPhase::run):
1558         * dfg/DFGTypeCheckHoistingPhase.cpp:
1559         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
1560         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
1561         * dfg/DFGValidate.cpp:
1562         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
1563         (JSC::DFG::VirtualRegisterAllocationPhase::run):
1564         * heap/HeapVerifier.cpp:
1565         (JSC::trimDeadObjectsFromList):
1566         (JSC::HeapVerifier::trimDeadObjects):
1567         * heap/LiveObjectList.cpp:
1568         (JSC::LiveObjectList::findObject):
1569         * heap/MarkedAllocator.cpp:
1570         (JSC::MarkedAllocator::isPagedOut):
1571         * inspector/ScriptCallStack.cpp:
1572         (Inspector::ScriptCallStack::firstNonNativeCallFrame):
1573         * jit/JIT.cpp:
1574         (JSC::JIT::link):
1575         * parser/VariableEnvironment.cpp:
1576         (JSC::VariableEnvironment::markAllVariablesAsCaptured):
1577         (JSC::VariableEnvironment::hasCapturedVariables):
1578         * runtime/FunctionHasExecutedCache.cpp:
1579         (JSC::FunctionHasExecutedCache::hasExecutedAtOffset):
1580         (JSC::FunctionHasExecutedCache::getFunctionRanges):
1581         * runtime/JSPropertyNameEnumerator.cpp:
1582         (JSC::JSPropertyNameEnumerator::visitChildren):
1583         * runtime/TypeProfiler.cpp:
1584         (JSC::TypeProfiler::findLocation):
1585         * runtime/TypeSet.cpp:
1586         (JSC::TypeSet::addTypeInformation):
1587         (JSC::TypeSet::dumpTypes):
1588         * runtime/VM.cpp:
1589         (JSC::VM::gatherConservativeRoots):
1590         * runtime/WeakMapData.cpp:
1591         (JSC::WeakMapData::DeadKeyCleaner::visitWeakReferences):
1592         (JSC::WeakMapData::DeadKeyCleaner::finalizeUnconditionally):
1593         * tools/ProfileTreeNode.h:
1594         (JSC::ProfileTreeNode::dumpInternal):
1595         * yarr/YarrInterpreter.cpp:
1596         (JSC::Yarr::ByteCompiler::emitDisjunction):
1597
1598 2016-12-20  Konstantin Tokarev  <annulen@yandex.ru>
1599
1600         __cpuid() requires <intrin.h> to be included
1601         https://bugs.webkit.org/show_bug.cgi?id=166051
1602
1603         Reviewed by Yusuke Suzuki.
1604
1605         * assembler/MacroAssemblerX86Common.h:
1606
1607 2016-12-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1608
1609         [ES6] Enable ES6 Modules
1610         https://bugs.webkit.org/show_bug.cgi?id=165849
1611
1612         Reviewed by Geoffrey Garen.
1613
1614         * features.json:
1615
1616 2016-12-19  Mark Lam  <mark.lam@apple.com>
1617
1618         Rolling out r209974 and r209952. They break some websites in mysterious ways. Step 2: Rollout r209952.
1619         https://bugs.webkit.org/show_bug.cgi?id=166049
1620
1621         Not reviewed.
1622
1623         * bytecode/HandlerInfo.h:
1624         (JSC::HandlerInfoBase::typeName):
1625         * bytecompiler/BytecodeGenerator.cpp:
1626         (JSC::BytecodeGenerator::generate):
1627         (JSC::BytecodeGenerator::BytecodeGenerator):
1628         (JSC::BytecodeGenerator::emitReturn):
1629         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
1630         (JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope):
1631         (JSC::BytecodeGenerator::popFinallyControlFlowScope):
1632         (JSC::BytecodeGenerator::popIteratorCloseControlFlowScope):
1633         (JSC::BytecodeGenerator::emitComplexPopScopes):
1634         (JSC::BytecodeGenerator::emitPopScopes):
1635         (JSC::BytecodeGenerator::pushTry):
1636         (JSC::BytecodeGenerator::popTryAndEmitCatch):
1637         (JSC::BytecodeGenerator::labelScopeDepth):
1638         (JSC::BytecodeGenerator::pushLocalControlFlowScope):
1639         (JSC::BytecodeGenerator::popLocalControlFlowScope):
1640         (JSC::BytecodeGenerator::emitEnumeration):
1641         (JSC::BytecodeGenerator::emitYield):
1642         (JSC::BytecodeGenerator::emitDelegateYield):
1643         (JSC::BytecodeGenerator::popTry): Deleted.
1644         (JSC::BytecodeGenerator::emitCatch): Deleted.
1645         (JSC::BytecodeGenerator::restoreScopeRegister): Deleted.
1646         (JSC::BytecodeGenerator::labelScopeDepthToLexicalScopeIndex): Deleted.
1647         (JSC::BytecodeGenerator::emitIsNumber): Deleted.
1648         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded): Deleted.
1649         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded): Deleted.
1650         (JSC::BytecodeGenerator::emitFinallyCompletion): Deleted.
1651         (JSC::BytecodeGenerator::allocateFinallyRegisters): Deleted.
1652         (JSC::BytecodeGenerator::releaseFinallyRegisters): Deleted.
1653         (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf): Deleted.
1654         * bytecompiler/BytecodeGenerator.h:
1655         (JSC::BytecodeGenerator::isInFinallyBlock):
1656         (JSC::FinallyJump::FinallyJump): Deleted.
1657         (JSC::FinallyContext::FinallyContext): Deleted.
1658         (JSC::FinallyContext::outerContext): Deleted.
1659         (JSC::FinallyContext::finallyLabel): Deleted.
1660         (JSC::FinallyContext::depth): Deleted.
1661         (JSC::FinallyContext::numberOfBreaksOrContinues): Deleted.
1662         (JSC::FinallyContext::incNumberOfBreaksOrContinues): Deleted.
1663         (JSC::FinallyContext::handlesReturns): Deleted.
1664         (JSC::FinallyContext::setHandlesReturns): Deleted.
1665         (JSC::FinallyContext::registerJump): Deleted.
1666         (JSC::FinallyContext::numberOfJumps): Deleted.
1667         (JSC::FinallyContext::jumps): Deleted.
1668         (JSC::ControlFlowScope::ControlFlowScope): Deleted.
1669         (JSC::ControlFlowScope::isLabelScope): Deleted.
1670         (JSC::ControlFlowScope::isFinallyScope): Deleted.
1671         (JSC::BytecodeGenerator::currentLexicalScopeIndex): Deleted.
1672         (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope): Deleted.
1673         (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope): Deleted.
1674         (JSC::BytecodeGenerator::finallyActionRegister): Deleted.
1675         (JSC::BytecodeGenerator::finallyReturnValueRegister): Deleted.
1676         (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion): Deleted.
1677         (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion): Deleted.
1678         (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID): Deleted.
1679         (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister): Deleted.
1680         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion): Deleted.
1681         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump): Deleted.
1682         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion): Deleted.
1683         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion): Deleted.
1684         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion): Deleted.
1685         (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow): Deleted.
1686         (JSC::BytecodeGenerator::bytecodeOffsetToJumpID): Deleted.
1687         * bytecompiler/NodesCodegen.cpp:
1688         (JSC::ContinueNode::emitBytecode):
1689         (JSC::BreakNode::emitBytecode):
1690         (JSC::ReturnNode::emitBytecode):
1691         (JSC::TryNode::emitBytecode):
1692
1693 2016-12-19  Mark Lam  <mark.lam@apple.com>
1694
1695         Rolling out r209974 and r209952. They break some websites in mysterious ways. Step 1: Rollout r209974.
1696         https://bugs.webkit.org/show_bug.cgi?id=166049
1697
1698         Not reviewed.
1699
1700         * bytecompiler/BytecodeGenerator.cpp:
1701         (JSC::BytecodeGenerator::emitEnumeration):
1702         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
1703         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
1704         (JSC::BytecodeGenerator::emitFinallyCompletion):
1705         (JSC::BytecodeGenerator::allocateFinallyRegisters):
1706         (JSC::BytecodeGenerator::releaseFinallyRegisters):
1707         (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf):
1708         (JSC::BytecodeGenerator::allocateCompletionRecordRegisters): Deleted.
1709         (JSC::BytecodeGenerator::releaseCompletionRecordRegisters): Deleted.
1710         (JSC::BytecodeGenerator::emitJumpIfCompletionType): Deleted.
1711         * bytecompiler/BytecodeGenerator.h:
1712         (JSC::FinallyJump::FinallyJump):
1713         (JSC::FinallyContext::registerJump):
1714         (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope):
1715         (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope):
1716         (JSC::BytecodeGenerator::finallyActionRegister):
1717         (JSC::BytecodeGenerator::finallyReturnValueRegister):
1718         (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion):
1719         (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion):
1720         (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID):
1721         (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister):
1722         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion):
1723         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump):
1724         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion):
1725         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion):
1726         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion):
1727         (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow):
1728         (JSC::BytecodeGenerator::bytecodeOffsetToJumpID):
1729         (JSC::bytecodeOffsetToJumpID): Deleted.
1730         (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope): Deleted.
1731         (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope): Deleted.
1732         (JSC::BytecodeGenerator::completionTypeRegister): Deleted.
1733         (JSC::BytecodeGenerator::completionValueRegister): Deleted.
1734         (JSC::BytecodeGenerator::emitSetCompletionType): Deleted.
1735         (JSC::BytecodeGenerator::emitSetCompletionValue): Deleted.
1736         * bytecompiler/NodesCodegen.cpp:
1737         (JSC::TryNode::emitBytecode):
1738
1739 2016-12-19  Joseph Pecoraro  <pecoraro@apple.com>
1740
1741         Web Inspector: Assertion seen in InspectorDebuggerAgent::refAsyncCallData with Inspector open
1742         https://bugs.webkit.org/show_bug.cgi?id=166034
1743         <rdar://problem/29554366>
1744
1745         Reviewed by Brian Burg.
1746
1747         * inspector/agents/InspectorDebuggerAgent.cpp:
1748         (Inspector::InspectorDebuggerAgent::refAsyncCallData):
1749         Remove assertion. This assert can happen if the currently executing callback
1750         was just explicitly cancelled by script. Existing code already handles if
1751         no async data was found for the given identifier.
1752
1753 2016-12-18  Saam Barati  <sbarati@apple.com>
1754
1755         WebAssembly: Implement the WebAssembly.compile and WebAssembly.validate
1756         https://bugs.webkit.org/show_bug.cgi?id=165936
1757
1758         Reviewed by Mark Lam.
1759
1760         The APIs are documented here:
1761         - https://github.com/WebAssembly/design/blob/master/JS.md#webassemblycompile
1762         - https://github.com/WebAssembly/design/blob/master/JS.md#webassemblyvalidate
1763
1764         * wasm/JSWebAssembly.cpp:
1765         (JSC::webAssemblyCompileFunc):
1766         (JSC::webAssemblyValidateFunc):
1767         (JSC::JSWebAssembly::finishCreation):
1768         * wasm/WasmPlan.cpp:
1769         (JSC::Wasm::Plan::parseAndValidateModule):
1770         (JSC::Wasm::Plan::run):
1771         * wasm/WasmPlan.h:
1772         * wasm/js/JSWebAssemblyHelpers.h:
1773         (JSC::getWasmBufferFromValue):
1774         * wasm/js/WebAssemblyModuleConstructor.cpp:
1775         (JSC::constructJSWebAssemblyModule):
1776         (JSC::callJSWebAssemblyModule):
1777         (JSC::WebAssemblyModuleConstructor::createModule):
1778         * wasm/js/WebAssemblyModuleConstructor.h:
1779
1780 2016-12-18  Mark Lam  <mark.lam@apple.com>
1781
1782         Rename finallyActionRegister to completionTypeRegister and only store int JSValues in it.
1783         https://bugs.webkit.org/show_bug.cgi?id=165979
1784
1785         Reviewed by Saam Barati.
1786
1787         This patch makes it so that we only store int JSValues in the finallyActionRegister
1788         thereby making type prediction on this register more successful for JITs.  In so
1789         doing, we are able to get some additional benefits:
1790
1791         1. Renamed the following:
1792            FinallyRegistersScope => CompletionRecordScope
1793            finallyActionRegister => completionTypeRegister
1794            finallyReturnValueRegister => completionValueRegister
1795
1796            These new names are more in line with the ES spec, which describes these
1797            values as the completion record and its type and value properties.
1798            https://tc39.github.io/ecma262/#sec-completion-record-specification-type
1799
1800         2. We now think of the Break and Continue jumpIDs as encodings of CompletionType
1801            (in our implementation of completion type).  As a result, we only need one of
1802            each of the emitter methods for getting, setting, and compare-and-jump on the
1803            completion type.  The code using these methods also reads much clearer now.  
1804
1805         3. Finally blocks' op_catch should now always pop the caught Exception object into
1806            the completionValueRegister instead of the completionTypeRegister (formerly
1807            finallyActionRegister). 
1808
1809         Also removed the restoreScopeRegister() call in the IteratorClose catch block
1810         because that is an implementation specific synthesized catch block, and we
1811         can guarantee that it never needs to resolve any symbols from the scope.  Hence,
1812         there is no need to restore the scope register.
1813
1814         * bytecompiler/BytecodeGenerator.cpp:
1815         (JSC::BytecodeGenerator::emitEnumeration):
1816         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
1817         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
1818         (JSC::BytecodeGenerator::emitFinallyCompletion):
1819         (JSC::BytecodeGenerator::allocateCompletionRecordRegisters):
1820         (JSC::BytecodeGenerator::releaseCompletionRecordRegisters):
1821         (JSC::BytecodeGenerator::emitJumpIfCompletionType):
1822         (JSC::BytecodeGenerator::allocateFinallyRegisters): Deleted.
1823         (JSC::BytecodeGenerator::releaseFinallyRegisters): Deleted.
1824         (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf): Deleted.
1825         * bytecompiler/BytecodeGenerator.h:
1826         (JSC::bytecodeOffsetToJumpID):
1827         (JSC::FinallyJump::FinallyJump):
1828         (JSC::FinallyContext::registerJump):
1829         (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope):
1830         (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope):
1831         (JSC::BytecodeGenerator::completionTypeRegister):
1832         (JSC::BytecodeGenerator::completionValueRegister):
1833         (JSC::BytecodeGenerator::emitSetCompletionType):
1834         (JSC::BytecodeGenerator::emitSetCompletionValue):
1835         (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope): Deleted.
1836         (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope): Deleted.
1837         (JSC::BytecodeGenerator::finallyActionRegister): Deleted.
1838         (JSC::BytecodeGenerator::finallyReturnValueRegister): Deleted.
1839         (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion): Deleted.
1840         (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion): Deleted.
1841         (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID): Deleted.
1842         (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister): Deleted.
1843         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion): Deleted.
1844         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump): Deleted.
1845         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion): Deleted.
1846         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion): Deleted.
1847         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion): Deleted.
1848         (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow): Deleted.
1849         (JSC::BytecodeGenerator::bytecodeOffsetToJumpID): Deleted.
1850         * bytecompiler/NodesCodegen.cpp:
1851         (JSC::TryNode::emitBytecode):
1852
1853 2016-12-17  Saam Barati  <sbarati@apple.com>
1854
1855         WebAssembly: WasmB3IRGenerator uses WarmAny as a ValueRep but expects the incoming value to be a register
1856         https://bugs.webkit.org/show_bug.cgi?id=165989
1857
1858         Reviewed by Mark Lam.
1859
1860         The input should be constrained to a register to match what
1861         the patchpoint code expects.
1862
1863         * wasm/WasmB3IRGenerator.cpp:
1864
1865 2016-12-17  Saam Barati  <sbarati@apple.com>
1866
1867         WebAssembly: Change a RELEASE_ASSERT_NOT_REACHED to a jit.breakpoint() for now to allow us to run some wasm benchmarks
1868         https://bugs.webkit.org/show_bug.cgi?id=165990
1869
1870         Reviewed by Mark Lam.
1871
1872         * wasm/WasmBinding.cpp:
1873         (JSC::Wasm::importStubGenerator):
1874
1875 2016-12-16  Joseph Pecoraro  <pecoraro@apple.com>
1876
1877         JSContext Inspector: Avoid some possible exceptions inspecting a JSContext
1878         https://bugs.webkit.org/show_bug.cgi?id=165986
1879         <rdar://problem/29551379>
1880
1881         Reviewed by Matt Baker.
1882
1883         * inspector/InjectedScriptSource.js:
1884         (InjectedScript.prototype.processProperties):
1885         Prefer String.prototype.endsWith now that it is available.
1886
1887         (InjectedScript.prototype._describe):
1888         Prefer Function.prototype.toString for converting functions to String.
1889         Previously we were doing String(f) which would to Symbol.toPrimitive
1890         conversion which seems unnecessary here.
1891
1892 2016-12-16  Michael Catanzaro  <mcatanzaro@igalia.com>
1893
1894         Unreviewed, fix GCC 6 build failure after r209952
1895
1896         Return false, not nullptr, in function returning bool.
1897
1898         * bytecompiler/BytecodeGenerator.cpp:
1899         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
1900
1901 2016-12-16  Saam Barati  <sbarati@apple.com>
1902
1903         WebAssembly: We still have some incorrect parsing productions inside unreachable code
1904         https://bugs.webkit.org/show_bug.cgi?id=165981
1905
1906         Reviewed by Keith Miller.
1907
1908         This hardens our parsing for CallIndirect and Loop/Block/If to be exactly like their reachable variant.
1909         
1910         It also fixes a more nefarious bug in which we were decoding an extra varuint32
1911         for Br/BrIf inside unreachable code.
1912
1913         * wasm/WasmFunctionParser.h:
1914
1915 2016-12-16  Filip Pizlo  <fpizlo@apple.com>
1916
1917         CellState should have members with accurate names
1918         https://bugs.webkit.org/show_bug.cgi?id=165969
1919
1920         Reviewed by Mark Lam.
1921         
1922         This once again renames the members in CellState. I wanted to convey the following
1923         pieces of information in the names:
1924         
1925         - What does the state mean for Generational GC?
1926         - What does the state mean for Concurrent GC?
1927         - Does the state guarantee what it means, or is there some contingency?
1928         
1929         The names I came up with are:
1930         
1931         PossiblyOldOrBlack: An object in this state may be old, or may be black, depending on
1932             other things. If the mark bit is set then the object is either black or being
1933             blackened as we speak. It's going to survive the GC, so it will be old, but may be
1934             new now. In between GCs, objects in this state are definitely old. If the mark bit
1935             is not set, then the object is actually old and white.
1936         
1937         DefinitelyNewAndWhite: The object was just allocated so it is white (not marked) and
1938             new.
1939         
1940         DefinitelyGrey: The object is definitely grey - it will be rescanned in the future. It
1941             may be new or old depending on other things.
1942
1943         * heap/CellState.h:
1944         * heap/Heap.cpp:
1945         (JSC::Heap::addToRememberedSet):
1946         (JSC::Heap::writeBarrierSlowPath):
1947         * heap/SlotVisitor.cpp:
1948         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
1949         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
1950         (JSC::SlotVisitor::appendToMarkStack):
1951         (JSC::SlotVisitor::visitChildren):
1952         * runtime/JSCellInlines.h:
1953         (JSC::JSCell::JSCell):
1954         * runtime/StructureIDBlob.h:
1955         (JSC::StructureIDBlob::StructureIDBlob):
1956
1957 2016-12-16  Saam Barati  <sbarati@apple.com>
1958
1959         B3::DoubleToFloatReduction will accidentally convince itself it converted a Phi from Double to Float and then convert uses of that Phi into a use of FloatToDouble(@Phi)
1960         https://bugs.webkit.org/show_bug.cgi?id=165946
1961
1962         Reviewed by Keith Miller.
1963
1964         This was happening because the phase will convert some Phi nodes
1965         from Double to Float. However, one place that did this conversion
1966         forgot to first check if the Phi was already a Float. If it's already
1967         a Float, a later part of the phase will be buggy if the phase claims that it has
1968         converted it from Double->Float. The reason is that at the end of the
1969         phase, we'll look for all uses of former Double Phi nodes and make them
1970         be a use of ConvertFloatToDouble on the Phi, instead of a use of the Phi itself.
1971         This is clearly wrong if the Phi were Float to begin with (and
1972         therefore, the uses were Float uses to begin with).
1973
1974         * b3/B3ReduceDoubleToFloat.cpp:
1975         * b3/testb3.cpp:
1976         (JSC::B3::testReduceFloatToDoubleValidates):
1977         (JSC::B3::run):
1978
1979 2016-12-16  Mark Lam  <mark.lam@apple.com>
1980
1981         De-duplicate finally blocks.
1982         https://bugs.webkit.org/show_bug.cgi?id=160168
1983
1984         Reviewed by Keith Miller.
1985
1986         JS execution can arrive at a finally block when there are abrupt completions from
1987         its try or catch block.  The abrupt completion types include Break,
1988         Continue, Return, and Throw.  The non-abrupt completion type is called Normal
1989         (i.e. the case of a try block falling through to the finally block).
1990
1991         Previously, we enable each of these paths for abrupt completion (except for Throw)
1992         to run the finally block code by duplicating the finally block code at each of
1993         the sites that trigger those completions.  This patch fixes the implementation so
1994         that each of these abrupt completions will set a finallyActionRegister (plus a
1995         finallyReturnValueRegister for CompletionType::Return) and then jump to the
1996         relevant finally blocks, and continue to thread through subsequent outer finally
1997         blocks until execution reaches the outermost finally block that the completion
1998         type dictates.  We no longer duplicate the finally block code.
1999
2000         The implementation details:
2001         1. We allocate a pair of finallyActionRegister and finallyReturnValueRegister
2002            just before entering the outermost try-catch-finally scope.
2003
2004            On allocating the registers, we set them to the empty JSValue.  This serves
2005            to set the completion type to CompletionType::Normal (see (2) below).
2006
2007         2. The finallyActionRegister serves 2 purpose:
2008            a. indicates the CompletionType that triggered entry into the finally block.
2009
2010               This is how we encode the completion type in the finallyActionRegister:
2011               1. CompletionType::Normal
2012                  - finallyActionRegister is set to the empty JSValue.
2013               2. CompletionType::Break
2014                  - finallyActionRegister is set to the int jumpID for the site of the break statement.
2015               3. CompletionType::Continue
2016                  - finallyActionRegister is set to the int jumpID for the site of the continue statement.
2017               4. CompletionType::Return
2018                  - finallyActionRegister is set to CompletionType::Return as an int JSValue.
2019                  - finallyReturnValueRegister is set to the value to be returned. 
2020               5. CompletionType::Throw
2021                  - finallyActionRegister is set to the exception object that was caught by the finally block.
2022
2023               Hence, if the finallyActionRegister can either be:
2024               1. empty i.e. we're handling CompletionType::Normal.
2025               2. an int JSValue i.e. we're handling CompletionType::Break, Continue, or Return.
2026               3. an object i.e. we're handling CompletionType::Throw.
2027
2028            b. stores the exception caught in the finally block if we're handing
2029               CompletionType::Throw.
2030
2031         3. Each finally block will have 2 entries:
2032            a. the entry via throw.
2033            b. the normal entry.
2034
2035            The entry via throw is recorded in the codeBlock's exception table, and can
2036            only be jumped to by the VM's exception handling mechanism.
2037
2038            The normal entry is recorded in a FinallyContext (at bytecode generation time
2039            only) and is jumped to when we want enter the finally block due any of the
2040            other CompletionTypes.
2041
2042         4. CompletionType::Normal
2043            ======================
2044            We encounter this when falling through from a try or catch block to the finally block.  
2045            
2046            For the try block case, since finallyActionRegister is set to Normal by default,
2047            there's nothing more that needs to be done.
2048
2049            For the catch block case, since we entered the catch block with an exception,
2050            finallyActionRegister may be set to Throw.  We'll need to set it to Normal
2051            before jumping to the finally block's normal entry.
2052
2053            CompletionType::Break
2054            =====================
2055            When we emit bytecode for the BreakNode, we check if we have any FinallyContexts
2056            that we need to service before jumping to the breakTarget.  If we do, then:
2057            a. we'll register a jumpID along with the breakTarget with the outermost FinallyContext.
2058            b. we'll also increment the numberOfBreaksOrContinues count in each FinallyContext
2059               from the innermost to the outermost.
2060            c. instead of emitting bytecode to jump to the breakTarget, we:
2061               1. emit bytecode to set finallyActionRegister to the jumpID.
2062               b. emit bytecode to jump to the normal entry of the innermost finally block.
2063
2064            Each finally block will take care of cascading to the next outer finally block
2065            as needed (see (5) below).
2066
2067            CompletionType::Continue
2068            ========================
2069            Since continues and breaks work the same way (i.e. with a jump), we handle this
2070            exactly the same way as CompletionType::Break, except that we use the
2071            continueTarget instead of the breakTarget.
2072
2073            CompletionType::Return
2074            ======================
2075            When we emit bytecode for the ReturnNode, we check if we have any FinallyContexts
2076            at all on the m_controlFlowScopeStack.
2077
2078            If so, then instead of emitting op_ret, we:
2079               1. emit bytecode to set finallyActionRegister to the CompletionType::Return.
2080               1. emit bytecode to move the return value into finallyReturnValueRegister.
2081               2. emit bytecode to jump to the normal entry of the innermost finally block.
2082
2083            Each finally block will take care of cascading to the next outer finally block
2084            as needed (see (5) below).
2085
2086            CompletionType::Throw
2087            ======================
2088            The op_catch of a finally block will always store the caught exception object
2089            in the finallyActionRegister.  This means we're handling CompletionType::Throw
2090            (see (2) above).
2091
2092         5. What happens in each finally block?
2093            ==================================
2094            Only the finally block's entry via throw will have an op_catch that catches the
2095            pending exception (and stores it in the finallyActionRegister).  This throw
2096            entry then falls through to the normal entry.
2097
2098            The finally block's normal entry will restore the scope of the finally block
2099            and proceed to execute its code.
2100
2101            At the end of the finally block (see emitFinallyCompletion()), the finally
2102            block will check the finallyActionRegister for each completion type in the
2103            following order:
2104            
2105            a. CompletionType::Normal: jump to the code after the finally block as
2106               designated by a normalCompletion label.
2107
2108            b. CompletionType::Break and Continue:
2109               If the FinallyContext for this block has registered FinallyJumps, we'll
2110               check for the jumpIDs against the finallyActionRegister.  If the jumpID
2111               matches, jump to the corresponding jumpTarget.
2112
2113               If no jumpIDs match but the FinallyContext's numberOfBreaksOrContinues is
2114               greater than the number of registered FinallyJumps, then this means that
2115               we have a Break or Continue that needs to be handled by an outer finally
2116               block.  In that case, jump to the outer finally block's normal entry.
2117               
2118            c. CompletionType::Return:
2119               If this finally block is not the outermost and finallyActionRegister contains
2120               CompletionType::Return, then jump to the outer finally block's normal entry.
2121
2122               Otherwise, if this finally block is the outermost and finallyActionRegister
2123               contains CompletionType::Return, then execute op_ret and return the value
2124               in finallyReturnValueRegister.
2125
2126            d. CompletionType::Throw:
2127               If we're not handling any of the above cases, then just throw the
2128               finallyActionRegister which contains the exception to re-throw.
2129
2130         6. restoreScopeRegister()
2131         
2132            Since the needed scope objects are always stored in a local, we can restore
2133            the scope register by simply moving from that local instead of going through
2134            op_get_parent_scope.
2135
2136         7. m_controlFlowScopeStack needs to be a SegmentedVector instead of a Vector.
2137            This makes it easier to keep a pointer to the FinallyContext on that stack,
2138            and not have to worry about the vector being realloc'ed due to resizing. 
2139
2140         Performance appears to be neutral both on ES6SampleBench (run via cli) and the
2141         JSC benchmarks.
2142
2143         Relevant spec references:
2144         https://tc39.github.io/ecma262/#sec-completion-record-specification-type
2145         https://tc39.github.io/ecma262/#sec-try-statement-runtime-semantics-evaluation
2146
2147         * bytecode/HandlerInfo.h:
2148         (JSC::HandlerInfoBase::typeName):
2149         * bytecompiler/BytecodeGenerator.cpp:
2150         (JSC::BytecodeGenerator::generate):
2151         (JSC::BytecodeGenerator::BytecodeGenerator):
2152         (JSC::BytecodeGenerator::emitReturn):
2153         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
2154         (JSC::BytecodeGenerator::popFinallyControlFlowScope):
2155         (JSC::BytecodeGenerator::allocateAndEmitScope):
2156         (JSC::BytecodeGenerator::pushTry):
2157         (JSC::BytecodeGenerator::popTry):
2158         (JSC::BytecodeGenerator::emitCatch):
2159         (JSC::BytecodeGenerator::restoreScopeRegister):
2160         (JSC::BytecodeGenerator::labelScopeDepthToLexicalScopeIndex):
2161         (JSC::BytecodeGenerator::labelScopeDepth):
2162         (JSC::BytecodeGenerator::pushLocalControlFlowScope):
2163         (JSC::BytecodeGenerator::popLocalControlFlowScope):
2164         (JSC::BytecodeGenerator::emitEnumeration):
2165         (JSC::BytecodeGenerator::emitIsNumber):
2166         (JSC::BytecodeGenerator::emitYield):
2167         (JSC::BytecodeGenerator::emitDelegateYield):
2168         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
2169         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
2170         (JSC::BytecodeGenerator::emitFinallyCompletion):
2171         (JSC::BytecodeGenerator::allocateFinallyRegisters):
2172         (JSC::BytecodeGenerator::releaseFinallyRegisters):
2173         (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf):
2174         (JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope): Deleted.
2175         (JSC::BytecodeGenerator::popIteratorCloseControlFlowScope): Deleted.
2176         (JSC::BytecodeGenerator::emitComplexPopScopes): Deleted.
2177         (JSC::BytecodeGenerator::emitPopScopes): Deleted.
2178         (JSC::BytecodeGenerator::popTryAndEmitCatch): Deleted.
2179         * bytecompiler/BytecodeGenerator.h:
2180         (JSC::FinallyJump::FinallyJump):
2181         (JSC::FinallyContext::FinallyContext):
2182         (JSC::FinallyContext::outerContext):
2183         (JSC::FinallyContext::finallyLabel):
2184         (JSC::FinallyContext::depth):
2185         (JSC::FinallyContext::numberOfBreaksOrContinues):
2186         (JSC::FinallyContext::incNumberOfBreaksOrContinues):
2187         (JSC::FinallyContext::handlesReturns):
2188         (JSC::FinallyContext::setHandlesReturns):
2189         (JSC::FinallyContext::registerJump):
2190         (JSC::FinallyContext::numberOfJumps):
2191         (JSC::FinallyContext::jumps):
2192         (JSC::ControlFlowScope::ControlFlowScope):
2193         (JSC::ControlFlowScope::isLabelScope):
2194         (JSC::ControlFlowScope::isFinallyScope):
2195         (JSC::BytecodeGenerator::currentLexicalScopeIndex):
2196         (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope):
2197         (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope):
2198         (JSC::BytecodeGenerator::finallyActionRegister):
2199         (JSC::BytecodeGenerator::finallyReturnValueRegister):
2200         (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion):
2201         (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion):
2202         (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID):
2203         (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister):
2204         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion):
2205         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump):
2206         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion):
2207         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion):
2208         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion):
2209         (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow):
2210         (JSC::BytecodeGenerator::bytecodeOffsetToJumpID):
2211         (JSC::BytecodeGenerator::isInFinallyBlock): Deleted.
2212         * bytecompiler/NodesCodegen.cpp:
2213         (JSC::ContinueNode::emitBytecode):
2214         (JSC::BreakNode::emitBytecode):
2215         (JSC::ReturnNode::emitBytecode):
2216         (JSC::TryNode::emitBytecode):
2217
2218 2016-12-16  Keith Miller  <keith_miller@apple.com>
2219
2220         Add missing cases to parseUnreachableExpression and cleanup FunctionParser
2221         https://bugs.webkit.org/show_bug.cgi?id=165966
2222
2223         Reviewed by Saam Barati.
2224
2225         This patch adds a number of missing cases to the Wasm FunctionParser's unreachable
2226         code decoder. It also, removes unneeded OpType namespaces where they were not
2227         needed and has the unary / binary macros cover all the cases rather than
2228         just the simple cases.
2229
2230         * wasm/WasmFunctionParser.h:
2231
2232 2016-12-16  Mark Lam  <mark.lam@apple.com>
2233
2234         Add predecessor info to dumps from JSC_dumpBytecodeLivenessResults=true.
2235         https://bugs.webkit.org/show_bug.cgi?id=165958
2236
2237         Reviewed by Saam Barati.
2238
2239         Also:
2240         1. refactored the code to use a common lambda function to dump FastBitVectors.
2241         2. list successors by their block index instead of pointers.
2242
2243         * bytecode/BytecodeLivenessAnalysis.cpp:
2244         (JSC::BytecodeLivenessAnalysis::dumpResults):
2245
2246 2016-12-16  Saam Barati  <sbarati@apple.com>
2247
2248         WebAssembly: WasmB3IRGenerator should throw exceptions instead of crash
2249         https://bugs.webkit.org/show_bug.cgi?id=165834
2250
2251         Reviewed by Keith Miller.
2252
2253         This patch generalizes how we throw exceptions in the Wasm::B3IRGenerator.
2254         There are still places where we need to throw exceptions and we don't, but
2255         this patch removes most of those places inside the IR generator. There are
2256         still a few places we need to throw exceptions inside the IR generator, like
2257         div/mod by 0. Those will be done in a separate patch. Also, there are
2258         still some stubs we need to throw exceptions from; those will also be
2259         done in a separate patch.
2260
2261         All exceptions thrown from Wasm share a common stub. The ABI for the stub
2262         is to move the Wasm::ExceptionType into argGPR1 and jump to the stub.
2263         The stub will then throw an exception with an error message tailored
2264         to the particular Wasm::ExceptionType failure.
2265
2266         This patch also refactors B3::Compilation. Before, B3::Compilation(VM, Procedure)
2267         constructor would compile a B3 function. This patch makes B3::Compilation a simple 
2268         tuple that keeps the necessary bits of B3 function alive in order to be runnable.
2269         There is a new function that actually does the compilation for you. It is:
2270         Compilation B3::compile(VM&, Procedure&)
2271         The reason for this change is that I'm now using B3::Compilation(CodeRef, OpaqueByproducts)
2272         constructor in Wasm code. It is weird to have a class both have a
2273         constructor that instantiates the tuple, and another that performs the
2274         compilation and then instantiates the tuple. It's more straight
2275         forward if Compilation's job wasn't to actually do the compilation
2276         but just to hold the necessary bits to keep a compiled B3 alive.
2277
2278         * CMakeLists.txt:
2279         * JavaScriptCore.xcodeproj/project.pbxproj:
2280         * b3/B3Compilation.cpp:
2281         (JSC::B3::Compilation::Compilation):
2282         * b3/B3Compilation.h:
2283         * b3/B3Compile.cpp: Added.
2284         (JSC::B3::compile):
2285         * b3/B3Compile.h: Added.
2286         * b3/testb3.cpp:
2287         (JSC::B3::compile):
2288         * jit/ThunkGenerators.cpp:
2289         (JSC::throwExceptionFromWasmThunkGenerator):
2290         * jit/ThunkGenerators.h:
2291         * wasm/WasmB3IRGenerator.cpp:
2292         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2293         (JSC::Wasm::B3IRGenerator::emitExceptionCheck):
2294         (JSC::Wasm::createJSToWasmWrapper):
2295         (JSC::Wasm::parseAndCompile):
2296         * wasm/WasmExceptionType.h: Added.
2297         (JSC::Wasm::errorMessageForExceptionType):
2298
2299 2016-12-16  Keith Miller  <keith_miller@apple.com>
2300
2301         i64.eqz should use an Int64 zero
2302         https://bugs.webkit.org/show_bug.cgi?id=165942
2303
2304         Reviewed by Mark Lam.
2305
2306         This patch fixes i64.eqz, which was using an Int32 zero
2307         for the comparison previously. This patch also, adds
2308         printing opcodes names in verbose mode.
2309
2310         * wasm/WasmFunctionParser.h:
2311         * wasm/generateWasmOpsHeader.py:
2312         * wasm/wasm.json:
2313
2314 2016-12-15  Darin Adler  <darin@apple.com>
2315
2316         Use asString instead of toWTFString, toString, or getString when we already checked isString
2317         https://bugs.webkit.org/show_bug.cgi?id=165895
2318
2319         Reviewed by Yusuke Suzuki.
2320
2321         Once we have called isString, we should always use asString and value rather than using
2322         functions that have to deal with non-JSString objects. This leads to slightly fewer branches,
2323         slightly less reference count churn, since the string is stored right inside the JSString,
2324         and obviates the need for exception handling.
2325
2326         * bindings/ScriptValue.cpp:
2327         (Inspector::jsToInspectorValue): Use asString/value instead of getString.
2328         * dfg/DFGOperations.cpp:
2329         (JSC::DFG::operationMapHash): Call jsMapHash with its new arguments.
2330         * inspector/JSInjectedScriptHost.cpp:
2331         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension): Use asString/value instead
2332         of toWTFString.
2333         * inspector/JSJavaScriptCallFrame.cpp:
2334         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension): Ditto.
2335         * inspector/agents/InspectorHeapAgent.cpp:
2336         (Inspector::InspectorHeapAgent::getPreview): Use asString/tryGetValue, instead of the
2337         peculiar getString(nullptr) that was here before.
2338         * jsc.cpp:
2339         (functionGetGetterSetter): Use asString/toIdentifier instead of the much less efficient
2340         toWTFString/Identifier::fromString.
2341         (functionIsRope): Use asString instead of jsCast<JSString*>; same thing, but we should
2342         prefer the asString function, since it exists.
2343         (functionFindTypeForExpression): Use asString/value instead of getString.
2344         (functionHasBasicBlockExecuted): Ditto.
2345         (functionBasicBlockExecutionCount): Ditto.
2346         (functionCreateBuiltin): Use asString/value instead of toWTFString and removed
2347         unneeded RETURN_IF_EXCEPTION.
2348         (valueWithTypeOfWasmValue): Use asString instead of jsCast<String*>.
2349         (box): Ditto.
2350         * runtime/DateConstructor.cpp:
2351         (JSC::constructDate): Use asString/values instead of getString.
2352         * runtime/ExceptionHelpers.cpp:
2353         (JSC::errorDescriptionForValue): Tweaked formatting.
2354
2355         * runtime/HashMapImpl.h:
2356         (JSC::jsMapHash): Changed this function to use asString/value.
2357
2358         * runtime/JSCJSValue.cpp:
2359         (JSC::JSValue::dumpInContextAssumingStructure): Use asString instead of
2360         jsCast<JSString*>.
2361         (JSC::JSValue::dumpForBacktrace): Ditto.
2362         * runtime/JSCJSValueInlines.h:
2363         (JSC::toPreferredPrimitiveType): Ditto.
2364
2365         * runtime/JSGlobalObjectFunctions.cpp:
2366         (JSC::globalFuncEval): Use asString/value instead of toWTFString.
2367
2368         * runtime/JSString.cpp:
2369         (JSC::JSString::destroy): Streamlined by removing local variable.
2370         (JSC::JSString::estimatedSize): Use asString instead of jsCast<JSString*>.
2371         (JSC::JSString::visitChildren): Ditto.
2372         (JSC::JSString::toThis): Ditto.
2373         * runtime/JSString.h:
2374         (JSC::JSValue::toString): Ditto.
2375         (JSC::JSValue::toStringOrNull): Ditto.
2376         * runtime/NumberPrototype.cpp:
2377         (JSC::numberProtoFuncValueOf): Ditto.
2378         * runtime/ObjectPrototype.cpp:
2379         (JSC::objectProtoFuncToString): Ditto.
2380         * runtime/StringPrototype.cpp:
2381         (JSC::stringProtoFuncRepeatCharacter): Ditto.
2382         (JSC::stringProtoFuncSubstr): Ditto.
2383         (JSC::builtinStringSubstrInternal): Simplified assertion by removing local variable.
2384
2385 2016-12-15  Keith Miller  <keith_miller@apple.com>
2386
2387         Fix validation of non-void if blocks with no else
2388         https://bugs.webkit.org/show_bug.cgi?id=165938
2389
2390         Reviewed by Saam Barati.
2391
2392         We should not have been allowing non-void if-blocks that don't
2393         have an else. Since this causes a value to be placed on the
2394         stack that only appears under some control flow and not another.
2395
2396         * wasm/WasmValidate.cpp:
2397
2398 2016-12-15  Filip Pizlo  <fpizlo@apple.com>
2399
2400         Get rid of HeapRootVisitor and make SlotVisitor less painful to use
2401         https://bugs.webkit.org/show_bug.cgi?id=165911
2402
2403         Reviewed by Geoffrey Garen.
2404         
2405         Previously we had two ways of adding a raw pointer to the GC's mark stack:
2406         
2407         - SlotVisitor::appendUnbarrieredXYZ() methods
2408         - HeapRootVisitor::visit() methods
2409         
2410         HeapRootVisitor existed only to prevent you from calling its non-WriteBarrier<> methods
2411         unless you had permission. But SlotVisitor would let you do it anyway, because that was
2412         a lot more practical.
2413         
2414         I think that we should just have one way to do it. This removes HeapRootVisitor. It
2415         also renames appendUnbarrieredXYZ to appendUnbarriered, and it removes the use of extra
2416         indirection (so you now pass const WriteBarrier<>& instead of WriteBarrier<>*).
2417
2418         * API/JSCallbackObject.h:
2419         (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
2420         * JavaScriptCore.xcodeproj/project.pbxproj:
2421         * Scripts/builtins/builtins_templates.py:
2422         * bytecode/CodeBlock.cpp:
2423         (JSC::CodeBlock::visitWeakly):
2424         (JSC::CodeBlock::visitChildren):
2425         (JSC::CodeBlock::propagateTransitions):
2426         (JSC::CodeBlock::determineLiveness):
2427         (JSC::CodeBlock::visitOSRExitTargets):
2428         (JSC::CodeBlock::stronglyVisitStrongReferences):
2429         (JSC::CodeBlock::stronglyVisitWeakReferences):
2430         * bytecode/DirectEvalCodeCache.cpp:
2431         (JSC::DirectEvalCodeCache::visitAggregate):
2432         * bytecode/InternalFunctionAllocationProfile.h:
2433         (JSC::InternalFunctionAllocationProfile::visitAggregate):
2434         * bytecode/ObjectAllocationProfile.h:
2435         (JSC::ObjectAllocationProfile::visitAggregate):
2436         * bytecode/PolymorphicAccess.cpp:
2437         (JSC::AccessCase::propagateTransitions):
2438         * bytecode/UnlinkedCodeBlock.cpp:
2439         (JSC::UnlinkedCodeBlock::visitChildren):
2440         * bytecode/UnlinkedFunctionExecutable.cpp:
2441         (JSC::UnlinkedFunctionExecutable::visitChildren):
2442         * debugger/DebuggerScope.cpp:
2443         (JSC::DebuggerScope::visitChildren):
2444         * dfg/DFGDesiredTransitions.cpp:
2445         (JSC::DFG::DesiredTransition::visitChildren):
2446         * dfg/DFGDesiredWeakReferences.cpp:
2447         (JSC::DFG::DesiredWeakReferences::visitChildren):
2448         * dfg/DFGGraph.cpp:
2449         (JSC::DFG::Graph::visitChildren):
2450         * dfg/DFGPlan.cpp:
2451         (JSC::DFG::Plan::markCodeBlocks):
2452         (JSC::DFG::Plan::checkLivenessAndVisitChildren):
2453         * heap/HandleSet.cpp:
2454         (JSC::HandleSet::visitStrongHandles):
2455         * heap/HandleSet.h:
2456         * heap/HandleStack.cpp:
2457         (JSC::HandleStack::visit):
2458         * heap/HandleStack.h:
2459         * heap/Heap.cpp:
2460         (JSC::Heap::markToFixpoint):
2461         * heap/Heap.h:
2462         * heap/HeapRootVisitor.h: Removed.
2463         * heap/LargeAllocation.cpp:
2464         (JSC::LargeAllocation::visitWeakSet):
2465         * heap/LargeAllocation.h:
2466         * heap/MarkedBlock.h:
2467         (JSC::MarkedBlock::Handle::visitWeakSet):
2468         * heap/MarkedSpace.cpp:
2469         (JSC::MarkedSpace::visitWeakSets):
2470         * heap/MarkedSpace.h:
2471         * heap/SlotVisitor.cpp:
2472         (JSC::SlotVisitor::appendUnbarriered):
2473         * heap/SlotVisitor.h:
2474         * heap/SlotVisitorInlines.h:
2475         (JSC::SlotVisitor::appendUnbarriered):
2476         (JSC::SlotVisitor::append):
2477         (JSC::SlotVisitor::appendHidden):
2478         (JSC::SlotVisitor::appendValues):
2479         (JSC::SlotVisitor::appendValuesHidden):
2480         (JSC::SlotVisitor::appendUnbarrieredPointer): Deleted.
2481         (JSC::SlotVisitor::appendUnbarrieredReadOnlyPointer): Deleted.
2482         (JSC::SlotVisitor::appendUnbarrieredValue): Deleted.
2483         (JSC::SlotVisitor::appendUnbarrieredReadOnlyValue): Deleted.
2484         (JSC::SlotVisitor::appendUnbarrieredWeak): Deleted.
2485         * heap/WeakBlock.cpp:
2486         (JSC::WeakBlock::specializedVisit):
2487         (JSC::WeakBlock::visit):
2488         * heap/WeakBlock.h:
2489         * heap/WeakSet.h:
2490         (JSC::WeakSet::visit):
2491         * interpreter/ShadowChicken.cpp:
2492         (JSC::ShadowChicken::visitChildren):
2493         * jit/GCAwareJITStubRoutine.cpp:
2494         (JSC::MarkingGCAwareJITStubRoutine::markRequiredObjectsInternal):
2495         * jit/PolymorphicCallStubRoutine.cpp:
2496         (JSC::PolymorphicCallStubRoutine::markRequiredObjectsInternal):
2497         * jsc.cpp:
2498         (WTF::Element::visitChildren):
2499         (WTF::ImpureGetter::visitChildren):
2500         (WTF::SimpleObject::visitChildren):
2501         * runtime/AbstractModuleRecord.cpp:
2502         (JSC::AbstractModuleRecord::visitChildren):
2503         * runtime/ArgList.cpp:
2504         (JSC::MarkedArgumentBuffer::markLists):
2505         * runtime/ArgList.h:
2506         * runtime/ClonedArguments.cpp:
2507         (JSC::ClonedArguments::visitChildren):
2508         * runtime/DirectArguments.cpp:
2509         (JSC::DirectArguments::visitChildren):
2510         * runtime/EvalExecutable.cpp:
2511         (JSC::EvalExecutable::visitChildren):
2512         * runtime/Exception.cpp:
2513         (JSC::Exception::visitChildren):
2514         * runtime/FunctionExecutable.cpp:
2515         (JSC::FunctionExecutable::visitChildren):
2516         * runtime/FunctionRareData.cpp:
2517         (JSC::FunctionRareData::visitChildren):
2518         * runtime/GetterSetter.cpp:
2519         (JSC::GetterSetter::visitChildren):
2520         * runtime/HashMapImpl.cpp:
2521         (JSC::HashMapBucket<Data>::visitChildren):
2522         (JSC::HashMapImpl<HashMapBucket>::visitChildren):
2523         * runtime/InferredTypeTable.cpp:
2524         (JSC::InferredTypeTable::visitChildren):
2525         * runtime/InternalFunction.cpp:
2526         (JSC::InternalFunction::visitChildren):
2527         * runtime/IntlCollator.cpp:
2528         (JSC::IntlCollator::visitChildren):
2529         * runtime/IntlCollatorConstructor.cpp:
2530         (JSC::IntlCollatorConstructor::visitChildren):
2531         * runtime/IntlDateTimeFormat.cpp:
2532         (JSC::IntlDateTimeFormat::visitChildren):
2533         * runtime/IntlDateTimeFormatConstructor.cpp:
2534         (JSC::IntlDateTimeFormatConstructor::visitChildren):
2535         * runtime/IntlNumberFormat.cpp:
2536         (JSC::IntlNumberFormat::visitChildren):
2537         * runtime/IntlNumberFormatConstructor.cpp:
2538         (JSC::IntlNumberFormatConstructor::visitChildren):
2539         * runtime/JSBoundFunction.cpp:
2540         (JSC::JSBoundFunction::visitChildren):
2541         * runtime/JSCallee.cpp:
2542         (JSC::JSCallee::visitChildren):
2543         * runtime/JSCellInlines.h:
2544         (JSC::JSCell::visitChildren):
2545         * runtime/JSCustomGetterSetterFunction.cpp:
2546         (JSC::JSCustomGetterSetterFunction::visitChildren):
2547         * runtime/JSFunction.cpp:
2548         (JSC::JSFunction::visitChildren):
2549         * runtime/JSGlobalObject.cpp:
2550         (JSC::JSGlobalObject::visitChildren):
2551         * runtime/JSMapIterator.cpp:
2552         (JSC::JSMapIterator::visitChildren):
2553         * runtime/JSModuleEnvironment.cpp:
2554         (JSC::JSModuleEnvironment::visitChildren):
2555         * runtime/JSModuleNamespaceObject.cpp:
2556         (JSC::JSModuleNamespaceObject::visitChildren):
2557         * runtime/JSModuleRecord.cpp:
2558         (JSC::JSModuleRecord::visitChildren):
2559         * runtime/JSNativeStdFunction.cpp:
2560         (JSC::JSNativeStdFunction::visitChildren):
2561         * runtime/JSObject.cpp:
2562         (JSC::JSObject::visitButterflyImpl):
2563         * runtime/JSPromiseDeferred.cpp:
2564         (JSC::JSPromiseDeferred::visitChildren):
2565         * runtime/JSPropertyNameEnumerator.cpp:
2566         (JSC::JSPropertyNameEnumerator::visitChildren):
2567         * runtime/JSPropertyNameIterator.cpp:
2568         (JSC::JSPropertyNameIterator::visitChildren):
2569         * runtime/JSProxy.cpp:
2570         (JSC::JSProxy::visitChildren):
2571         * runtime/JSScope.cpp:
2572         (JSC::JSScope::visitChildren):
2573         * runtime/JSSegmentedVariableObject.cpp:
2574         (JSC::JSSegmentedVariableObject::visitChildren):
2575         * runtime/JSSetIterator.cpp:
2576         (JSC::JSSetIterator::visitChildren):
2577         * runtime/JSString.cpp:
2578         (JSC::JSRopeString::visitFibers):
2579         * runtime/JSSymbolTableObject.cpp:
2580         (JSC::JSSymbolTableObject::visitChildren):
2581         * runtime/JSWeakMap.cpp:
2582         (JSC::JSWeakMap::visitChildren):
2583         * runtime/JSWeakSet.cpp:
2584         (JSC::JSWeakSet::visitChildren):
2585         * runtime/JSWithScope.cpp:
2586         (JSC::JSWithScope::visitChildren):
2587         * runtime/JSWrapperObject.cpp:
2588         (JSC::JSWrapperObject::visitChildren):
2589         * runtime/LazyClassStructure.cpp:
2590         (JSC::LazyClassStructure::visit):
2591         * runtime/LazyPropertyInlines.h:
2592         (JSC::ElementType>::visit):
2593         * runtime/MapBase.cpp:
2594         (JSC::MapBase<HashMapBucketType>::visitChildren):
2595         * runtime/ModuleProgramExecutable.cpp:
2596         (JSC::ModuleProgramExecutable::visitChildren):
2597         * runtime/NativeErrorConstructor.cpp:
2598         (JSC::NativeErrorConstructor::visitChildren):
2599         * runtime/ProgramExecutable.cpp:
2600         (JSC::ProgramExecutable::visitChildren):
2601         * runtime/ProxyObject.cpp:
2602         (JSC::ProxyObject::visitChildren):
2603         * runtime/ProxyRevoke.cpp:
2604         (JSC::ProxyRevoke::visitChildren):
2605         * runtime/RegExpCachedResult.cpp:
2606         (JSC::RegExpCachedResult::visitChildren):
2607         * runtime/RegExpObject.cpp:
2608         (JSC::RegExpObject::visitChildren):
2609         * runtime/RegExpPrototype.cpp:
2610         (JSC::RegExpPrototype::visitChildren):
2611         * runtime/SamplingProfiler.cpp:
2612         (JSC::SamplingProfiler::visit):
2613         * runtime/ScopedArguments.cpp:
2614         (JSC::ScopedArguments::visitChildren):
2615         * runtime/SmallStrings.cpp:
2616         (JSC::SmallStrings::visitStrongReferences):
2617         * runtime/SparseArrayValueMap.cpp:
2618         (JSC::SparseArrayValueMap::visitChildren):
2619         * runtime/Structure.cpp:
2620         (JSC::Structure::visitChildren):
2621         (JSC::Structure::markIfCheap):
2622         * runtime/StructureChain.cpp:
2623         (JSC::StructureChain::visitChildren):
2624         * runtime/StructureRareData.cpp:
2625         (JSC::StructureRareData::visitChildren):
2626         * runtime/SymbolTable.cpp:
2627         (JSC::SymbolTable::visitChildren):
2628         * runtime/TypeProfilerLog.cpp:
2629         (JSC::TypeProfilerLog::visit):
2630         * runtime/WeakMapData.cpp:
2631         (JSC::WeakMapData::DeadKeyCleaner::visitWeakReferences):
2632         * wasm/js/JSWebAssemblyInstance.cpp:
2633         (JSC::JSWebAssemblyInstance::visitChildren):
2634         * wasm/js/JSWebAssemblyMemory.cpp:
2635         (JSC::JSWebAssemblyMemory::visitChildren):
2636         * wasm/js/JSWebAssemblyModule.cpp:
2637         (JSC::JSWebAssemblyModule::visitChildren):
2638         * wasm/js/JSWebAssemblyTable.cpp:
2639         (JSC::JSWebAssemblyTable::visitChildren):
2640         * wasm/js/WebAssemblyFunction.cpp:
2641         (JSC::WebAssemblyFunction::visitChildren):
2642         * wasm/js/WebAssemblyModuleRecord.cpp:
2643         (JSC::WebAssemblyModuleRecord::visitChildren):
2644
2645 2016-12-15  Myles C. Maxfield  <mmaxfield@apple.com>
2646
2647         Sort Xcode project files
2648         https://bugs.webkit.org/show_bug.cgi?id=165937
2649
2650         Reviewed by Simon Fraser.
2651
2652         * JavaScriptCore.xcodeproj/project.pbxproj:
2653
2654 2016-12-15  Keith Miller  <keith_miller@apple.com>
2655
2656         Wasm should not create empty unlinked callsites
2657         https://bugs.webkit.org/show_bug.cgi?id=165933
2658
2659         Reviewed by Mark Lam.
2660
2661         Wasm would create holes in the unlinked callsite vector if B3 was able to
2662         eliminate the callsite.
2663
2664         * wasm/WasmB3IRGenerator.cpp:
2665         (JSC::Wasm::B3IRGenerator::addCall):
2666
2667 2016-12-15  JF Bastien  <jfbastien@apple.com>
2668
2669         WebAssembly: improve compilation error messages
2670         https://bugs.webkit.org/show_bug.cgi?id=163919
2671
2672         Reviewed by Saam Barati.
2673
2674         The error handling messages were underwhelming because most
2675         locations merely returned `false` on failure. This patch uses
2676         std::expected to denote that failure isn't expected. Doing this
2677         makes it almost impossible to mess up the code: either a function
2678         returns a result (or a partial result for internal helpers) or an
2679         error. We're not synchronizing the error string with the m_failed
2680         bool anymore, and the caller will abort if they try to get a
2681         result but the outcome was an error.
2682
2683         This also shortens the code significantly using macros, while also
2684         judiciously preventing inlining of error handling code and biasing
2685         towards success using UNLIKELY. This means that the generated code
2686         should be more efficient (no string formatting on success, and
2687         regalloc can avoid these unlikely paths).
2688
2689         The patch adds a few missing checks as well, especially related to
2690         count limits and memory allocation failure.
2691
2692         As a follow-up I'd like to improve WTF::makeString further, so it
2693         does coercions to string and understands ADL as I did in this
2694         patch.
2695
2696         * wasm/WasmB3IRGenerator.cpp:
2697         (JSC::Wasm::B3IRGenerator::fail):
2698         (JSC::Wasm::parseAndCompile):
2699         * wasm/WasmB3IRGenerator.h:
2700         * wasm/WasmFormat.h:
2701         (JSC::Wasm::isValidExternalKind):
2702         (JSC::Wasm::makeString):
2703         * wasm/WasmFunctionParser.h:
2704         * wasm/WasmModuleParser.cpp:
2705         * wasm/WasmModuleParser.h:
2706         * wasm/WasmParser.h:
2707         (JSC::Wasm::FailureHelper::makeString):
2708         (JSC::Wasm::Parser::fail):
2709         (JSC::Wasm::Parser<SuccessType>::Parser):
2710         (JSC::Wasm::Parser<SuccessType>::consumeCharacter):
2711         (JSC::Wasm::Parser<SuccessType>::consumeString):
2712         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
2713         (JSC::Wasm::Parser<SuccessType>::parseVarUInt32):
2714         (JSC::Wasm::Parser<SuccessType>::parseVarUInt64):
2715         (JSC::Wasm::Parser<SuccessType>::parseVarInt32):
2716         (JSC::Wasm::Parser<SuccessType>::parseVarInt64):
2717         (JSC::Wasm::Parser<SuccessType>::parseUInt32):
2718         (JSC::Wasm::Parser<SuccessType>::parseUInt64):
2719         (JSC::Wasm::Parser<SuccessType>::parseUInt8):
2720         (JSC::Wasm::Parser<SuccessType>::parseInt7):
2721         (JSC::Wasm::Parser<SuccessType>::parseUInt7):
2722         (JSC::Wasm::Parser<SuccessType>::parseVarUInt1):
2723         (JSC::Wasm::Parser<SuccessType>::parseResultType):
2724         (JSC::Wasm::Parser<SuccessType>::parseValueType):
2725         (JSC::Wasm::Parser<SuccessType>::parseExternalKind):
2726         * wasm/WasmPlan.cpp:
2727         (JSC::Wasm::Plan::run):
2728         * wasm/WasmSections.h:
2729         (JSC::Wasm::isValidSection):
2730         (JSC::Wasm::validateOrder):
2731         (JSC::Wasm::makeString):
2732         * wasm/WasmValidate.cpp:
2733         (JSC::Wasm::Validate::fail):
2734         (JSC::Wasm::Validate::addUnreachable):
2735         (JSC::Wasm::validateFunction):
2736         * wasm/WasmValidate.h:
2737         * wasm/generateWasmB3IRGeneratorInlinesHeader.py:
2738         * wasm/generateWasmOpsHeader.py:
2739         * wasm/generateWasmValidateInlinesHeader.py:
2740         (loadMacro):
2741         (storeMacro):
2742         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2743         (JSC::constructJSWebAssemblyInstance):
2744         * wasm/js/WebAssemblyModuleRecord.cpp:
2745         (JSC::WebAssemblyModuleRecord::link):
2746
2747 2016-12-15  JF Bastien  <jfbastien@apple.com>
2748
2749         WebAssembly API: improve data section errors, initialize after Element
2750         https://bugs.webkit.org/show_bug.cgi?id=165733
2751
2752         Reviewed by Keith Miller.
2753
2754         * wasm/WasmModuleParser.cpp:
2755         (JSC::Wasm::ModuleParser::parseData): Data section without Memory section or import is a validation error
2756         * wasm/js/WebAssemblyModuleRecord.cpp:
2757         (JSC::dataSegmentFail):
2758         (JSC::WebAssemblyModuleRecord::evaluate): tighten checks (though the spec isn't fully baked), and move after Element initialization
2759
2760 2016-12-15  Keith Miller  <keith_miller@apple.com>
2761
2762         Turn on WebAssembly by default
2763         https://bugs.webkit.org/show_bug.cgi?id=165918
2764
2765         Reviewed by Saam Barati.
2766
2767         * runtime/Options.h:
2768
2769 2016-12-15  Konstantin Tokarev  <annulen@yandex.ru>
2770
2771         Added missing override and final specifiers
2772         https://bugs.webkit.org/show_bug.cgi?id=165903
2773
2774         Reviewed by Darin Adler.
2775
2776         * bytecompiler/BytecodeGenerator.h:
2777         * jsc.cpp:
2778         * parser/Nodes.h:
2779
2780 2016-12-15  Chris Dumez  <cdumez@apple.com>
2781
2782         Harden JSObject::getOwnPropertyDescriptor()
2783         https://bugs.webkit.org/show_bug.cgi?id=165908
2784
2785         Reviewed by Geoffrey Garen.
2786
2787         * runtime/JSObject.cpp:
2788         (JSC::JSObject::getOwnPropertyDescriptor):
2789
2790 2016-12-15  Keith Miller  <keith_miller@apple.com>
2791
2792         Fix 64-bit shift family Wasm opcodes
2793         https://bugs.webkit.org/show_bug.cgi?id=165902
2794
2795         Reviewed by Geoffrey Garen.
2796
2797         The Int64 versions of the shift family B3 opcodes take an Int32
2798         for the shift value. Wasm, however, takes an i64, so we need to
2799         Trunc the shift value. Also, this fixes a bug where shr_u mapped
2800         to signed shift and shr_s mapped to the unsigned shift.
2801
2802         * wasm/wasm.json:
2803
2804 2016-12-14  Keith Miller  <keith_miller@apple.com>
2805
2806         Wasm should decode constants correctly
2807         https://bugs.webkit.org/show_bug.cgi?id=165886
2808
2809         Reviewed by Saam Barati.
2810
2811         This patch fixes how we decode the constant part of i32, i64, f32,
2812         and f64.const opcodes.
2813
2814         * wasm/WasmFunctionParser.h:
2815         (JSC::Wasm::FunctionParser<Context>::parseExpression):
2816         * wasm/wasm.json:
2817
2818 2016-12-14  Saam Barati  <sbarati@apple.com>
2819
2820         WebAssembly: Add various low hanging fruit that will allow us to run the LLVM torture tests in Wasm
2821         https://bugs.webkit.org/show_bug.cgi?id=165883
2822
2823         Reviewed by Keith Miller.
2824
2825         This patch implements some low hanging fruit:
2826         - Exporting Table
2827         - Exporting Memory
2828         - Load16 with zero extension to both 32 and 64 bit values.
2829         - Fixes Unreachable to emit code that will prevent B3 from having a validation error.
2830
2831         * wasm/WasmB3IRGenerator.cpp:
2832         (JSC::Wasm::B3IRGenerator::addUnreachable):
2833         (JSC::Wasm::sizeOfLoadOp):
2834         (JSC::Wasm::B3IRGenerator::emitLoadOp):
2835         * wasm/WasmFunctionParser.h:
2836         (JSC::Wasm::FunctionParser<Context>::parseExpression):
2837         * wasm/WasmModuleParser.cpp:
2838         (JSC::Wasm::ModuleParser::parseExport):
2839         * wasm/WasmValidate.cpp:
2840         (JSC::Wasm::Validate::addUnreachable):
2841         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2842         (JSC::constructJSWebAssemblyInstance):
2843         * wasm/js/WebAssemblyModuleRecord.cpp:
2844         (JSC::WebAssemblyModuleRecord::finishCreation):
2845         (JSC::WebAssemblyModuleRecord::link):
2846
2847 2016-12-14  Yusuke Suzuki  <utatane.tea@gmail.com>
2848
2849         Update ModuleLoader code by using the latest builtin primitives
2850         https://bugs.webkit.org/show_bug.cgi?id=165851
2851
2852         Reviewed by Sam Weinig.
2853
2854         Update the module loader code,
2855
2856         1. Use @globalPrivate for the utilities, instead of setting them as the member of ModuleLoader.
2857         2. Use @putByValDirect instead of @push. @push is user-observable since it uses Set() operation
2858            and it can be observed by defining indexed setters in Array.prototype.
2859
2860         * builtins/ModuleLoaderPrototype.js:
2861         (ensureRegistered):
2862         (fulfillFetch):
2863         (commitInstantiated):
2864         (requestFetch):
2865         (requestSatisfy):
2866         (setStateToMax): Deleted.
2867         (newRegistryEntry): Deleted.
2868         * runtime/ModuleLoaderPrototype.cpp:
2869
2870 2016-12-14  Michael Saboff  <msaboff@apple.com>
2871
2872         The stress GC bot crashes in JavaScriptCore beneath ShadowChicken::update and Inspector::jsToInspectorValue
2873         https://bugs.webkit.org/show_bug.cgi?id=165871
2874
2875         Reviewed by Mark Lam.
2876
2877         This fixes two issues with the VM watch dog timer firing in a worker.
2878
2879         The first issue has to do with bytecode ordering.  Prior to this change, the first few opcodes
2880         generated when the watch dog is enabled are:
2881                 op_enter
2882                 op_watchdog
2883                 op_get_scope
2884         When the watchdog fires, the function will get an exception at op_watchdog.  In processing that exception,
2885         we'll try to update the ShadowChicken shadow stack.  That update assumes that if there is a scope 
2886         VirtualRegister allocated, then the slot contains a valid JSScope.  With the current bytecode ordering,
2887         this is not true at op_watchdog as op_enter will put JSUndefined in the scope slot.  It isn't until the
2888         op_get_scope gets processed that we'll have a valid scope in the slot.  The fix for this issue is to 
2889         ensure that op_get_scope happens before the op_watchdog.
2890
2891         The second issue is that ScriptFunctionCall::call() will not tell its caller that a terminated
2892         execution exception happened.  Instead call() returns an empty JSValue.  InjectedScript::wrapCallFrames()
2893         wasn't checking for an empty JSValue, but was passing it to another function.  Added a short circuit
2894         return when call returns an empty JSValue.
2895
2896         Added <https://bugs.webkit.org/show_bug.cgi?id=165875> to fix other callers of ScriptFunctionCall::call()
2897         to check for an empty JSValue return value.
2898         Also tracked with <rdar://problem/29671015>.
2899
2900         * bytecompiler/BytecodeGenerator.cpp:
2901         (JSC::BytecodeGenerator::BytecodeGenerator):
2902         (JSC::BytecodeGenerator::emitEnter):
2903         * inspector/InjectedScript.cpp:
2904         (Inspector::InjectedScript::wrapCallFrames):
2905
2906 2016-12-14  Filip Pizlo  <fpizlo@apple.com>
2907
2908         DirectTailCall implementation needs to tell the shuffler what to put into the ArgumentCount explicitly
2909         https://bugs.webkit.org/show_bug.cgi?id=165882
2910
2911         Reviewed by Mark Lam.
2912         
2913         The CallFrameShuffler was assuming that the ArgumentCount that it should store into the
2914         callee frame is simply the size of the args vector.
2915         
2916         That's not true for DirectTailCall, which will pad the args vector with undefined if we
2917         are optimizing an arity mismatch. We need to pass the ArgumentCount explicitly in this
2918         case.
2919
2920         * dfg/DFGSpeculativeJIT32_64.cpp:
2921         (JSC::DFG::SpeculativeJIT::emitCall):
2922         * dfg/DFGSpeculativeJIT64.cpp:
2923         (JSC::DFG::SpeculativeJIT::emitCall):
2924         * ftl/FTLLowerDFGToB3.cpp:
2925         (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
2926         (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
2927         * jit/CallFrameShuffleData.h:
2928         * jit/CallFrameShuffler.cpp:
2929         (JSC::CallFrameShuffler::CallFrameShuffler):
2930         (JSC::CallFrameShuffler::prepareAny):
2931         * jit/CallFrameShuffler.h:
2932         (JSC::CallFrameShuffler::snapshot):
2933         * jit/JITCall.cpp:
2934         (JSC::JIT::compileOpCall):
2935
2936 2016-12-14  Keith Miller  <keith_miller@apple.com>
2937
2938         WebAssembly JS API: implement Global
2939         https://bugs.webkit.org/show_bug.cgi?id=164133
2940
2941         Reviewed by Saam Barati.
2942
2943         This patch adds support for globals. It handles imports, exports
2944         and internal globals. In the MVP only internal globals are allowed
2945         to be mutable. This means we can store a C-array of 64-bit slots
2946         off the instance holding them. When globals are exported to JS
2947         they are done so as numbers. This means that i64 globals cannot be
2948         imported or exported.
2949
2950         * wasm/WasmB3IRGenerator.cpp:
2951         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2952         (JSC::Wasm::B3IRGenerator::getGlobal):
2953         (JSC::Wasm::B3IRGenerator::setGlobal):
2954         (JSC::Wasm::B3IRGenerator::addCallIndirect):
2955         (JSC::Wasm::parseAndCompile):
2956         * wasm/WasmFormat.h:
2957         * wasm/WasmFunctionParser.h:
2958         (JSC::Wasm::FunctionParser<Context>::parseExpression):
2959         * wasm/WasmModuleParser.cpp:
2960         (JSC::Wasm::ModuleParser::parseImport):
2961         (JSC::Wasm::ModuleParser::parseGlobal):
2962         (JSC::Wasm::ModuleParser::parseExport):
2963         (JSC::Wasm::ModuleParser::parseElement):
2964         (JSC::Wasm::ModuleParser::parseInitExpr):
2965         (JSC::Wasm::ModuleParser::parseGlobalType):
2966         (JSC::Wasm::ModuleParser::parseData):
2967         * wasm/WasmModuleParser.h:
2968         * wasm/WasmParser.h:
2969         (JSC::Wasm::Parser::parseVarInt32):
2970         (JSC::Wasm::Parser::parseVarInt64):
2971         (JSC::Wasm::Parser::parseUInt64):
2972         * wasm/WasmValidate.cpp:
2973         (JSC::Wasm::Validate::hasMemory):
2974         (JSC::Wasm::Validate::Validate):
2975         (JSC::Wasm::Validate::getGlobal):
2976         (JSC::Wasm::Validate::setGlobal):
2977         (JSC::Wasm::validateFunction):
2978         * wasm/generateWasmOpsHeader.py:
2979         * wasm/js/JSWebAssemblyInstance.cpp:
2980         (JSC::JSWebAssemblyInstance::create):
2981         (JSC::JSWebAssemblyInstance::finishCreation):
2982         (JSC::JSWebAssemblyInstance::visitChildren):
2983         * wasm/js/JSWebAssemblyInstance.h:
2984         (JSC::JSWebAssemblyInstance::loadI32Global):
2985         (JSC::JSWebAssemblyInstance::loadI64Global):
2986         (JSC::JSWebAssemblyInstance::loadF32Global):
2987         (JSC::JSWebAssemblyInstance::loadF64Global):
2988         (JSC::JSWebAssemblyInstance::setGlobal):
2989         (JSC::JSWebAssemblyInstance::offsetOfGlobals):
2990         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2991         (JSC::constructJSWebAssemblyInstance):
2992         * wasm/js/WebAssemblyModuleRecord.cpp:
2993         (JSC::WebAssemblyModuleRecord::finishCreation):
2994         (JSC::WebAssemblyModuleRecord::link):
2995
2996 2016-12-14  Filip Pizlo  <fpizlo@apple.com>
2997
2998         Unreviewed, re-enable concurrent GC on ARM64 now that the most likely culprit of the memory
2999         regressions is fixed. Lets see what the bots think!
3000
3001         * runtime/Options.cpp:
3002         (JSC::recomputeDependentOptions):
3003
3004 2016-12-14  Filip Pizlo  <fpizlo@apple.com>
3005
3006         Devices with fewer cores should use a more aggressive GC schedule by default
3007         https://bugs.webkit.org/show_bug.cgi?id=165859
3008
3009         Reviewed by Mark Lam.
3010
3011         * heap/Heap.cpp:
3012         (JSC::Heap::markToFixpoint): Log when we have an unexpected delay in wake-up.
3013         * heap/SlotVisitor.cpp:
3014         (JSC::SlotVisitor::drainInParallelPassively): Don't drain passively if there aren't many cores.
3015         * runtime/Options.cpp:
3016         (JSC::overrideDefaults): Change the heuristics if we have fewer cores.
3017         (JSC::Options::initialize):
3018         * runtime/Options.h:
3019
3020 2016-12-14  Mark Lam  <mark.lam@apple.com>
3021
3022         BytecodeBasicBlock::computeImpl() should not keep iterating blocks if all jump targets have already been found.
3023         https://bugs.webkit.org/show_bug.cgi?id=165820
3024
3025         Reviewed by Saam Barati.
3026
3027         Currently, if an opcode is a branch type opcode, BytecodeBasicBlock::computeImpl()
3028         will iterate over all basic blocks looking for the block containing the jump
3029         target, and it will continue to do this even when all the jump targets have been
3030         found.  This is wasted work, and all the more so given that most branch type
3031         opcodes only have a single jump target.
3032
3033         * bytecode/BytecodeBasicBlock.cpp:
3034         (JSC::BytecodeBasicBlock::computeImpl):
3035
3036 2016-12-14  Gavin Barraclough  <barraclough@apple.com>
3037
3038         MarkedBlock::marksConveyLivenessDuringMarking should take into account collection scope
3039         https://bugs.webkit.org/show_bug.cgi?id=165741
3040
3041         Unreviewed, re-landing this with fix (revert erroneous change to Options).
3042
3043         * CMakeLists.txt:
3044         * JavaScriptCore.xcodeproj/project.pbxproj:
3045         * heap/CellContainer.cpp: Added.
3046         (JSC::CellContainer::isNewlyAllocated):
3047         * heap/CellContainer.h:
3048         * heap/MarkedAllocator.cpp:
3049         (JSC::MarkedAllocator::addBlock):
3050         (JSC::MarkedAllocator::removeBlock):
3051         (JSC::MarkedAllocator::dumpBits):
3052         * heap/MarkedAllocator.h:
3053         (JSC::MarkedAllocator::forEachBitVector):
3054         (JSC::MarkedAllocator::forEachBitVectorWithName):
3055         * heap/MarkedBlock.cpp:
3056         (JSC::MarkedBlock::tryCreate):
3057         (JSC::MarkedBlock::Handle::~Handle):
3058         (JSC::MarkedBlock::MarkedBlock):
3059         (JSC::MarkedBlock::Handle::specializedSweep):
3060         (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
3061         (JSC::MarkedBlock::Handle::stopAllocating):
3062         (JSC::MarkedBlock::Handle::resumeAllocating):
3063         (JSC::MarkedBlock::aboutToMarkSlow):
3064         (JSC::MarkedBlock::Handle::didConsumeFreeList):
3065         (JSC::MarkedBlock::Handle::dumpState):
3066         * heap/MarkedBlock.h:
3067         (JSC::MarkedBlock::markingVersion):
3068         (JSC::MarkedBlock::isMarkedRaw):
3069         (JSC::MarkedBlock::isMarked):
3070         * heap/MarkedBlockInlines.h:
3071         (JSC::MarkedBlock::marksConveyLivenessDuringMarking):
3072         * heap/SlotVisitor.cpp:
3073         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
3074         * runtime/StructureIDTable.h:
3075         (JSC::StructureIDTable::size):
3076         (JSC::StructureIDTable::get):
3077
3078 2016-12-14  Chris Dumez  <cdumez@apple.com>
3079
3080         Unreviewed, rolling out r209766.
3081
3082         Regressed Dromaeo JSLib by ~50%
3083
3084         Reverted changeset:
3085
3086         "Make opaque root scanning truly constraint-based"
3087         https://bugs.webkit.org/show_bug.cgi?id=165760
3088         http://trac.webkit.org/changeset/209766
3089
3090 2016-12-14  Commit Queue  <commit-queue@webkit.org>
3091
3092         Unreviewed, rolling out r209795.
3093         https://bugs.webkit.org/show_bug.cgi?id=165853
3094
3095         rolled out the wrong revision (Requested by pizlo on #webkit).
3096
3097         Reverted changeset:
3098
3099         "MarkedBlock::marksConveyLivenessDuringMarking should take
3100         into account collection scope"
3101         https://bugs.webkit.org/show_bug.cgi?id=165741
3102         http://trac.webkit.org/changeset/209795
3103
3104 2016-12-14  Filip Pizlo  <fpizlo@apple.com>
3105
3106         Unreviewed, disable concurrent GC on ARM while we investigate a memory use regression.
3107
3108         * runtime/Options.cpp:
3109         (JSC::recomputeDependentOptions):
3110
3111 2016-12-13  Yusuke Suzuki  <utatane.tea@gmail.com>
3112
3113         Use JSValue::toWTFString instead of calling toString(exec) and value(exec)
3114         https://bugs.webkit.org/show_bug.cgi?id=165795
3115
3116         Reviewed by Saam Barati.
3117
3118         In old days, we frequently use the idiom like, `value.toString(exec)->value(exec)` to
3119         get WTFString from the given JSValue. But now, we have better function, `toWTFString`.
3120         `toWTFString` does not create intermediate JSString objects, then reduce unnecessary
3121         allocations.
3122
3123         This patch mechanically replaces `value.toString(exec)->value(exec)` with `toWTFString(exec)`.
3124
3125         * API/JSValueRef.cpp:
3126         (JSValueToStringCopy):
3127         * bindings/ScriptValue.cpp:
3128         (Deprecated::ScriptValue::toString):
3129         * inspector/JSGlobalObjectInspectorController.cpp:
3130         (Inspector::JSGlobalObjectInspectorController::reportAPIException):
3131         * inspector/JSInjectedScriptHost.cpp:
3132         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
3133         * inspector/JSJavaScriptCallFrame.cpp:
3134         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
3135         * inspector/ScriptCallStackFactory.cpp:
3136         (Inspector::extractSourceInformationFromException):
3137         * runtime/ConsoleObject.cpp:
3138         (JSC::valueToStringWithUndefinedOrNullCheck):
3139         (JSC::valueOrDefaultLabelString):
3140         * runtime/DateConstructor.cpp:
3141         (JSC::dateParse):
3142         * runtime/DatePrototype.cpp:
3143         (JSC::formatLocaleDate):
3144         * runtime/ErrorInstance.cpp:
3145         (JSC::ErrorInstance::sanitizedToString):
3146         * runtime/ErrorPrototype.cpp:
3147         (JSC::errorProtoFuncToString):
3148         * runtime/InspectorInstrumentationObject.cpp:
3149         (JSC::inspectorInstrumentationObjectLog):
3150         * runtime/JSGlobalObjectFunctions.cpp:
3151         (JSC::globalFuncEval):
3152         * runtime/JSModuleLoader.cpp:
3153         (JSC::JSModuleLoader::fetch):
3154         * runtime/ModuleLoaderPrototype.cpp:
3155         (JSC::moduleLoaderPrototypeParseModule):
3156         * runtime/RegExpConstructor.cpp:
3157         (JSC::regExpCreate):
3158         * runtime/RegExpPrototype.cpp:
3159         (JSC::regExpProtoFuncCompile):
3160         (JSC::regExpProtoFuncToString):
3161         * runtime/StringPrototype.cpp:
3162         (JSC::replaceUsingRegExpSearch):
3163         (JSC::replaceUsingStringSearch):
3164         (JSC::stringProtoFuncSlice):
3165         (JSC::stringProtoFuncSplitFast):
3166         (JSC::stringProtoFuncSubstr):
3167         (JSC::stringProtoFuncLocaleCompare):
3168         (JSC::stringProtoFuncBig):
3169         (JSC::stringProtoFuncSmall):
3170         (JSC::stringProtoFuncBlink):
3171         (JSC::stringProtoFuncBold):
3172         (JSC::stringProtoFuncFixed):
3173         (JSC::stringProtoFuncItalics):
3174         (JSC::stringProtoFuncStrike):
3175         (JSC::stringProtoFuncSub):
3176         (JSC::stringProtoFuncSup):
3177         (JSC::stringProtoFuncFontcolor):
3178         (JSC::stringProtoFuncFontsize):
3179         (JSC::stringProtoFuncAnchor):
3180         (JSC::stringProtoFuncLink):
3181         (JSC::trimString):
3182         (JSC::stringProtoFuncStartsWith):
3183         (JSC::stringProtoFuncEndsWith):
3184         (JSC::stringProtoFuncIncludes):
3185         (JSC::builtinStringIncludesInternal):
3186         (JSC::stringProtoFuncNormalize):
3187         * tools/JSDollarVMPrototype.cpp:
3188         (JSC::functionPrint):
3189         * wasm/js/JSWebAssemblyCompileError.h:
3190         (JSC::JSWebAssemblyCompileError::create):
3191         * wasm/js/JSWebAssemblyRuntimeError.h:
3192         (JSC::JSWebAssemblyRuntimeError::create):
3193
3194 2016-12-14  Gavin Barraclough  <barraclough@apple.com>
3195
3196         MarkedBlock::marksConveyLivenessDuringMarking should take into account collection scope
3197         https://bugs.webkit.org/show_bug.cgi?id=165741
3198
3199         Unreviewed rollout due to performance regression.
3200
3201         * CMakeLists.txt:
3202         * JavaScriptCore.xcodeproj/project.pbxproj:
3203         * heap/CellContainer.cpp: Removed.
3204         * heap/CellContainer.h:
3205         * heap/MarkedAllocator.cpp:
3206         (JSC::MarkedAllocator::addBlock):
3207         (JSC::MarkedAllocator::removeBlock):
3208         (JSC::MarkedAllocator::dumpBits):
3209         * heap/MarkedAllocator.h:
3210         (JSC::MarkedAllocator::forEachBitVector):
3211         (JSC::MarkedAllocator::forEachBitVectorWithName):
3212         * heap/MarkedBlock.cpp:
3213         (JSC::MarkedBlock::tryCreate):
3214         (JSC::MarkedBlock::Handle::~Handle):
3215         (JSC::MarkedBlock::MarkedBlock):
3216         (JSC::MarkedBlock::Handle::specializedSweep):
3217         (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
3218         (JSC::MarkedBlock::Handle::stopAllocating):
3219         (JSC::MarkedBlock::Handle::resumeAllocating):
3220         (JSC::MarkedBlock::aboutToMarkSlow):
3221         (JSC::MarkedBlock::Handle::didConsumeFreeList):
3222         (JSC::MarkedBlock::Handle::dumpState): Deleted.
3223         * heap/MarkedBlock.h:
3224         (JSC::MarkedBlock::isMarked):
3225         (JSC::MarkedBlock::markingVersion): Deleted.
3226         (JSC::MarkedBlock::isMarkedRaw): Deleted.
3227         * heap/MarkedBlockInlines.h:
3228         (JSC::MarkedBlock::marksConveyLivenessDuringMarking):
3229         * heap/SlotVisitor.cpp:
3230         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
3231         * runtime/Options.h:
3232         * runtime/StructureIDTable.h:
3233         (JSC::StructureIDTable::get):
3234         (JSC::StructureIDTable::size): Deleted.
3235
3236 2016-12-13  Commit Queue  <commit-queue@webkit.org>
3237
3238         Unreviewed, rolling out r209792.
3239         https://bugs.webkit.org/show_bug.cgi?id=165841
3240
3241         Cause build failures (Requested by yusukesuzuki on #webkit).
3242
3243         Reverted changeset:
3244
3245         "Use JSValue::toWTFString instead of calling toString(exec)
3246         and value(exec)"
3247         https://bugs.webkit.org/show_bug.cgi?id=165795
3248         http://trac.webkit.org/changeset/209792
3249
3250 2016-12-13  Yusuke Suzuki  <utatane.tea@gmail.com>
3251
3252         Use JSValue::toWTFString instead of calling toString(exec) and value(exec)
3253         https://bugs.webkit.org/show_bug.cgi?id=165795
3254
3255         Reviewed by Saam Barati.
3256
3257         In old days, we frequently use the idiom like, `value.toString(exec)->value(exec)` to
3258         get WTFString from the given JSValue. But now, we have better function, `toWTFString`.
3259         `toWTFString` does not create intermediate JSString objects, then reduce unnecessary
3260         allocations.
3261
3262         This patch mechanically replaces `value.toString(exec)->value(exec)` with `toWTFString(exec)`.
3263
3264         * API/JSValueRef.cpp:
3265         (JSValueToStringCopy):
3266         * bindings/ScriptValue.cpp:
3267         (Deprecated::ScriptValue::toString):
3268         * inspector/JSGlobalObjectInspectorController.cpp:
3269         (Inspector::JSGlobalObjectInspectorController::reportAPIException):
3270         * inspector/JSInjectedScriptHost.cpp:
3271         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
3272         * inspector/JSJavaScriptCallFrame.cpp:
3273         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
3274         * inspector/ScriptCallStackFactory.cpp:
3275         (Inspector::extractSourceInformationFromException):
3276         * runtime/ConsoleObject.cpp:
3277         (JSC::valueToStringWithUndefinedOrNullCheck):
3278         (JSC::valueOrDefaultLabelString):
3279         * runtime/DateConstructor.cpp:
3280         (JSC::dateParse):
3281         * runtime/DatePrototype.cpp:
3282         (JSC::formatLocaleDate):
3283         * runtime/ErrorInstance.cpp:
3284         (JSC::ErrorInstance::sanitizedToString):
3285         * runtime/ErrorPrototype.cpp:
3286         (JSC::errorProtoFuncToString):
3287         * runtime/InspectorInstrumentationObject.cpp:
3288         (JSC::inspectorInstrumentationObjectLog):
3289         * runtime/JSCJSValue.cpp:
3290         (JSC::JSValue::toWTFStringSlowCase):
3291         * runtime/JSGlobalObjectFunctions.cpp:
3292         (JSC::globalFuncEval):
3293         * runtime/JSModuleLoader.cpp:
3294         (JSC::JSModuleLoader::fetch):
3295         * runtime/ModuleLoaderPrototype.cpp:
3296         (JSC::moduleLoaderPrototypeParseModule):
3297         * runtime/RegExpConstructor.cpp:
3298         (JSC::regExpCreate):
3299         * runtime/RegExpPrototype.cpp:
3300         (JSC::regExpProtoFuncCompile):
3301         (JSC::regExpProtoFuncToString):
3302         * runtime/StringPrototype.cpp:
3303         (JSC::replaceUsingRegExpSearch):
3304         (JSC::replaceUsingStringSearch):
3305         (JSC::stringProtoFuncSlice):
3306         (JSC::stringProtoFuncSplitFast):
3307         (JSC::stringProtoFuncSubstr):
3308         (JSC::stringProtoFuncLocaleCompare):
3309         (JSC::stringProtoFuncBig):