[JSC] disallow references to `await` in AsyncFunction formal parameters
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-10-20  Caitlin Potter  <caitp@igalia.com>
2
3         [JSC] disallow references to `await` in AsyncFunction formal parameters
4         https://bugs.webkit.org/show_bug.cgi?id=163694
5
6         Reviewed by Saam Barati.
7
8         * parser/Parser.cpp:
9         (JSC::Parser<LexerType>::parseAssignmentExpression):
10
11 2016-10-19  Yusuke Suzuki  <utatane.tea@gmail.com>
12
13         [JSC] Move InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero to out of line type info flags
14         https://bugs.webkit.org/show_bug.cgi?id=163716
15
16         Reviewed by Saam Barati.
17
18         We found that all the accesses to the InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero flag is
19         done through the Structure. There is no user that accesses this flag in the cell inlined member. And JIT
20         code does not access it directly. That means that we can move this flag from inlined flags to out of line
21         flags. This patch moves it to the out of line flags. And make one bit empty in inlined flags. Later this
22         new empty flag will be used by megamorphic DOMJIT implementation.
23
24         * runtime/JSTypeInfo.h:
25         (JSC::TypeInfo::hasStaticPropertyTable):
26         (JSC::TypeInfo::interceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero):
27
28 2016-10-20  Keith Miller  <keith_miller@apple.com>
29
30         Invalid assertion in arguments elimination
31         https://bugs.webkit.org/show_bug.cgi?id=163740
32         <rdar://problem/27911462>
33
34         Reviewed by Michael Saboff.
35
36         The DFGFTL's arguments elimination phase incorrectly asserted that a GetFromArguments' first
37         child would always be a CreateDirectArguments.  While we only create the
38         op_get_from_arguments bytecode pointing to a create_direct_arguments, its possible for a
39         number of reasons that a DFG GetFromArguments may not point to a CreateDirectArguments. For
40         example, if we are OSR entering in some function with direct arguments the
41         CreateDirectArguments node might become ExtractOSREntryLocals.
42
43         * dfg/DFGArgumentsEliminationPhase.cpp:
44
45 2016-10-20  Caitlin Potter  <caitp@igalia.com>
46
47         [JSC] throw TypeError when constructing dynamically created JSGeneratorFunction
48         https://bugs.webkit.org/show_bug.cgi?id=163714
49
50         Reviewed by Mark Lam.
51
52         According to CreateDynamicFunction() (https://tc39.github.io/ecma262/#sec-createdynamicfunction),
53         non-normal functions are not constructors. Previously, dynamically created functions would always
54         be constructible, and so it was possible to evaluate `new  (function*() {}.constructor())`,
55         and have it return an Iterator object.
56
57         This change selects a dynamically created function's ConstructAbility based on its parse mode instead.
58
59         * runtime/CodeCache.cpp:
60         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
61
62 2016-10-19  JF Bastien  <jfbastien@apple.com>
63
64         create_hash_table: allow empty tables
65
66         The Windows build was broken by because I added empty tables and Windows insists that empty tables are horrible. Put in dummy entries in that case.
67
68         create_hash_table: allow empty tables
69         https://bugs.webkit.org/show_bug.cgi?id=163701
70
71         Reviewed by Keith Miller.
72
73         * create_hash_table:
74
75 2016-10-19  JF Bastien  <jfbastien@apple.com>
76
77         JavaScript WebAssembly API: baby steps
78
79          - Expand WebAssembly constructors into their own files. This requires a lot of
80            boilerplate, as well as adding the .lut.h files. All of the
81            JSWebAssembly*.{h,cpp}, as well as Constructor and Prototype files, are
82            currently the same between the 4 specified WebAssembly constructors. It'll be
83            easy to implement individual functions on constructed objects as per the
84            spec, and have each of these files diverge. The error constructors are also
85            similar, except that their instance derives from ErrorInstance.
86          - Use constructor macro when initializing the global object.
87          - Dramatically improve testing of the WebAssembly API by checking for
88            properties specified in the spec [*].
89          - Clean up assert.js' exception testing.
90          - Fix a copy-paste bug in wasm.json: floating-point const return values were
91            swapped.
92
93         [*] https://github.com/WebAssembly/design/blob/master/JS.md
94
95         Implement more of the JavaScript WebAssembly API
96         https://bugs.webkit.org/show_bug.cgi?id=163571
97
98         Reviewed by Keith Miller.
99
100         * CMakeLists.txt: add .lut.h generation
101         * DerivedSources.make: ditto
102         * JavaScriptCore.xcodeproj/project.pbxproj: add .lut.h generation and all the new files
103         * runtime/JSGlobalObject.cpp:
104         (JSC::JSGlobalObject::init): use macro to list all constructors
105         * wasm/WebAssemblyObject.cpp: unboilerplate, all constructors into their own files
106         * wasm/WebAssemblyObject.h: ditto
107         * wasm/js/JSWebAssemblyCompileError.cpp: Added.
108         (JSC::JSWebAssemblyCompileError::create):
109         (JSC::JSWebAssemblyCompileError::createStructure):
110         (JSC::JSWebAssemblyCompileError::JSWebAssemblyCompileError):
111         (JSC::JSWebAssemblyCompileError::finishCreation):
112         (JSC::JSWebAssemblyCompileError::destroy):
113         (JSC::JSWebAssemblyCompileError::visitChildren):
114         * wasm/js/JSWebAssemblyCompileError.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
115         * wasm/js/JSWebAssemblyInstance.cpp: Added.
116         (JSC::JSWebAssemblyInstance::create):
117         (JSC::JSWebAssemblyInstance::createStructure):
118         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
119         (JSC::JSWebAssemblyInstance::finishCreation):
120         (JSC::JSWebAssemblyInstance::destroy):
121         (JSC::JSWebAssemblyInstance::visitChildren):
122         * wasm/js/JSWebAssemblyInstance.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
123         * wasm/js/JSWebAssemblyMemory.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
124         (JSC::JSWebAssemblyMemory::create):
125         (JSC::JSWebAssemblyMemory::createStructure):
126         (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
127         (JSC::JSWebAssemblyMemory::finishCreation):
128         (JSC::JSWebAssemblyMemory::destroy):
129         (JSC::JSWebAssemblyMemory::visitChildren):
130         * wasm/js/JSWebAssemblyMemory.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
131         * wasm/js/JSWebAssemblyModule.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
132         (JSC::JSWebAssemblyModule::create):
133         (JSC::JSWebAssemblyModule::createStructure):
134         (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
135         (JSC::JSWebAssemblyModule::finishCreation):
136         (JSC::JSWebAssemblyModule::destroy):
137         (JSC::JSWebAssemblyModule::visitChildren):
138         * wasm/js/JSWebAssemblyModule.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
139         * wasm/js/JSWebAssemblyRuntimeError.cpp: Added.
140         (JSC::JSWebAssemblyRuntimeError::create):
141         (JSC::JSWebAssemblyRuntimeError::createStructure):
142         (JSC::JSWebAssemblyRuntimeError::JSWebAssemblyRuntimeError):
143         (JSC::JSWebAssemblyRuntimeError::finishCreation):
144         (JSC::JSWebAssemblyRuntimeError::destroy):
145         (JSC::JSWebAssemblyRuntimeError::visitChildren):
146         * wasm/js/JSWebAssemblyRuntimeError.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
147         * wasm/js/JSWebAssemblyTable.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
148         (JSC::JSWebAssemblyTable::create):
149         (JSC::JSWebAssemblyTable::createStructure):
150         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
151         (JSC::JSWebAssemblyTable::finishCreation):
152         (JSC::JSWebAssemblyTable::destroy):
153         (JSC::JSWebAssemblyTable::visitChildren):
154         * wasm/js/JSWebAssemblyTable.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
155         * wasm/js/WebAssemblyCompileErrorConstructor.cpp: Added.
156         (JSC::constructJSWebAssemblyCompileError):
157         (JSC::callJSWebAssemblyCompileError):
158         (JSC::WebAssemblyCompileErrorConstructor::create):
159         (JSC::WebAssemblyCompileErrorConstructor::createStructure):
160         (JSC::WebAssemblyCompileErrorConstructor::finishCreation):
161         (JSC::WebAssemblyCompileErrorConstructor::WebAssemblyCompileErrorConstructor):
162         (JSC::WebAssemblyCompileErrorConstructor::getConstructData):
163         (JSC::WebAssemblyCompileErrorConstructor::getCallData):
164         (JSC::WebAssemblyCompileErrorConstructor::visitChildren):
165         * wasm/js/WebAssemblyCompileErrorConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
166         (JSC::WebAssemblyCompileErrorConstructor::CompileErrorStructure):
167         * wasm/js/WebAssemblyCompileErrorPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
168         (JSC::WebAssemblyCompileErrorPrototype::create):
169         (JSC::WebAssemblyCompileErrorPrototype::createStructure):
170         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
171         (JSC::WebAssemblyCompileErrorPrototype::WebAssemblyCompileErrorPrototype):
172         * wasm/js/WebAssemblyCompileErrorPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
173         * wasm/js/WebAssemblyInstanceConstructor.cpp: Added.
174         (JSC::constructJSWebAssemblyInstance):
175         (JSC::callJSWebAssemblyInstance):
176         (JSC::WebAssemblyInstanceConstructor::create):
177         (JSC::WebAssemblyInstanceConstructor::createStructure):
178         (JSC::WebAssemblyInstanceConstructor::finishCreation):
179         (JSC::WebAssemblyInstanceConstructor::WebAssemblyInstanceConstructor):
180         (JSC::WebAssemblyInstanceConstructor::getConstructData):
181         (JSC::WebAssemblyInstanceConstructor::getCallData):
182         (JSC::WebAssemblyInstanceConstructor::visitChildren):
183         * wasm/js/WebAssemblyInstanceConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
184         (JSC::WebAssemblyInstanceConstructor::InstanceStructure):
185         * wasm/js/WebAssemblyInstancePrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
186         (JSC::WebAssemblyInstancePrototype::create):
187         (JSC::WebAssemblyInstancePrototype::createStructure):
188         (JSC::WebAssemblyInstancePrototype::finishCreation):
189         (JSC::WebAssemblyInstancePrototype::WebAssemblyInstancePrototype):
190         * wasm/js/WebAssemblyInstancePrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
191         * wasm/js/WebAssemblyMemoryConstructor.cpp: Added.
192         (JSC::constructJSWebAssemblyMemory):
193         (JSC::callJSWebAssemblyMemory):
194         (JSC::WebAssemblyMemoryConstructor::create):
195         (JSC::WebAssemblyMemoryConstructor::createStructure):
196         (JSC::WebAssemblyMemoryConstructor::finishCreation):
197         (JSC::WebAssemblyMemoryConstructor::WebAssemblyMemoryConstructor):
198         (JSC::WebAssemblyMemoryConstructor::getConstructData):
199         (JSC::WebAssemblyMemoryConstructor::getCallData):
200         (JSC::WebAssemblyMemoryConstructor::visitChildren):
201         * wasm/js/WebAssemblyMemoryConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
202         (JSC::WebAssemblyMemoryConstructor::MemoryStructure):
203         * wasm/js/WebAssemblyMemoryPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
204         (JSC::WebAssemblyMemoryPrototype::create):
205         (JSC::WebAssemblyMemoryPrototype::createStructure):
206         (JSC::WebAssemblyMemoryPrototype::finishCreation):
207         (JSC::WebAssemblyMemoryPrototype::WebAssemblyMemoryPrototype):
208         * wasm/js/WebAssemblyMemoryPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
209         * wasm/js/WebAssemblyModuleConstructor.cpp: Added.
210         (JSC::constructJSWebAssemblyModule):
211         (JSC::callJSWebAssemblyModule):
212         (JSC::WebAssemblyModuleConstructor::create):
213         (JSC::WebAssemblyModuleConstructor::createStructure):
214         (JSC::WebAssemblyModuleConstructor::finishCreation):
215         (JSC::WebAssemblyModuleConstructor::WebAssemblyModuleConstructor):
216         (JSC::WebAssemblyModuleConstructor::getConstructData):
217         (JSC::WebAssemblyModuleConstructor::getCallData):
218         (JSC::WebAssemblyModuleConstructor::visitChildren):
219         * wasm/js/WebAssemblyModuleConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
220         (JSC::WebAssemblyModuleConstructor::ModuleStructure):
221         * wasm/js/WebAssemblyModulePrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
222         (JSC::WebAssemblyModulePrototype::create):
223         (JSC::WebAssemblyModulePrototype::createStructure):
224         (JSC::WebAssemblyModulePrototype::finishCreation):
225         (JSC::WebAssemblyModulePrototype::WebAssemblyModulePrototype):
226         * wasm/js/WebAssemblyModulePrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
227         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp: Added.
228         (JSC::constructJSWebAssemblyRuntimeError):
229         (JSC::callJSWebAssemblyRuntimeError):
230         (JSC::WebAssemblyRuntimeErrorConstructor::create):
231         (JSC::WebAssemblyRuntimeErrorConstructor::createStructure):
232         (JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
233         (JSC::WebAssemblyRuntimeErrorConstructor::WebAssemblyRuntimeErrorConstructor):
234         (JSC::WebAssemblyRuntimeErrorConstructor::getConstructData):
235         (JSC::WebAssemblyRuntimeErrorConstructor::getCallData):
236         (JSC::WebAssemblyRuntimeErrorConstructor::visitChildren):
237         * wasm/js/WebAssemblyRuntimeErrorConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
238         (JSC::WebAssemblyRuntimeErrorConstructor::RuntimeErrorStructure):
239         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
240         (JSC::WebAssemblyRuntimeErrorPrototype::create):
241         (JSC::WebAssemblyRuntimeErrorPrototype::createStructure):
242         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
243         (JSC::WebAssemblyRuntimeErrorPrototype::WebAssemblyRuntimeErrorPrototype):
244         * wasm/js/WebAssemblyRuntimeErrorPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
245         * wasm/js/WebAssemblyTableConstructor.cpp: Added.
246         (JSC::constructJSWebAssemblyTable):
247         (JSC::callJSWebAssemblyTable):
248         (JSC::WebAssemblyTableConstructor::create):
249         (JSC::WebAssemblyTableConstructor::createStructure):
250         (JSC::WebAssemblyTableConstructor::finishCreation):
251         (JSC::WebAssemblyTableConstructor::WebAssemblyTableConstructor):
252         (JSC::WebAssemblyTableConstructor::getConstructData):
253         (JSC::WebAssemblyTableConstructor::getCallData):
254         (JSC::WebAssemblyTableConstructor::visitChildren):
255         * wasm/js/WebAssemblyTableConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
256         (JSC::WebAssemblyTableConstructor::TableStructure):
257         * wasm/js/WebAssemblyTablePrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
258         (JSC::WebAssemblyTablePrototype::create):
259         (JSC::WebAssemblyTablePrototype::createStructure):
260         (JSC::WebAssemblyTablePrototype::finishCreation):
261         (JSC::WebAssemblyTablePrototype::WebAssemblyTablePrototype):
262         * wasm/js/WebAssemblyTablePrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
263
264 2016-10-19  Caitlin Potter  <caitp@igalia.com>
265
266         [JSC] forbid "use strict" directive in generator functions with non-simple parameters
267         https://bugs.webkit.org/show_bug.cgi?id=163683
268
269         Reviewed by Geoffrey Garen.
270
271         Because generator functions and async functions both have an implicit
272         inner function whose arguments are inherited from its parent, "use strict"
273         directives within these functions did not yield a SyntaxError.
274
275         Now, the correct syntax error is reported, fixing several test262 failures
276         for generators and async functions.
277
278         * parser/Parser.cpp:
279         (JSC::Parser<LexerType>::parseFunctionInfo):
280
281 2016-10-19  Ryan Haddad  <ryanhaddad@apple.com>
282
283         Unreviewed, rolling out r207557.
284
285         This change caused animations/font-variations tests to time
286         out on pre-Sierra Macs.
287
288         Reverted changeset:
289
290         "[macOS] [iOS] Disable variation fonts on macOS El Capitan and
291         iOS 9"
292         https://bugs.webkit.org/show_bug.cgi?id=163374
293         http://trac.webkit.org/changeset/207557
294
295 2016-10-19  Filip Pizlo  <fpizlo@apple.com>
296
297         Baseline JIT should use AutomaticThread
298         https://bugs.webkit.org/show_bug.cgi?id=163686
299
300         Reviewed by Geoffrey Garen.
301         
302         Change the JITWorklist to use AutomaticThread, so that the Baseline JIT's concurrent
303         compiler thread shuts down automatically after inactivity.
304         
305         With this change, all of JSC's threads shut down automatically. If you run splay for a few
306         seconds (which fires up all threads - compiler and GC) and then go to sleep for a second,
307         you'll see that the only threads left are the main thread and the bmalloc thread.
308
309         * jit/JITWorklist.cpp:
310         (JSC::JITWorklist::Thread::Thread):
311         (JSC::JITWorklist::JITWorklist):
312         (JSC::JITWorklist::completeAllForVM):
313         (JSC::JITWorklist::poll):
314         (JSC::JITWorklist::compileLater):
315         (JSC::JITWorklist::compileNow):
316         (JSC::JITWorklist::finalizePlans):
317         (JSC::JITWorklist::runThread): Deleted.
318         * jit/JITWorklist.h:
319
320 2016-10-19  Myles C. Maxfield  <mmaxfield@apple.com>
321
322         [macOS] [iOS] Disable variation fonts on macOS El Capitan and iOS 9
323         https://bugs.webkit.org/show_bug.cgi?id=163374
324
325         Reviewed by Darin Adler.
326
327         * Configurations/FeatureDefines.xcconfig:
328
329 2016-10-19  Aaron Chu  <aaron_chu@apple.com>
330
331         Web Inspector: AXI: expose computed tree node and heading level
332         https://bugs.webkit.org/show_bug.cgi?id=130825
333         <rdar://problem/16442349>
334
335         Reviewed by Joseph Pecoraro.
336
337         Exposing two new accessibility properties: Heading Level and Hierarchical Level.
338
339         * inspector/protocol/DOM.json:
340
341 2016-10-18  Filip Pizlo  <fpizlo@apple.com>
342
343         DFG worklist should use AutomaticThread
344         https://bugs.webkit.org/show_bug.cgi?id=163615
345
346         Reviewed by Mark Lam.
347         
348         AutomaticThread is a new feature in WTF that allows you to easily create worker threads that
349         shut down automatically. This changes DFG::Worklist to use AutomaticThread, so that its
350         threads shut down automatically, too. This has the potential to save a lot of memory.
351         
352         This required some improvements to AutomaticThread: Worklist likes to be able to keep state
353         around for the whole lifetime of a thread, and so it likes knowing when threads are born and
354         when they die. I added virtual methods for that. Also, Worklist uses notifyOne() so I added
355         that, too.
356         
357         This looks to be perf-neutral.
358
359         * dfg/DFGThreadData.cpp:
360         (JSC::DFG::ThreadData::ThreadData):
361         * dfg/DFGThreadData.h:
362         * dfg/DFGWorklist.cpp:
363         (JSC::DFG::Worklist::ThreadBody::ThreadBody):
364         (JSC::DFG::Worklist::Worklist):
365         (JSC::DFG::Worklist::~Worklist):
366         (JSC::DFG::Worklist::finishCreation):
367         (JSC::DFG::Worklist::isActiveForVM):
368         (JSC::DFG::Worklist::enqueue):
369         (JSC::DFG::Worklist::compilationState):
370         (JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
371         (JSC::DFG::Worklist::removeAllReadyPlansForVM):
372         (JSC::DFG::Worklist::completeAllReadyPlansForVM):
373         (JSC::DFG::Worklist::rememberCodeBlocks):
374         (JSC::DFG::Worklist::visitWeakReferences):
375         (JSC::DFG::Worklist::removeDeadPlans):
376         (JSC::DFG::Worklist::removeNonCompilingPlansForVM):
377         (JSC::DFG::Worklist::queueLength):
378         (JSC::DFG::Worklist::dump):
379         (JSC::DFG::Worklist::runThread): Deleted.
380         (JSC::DFG::Worklist::threadFunction): Deleted.
381         * dfg/DFGWorklist.h:
382
383 2016-10-19  Dan Bernstein  <mitz@apple.com>
384
385         [Xcode] JavaScriptCore fails to build when CLANG_WARN_DOCUMENTATION_COMMENTS is enabled
386         https://bugs.webkit.org/show_bug.cgi?id=163642
387
388         Reviewed by Darin Adler.
389
390         * API/JSClassRef.cpp: Removed a bad headerdoc comment inside an implementation file.
391         * API/JSContext.h: Changed @methodgroup to @functiongroup, because the compiler requires the
392           former to be followed by a method (and we have a property), but not the latter. Changed
393           a couple of instances of “method” to “@method”. Removed empty @param entries.
394         * API/JSContextRefInternal.h: Named a parameter referenced in a @param entry.
395         * API/JSContextRefPrivate.h: Ditto.
396         * API/JSManagedValue.h: Removed empty @param entries.
397         * API/JSObjectRef.h: Corrected parameter name in @param entry.
398         * API/JSTypedArray.h: Ditto.
399         * API/JSValue.h: Removed empty @param entries, changed @methodgroup to @functiongroup, and
400           changed @method to @property where appropriate. Removed empty @param entries.
401         * API/JSValueRef.h: Named a parameter referenced in a @param entry.
402         * API/JSWeakObjectMapRefPrivate.h: Ditto.
403         * Configurations/Base.xcconfig: Enabled CLANG_WARN_DOCUMENTATION_COMMENTS. Made the compiler
404           treat the icu headers as system headers, to stop it from emitting warnings about headers
405           we don’t want to change.
406         * Configurations/ToolExecutable.xcconfig: Made the compiler treat the icu headers as system
407           headers.
408
409 2016-10-19  Csaba Osztrogonác  <ossy@webkit.org>
410
411         Unreviewed ARM buildfix after r207475.
412
413         * assembler/ARMAssembler.h:
414         (JSC::ARMAssembler::relinkJumpToNop):
415
416 2016-10-18  Mark Lam  <mark.lam@apple.com>
417
418         Invoking Object.prototype.__proto__ accessors directly should throw a TypeError.
419         https://bugs.webkit.org/show_bug.cgi?id=154377
420         <rdar://problem/27330808>
421
422         Reviewed by Filip Pizlo and Saam Barati.
423
424         In a scenario where we cache the __proto__ accessors in global variables, and
425         later explicitly invoke those accessors as functions, the spec for Function Calls
426         (see https://tc39.github.io/ecma262/#sec-function-calls) states that the function
427         ref value is of type Reference, and base of ref is an Environment Record.  Then,
428         it follows that the thisValue should be set to refEnv.WithBaseObject()
429         (see section 4.b.ii of 12.3.4.1 at
430         https://tc39.github.io/ecma262/#sec-function-calls-runtime-semantics-evaluation).
431
432         refEnv in this case is the environment record that the cached accessors were
433         found in i.e. the global object.  The WithBaseObject() of the global object is
434         undefined (see details about WithBaseObject at
435         https://tc39.github.io/ecma262/#sec-environment-records).
436
437         Hence, the __proto__ accessors should see a thisValue of undefined, and throw
438         TypeErrors.  See https://tc39.github.io/ecma262/#sec-get-object.prototype.__proto__,
439         https://tc39.github.io/ecma262/#sec-set-object.prototype.__proto__,
440         https://tc39.github.io/ecma262/#sec-toobject, and
441         https://tc39.github.io/ecma262/#sec-requireobjectcoercible.
442
443         In JSC's implementation, the callee needs to do a ToThis operation on the
444         incoming "this" argument in order to get the specified thisValue.  The
445         implementations of the __proto__ accessors were not doing this correctly.  This
446         has now been fixed.
447
448         * runtime/JSGlobalObjectFunctions.cpp:
449         (JSC::globalFuncProtoGetter):
450         (JSC::globalFuncProtoSetter):
451
452 2016-10-18  Sam Weinig  <sam@webkit.org>
453
454         Replace std::experimental::variant with WTF::Variant (or similar)
455         https://bugs.webkit.org/show_bug.cgi?id=163626
456
457         Reviewed by Chris Dumez.
458
459         Rename std::experimental::variant, Variant. Move helpers get/holds_alternative/etc.
460         into the WTF namespace.
461
462         * domjit/DOMJITReg.h:
463         (JSC::DOMJIT::Reg::gpr):
464         (JSC::DOMJIT::Reg::fpr):
465         (JSC::DOMJIT::Reg::jsValueRegs):
466
467 2016-10-18  Keith Miller  <keith_miller@apple.com>
468
469         GetByVal to GetById conversion in the DFG is incorrect for getters with control flow
470         https://bugs.webkit.org/show_bug.cgi?id=163629
471
472         Reviewed by Yusuke Suzuki.
473
474         This patch fixes a bug in the DFG when attempt to convert a
475         GetByVal into a GetById. While converting the GetByVal, during
476         handleGetById in the Bytecode parser, we would mistakenly use the
477         opcode length of op_get_by_id rather than op_get_by_val. This causes
478         the new basic block we create to point to the wrong offset. In the
479         added test this will cause us to infinite loop.
480
481         * dfg/DFGByteCodeParser.cpp:
482         (JSC::DFG::ByteCodeParser::handleGetById):
483         (JSC::DFG::ByteCodeParser::parseBlock):
484
485 2016-10-18  Dean Jackson  <dino@apple.com>
486
487         Remove CSS_SHAPES feature definition. This should always be on.
488         https://bugs.webkit.org/show_bug.cgi?id=163628
489         <rdar://problem/28834613>
490         Reviewed by Tim Horton.
491
492         * Configurations/FeatureDefines.xcconfig:
493
494 2016-10-18  Michael Saboff  <msaboff@apple.com>
495
496         Add JSC option to show time spent in each optimization phase
497         https://bugs.webkit.org/show_bug.cgi?id=163617
498
499         Reviewed by Saam Barati.
500
501         Added reportDFGPhaseTimes option.  This outputs one line per phase similar to
502             Phase CPS rethreading took 0.2661 ms
503
504         One line is output for each phase run.
505
506         * dfg/DFGPhase.h:
507         (JSC::DFG::runAndLog):
508         * dfg/DFGPlan.cpp:
509         (JSC::DFG::Plan::compileInThread):
510         * runtime/Options.cpp:
511         (JSC::recomputeDependentOptions):
512         * runtime/Options.h:
513
514 2016-10-18  Filip Pizlo  <fpizlo@apple.com>
515
516         WTF should make it easier to create threads that die automatically after inactivity
517         https://bugs.webkit.org/show_bug.cgi?id=163576
518
519         Reviewed by Andreas Kling.
520         
521         Added a sleepSeconds() function, which made it easier for me to test this change.
522         
523         The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
524         shut down automatically after 1 second of inactivity. Maybe this will save some memory.
525
526         * jsc.cpp:
527         (GlobalObject::finishCreation):
528         (functionSleepSeconds):
529
530 2016-10-18  Keith Miller  <keith_miller@apple.com>
531
532         Cleanup Wasm memory.
533         https://bugs.webkit.org/show_bug.cgi?id=163601
534
535         Reviewed by Saam Barati.
536
537         There were a couple of issues with the original Wasm memory patch.
538         This is a follow-up patch to fix those issues.
539
540         * wasm/WASMMemory.cpp:
541         (JSC::WASM::Memory::Memory):
542         * wasm/WASMMemory.h:
543
544 2016-10-15  Filip Pizlo  <fpizlo@apple.com>
545
546         DFG and FTL should be able to use DirectCall ICs when they proved the callee or its executable
547         https://bugs.webkit.org/show_bug.cgi?id=163371
548
549         Reviewed by Geoffrey Garen and Saam Barati.
550         
551         This adds a new kind of call inline cache for when the DFG can prove what the callee
552         executable is. In those cases, we can skip some of the things that the traditional call IC
553         would do:
554         
555         - No need to check who the callee is.
556         - No need to do arity checks.
557         
558         This case isn't as simple as just emitting a call instruction since the callee may not be
559         compiled at the time that the caller is compiled. So, we need lazy resolution. Also, the
560         callee may be jettisoned independently of the caller, so we need to be able to revert the
561         call to an unlinked state. This means that we need almost all of the things that
562         CallLinkInfo has. CallLinkInfo already knows about different kinds of calls. This patch
563         teaches it about new "Direct" call types.
564         
565         The direct non-tail call IC looks like this:
566         
567                 set up arguments
568             FastPath:
569                 call _SlowPath
570                 lea -FrameSize(%rbp), %rsp
571             
572             SlowPath:
573                 pop
574                 call operationLinkDirectCall
575                 check exception
576                 jmp FastPath
577         
578         The job of operationLinkDirectCall is to link the fast path's call entrypoint of the callee.
579         This means that in steady state, a call is just that: a call. There are no extra branches or
580         checks.
581         
582         The direct tail call IC is a bit more complicated because the act of setting up arguments
583         destroys our frame, which would prevent us from being able to throw an exception if we
584         failed to compile the callee. So, direct tail call ICs look like this:
585         
586                 jmp _SlowPath
587             FastPath:
588                 set up arguments
589                 jmp 0 // patch to jump to callee
590             
591             SlowPath:
592                 silent spill
593                 call operationLinkDirectCall
594                 silent fill
595                 check exception
596                 jmp FastPath
597         
598         The jmp to the slow path is patched to be a fall-through jmp when we link the call.
599         
600         Direct calls mean less code at call sites, fewer checks on the steady state call fast path,
601         and no need for arity fixup. This looks like a slight speed-up (~0.8%) on both Octane and
602         AsmBench.
603
604         * assembler/ARM64Assembler.h:
605         (JSC::ARM64Assembler::relinkJumpToNop):
606         * assembler/ARMv7Assembler.h:
607         (JSC::ARMv7Assembler::relinkJumpToNop):
608         (JSC::ARMv7Assembler::relinkJump): Deleted.
609         * assembler/AbstractMacroAssembler.h:
610         (JSC::AbstractMacroAssembler::repatchJumpToNop):
611         (JSC::AbstractMacroAssembler::repatchJump): Deleted.
612         * assembler/X86Assembler.h:
613         (JSC::X86Assembler::relinkJumpToNop):
614         * bytecode/CallLinkInfo.cpp:
615         (JSC::CallLinkInfo::CallLinkInfo):
616         (JSC::CallLinkInfo::callReturnLocation):
617         (JSC::CallLinkInfo::patchableJump):
618         (JSC::CallLinkInfo::hotPathBegin):
619         (JSC::CallLinkInfo::slowPathStart):
620         (JSC::CallLinkInfo::setCallee):
621         (JSC::CallLinkInfo::clearCallee):
622         (JSC::CallLinkInfo::callee):
623         (JSC::CallLinkInfo::setCodeBlock):
624         (JSC::CallLinkInfo::clearCodeBlock):
625         (JSC::CallLinkInfo::codeBlock):
626         (JSC::CallLinkInfo::setLastSeenCallee):
627         (JSC::CallLinkInfo::clearLastSeenCallee):
628         (JSC::CallLinkInfo::lastSeenCallee):
629         (JSC::CallLinkInfo::haveLastSeenCallee):
630         (JSC::CallLinkInfo::setExecutableDuringCompilation):
631         (JSC::CallLinkInfo::executable):
632         (JSC::CallLinkInfo::setMaxNumArguments):
633         (JSC::CallLinkInfo::visitWeak):
634         * bytecode/CallLinkInfo.h:
635         (JSC::CallLinkInfo::specializationKindFor):
636         (JSC::CallLinkInfo::callModeFor):
637         (JSC::CallLinkInfo::isDirect):
638         (JSC::CallLinkInfo::nearCallMode):
639         (JSC::CallLinkInfo::isLinked):
640         (JSC::CallLinkInfo::setCallLocations):
641         (JSC::CallLinkInfo::addressOfMaxNumArguments):
642         (JSC::CallLinkInfo::maxNumArguments):
643         (JSC::CallLinkInfo::isTailCall): Deleted.
644         (JSC::CallLinkInfo::setUpCallFromFTL): Deleted.
645         (JSC::CallLinkInfo::callReturnLocation): Deleted.
646         (JSC::CallLinkInfo::hotPathBegin): Deleted.
647         (JSC::CallLinkInfo::callee): Deleted.
648         (JSC::CallLinkInfo::setLastSeenCallee): Deleted.
649         (JSC::CallLinkInfo::clearLastSeenCallee): Deleted.
650         (JSC::CallLinkInfo::lastSeenCallee): Deleted.
651         (JSC::CallLinkInfo::haveLastSeenCallee): Deleted.
652         * bytecode/CallLinkStatus.cpp:
653         (JSC::CallLinkStatus::computeDFGStatuses):
654         * bytecode/PolymorphicAccess.cpp:
655         (JSC::AccessCase::generateImpl):
656         * bytecode/UnlinkedFunctionExecutable.h:
657         * bytecode/ValueRecovery.h:
658         (JSC::ValueRecovery::forEachReg):
659         * dfg/DFGAbstractInterpreterInlines.h:
660         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
661         * dfg/DFGBasicBlock.h:
662         (JSC::DFG::BasicBlock::findTerminal):
663         * dfg/DFGByteCodeParser.cpp:
664         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
665         (JSC::DFG::ByteCodeParser::handleCall):
666         * dfg/DFGClobberize.h:
667         (JSC::DFG::clobberize):
668         * dfg/DFGDoesGC.cpp:
669         (JSC::DFG::doesGC):
670         * dfg/DFGFixupPhase.cpp:
671         (JSC::DFG::FixupPhase::fixupNode):
672         * dfg/DFGGraph.cpp:
673         (JSC::DFG::Graph::parameterSlotsForArgCount):
674         * dfg/DFGGraph.h:
675         * dfg/DFGInPlaceAbstractState.cpp:
676         (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
677         * dfg/DFGJITCompiler.cpp:
678         (JSC::DFG::JITCompiler::link):
679         * dfg/DFGJITCompiler.h:
680         (JSC::DFG::JITCompiler::addJSDirectCall):
681         (JSC::DFG::JITCompiler::addJSDirectTailCall):
682         (JSC::DFG::JITCompiler::JSCallRecord::JSCallRecord):
683         (JSC::DFG::JITCompiler::JSDirectCallRecord::JSDirectCallRecord):
684         (JSC::DFG::JITCompiler::JSDirectTailCallRecord::JSDirectTailCallRecord):
685         (JSC::DFG::JITCompiler::currentJSCallIndex): Deleted.
686         * dfg/DFGNode.cpp:
687         (JSC::DFG::Node::convertToDirectCall):
688         * dfg/DFGNode.h:
689         (JSC::DFG::Node::isTerminal):
690         (JSC::DFG::Node::hasHeapPrediction):
691         (JSC::DFG::Node::hasCellOperand):
692         * dfg/DFGNodeType.h:
693         * dfg/DFGPredictionPropagationPhase.cpp:
694         * dfg/DFGSafeToExecute.h:
695         (JSC::DFG::safeToExecute):
696         * dfg/DFGSpeculativeJIT.h:
697         (JSC::DFG::SpeculativeJIT::callOperation):
698         * dfg/DFGSpeculativeJIT64.cpp:
699         (JSC::DFG::SpeculativeJIT::emitCall):
700         (JSC::DFG::SpeculativeJIT::compile):
701         * dfg/DFGStrengthReductionPhase.cpp:
702         (JSC::DFG::StrengthReductionPhase::handleNode):
703         * ftl/FTLCapabilities.cpp:
704         (JSC::FTL::canCompile):
705         * ftl/FTLLowerDFGToB3.cpp:
706         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
707         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
708         (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
709         (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
710         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
711         * interpreter/Interpreter.cpp:
712         (JSC::Interpreter::execute):
713         (JSC::Interpreter::executeCall):
714         (JSC::Interpreter::executeConstruct):
715         (JSC::Interpreter::prepareForRepeatCall):
716         * jit/JIT.cpp:
717         (JSC::JIT::link):
718         * jit/JITCall.cpp:
719         (JSC::JIT::compileSetupVarargsFrame):
720         * jit/JITCall32_64.cpp:
721         (JSC::JIT::compileSetupVarargsFrame):
722         * jit/JITOperations.cpp:
723         * jit/JITOperations.h:
724         * jit/Repatch.cpp:
725         (JSC::linkDirectFor):
726         (JSC::revertCall):
727         * jit/Repatch.h:
728         * llint/LLIntSlowPaths.cpp:
729         (JSC::LLInt::setUpCall):
730         * runtime/Executable.cpp:
731         (JSC::ScriptExecutable::prepareForExecutionImpl):
732         * runtime/Executable.h:
733         (JSC::ScriptExecutable::prepareForExecution):
734         * runtime/Options.h:
735
736 2016-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
737
738         [DOMJIT] Not emit exception case if it is not necessary
739         https://bugs.webkit.org/show_bug.cgi?id=163589
740
741         Reviewed by Sam Weinig.
742
743         We should not emit exception case if we do not use the slow path calls.
744         For example, nodeType accessor does not use the slow path calls.
745
746         * bytecode/PolymorphicAccess.cpp:
747         (JSC::AccessCase::emitDOMJITGetter):
748
749 2016-10-18  Caitlin Potter  <caitp@igalia.com>
750
751         [JSC] ES6 Method functions should not have prototype
752         https://bugs.webkit.org/show_bug.cgi?id=162530
753
754         Reviewed by Saam Barati.
755
756         ECMA-262 only adds "prototype" properties to specific syntactic function forms.
757         Specific items which do not contain "prototype" include (most) built-in functions (such as Math.pow),
758         MethodDefinitions which are not either class "constructor" methods or GeneratorMethods, AsyncFunctions,
759         and ArrowFunctions.
760         
761         For details, see the following spec text, and the difference between GeneratorMethod evaluation and
762         the evaluation of other MethodDefinition forms.
763         
764         - https://tc39.github.io/ecma262/#sec-method-definitions-runtime-semantics-propertydefinitionevaluation
765         - https://tc39.github.io/ecma262/#sec-arrow-function-definitions-runtime-semantics-evaluation
766         - https://tc39.github.io/ecmascript-asyncawait/#async-function-instances
767         - https://tc39.github.io/ecma262/#sec-generator-function-definitions-runtime-semantics-propertydefinitionevaluation
768         
769
770         * runtime/Executable.h:
771         * runtime/JSFunction.cpp:
772         (JSC::JSFunction::callerGetter):
773         (JSC::JSFunction::getOwnPropertySlot):
774         (JSC::JSFunction::deleteProperty):
775
776         * bytecompiler/BytecodeGenerator.h:
777         (JSC::BytecodeGenerator::makeFunction):
778         * runtime/Executable.h:
779         * runtime/JSFunction.cpp:
780         (JSC::JSFunction::getOwnPropertySlot):
781         (JSC::JSFunction::getOwnNonIndexPropertyNames):
782         (JSC::JSFunction::put):
783         (JSC::JSFunction::deleteProperty):
784         (JSC::JSFunction::defineOwnProperty):
785         * runtime/JSGlobalObjectFunctions.cpp:
786         (JSC::globalFuncThrowTypeErrorArgumentsCalleeAndCaller):
787
788 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
789
790         [DOMJIT] Use NativeCallFrameTracer for operations used for DOMJIT slow calls
791         https://bugs.webkit.org/show_bug.cgi?id=163586
792
793         Reviewed by Saam Barati.
794
795         C functions called from the DOMJIT slow path calls should use NativeCallFrameTracer.
796         This fixes the debug assertion caused in r207427.
797
798         * bytecode/DOMJITAccessCasePatchpointParams.cpp:
799         (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
800         (JSC::DOMJITAccessCasePatchpointParams::emitSlowPathCalls):
801         * bytecode/DOMJITAccessCasePatchpointParams.h:
802         * bytecode/PolymorphicAccess.cpp:
803         (JSC::AccessCase::emitDOMJITGetter):
804         * jsc.cpp:
805         (WTF::DOMJITGetter::DOMJITNodeDOMJIT::slowCall):
806         (WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::slowCall):
807
808 2016-10-17  Keith Miller  <keith_miller@apple.com>
809
810         Add support for WASM Memory.
811         https://bugs.webkit.org/show_bug.cgi?id=161710
812
813         Reviewed by Geoffrey Garen.
814
815         This patch add initial support for WASM memory operations. First,
816         it adds the concept of a WASM Module memory management object.
817         This object currently mmaps a 32-bit address space for WASM use,
818         although it marks all the memory outside the current breakpoint as
819         PROT_NONE. For now, we do a range check on each store and load. In
820         the future, we should change this to be an signal handler that
821         checks what module the program trapped in.
822
823         Additionally, this patch changes the way that our temporary tests
824         call into WASM code. There is now a true "thunk" that relocates
825         arguments and calls into WASM. This thunk does not tail call
826         because we use pinned values to memory base-pointer and
827         size. We use the new B3 pinned register api to pin the values.
828
829         * CMakeLists.txt:
830         * Configurations/ToolExecutable.xcconfig:
831         * JavaScriptCore.xcodeproj/project.pbxproj:
832         * testWASM.cpp:
833         (runWASMTests):
834         (main):
835         * wasm/WASMB3IRGenerator.cpp:
836         (JSC::WASM::createJSWrapper):
837         (JSC::WASM::parseAndCompile):
838         * wasm/WASMB3IRGenerator.h:
839         * wasm/WASMCallingConvention.h:
840         (JSC::WASM::CallingConvention::iterate):
841         (JSC::WASM::CallingConvention::setupCall):
842         (JSC::WASM::nextJSCOffset):
843         * wasm/WASMFormat.h:
844         * wasm/WASMFunctionParser.h:
845         (JSC::WASM::FunctionParser<Context>::parseExpression):
846         * wasm/WASMMemory.cpp: Copied from Source/JavaScriptCore/wasm/WASMPlan.cpp.
847         (JSC::WASM::Memory::Memory):
848         * wasm/WASMMemory.h: Copied from Source/JavaScriptCore/wasm/WASMModuleParser.h.
849         (JSC::WASM::Memory::~Memory):
850         (JSC::WASM::Memory::memory):
851         (JSC::WASM::Memory::size):
852         (JSC::WASM::Memory::pinnedRegisters):
853         (JSC::WASM::Memory::mode):
854         (JSC::WASM::Memory::growMemory):
855         (JSC::WASM::Memory::offsetOfSize):
856         * wasm/WASMModuleParser.cpp:
857         (JSC::WASM::ModuleParser::parse):
858         (JSC::WASM::ModuleParser::parseMemory):
859         * wasm/WASMModuleParser.h:
860         (JSC::WASM::ModuleParser::functionInformation):
861         (JSC::WASM::ModuleParser::memory):
862         * wasm/WASMOps.h:
863         * wasm/WASMPlan.cpp:
864         (JSC::WASM::Plan::Plan):
865         * wasm/WASMPlan.h:
866         * wasm/WASMSections.h:
867
868 2016-10-17  Joseph Pecoraro  <pecoraro@apple.com>
869
870         Web Inspector: Add toggles for debugger pauses at console.assert failures
871         https://bugs.webkit.org/show_bug.cgi?id=139542
872         <rdar://problem/19281600>
873
874         Reviewed by Timothy Hatcher.
875
876         * inspector/agents/InspectorDebuggerAgent.h:
877         * inspector/agents/InspectorDebuggerAgent.cpp:
878         (Inspector::InspectorDebuggerAgent::disable):
879         (Inspector::InspectorDebuggerAgent::setPauseOnAssertions):
880         Toggle pause on assertions state. Default is disabled,
881         and disable it when frontends disconnect.
882
883         (Inspector::InspectorDebuggerAgent::handleConsoleAssert):
884         Instead of using the PauseOnAllExceptions state, use this
885         new state specific to assertions.
886
887         * inspector/protocol/Debugger.json:
888         New protocol method to toggle pausing on assertions.
889
890 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
891
892         [DOMJIT][JSC] Add Option::useDOMJIT
893         https://bugs.webkit.org/show_bug.cgi?id=163457
894
895         Reviewed by Saam Barati.
896
897         Add an option to switch the DOMJIT optimization.
898
899         * bytecode/PolymorphicAccess.cpp:
900         (JSC::AccessCase::generateImpl):
901         * dfg/DFGByteCodeParser.cpp:
902         (JSC::DFG::ByteCodeParser::handleGetById):
903         * runtime/Options.cpp:
904         (JSC::recomputeDependentOptions):
905         * runtime/Options.h:
906
907 2016-10-17  Filip Pizlo  <fpizlo@apple.com>
908
909         Air::IRC doesn't need to have a special-case for uncolored Tmps since they all get colored
910         https://bugs.webkit.org/show_bug.cgi?id=163548
911         <rdar://problem/28804381>
912
913         Reviewed by Geoffrey Garen.
914         
915         Before r207408, IRC had a mode where it would silently assign the first assignable register (so
916         %rax, %xmm0, etc) to any tmp that was not colorable due to a pathological interference fencepost.
917         We reason about interference at instruction boundaries. This means that if you have, for example,
918         an instruction that clobbers all registers late followed by an instruction that has an early def
919         in the same register file, then the early def will not be colorable because it interferes with
920         all registers. This already happens in our tests, but IRC silently returns the first assignable
921         register to such tmps. For some reason the resulting code works OK - probably because this tends
922         to only be hit by fuzzing, which may not then stress that code enough to shake out the register
923         corruption. Also, this can only happen for floating point registers, so it's hard to get an
924         exciting crash. The worst case is that your numbers get all messed up.
925         
926         This change fixes the issue:
927         
928         - IRC will now crash if it can't color a tmp.
929         
930         - IRC doesn't crash on our tests anymore because I added a padInterference() utility that works
931           around the interference problem by inserting Nops to pad between those instructions where
932           conflating their early and late actions into one interference fencepost could create an
933           uncolorable graph.
934         
935         See https://bugs.webkit.org/show_bug.cgi?id=163548#c2 for a detailed discussion of how the
936         problem can arise.
937         
938         This problem almost made me want to abandon our use of interference at instruction boundaries,
939         and introduce something more comprehensive, like interference at various stages of an
940         instruction's execution. The reason why I didn't do this is that this problem only arises in well
941         confined corner cases: you need an instruction that does a late use or def followed by an
942         instruction that does an early def. Register clobbers count as defs for this equation.
943         Fortunately, early defs are rare, and even when they do happen, you still need the previous
944         instruction to have a late something. Late uses are rare and many instructions don't have defs at
945         all, which means that it's actually pretty common for an instruction to not have anything late.
946         This means that the padInterference() strategy is ideal: our algorithms stay simple because they
947         only have to worry about interference at boundaries, and we rarely insert any Nops in
948         padInterference() so the IR stays nice and compact. Those Nops get removed by any phase that does
949         DCE, which includes eliminateDeadCode(), allocateStack(), and reportUsedRegisters(). In practice
950         allocateStack() kills them.
951         
952         This also finally refactors our passing of RegisterSet to pass it by value, since it's small
953         enough that we're not gaining anything by using references. On x86, RegisterSet ought to be
954         smaller than a pointer.
955
956         * CMakeLists.txt:
957         * JavaScriptCore.xcodeproj/project.pbxproj:
958         * b3/B3StackmapSpecial.cpp:
959         (JSC::B3::StackmapSpecial::extraClobberedRegs):
960         (JSC::B3::StackmapSpecial::extraEarlyClobberedRegs):
961         * b3/B3StackmapSpecial.h:
962         * b3/air/AirCCallSpecial.cpp:
963         (JSC::B3::Air::CCallSpecial::extraEarlyClobberedRegs):
964         (JSC::B3::Air::CCallSpecial::extraClobberedRegs):
965         * b3/air/AirCCallSpecial.h:
966         * b3/air/AirInst.h:
967         * b3/air/AirInstInlines.h:
968         (JSC::B3::Air::Inst::extraClobberedRegs):
969         (JSC::B3::Air::Inst::extraEarlyClobberedRegs):
970         * b3/air/AirIteratedRegisterCoalescing.cpp:
971         (JSC::B3::Air::iteratedRegisterCoalescing):
972         * b3/air/AirPadInterference.cpp: Added.
973         (JSC::B3::Air::padInterference):
974         * b3/air/AirPadInterference.h: Added.
975         * b3/air/AirSpecial.h:
976         * b3/air/AirSpillEverything.cpp:
977         (JSC::B3::Air::spillEverything):
978         * jit/RegisterSet.h:
979         (JSC::RegisterSet::isEmpty):
980
981 2016-10-17  JF Bastien  <jfbastien@apple.com>
982
983         WebAssembly JS API: implement basic stub
984
985         Implement the global WebAssembly JavaScript object, and its constructor +
986         function properties as described in:
987           https://github.com/WebAssembly/design/blob/master/JS.md
988
989         These don't do anything at the moment, the parent bug will take care of adding
990         more functionality and associated tests.
991
992         WebAssembly JS API: implement basic stub
993         https://bugs.webkit.org/show_bug.cgi?id=163404
994
995         Reviewed by Keith Miller.
996
997         * CMakeLists.txt:
998         * JavaScriptCore.xcodeproj/project.pbxproj:
999         * builtins/BuiltinNames.h: register the new WebAssembly object's name and its constructor properties
1000         * jsc.cpp: remove useless include
1001         * runtime/JSGlobalObject.cpp:
1002         (JSC::JSGlobalObject::init): add the WebAssembly global object and its constructor properties, but only if the JSC option enables it
1003         * runtime/Options.h: add the useWebAssembly (alias: enableWebAssembly) option, defaulting to false
1004         * wasm/WebAssemblyObject.cpp: Added.
1005         (JSC::WebAssemblyObject::create): boilerplate
1006         (JSC::WebAssemblyObject::createStructure): boilerplate
1007         (JSC::WebAssemblyObject::finishCreation): boilerplate
1008         (JSC::WebAssemblyObject::WebAssemblyObject): boilerplate
1009         (JSC::wasmObjectFuncvalidate): auto-throws for now
1010         (JSC::wasmObjectFunccompile): auto-throws for now
1011         * wasm/WebAssemblyObject.h: Added.
1012
1013 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
1014
1015         Unreviewed, build fix after r207428
1016         https://bugs.webkit.org/show_bug.cgi?id=163223
1017
1018         Previous build fix r207428 broke all the builds.
1019
1020         * bytecode/PolymorphicAccess.h:
1021
1022 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
1023
1024         Unreviewed, build fix for GTK and Windows
1025         https://bugs.webkit.org/show_bug.cgi?id=163223
1026
1027         Attempt to fix build failures in GTK port and Windows port.
1028
1029         * bytecode/PolymorphicAccess.cpp:
1030         * bytecode/PolymorphicAccess.h:
1031         (JSC::AccessGenerationState::SpillState::SpillState):
1032
1033 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
1034
1035         [DOMJIT] Use DOMJIT::Patchpoint in IC
1036         https://bugs.webkit.org/show_bug.cgi?id=163223
1037
1038         Reviewed by Saam Barati.
1039
1040         This patch uses DOMJIT::Patchpoint to inline DOM accesses even in IC!
1041         It is useful for Baseline JIT cases and GetById cases in DFG and FTL.
1042         In AccessCase, we construct the environment that allows DOMJIT::Patchpoint
1043         to emit code and make DOMJIT accessors inlined in IC.
1044
1045         To allow DOMJIT::Patchpoint to emit code, we create a mechanism to emit calls
1046         required in DOMJIT::Patchpoint. This system is useful when we create the super-
1047         polymorphic support[1] later. And inlining mechanism is useful even after
1048         introducing super-polymorphic support since it can work even after we fire the
1049         watchpoint for super-polymorphic handling.
1050
1051         This patch improves Dromaeo dom-traverse 8% (263.95 runs/s v.s. 244.07 runs/s).
1052
1053         [1]: https://bugs.webkit.org/show_bug.cgi?id=163226
1054
1055         * CMakeLists.txt:
1056         * JavaScriptCore.xcodeproj/project.pbxproj:
1057         * bytecode/DOMJITAccessCasePatchpointParams.cpp: Added.
1058         (JSC::SlowPathCallGeneratorWithArguments::SlowPathCallGeneratorWithArguments):
1059         (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
1060         (JSC::DOMJITAccessCasePatchpointParams::emitSlowPathCalls):
1061         * bytecode/DOMJITAccessCasePatchpointParams.h: Copied from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.h.
1062         (JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams):
1063         (JSC::DOMJITAccessCasePatchpointParams::SlowPathCallGenerator::~SlowPathCallGenerator):
1064         * bytecode/PolymorphicAccess.cpp:
1065         (JSC::AccessGenerationState::liveRegistersForCall):
1066         (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
1067         (JSC::calleeSaveRegisters):
1068         (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
1069         (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCallWithThrownException):
1070         (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCall):
1071         (JSC::AccessGenerationState::callSiteIndexForExceptionHandlingOrOriginal):
1072         (JSC::AccessGenerationState::originalExceptionHandler):
1073         (JSC::AccessCase::generateImpl):
1074         (JSC::AccessCase::emitDOMJITGetter):
1075         (JSC::PolymorphicAccess::regenerate):
1076         (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall): Deleted.
1077         * bytecode/PolymorphicAccess.h:
1078         (JSC::AccessGenerationState::SpillState::isEmpty):
1079         (JSC::AccessGenerationState::setSpillStateForJSGetterSetter):
1080         (JSC::AccessGenerationState::spillStateForJSGetterSetter):
1081         (JSC::AccessGenerationState::liveRegistersForCall): Deleted.
1082         (JSC::AccessGenerationState::numberOfStackBytesUsedForRegisterPreservation): Deleted.
1083         (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite): Deleted.
1084         * dfg/DFGDOMJITPatchpointParams.cpp:
1085         * dfg/DFGDOMJITPatchpointParams.h:
1086         * domjit/DOMJITPatchpoint.h:
1087         * domjit/DOMJITPatchpointParams.h:
1088         (JSC::DOMJIT::PatchpointParams::addSlowPathCall):
1089         * ftl/FTLDOMJITPatchpointParams.cpp:
1090         * ftl/FTLDOMJITPatchpointParams.h:
1091         * jsc.cpp:
1092         (WTF::DOMJITNode::checkDOMJITNode):
1093         (WTF::DOMJITGetterComplex::DOMJITGetterComplex):
1094         (WTF::DOMJITGetterComplex::createStructure):
1095         (WTF::DOMJITGetterComplex::create):
1096         (WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT):
1097         (WTF::DOMJITGetterComplex::domJITNodeGetterSetter):
1098         (WTF::DOMJITGetterComplex::finishCreation):
1099         (WTF::DOMJITGetterComplex::functionEnableException):
1100         (WTF::DOMJITGetterComplex::customGetter):
1101         (GlobalObject::finishCreation):
1102         (functionCreateDOMJITGetterComplexObject):
1103
1104 2016-10-17  Saam Barati  <sbarati@apple.com>
1105
1106         Build fix for HasOwnPropertyCache::Entry caused slowdown by introducing a constructor that doesn't use move semantics for the RefPtr<UniquedStringImpl> parameter
1107         https://bugs.webkit.org/show_bug.cgi?id=163490
1108
1109         Reviewed by Darin Adler.
1110
1111         * runtime/HasOwnPropertyCache.h:
1112         (JSC::HasOwnPropertyCache::Entry::Entry):
1113         (JSC::HasOwnPropertyCache::tryAdd):
1114
1115 2016-10-17  Mark Lam  <mark.lam@apple.com>
1116
1117         Use the reject() helper function for conditionally throwing TypeErrors.
1118         https://bugs.webkit.org/show_bug.cgi?id=163491
1119
1120         Reviewed by Filip Pizlo.
1121
1122         In some places where we may conditionally throw a TypeError (e.g. when in strict
1123         mode), we already use the reject() helper function to conditionally throw the
1124         TypeError.  Doing so makes the code mode compact.  This patch applies this idiom
1125         consistently in all places that throws TypeError where appropriate.
1126
1127         This patch also does the following:
1128         1. Make the reject() helper function take an ASCIILiteral instead of a const char*
1129            because we always pass it a literal string anyway.
1130         2. Change the reject helper() to take a ThrowScope&.  This allows the thrown
1131            error to be attributed to its caller.
1132         3. When an error message string is instantiated repeatedly in more than 1 place,
1133            create a common copy of that literal string in JSObject.cpp (if one doesn't
1134            already exist) and use that common string in all those places.
1135         4. Since I was auditing call sites of throwTypeError() to check if they should be
1136            using the reject() helper instead, I also fixed those up to pass the error
1137            message as an ASCIILiteral where appropriate.
1138         5. In functions that I touched, change the code to not recompute the VM& when it
1139            is already available.
1140
1141         * jit/JITOperations.cpp:
1142         * llint/LLIntSlowPaths.cpp:
1143         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1144         * runtime/ArrayPrototype.cpp:
1145         (JSC::shift):
1146         (JSC::unshift):
1147         (JSC::arrayProtoFuncPop):
1148         (JSC::arrayProtoFuncReverse):
1149         * runtime/CommonSlowPaths.cpp:
1150         (JSC::SLOW_PATH_DECL):
1151         * runtime/GetterSetter.cpp:
1152         (JSC::callSetter):
1153         * runtime/JSArray.cpp:
1154         (JSC::JSArray::defineOwnProperty):
1155         (JSC::JSArray::setLengthWithArrayStorage):
1156         (JSC::JSArray::pop):
1157         * runtime/JSArrayBuffer.cpp:
1158         (JSC::JSArrayBuffer::put):
1159         (JSC::JSArrayBuffer::defineOwnProperty):
1160         * runtime/JSCJSValue.cpp:
1161         (JSC::JSValue::putToPrimitive):
1162         (JSC::JSValue::putToPrimitiveByIndex):
1163         * runtime/JSDataView.cpp:
1164         (JSC::JSDataView::put):
1165         (JSC::JSDataView::defineOwnProperty):
1166         * runtime/JSFunction.cpp:
1167         (JSC::JSFunction::put):
1168         (JSC::JSFunction::defineOwnProperty):
1169         * runtime/JSGenericTypedArrayView.h:
1170         (JSC::JSGenericTypedArrayView::setIndex):
1171         * runtime/JSGenericTypedArrayViewInlines.h:
1172         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
1173         (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
1174         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
1175         (JSC::speciesConstruct):
1176         (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
1177         * runtime/JSModuleNamespaceObject.cpp:
1178         (JSC::JSModuleNamespaceObject::defineOwnProperty):
1179         * runtime/JSObject.cpp:
1180         (JSC::ordinarySetSlow):
1181         (JSC::JSObject::putInlineSlow):
1182         (JSC::JSObject::setPrototypeWithCycleCheck):
1183         (JSC::JSObject::defineOwnIndexedProperty):
1184         (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
1185         (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
1186         (JSC::validateAndApplyPropertyDescriptor):
1187         * runtime/JSObject.h:
1188         * runtime/JSObjectInlines.h:
1189         (JSC::JSObject::putInline):
1190         * runtime/JSProxy.cpp:
1191         (JSC::JSProxy::setPrototype):
1192         * runtime/JSSymbolTableObject.h:
1193         (JSC::symbolTablePut):
1194         * runtime/Lookup.h:
1195         (JSC::putEntry):
1196         * runtime/RegExpObject.cpp:
1197         (JSC::RegExpObject::defineOwnProperty):
1198         * runtime/RegExpObject.h:
1199         (JSC::RegExpObject::setLastIndex):
1200         * runtime/Reject.h:
1201         (JSC::reject):
1202         * runtime/SparseArrayValueMap.cpp:
1203         (JSC::SparseArrayValueMap::putEntry):
1204         (JSC::SparseArrayValueMap::putDirect):
1205         (JSC::SparseArrayEntry::put):
1206         * runtime/StringObject.cpp:
1207         (JSC::StringObject::put):
1208         (JSC::StringObject::putByIndex):
1209         * runtime/SymbolConstructor.cpp:
1210         (JSC::symbolConstructorKeyFor):
1211
1212 2016-10-16  Filip Pizlo  <fpizlo@apple.com>
1213
1214         Air::IRC needs to place all Tmps on some worklist, even if they have no interference edges
1215         https://bugs.webkit.org/show_bug.cgi?id=163509
1216
1217         Reviewed by Mark Lam.
1218         
1219         The worklist building function in IRC skips temporaries that have no degree. This doesn't appear
1220         to be necessary. This has been there since the original IRC commit. It hasn't caused bugs because
1221         ordinarily, the only way to have a tmp with no degree is to not have any mention of that tmp. But
1222         while working on bug 163371, I hit a crazy corner case where a temporary would have no
1223         interference edges (i.e. no degree). Here's how it happens:
1224         
1225         A spill tmp from a previous iteration of IRC may have no degree: imagine a tmp that is live
1226         everywhere and interferes with everyone, but has one use like:
1227
1228         Move %ourTmp, %someOtherTmp
1229
1230         Where there are no other tmps live.  After spill conversion, this may look like:
1231
1232         Move (ourSpill), %newTmp
1233         Move %newTmp, %someOtherTmp
1234
1235         Of course, we'd rather not get this kind of spill code but it's totally possible because we now
1236         have a bunch of random conditions under which we won't slap the spill address directly into the
1237         Move.
1238
1239         After this happens, assuming that the only thing live was %someOtherTmp, we will have zero degree
1240         for %newTmp because the Move is coalescable and does not contribute to interference.
1241
1242         Then, we might coalesce %someOtherTmp with %newTmp.  Once this happens, if we make the %newTmp be
1243         the master, we're in deep trouble because %newTmp is not on any worklist.
1244         
1245         I don't know how to reproduce this except through the patch in bug 163371. Removing the two lines
1246         of code that skipped no-degree tmps causes no regressions, and resolves the problem I was having.
1247
1248         * b3/air/AirIteratedRegisterCoalescing.cpp:
1249
1250 2016-10-15  Mark Lam  <mark.lam@apple.com>
1251
1252         Add a $vm.getpid() method.
1253         https://bugs.webkit.org/show_bug.cgi?id=163493
1254
1255         Reviewed by Saam Barati.
1256
1257         This is especially useful when we need to know the pid of an instance of jsc in
1258         the foreground that we're trying to attach a debugger to while the JSC tests are
1259         running in the background with a gazillion other jsc processes live at the same
1260         time.
1261
1262         Currently, $vm.getpid() is only supported on non-Windows platforms.
1263         According to https://msdn.microsoft.com/en-us/library/ms235372.aspx, getpid() is
1264         deprecated.  According to https://msdn.microsoft.com/en-us/library/t2y34y40.aspx,
1265         _getpid() cannot be used in applications that execute in the Windows Runtime.
1266
1267         Since this is only a debugging tool and is not a required feature, I'll defer
1268         the Windows implementation of this function till the time when someone actually
1269         needs it.
1270
1271         * tools/JSDollarVMPrototype.cpp:
1272         (JSC::functionGetPID):
1273         (JSC::JSDollarVMPrototype::finishCreation):
1274
1275 2016-10-15  Saam Barati  <sbarati@apple.com>
1276
1277         Assertion failed under operationToLowerCase with a rope with zero length
1278         https://bugs.webkit.org/show_bug.cgi?id=163314
1279
1280         Reviewed by Mark Lam.
1281
1282         There are some ways to get JSC to create empty rope strings. ToLowerCase
1283         inside the DFG/FTL goes to the slow path when the argument is a rope.
1284         operationToLowerCase was calling into a WTF string function that
1285         assumed we are passing it a this value that has non-zero length.
1286         However, we were calling it with a string that did have zero length.
1287         To fix this, we make operationToLowerCase return the empty JSString
1288         if it is going to make a string with zero length.
1289
1290         * dfg/DFGOperations.cpp:
1291         * jsc.cpp:
1292         (GlobalObject::finishCreation):
1293         (functionIsRope):
1294
1295 2016-10-14  Benjamin Poulain  <bpoulain@apple.com>
1296
1297         [JSC] op_negate should with any type
1298         https://bugs.webkit.org/show_bug.cgi?id=162587
1299
1300         Reviewed by Saam Barati.
1301
1302         * dfg/DFGAbstractInterpreterInlines.h:
1303         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1304         ArithNegate is quite simple. If the input is double, the output
1305         is double. The other cases are set from the LLInt slow case.
1306
1307         * dfg/DFGByteCodeParser.cpp:
1308         (JSC::DFG::ByteCodeParser::makeSafe):
1309         * dfg/DFGClobberize.h:
1310         (JSC::DFG::clobberize):
1311         * dfg/DFGFixupPhase.cpp:
1312         (JSC::DFG::FixupPhase::fixupNode):
1313
1314         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
1315         Tweak a bit the IntegerRangeOptimizationPhase when simplifying
1316         ArithAbs to ArithNegate.
1317         We should not do the conversion if the target nodes OSR Exits
1318         on different input than the source node.
1319
1320         In particular, Checked ArithNegate exits on zero while
1321         ArithAbs has not problem with it.
1322         Unchecked ArithAbs() do not OSR Exit on INT_MIN, ArithNeg
1323         should not either.
1324
1325         * dfg/DFGPredictionPropagationPhase.cpp:
1326         * dfg/DFGSpeculativeJIT.cpp:
1327         (JSC::DFG::SpeculativeJIT::compileArithNegate):
1328         (JSC::DFG::SpeculativeJIT::compileMathIC):
1329         * dfg/DFGSpeculativeJIT.h:
1330         (JSC::DFG::SpeculativeJIT::callOperation):
1331         * ftl/FTLLowerDFGToB3.cpp:
1332         (JSC::FTL::DFG::LowerDFGToB3::compileMathIC):
1333         (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
1334
1335         * jit/JITNegGenerator.cpp:
1336         (JSC::JITNegGenerator::generateFastPath):
1337         * jit/JITOperations.cpp:
1338         Add result profiling in baseline to have types we can use
1339         in DFG and FTL.
1340
1341 2016-10-14  Keith Miller  <keith_miller@apple.com>
1342
1343         B3 needs a special WasmAddress Opcode
1344         https://bugs.webkit.org/show_bug.cgi?id=163394
1345
1346         Reviewed by Filip Pizlo.
1347
1348         This patch adds support for WasmAddress. WasmAddress will be used by
1349         Wasm to compute the address of a memory operation from the pinned
1350         base pointer. WasmAddress takes an IntPtr so we can avoid emitting
1351         unnecessary Move32s in Air. This could happen in the following case:
1352
1353         @ptr = Trunc(...)
1354         WasmAddress(@ptr, pinnedGPR)
1355         ...
1356         PatchPoint(...) // Do Wasm call
1357         WasmAddress(@ptr, pinnedGPR)
1358         ...
1359
1360         In this case we will not be able to CSE the WasmAddresses since the
1361         call writes to pinnedGPR. Thus if WasmAddress took an Int32 we would need
1362         to emit an extra Move32 at the second WasmAddress to ensure it saw a proper
1363         32-bit value. If Wasm ensures that there there is a leading ZExt32 then
1364         the duplicated moves become unnecessary.
1365
1366         * CMakeLists.txt:
1367         * JavaScriptCore.xcodeproj/project.pbxproj:
1368         * b3/B3LowerToAir.cpp:
1369         (JSC::B3::Air::LowerToAir::effectiveAddr):
1370         (JSC::B3::Air::LowerToAir::lower):
1371         * b3/B3Opcode.cpp:
1372         (WTF::printInternal):
1373         * b3/B3Opcode.h:
1374         * b3/B3Validate.cpp:
1375         * b3/B3Value.cpp:
1376         (JSC::B3::Value::effects):
1377         * b3/B3WasmAddressValue.cpp: Added.
1378         (JSC::B3::WasmAddressValue::~WasmAddressValue):
1379         (JSC::B3::WasmAddressValue::dumpMeta):
1380         (JSC::B3::WasmAddressValue::cloneImpl):
1381         (JSC::B3::WasmAddressValue::WasmAddressValue):
1382         * b3/B3WasmAddressValue.h: Added.
1383         * b3/testb3.cpp:
1384         (JSC::B3::testWasmAddress):
1385         (JSC::B3::run):
1386
1387 2016-10-14  Joseph Pecoraro  <pecoraro@apple.com>
1388
1389         test262: @isConstructor incorrectly thinks Math.cos is a constructor
1390         https://bugs.webkit.org/show_bug.cgi?id=163437
1391
1392         Reviewed by Saam Barati.
1393
1394         * runtime/JSFunction.cpp:
1395         (JSC::JSFunction::getConstructData):
1396         By default, Host JSFunctions are not constructable. They get
1397         the default callHostFunctionAsConstructor native constructor.
1398         When getting construct data we can return ConstructType::None
1399         in these cases instead of indicating it might be constructable
1400         and later throwing an exception when construction is attempted.
1401
1402 2016-10-14  Ryan Haddad  <ryanhaddad@apple.com>
1403
1404         Unreviewed, rolling out r207322.
1405
1406         This change caused JSC test failures
1407
1408         Reverted changeset:
1409
1410         "Fix Array.prototype.splice ES6 compliance."
1411         https://bugs.webkit.org/show_bug.cgi?id=163372
1412         http://trac.webkit.org/changeset/207322
1413
1414 2016-10-14  Mark Lam  <mark.lam@apple.com>
1415
1416         JSON.parse should not modify frozen objects.
1417         https://bugs.webkit.org/show_bug.cgi?id=163430
1418
1419         Reviewed by Saam Barati.
1420
1421         The ES6 spec for JSON.parse (https://tc39.github.io/ecma262/#sec-json.parse and
1422         https://tc39.github.io/ecma262/#sec-internalizejsonproperty) states that it uses
1423         CreateDataProperty() (https://tc39.github.io/ecma262/#sec-createdataproperty) to
1424         set values returned by a reviver.  The spec for CreateDataPropertyOrThrow states:
1425
1426         "This abstract operation creates a property whose attributes are set to the same
1427         defaults used for properties created by the ECMAScript language assignment
1428         operator. Normally, the property will not already exist. If it does exist and is
1429         not configurable or if O is not extensible, [[DefineOwnProperty]] will return
1430         false."
1431
1432         Note: CreateDataProperty() will not throw a TypeError.
1433
1434         Since the properties of frozen objects are not extensible, not configurable, and
1435         not writeable, JSON.parse should fail to write to any frozen objects.  Similarly,
1436         JSON.parse should fail to delete properties in frozen objects.
1437
1438         In JSON.parse(), we previously write to array elements using the form of
1439         putDirectIndex() that uses mode PutDirectIndexLikePutDirect.  This makes it so
1440         that the write (i.e. put) is always successful.  We've now fixed this to use
1441         PutDirectIndexShouldNotThrow mode instead, which will fail to put the element if
1442         the array is not writeable.
1443
1444         Also changed Walker::walk() to use the version of methodTable() that takes a VM&
1445         since the VM& is already available.
1446
1447         * runtime/JSONObject.cpp:
1448         (JSC::Walker::walk):
1449
1450 2016-10-14  Joseph Pecoraro  <pecoraro@apple.com>
1451
1452         test262: Failure with RegExp.prototype.compile when pattern is undefined
1453         https://bugs.webkit.org/show_bug.cgi?id=163431
1454
1455         Reviewed by Yusuke Suzuki.
1456
1457         If pattern is undefined let P be the empty String.
1458         https://tc39.github.io/ecma262/#sec-regexpinitialize
1459
1460         * runtime/RegExpPrototype.cpp:
1461         (JSC::regExpProtoFuncCompile):
1462
1463 2016-10-13  Joseph Pecoraro  <pecoraro@apple.com>
1464
1465         Exception message for expressions with multiple bracket accesses is inconsistent / incorrect
1466         https://bugs.webkit.org/show_bug.cgi?id=163426
1467
1468         Reviewed by Geoffrey Garen.
1469
1470         * bytecompiler/NodesCodegen.cpp:
1471         (JSC::BracketAccessorNode::emitBytecode):
1472         It matters where emitExpressionInfo is called since it gathers
1473         info about where we are in the instruction stream. We need to
1474         emit it before the bytecode that we want to associate the data
1475         with. In this case, before the getById / getByVal.
1476
1477 2016-10-13  Mark Lam  <mark.lam@apple.com>
1478
1479         Fix Array.prototype.splice ES6 compliance.
1480         https://bugs.webkit.org/show_bug.cgi?id=163372
1481
1482         Reviewed by Geoffrey Garen and Yusuke Suzuki.
1483
1484         Our Array.prototype.splice implementation neglected to set length on the result
1485         array (step 12 of https://tc39.github.io/ecma262/#sec-array.prototype.splice) in
1486         a certain code path.  This is now fixed.
1487
1488         I'm deferring the implementation of step 8 till later because it requires more
1489         careful consideration and the fix is of a lesser value (and therefore, of less
1490         urgency).  See https://bugs.webkit.org/show_bug.cgi?id=163417
1491
1492         Also added some needed exception checks and assertions.
1493
1494         * runtime/ArrayPrototype.cpp:
1495         (JSC::arrayProtoFuncSplice):
1496
1497 2016-10-13  Joseph Pecoraro  <pecoraro@apple.com>
1498
1499         Web Inspector: Stepping highlight for dot/bracket expressions in if statements highlights subset of the expression
1500         https://bugs.webkit.org/show_bug.cgi?id=163378
1501         <rdar://problem/28749376>
1502
1503         Reviewed by Saam Barati.
1504
1505         * parser/Parser.cpp:
1506         (JSC::Parser<LexerType>::parseAssignmentExpression):
1507         Since each expression builds on the previous, always keep the starting
1508         location the first location.
1509
1510 2016-10-13  Per Arne Vollan  <pvollan@apple.com>
1511
1512         [Win64] Compile fix.
1513         https://bugs.webkit.org/show_bug.cgi?id=163384
1514
1515         Reviewed by Brent Fulgham.
1516
1517         Fix use of potentially uninitialized variable.
1518
1519         * dfg/DFGSpeculativeJIT64.cpp:
1520         (JSC::DFG::SpeculativeJIT::compile):
1521
1522 2016-10-12  Chris Dumez  <cdumez@apple.com>
1523
1524         [Web IDL] Drop support for legacy [ConstructorConditional=*]
1525         https://bugs.webkit.org/show_bug.cgi?id=163368
1526
1527         Reviewed by Ryosuke Niwa.
1528
1529         Drop ENABLE_DOM4_EVENTS_CONSTRUCTOR compiler flag.
1530
1531         * Configurations/FeatureDefines.xcconfig:
1532
1533 2016-10-12  Joseph Pecoraro  <pecoraro@apple.com>
1534
1535         Web Inspector: step-into `console.log(o)` should not step through inspector javascript
1536         https://bugs.webkit.org/show_bug.cgi?id=161656
1537         <rdar://problem/28181123>
1538
1539         Reviewed by Timothy Hatcher.
1540
1541         * debugger/Debugger.h:
1542         * debugger/Debugger.cpp:
1543         (JSC::Debugger::pauseIfNeeded):
1544         If the Script is blacklisted skip checking if we need to pause.
1545
1546         (JSC::Debugger::isBlacklisted):
1547         (JSC::Debugger::addToBlacklist):
1548         (JSC::Debugger::clearBlacklist):
1549         Add the ability to add a Script to a blacklist. Currently the blacklist
1550         only prevents pausing in the Script.
1551
1552         * inspector/agents/InspectorDebuggerAgent.cpp:
1553         (Inspector::isWebKitInjectedScript):
1554         (Inspector::InspectorDebuggerAgent::didParseSource):
1555         Always add Internal InjectedScripts to the Debugger's blacklist.
1556
1557         (Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
1558         Clear blacklists when clearing debugger state.
1559
1560 2016-10-12  Keith Miller  <keith_miller@apple.com>
1561
1562         B3 needs a special WasmBoundsCheck Opcode
1563         https://bugs.webkit.org/show_bug.cgi?id=163246
1564
1565         Reviewed by Filip Pizlo.
1566
1567         This patch adds a new Opcode, WasmBoundsCheck, as well as a B3::Value subclass for it,
1568         WasmBoundsCheckValue. WasmBoundsCheckValue takes three pieces of information. The first is
1569         the Int32 pointer value used to be used by the Load.  Next is the pinned register. The
1570         pinned register must be pinned by calling proc.setPinned() prior to compiling the
1571         Procedure. Lastly, the WasmBoundsCheckValue takes an offset. The WasmBoundsCheckValue is
1572         will then emit code that side-exits if the Int64 sum of the offset and pointer is greater
1573         than or equal to the value in the pinnedRegister. Instead of taking a generator for each
1574         value like Check/Patchpoint, WasmBoundsCheck gets its generator directly off Air::Code. In
1575         Air this patch adds a new Custom opcode, WasmBoundsCheck.
1576
1577         In the future we should add WasmBoundsCheck to CSE so it can eliminate redundant bounds
1578         checks. At the first cut, we can remove any WasmBoundsCheck dominated by another
1579         WasmBoundsCheck with the same pointer and pinnedGPR, and a larger offset.
1580
1581         * CMakeLists.txt:
1582         * JavaScriptCore.xcodeproj/project.pbxproj:
1583         * b3/B3LowerToAir.cpp:
1584         (JSC::B3::Air::LowerToAir::imm):
1585         (JSC::B3::Air::LowerToAir::lower):
1586         * b3/B3Opcode.cpp:
1587         (WTF::printInternal):
1588         * b3/B3Opcode.h:
1589         * b3/B3Procedure.cpp:
1590         (JSC::B3::Procedure::setWasmBoundsCheckGenerator):
1591         * b3/B3Procedure.h:
1592         (JSC::B3::Procedure::setWasmBoundsCheckGenerator):
1593         * b3/B3Validate.cpp:
1594         * b3/B3Value.cpp:
1595         (JSC::B3::Value::effects):
1596         (JSC::B3::Value::typeFor):
1597         * b3/B3WasmBoundsCheckValue.cpp: Added.
1598         (JSC::B3::WasmBoundsCheckValue::~WasmBoundsCheckValue):
1599         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
1600         (JSC::B3::WasmBoundsCheckValue::dumpMeta):
1601         * b3/B3WasmBoundsCheckValue.h: Added.
1602         (JSC::B3::WasmBoundsCheckValue::accepts):
1603         (JSC::B3::WasmBoundsCheckValue::pinnedGPR):
1604         (JSC::B3::WasmBoundsCheckValue::offset):
1605         * b3/air/AirCode.h:
1606         (JSC::B3::Air::Code::setWasmBoundsCheckGenerator):
1607         (JSC::B3::Air::Code::wasmBoundsCheckGenerator):
1608         * b3/air/AirCustom.cpp:
1609         (JSC::B3::Air::WasmBoundsCheckCustom::isValidForm):
1610         * b3/air/AirCustom.h:
1611         (JSC::B3::Air::WasmBoundsCheckCustom::forEachArg):
1612         (JSC::B3::Air::WasmBoundsCheckCustom::isValidFormStatic):
1613         (JSC::B3::Air::WasmBoundsCheckCustom::admitsStack):
1614         (JSC::B3::Air::WasmBoundsCheckCustom::isTerminal):
1615         (JSC::B3::Air::WasmBoundsCheckCustom::hasNonArgNonControlEffects):
1616         (JSC::B3::Air::WasmBoundsCheckCustom::generate):
1617         * b3/air/AirOpcode.opcodes:
1618         * b3/testb3.cpp:
1619         (JSC::B3::testWasmBoundsCheck):
1620         (JSC::B3::run):
1621
1622 2016-10-12  Filip Pizlo  <fpizlo@apple.com>
1623
1624         The blackening of CellState is a bad way of tracking if the object is being marked for the first time
1625         https://bugs.webkit.org/show_bug.cgi?id=163343
1626
1627         Reviewed by Mark Lam.
1628         
1629         When I first added the concept of NewGrey/OldGrey, I had the SlotVisitor store the old cell
1630         state in itself, so that it could use it to decide what to do for reportExtraMemoryVisited().
1631         
1632         Then I changed it in a recent commit, because I wanted the freedom to have SlotVisitor visit
1633         multiple objects in tandem. But I never ended up using this capability. Still, I liked the
1634         new way better: instead of the SlotVisitor rembemering the state-before-blackening, we would
1635         make the object's state reflect whether it was black for the first time or not. That seemed
1636         convenient.
1637         
1638         Unfortunately it's wrong. After we blacken the object, a concurrent barrier could instantly
1639         grey it. Then we would forget that we are visiting this object for the first time.
1640         Subsequent visits will think that they are not the first. So, we will fail to do the right
1641         thing in reportExtraMemoryVisited().
1642         
1643         So, this reverts that change. This is a little more than just a revert, though. I've changed
1644         the terminology a bit. For example, I got tired of reading Black and having to remind myself
1645         that it really means that the object has begun being visited, instead of the more strict
1646         meaning that implies that it has already been visited. We want to say that it's Black or
1647         currently being scanned. I'm going to adopt Siebert's term for this: Anthracite [1]. So, our
1648         black CellState is now called AnthraciteOrBlack.
1649         
1650         [1] https://pdfs.semanticscholar.org/7ae4/633265aead1f8835cf7966e179d02c2c8a4b.pdf
1651
1652         * heap/CellState.h:
1653         (JSC::isBlack): Deleted.
1654         (JSC::blacken): Deleted.
1655         * heap/Heap.cpp:
1656         (JSC::Heap::addToRememberedSet):
1657         (JSC::Heap::writeBarrierSlowPath):
1658         * heap/Heap.h:
1659         * heap/HeapInlines.h:
1660         (JSC::Heap::reportExtraMemoryVisited):
1661         (JSC::Heap::reportExternalMemoryVisited):
1662         * heap/SlotVisitor.cpp:
1663         (JSC::SlotVisitor::appendToMarkStack):
1664         (JSC::SlotVisitor::visitChildren):
1665         * heap/SlotVisitor.h:
1666         * heap/SlotVisitorInlines.h:
1667         (JSC::SlotVisitor::reportExtraMemoryVisited):
1668         (JSC::SlotVisitor::reportExternalMemoryVisited):
1669         * llint/LLIntData.cpp:
1670         (JSC::LLInt::Data::performAssertions):
1671         * llint/LowLevelInterpreter.asm:
1672
1673 2016-10-12  Mark Lam  <mark.lam@apple.com>
1674
1675         Rename variables in arrayProtoFuncSplice() to match names in the spec.
1676         https://bugs.webkit.org/show_bug.cgi?id=163354
1677
1678         Reviewed by Saam Barati.
1679
1680         This will make it easier to see whether the code matches the spec or not.
1681         Ref: https://tc39.github.io/ecma262/#sec-array.prototype.splice
1682
1683         * runtime/ArrayPrototype.cpp:
1684         (JSC::arrayProtoFuncSplice):
1685
1686 2016-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
1687
1688         [DOMJIT][JSC] Explore the way to embed nodeType into JSC::JSType in WebCore
1689         https://bugs.webkit.org/show_bug.cgi?id=163245
1690
1691         Reviewed by Filip Pizlo.
1692
1693         We reserve the highest bit of JSC::JSType for extensions outside JSC.
1694         JSC does not use JSType bits so many: only 52 types are defined.
1695
1696         And we extend CallDOM patchpoint to claim that it does not require a global object.
1697         This global object is used to generate a DOM wrapper. However, nodeType does not require
1698         it since it just returns integer. In the future, we will extend CallDOM to claim
1699         its result type. And we can decide this `requireGlobalObject` condition automatically
1700         according to the result type.
1701
1702         * JavaScriptCore.xcodeproj/project.pbxproj:
1703         * dfg/DFGByteCodeParser.cpp:
1704         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
1705         * dfg/DFGFixupPhase.cpp:
1706         (JSC::DFG::FixupPhase::fixupNode):
1707         * dfg/DFGGraph.h:
1708         * dfg/DFGNode.h:
1709         (JSC::DFG::Node::hasCheckDOMPatchpoint):
1710         (JSC::DFG::Node::checkDOMPatchpoint):
1711         (JSC::DFG::Node::hasCallDOMPatchpoint):
1712         (JSC::DFG::Node::callDOMPatchpoint):
1713         (JSC::DFG::Node::hasDOMJIT): Deleted.
1714         (JSC::DFG::Node::domJIT): Deleted.
1715         * dfg/DFGSpeculativeJIT.cpp:
1716         (JSC::DFG::SpeculativeJIT::compileCallDOM):
1717         (JSC::DFG::SpeculativeJIT::compileCheckDOM):
1718         * domjit/DOMJITCallDOMPatchpoint.h: Copied from Source/JavaScriptCore/domjit/DOMJITGetterSetter.h.
1719         (JSC::DOMJIT::CallDOMPatchpoint::create):
1720         * domjit/DOMJITGetterSetter.h:
1721         * domjit/DOMJITPatchpoint.h:
1722         * ftl/FTLLowerDFGToB3.cpp:
1723         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
1724         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
1725         * jsc.cpp:
1726         * llint/LLIntData.cpp:
1727         (JSC::LLInt::Data::performAssertions):
1728         * llint/LowLevelInterpreter.asm:
1729         * runtime/JSType.h:
1730
1731 2016-10-12  Keith Miller  <keith_miller@apple.com>
1732
1733         Handle non-function, non-undefined comparator in Array.prototype.sort
1734         https://bugs.webkit.org/show_bug.cgi?id=163085
1735
1736         Reviewed by Yusuke Suzuki.
1737
1738         * builtins/ArrayPrototype.js:
1739         (sort.comparatorSort):
1740         (sort.stringSort):
1741         (sort):
1742
1743 2016-10-12  Filip Pizlo  <fpizlo@apple.com>
1744
1745         REGRESSION (r207179): ASSERTION FAILED: node.cell != previousCell
1746         https://bugs.webkit.org/show_bug.cgi?id=163337
1747
1748         Reviewed by Mark Lam.
1749         
1750         It turns out that HeapSnapshot was not down with revisiting. The concurrent GC is going to be
1751         built around the idea that we can revisit objects many times. This means that any action that
1752         should only take place once per object must check the object's state. This fixes the snapshot
1753         code to do this.
1754         
1755         While writing this code, I realized that we're actually doing this check incorrectly, so I
1756         filed bug 163343. That bug requires a race, so we aren't going to see it yet.
1757
1758         * heap/HeapSnapshot.cpp:
1759         (JSC::HeapSnapshot::finalize):
1760         * heap/SlotVisitor.cpp:
1761         (JSC::SlotVisitor::appendToMarkStack):
1762         (JSC::SlotVisitor::visitChildren):
1763
1764 2016-10-12  Joseph Pecoraro  <pecoraro@apple.com>
1765
1766         Web Inspector: Improve support for logging Proxy objects in console
1767         https://bugs.webkit.org/show_bug.cgi?id=163323
1768         <rdar://problem/28432553>
1769
1770         Reviewed by Timothy Hatcher.
1771
1772         This is based off of similiar patches in Blink for Proxy handling.
1773
1774         * bindings/ScriptValue.cpp:
1775         (Deprecated::ScriptValue::isEqual):
1776         Use strict equality. This is the intent, and it prevents the possibility of triggering
1777         primitive conversion on objects in previous ConsoleMessage argument lists.
1778
1779         * inspector/InjectedScriptSource.js:
1780         (InjectedScript.prototype._propertyDescriptors):
1781         Bail if the object is a Proxy.
1782
1783         (InjectedScript.prototype._describe):
1784         Provide a friendlier name, "Proxy" instead of "ProxyObject".
1785         
1786         (InjectedScript.RemoteObject):
1787         When generating a preview for a Proxy object, generate it from the final target
1788         and mark it as lossy so that the object can always be expanded to get the internal
1789         target/handler properties.
1790
1791         * inspector/JSInjectedScriptHost.h:
1792         * inspector/JSInjectedScriptHost.cpp:
1793         (Inspector::JSInjectedScriptHost::subtype):
1794         New subtype for Proxy objects.
1795
1796         (Inspector::JSInjectedScriptHost::proxyTargetValue):
1797         Resolve the final target value for a Proxy.
1798
1799         * inspector/JSInjectedScriptHostPrototype.cpp:
1800         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
1801         (Inspector::jsInjectedScriptHostPrototypeFunctionProxyTargetValue):
1802         Add the new method.
1803
1804         * inspector/ScriptArguments.cpp:
1805         (Inspector::ScriptArguments::getFirstArgumentAsString):
1806         Avoid triggering Proxy traps on a Proxy object when getting a quick
1807         string description for ConsoleMessages.
1808
1809         * inspector/protocol/Runtime.json:
1810         Add new "proxy" subtype.
1811
1812 2016-10-12  Joseph Pecoraro  <pecoraro@apple.com>
1813
1814         Emit DebugHooks uniformly with pause locations instead of having separate pause locations and op_debug emits
1815         https://bugs.webkit.org/show_bug.cgi?id=162809
1816
1817         Reviewed by Geoffrey Garen.
1818
1819         Change how BytecodeGeneration emits debug hooks to be more consistent.
1820         Previously most nodes individually generated their own debug hook
1821         and we asserted that it matched a breakpoint location identified
1822         by the parser. This could get out of sync, or nodes could forget to
1823         emit debug hooks expected by the parser.
1824         
1825         With this change, we always check and emit a debug hook for any
1826         node. The default behavior is for BytecodeGenerator::emitNode
1827         to emit the debug hook when emitting the node itself. This covers
1828         the majority of cases (statements).
1829
1830         There are a few exceptions where we continue to need to customize
1831         emitting debug hooks:
1832
1833             1. Nodes with emitBytecodeInConditionContext
1834                 - non-Expression nodes customize how they emit their children
1835                 - constants conditions may emit nothing, but we had recorded a breakpoint location so emit a debug hook
1836                 - always emit one debug hook in case we recorded a breakpoint location, but avoid emitting multiple
1837                   in nodes which may call up to the ExpressionNode::emitBytecodeInConditionContext base impl.
1838             2. Specialized Debug Hooks
1839                 - such as hooks for Program start/end, debugger statements, etc.
1840             3. Debug Hooks in for..of / for..in that don't correspond to re-emitting nodes
1841                 - such as pausing on the assignment expression inside these loops
1842
1843         The majority of nodes no longer have custom emits.
1844
1845         * bytecompiler/BytecodeGenerator.h:
1846         (JSC::BytecodeGenerator::emitNodeInTailPosition):
1847         (JSC::BytecodeGenerator::emitNodeInConditionContext):
1848         * bytecompiler/BytecodeGenerator.cpp:
1849         (JSC::BytecodeGenerator::emitDebugHook):
1850         (JSC::BytecodeGenerator::emitEnumeration):
1851         By default, when emitting a node check if we should also emit an op_debug for it.
1852         This default DebugHook is WillExecuteStatement, which is a normal pause point.
1853
1854         * bytecompiler/NodesCodegen.cpp:
1855         (JSC::ConstantNode::emitBytecodeInConditionContext):
1856         (JSC::LogicalNotNode::emitBytecodeInConditionContext):
1857         (JSC::BinaryOpNode::emitBytecodeInConditionContext):
1858         (JSC::LogicalOpNode::emitBytecodeInConditionContext):
1859         The parser would have generated a pause location for these conditions
1860         no matter what constant folding and re-writing these nodes may perform.
1861         So, when emitting these nodes in condition context check if they need
1862         emit their own debug hook.
1863
1864         (JSC::EmptyStatementNode::emitBytecode):
1865         (JSC::ExprStatementNode::emitBytecode):
1866         (JSC::DeclarationStatement::emitBytecode):
1867         (JSC::IfElseNode::emitBytecode):
1868         (JSC::DoWhileNode::emitBytecode):
1869         (JSC::WhileNode::emitBytecode):
1870         (JSC::ForNode::emitBytecode):
1871         (JSC::ContinueNode::emitBytecode):
1872         (JSC::BreakNode::emitBytecode):
1873         (JSC::ReturnNode::emitBytecode):
1874         (JSC::WithNode::emitBytecode):
1875         (JSC::SwitchNode::emitBytecode):
1876         (JSC::ThrowNode::emitBytecode):
1877         No longer need to custom emit debug hooks. The default emitNode will handle these.
1878
1879         (JSC::ForInNode::emitBytecode):
1880         Include extra debug hooks the user expects to return back to the assignment
1881         expression in the loop header before starting the body again. The same is done
1882         for for..of with emitEnumeration.
1883
1884         * parser/ASTBuilder.h:
1885         (JSC::ASTBuilder::createExportDefaultDeclaration):
1886         (JSC::ASTBuilder::createExportLocalDeclaration):
1887         These are no longer needed to fake-satisfy assertions. We never wanted to
1888         emit debug hooks for these inner statements because the export statement
1889         will already have the debug hooks.
1890
1891         (JSC::ASTBuilder::createForInLoop):
1892         (JSC::ASTBuilder::createForOfLoop):
1893         Include the correct location where the declaration starts.
1894
1895         (JSC::ASTBuilder::breakpointLocation):
1896         Simplify to a general implementation for Node.
1897
1898         * parser/SyntaxChecker.h:
1899         (JSC::SyntaxChecker::createForInLoop):
1900         (JSC::SyntaxChecker::createForOfLoop):
1901         Ignore the new extra parameter.
1902
1903         * parser/Nodes.h:
1904         (JSC::Node::needsDebugHook):
1905         (JSC::Node::setNeedsDebugHook):
1906         (JSC::ExpressionNode::needsDebugHook): Deleted.
1907         (JSC::ExpressionNode::setNeedsDebugHook): Deleted.
1908         (JSC::StatementNode::isEmptyStatement): Deleted.
1909         (JSC::StatementNode::needsDebugHook): Deleted.
1910         (JSC::StatementNode::setNeedsDebugHook): Deleted.
1911         Move debug hook logic into the base Node class.
1912
1913         (JSC::StatementNode::isDebuggerStatement):
1914         Provide a way to distinguish a debugger statement.
1915
1916         * parser/Parser.cpp:
1917         (JSC::Parser<LexerType>::parseForStatement):
1918         Provide the location before the declaration starts.
1919
1920 2016-10-12  Mark Lam  <mark.lam@apple.com>
1921
1922         Array.prototype.slice should not modify frozen objects.
1923         https://bugs.webkit.org/show_bug.cgi?id=163338
1924
1925         Reviewed by Filip Pizlo.
1926
1927         1. The ES6 spec for Array.prototype.slice
1928            (https://tc39.github.io/ecma262/#sec-array.prototype.slice) states that it uses
1929            the CreateDataPropertyOrThrow()
1930            (https://tc39.github.io/ecma262/#sec-createdatapropertyorthrow) to add items to
1931            the result array.  The spec for CreateDataPropertyOrThrow states:
1932
1933            "This abstract operation creates a property whose attributes are set to the
1934            same defaults used for properties created by the ECMAScript language assignment
1935            operator. Normally, the property will not already exist. If it does exist and
1936            is not configurable or if O is not extensible, [[DefineOwnProperty]] will
1937            return false causing this operation to throw a TypeError exception."
1938
1939         2. Array.prototype.slice also uses a Set function
1940            (https://tc39.github.io/ecma262/#sec-set-o-p-v-throw) to set the "length"
1941            property and passes true for the Throw argument.  Ultimately, it ends up
1942            calling the OrdinarySet function
1943            (https://tc39.github.io/ecma262/#sec-ordinaryset) that will fail if the
1944            property is not writable.  This failure should result in a TypeError being
1945            thrown in Set.
1946
1947            Since the properties of frozen objects are not extensible, not configurable,
1948            and not writeable, Array.prototype.slice should fail to write to the result
1949            array if it is frozen.
1950
1951         If the source array being sliced has 1 or more elements, (1) will take effect
1952         when we try to set the element in the non-writeable result obj.
1953         If the source array being sliced has 0 elements, we will not set any elements and
1954         (1) will not trigger.  Subsequently, (2) will take effect when we will try to
1955         set the length of the result obj.
1956
1957         * runtime/ArrayPrototype.cpp:
1958         (JSC::putLength):
1959         (JSC::setLength):
1960         (JSC::arrayProtoFuncSlice):
1961         (JSC::arrayProtoFuncSplice):
1962
1963 2016-10-12  Filip Pizlo  <fpizlo@apple.com>
1964
1965         Remove JITWriteBarrier.h
1966         https://bugs.webkit.org/show_bug.cgi?id=163334
1967
1968         Reviewed by Mark Lam.
1969         
1970         I guess that the idea of JITWriteBarrier was to make sure that if you slap some heap pointer
1971         bits into machine code, then you better execute a barrier on the code block. But it's a
1972         complicated piece of code, and I can never remember how it quite works. These days it looks
1973         vestigial, particularly since only the CallLinkInfo patchable callee immediate uses it. It's
1974         not really necessary to have something like this, since our convention is that any pointer
1975         stored in machine code must always be shadowed in the GC heap. I think that convention has
1976         won by overwhelming majority, so we should finally remove JITWriteBarrier.
1977         
1978         A practical outcome of this change is that it makes it easier to implement DirectCall ICs,
1979         which will have to store the callee in the CallLinkInfo but not in the machine code.
1980
1981         * JavaScriptCore.xcodeproj/project.pbxproj:
1982         * assembler/AbstractMacroAssembler.h:
1983         * bytecode/CallLinkInfo.cpp:
1984         (JSC::CallLinkInfo::setCallee):
1985         (JSC::CallLinkInfo::clearCallee):
1986         * bytecode/CallLinkInfo.h:
1987         (JSC::CallLinkInfo::setCallee): Deleted.
1988         (JSC::CallLinkInfo::clearCallee): Deleted.
1989         * heap/SlotVisitor.h:
1990         * jit/JITWriteBarrier.h: Removed.
1991
1992 2016-10-12  Csaba Osztrogonác  <ossy@webkit.org>
1993
1994         Unreviewed buildfix for GCC 4.9 after r207186.
1995         https://bugs.webkit.org/show_bug.cgi?id=163255
1996
1997         * runtime/HasOwnPropertyCache.h:
1998         (JSC::HasOwnPropertyCache::Entry::Entry):
1999
2000 2016-10-11  Saam Barati  <sbarati@apple.com>
2001
2002         HasOwnPropertyCache needs to ref the UniquedStringImpls it sees
2003         https://bugs.webkit.org/show_bug.cgi?id=163255
2004
2005         Reviewed by Geoffrey Garen.
2006
2007         The cache needs to be responsible for ensuring that things
2008         in the cache stay alive. Before, it wasn't doing this, and
2009         that was wrong.
2010
2011         * runtime/HasOwnPropertyCache.h:
2012         (JSC::HasOwnPropertyCache::Entry::operator=):
2013         (JSC::HasOwnPropertyCache::operator delete):
2014         (JSC::HasOwnPropertyCache::create):
2015         (JSC::HasOwnPropertyCache::get):
2016         (JSC::HasOwnPropertyCache::tryAdd):
2017         (JSC::HasOwnPropertyCache::clear):
2018         (JSC::HasOwnPropertyCache::zeroBuffer):
2019
2020 2016-10-06  Filip Pizlo  <fpizlo@apple.com>
2021
2022         MarkedBlock should know what objects are live during marking
2023         https://bugs.webkit.org/show_bug.cgi?id=162309
2024
2025         Reviewed by Geoffrey Garen.
2026         
2027         It used to be that we would forget which objects are live the moment we started collection.
2028         That's because the flip at the beginning clears all mark bits.
2029         
2030         But we already have a facility for tracking objects that are live-but-not-marked. It's called
2031         newlyAllocated. So, instead of clearing mark bits, we want to just transfer them to
2032         newlyAllocated. Then we want to clear all newlyAllocated after GC.
2033         
2034         This implements such an approach, along with a versioning optimization for newlyAllocated.
2035         Instead of walking the whole heap to clear newlyAllocated bits at the end of the GC, we bump
2036         the newlyAllocatedVersion, which causes MarkedBlock to treat newlyAllocated as if it was
2037         clear.
2038         
2039         We could have even avoided allocating newlyAllocated in most cases, since empirically most
2040         blocks are either completely empty or completely full. An earlier version of this patch did
2041         this, but it was not better than this patch. In fact, it seemed to actually be worse for PLT
2042         and membuster.
2043         
2044         To validate this change, we now run the conservative scan after the beginMarking flip. And it
2045         totally works!
2046         
2047         This is a huge step towards concurrent GC. It means that we ought to be able to run the
2048         allocator while marking. Since we already separately made it possible to run the barrier
2049         while marking, this means that we're pretty much ready for some serious concurrency action.
2050         
2051         This appears to be perf-neutral and space-neutral.
2052
2053         * JavaScriptCore.xcodeproj/project.pbxproj:
2054         * bytecode/CodeBlock.cpp:
2055         * bytecode/CodeBlock.h:
2056         (JSC::CodeBlockSet::mark): Deleted.
2057         * heap/CodeBlockSet.cpp:
2058         (JSC::CodeBlockSet::writeBarrierCurrentlyExecuting):
2059         (JSC::CodeBlockSet::clearCurrentlyExecuting):
2060         (JSC::CodeBlockSet::writeBarrierCurrentlyExecutingCodeBlocks): Deleted.
2061         * heap/CodeBlockSet.h:
2062         * heap/CodeBlockSetInlines.h: Added.
2063         (JSC::CodeBlockSet::mark):
2064         * heap/ConservativeRoots.cpp:
2065         * heap/Heap.cpp:
2066         (JSC::Heap::markRoots):
2067         (JSC::Heap::beginMarking):
2068         (JSC::Heap::collectImpl):
2069         (JSC::Heap::writeBarrierCurrentlyExecutingCodeBlocks):
2070         (JSC::Heap::clearCurrentlyExecutingCodeBlocks):
2071         * heap/Heap.h:
2072         * heap/HeapUtil.h:
2073         (JSC::HeapUtil::findGCObjectPointersForMarking):
2074         * heap/MarkedAllocator.cpp:
2075         (JSC::MarkedAllocator::isPagedOut):
2076         * heap/MarkedBlock.cpp:
2077         (JSC::MarkedBlock::Handle::Handle):
2078         (JSC::MarkedBlock::Handle::sweepHelperSelectHasNewlyAllocated):
2079         (JSC::MarkedBlock::Handle::stopAllocating):
2080         (JSC::MarkedBlock::Handle::lastChanceToFinalize):
2081         (JSC::MarkedBlock::Handle::resumeAllocating):
2082         (JSC::MarkedBlock::aboutToMarkSlow):
2083         (JSC::MarkedBlock::Handle::resetAllocated):
2084         (JSC::MarkedBlock::resetMarks):
2085         (JSC::MarkedBlock::setNeedsDestruction):
2086         (JSC::MarkedBlock::Handle::didAddToAllocator):
2087         (JSC::MarkedBlock::Handle::isLive):
2088         (JSC::MarkedBlock::Handle::isLiveCell):
2089         (JSC::MarkedBlock::clearMarks): Deleted.
2090         * heap/MarkedBlock.h:
2091         (JSC::MarkedBlock::Handle::newlyAllocatedVersion):
2092         (JSC::MarkedBlock::Handle::hasAnyNewlyAllocated): Deleted.
2093         (JSC::MarkedBlock::Handle::clearNewlyAllocated): Deleted.
2094         * heap/MarkedBlockInlines.h:
2095         (JSC::MarkedBlock::Handle::cellsPerBlock):
2096         (JSC::MarkedBlock::Handle::isLive):
2097         (JSC::MarkedBlock::Handle::isLiveCell):
2098         (JSC::MarkedBlock::Handle::isNewlyAllocatedStale):
2099         (JSC::MarkedBlock::Handle::hasAnyNewlyAllocatedWithSweep):
2100         (JSC::MarkedBlock::Handle::hasAnyNewlyAllocated):
2101         (JSC::MarkedBlock::heap):
2102         (JSC::MarkedBlock::space):
2103         (JSC::MarkedBlock::Handle::space):
2104         (JSC::MarkedBlock::resetMarkingVersion): Deleted.
2105         * heap/MarkedSpace.cpp:
2106         (JSC::MarkedSpace::beginMarking):
2107         (JSC::MarkedSpace::endMarking):
2108         (JSC::MarkedSpace::clearNewlyAllocated): Deleted.
2109         * heap/MarkedSpace.h:
2110         (JSC::MarkedSpace::nextVersion):
2111         (JSC::MarkedSpace::newlyAllocatedVersion):
2112         (JSC::MarkedSpace::markingVersion): Deleted.
2113         * runtime/SamplingProfiler.cpp:
2114
2115 2016-10-11  Mark Lam  <mark.lam@apple.com>
2116
2117         Array.prototype.concat should not modify frozen objects.
2118         https://bugs.webkit.org/show_bug.cgi?id=163302
2119
2120         Reviewed by Filip Pizlo.
2121
2122         The ES6 spec for Array.prototype.concat states that it uses the
2123         CreateDataPropertyOrThrow() to add items to the result array.  The spec for
2124         CreateDataPropertyOrThrow states:
2125
2126         "This abstract operation creates a property whose attributes are set to the same
2127         defaults used for properties created by the ECMAScript language assignment
2128         operator. Normally, the property will not already exist. If it does exist and is
2129         not configurable or if O is not extensible, [[DefineOwnProperty]] will return
2130         false causing this operation to throw a TypeError exception."
2131
2132         Since the properties of frozen objects are not extensible, not configurable, and
2133         not writable, Array.prototype.concat should fail to write to the result array if
2134         it is frozen.
2135
2136         Ref: https://tc39.github.io/ecma262/#sec-array.prototype.concat,
2137         https://tc39.github.io/ecma262/#sec-createdatapropertyorthrow, and
2138         https://tc39.github.io/ecma262/#sec-createdataproperty.
2139
2140         The fix consists of 2 parts:
2141         1. moveElement() should use the PutDirectIndexShouldThrow mode when invoking
2142            putDirectIndex(), and
2143         2. SparseArrayValueMap::putDirect() should check for the case where the property
2144            is read only.
2145
2146         (2) ensures that we don't write into a non-writable property.
2147         (1) ensures that we throw a TypeError for attempts to write to a non-writeable
2148         property.
2149
2150         * runtime/ArrayPrototype.cpp:
2151         (JSC::moveElements):
2152         * runtime/SparseArrayValueMap.cpp:
2153         (JSC::SparseArrayValueMap::putDirect):
2154
2155 2016-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2156
2157         [DOMJIT] DOMJIT::Patchpoint should have a way to receive constant folded arguments
2158         https://bugs.webkit.org/show_bug.cgi?id=163224
2159
2160         Reviewed by Filip Pizlo.
2161
2162         We use the GetGlobalObject DFG node to retrieve a global object from a DOM node.
2163         This global object is necessary to check whether the world is normal before entering
2164         the fast path of looking up the DOM wrapper cache.
2165         We can sometimes constant-fold this GetGlobalObject. For example, if we performed
2166         CheckStructure, the structure can offer the information about the possible result
2167         of GetGlobalObject. By using this constant-folded global object, we can drop some
2168         checks.
2169
2170         This patch introduces the way to tell the constant-folded values to DOMJIT::Patchpoint.
2171         We pass DOMJIT::Value instead of DOMJIT::Reg as a parameter of DOMJIT::PatchpointParams.
2172         This DOMJIT::Value is a pair of DOMJIT::Reg and JSValue. If the given parameter has a
2173         constant value, this JSValue is filled with it.
2174
2175         * JavaScriptCore.xcodeproj/project.pbxproj:
2176         * dfg/DFGDOMJITPatchpointParams.h:
2177         (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
2178         * dfg/DFGSpeculativeJIT.cpp:
2179         (JSC::DFG::SpeculativeJIT::compileCallDOM):
2180         (JSC::DFG::SpeculativeJIT::compileCheckDOM):
2181         * domjit/DOMJITPatchpointParams.h:
2182         (JSC::DOMJIT::PatchpointParams::at):
2183         (JSC::DOMJIT::PatchpointParams::operator[]):
2184         (JSC::DOMJIT::PatchpointParams::PatchpointParams):
2185         * domjit/DOMJITValue.h: Copied from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.h.
2186         (JSC::DOMJIT::Value::Value):
2187         (JSC::DOMJIT::Value::isGPR):
2188         (JSC::DOMJIT::Value::isFPR):
2189         (JSC::DOMJIT::Value::isJSValueRegs):
2190         (JSC::DOMJIT::Value::gpr):
2191         (JSC::DOMJIT::Value::fpr):
2192         (JSC::DOMJIT::Value::jsValueRegs):
2193         (JSC::DOMJIT::Value::reg):
2194         (JSC::DOMJIT::Value::value):
2195         * ftl/FTLDOMJITPatchpointParams.h:
2196         (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
2197         * ftl/FTLLowerDFGToB3.cpp:
2198         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
2199         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
2200
2201 2016-10-10  Filip Pizlo  <fpizlo@apple.com>
2202
2203         Air should be able to replace constant materializations with adds
2204         https://bugs.webkit.org/show_bug.cgi?id=162749
2205
2206         Reviewed by Yusuke Suzuki.
2207         
2208         We have a lot of defenses against emitting code that materializes huge contants. But if we do
2209         end up with such code in the backend, it's better to convert those materializations into add
2210         instructions by checking if other registers are known to contain nearby constants. That's
2211         what this patch does.
2212
2213         * b3/air/AirFixObviousSpills.cpp:
2214         * b3/testb3.cpp:
2215
2216 2016-10-11  Filip Pizlo  <fpizlo@apple.com>
2217
2218         B3->Air lowering needs the same defenses in effectiveAddr() that it has in tryAppendLea()
2219         https://bugs.webkit.org/show_bug.cgi?id=163264
2220
2221         Reviewed by Mark Lam.
2222         
2223         When writing the lea patch (r207039), I was very careful about how I convert a Shl into a
2224         BaseIndex scale. But I forgot to check if the older code for creating BaseIndexes for
2225         effectiveAddr() got this right. It turns out that the older code missed the <<32 corner
2226         case.
2227         
2228         It's sad that the two paths can't share all of their code, but it's somewhat inevitable due
2229         to how matching an address and matching a lea have to do very different things. Matching a
2230         lea means creating an instruction that is distinct from other instructions to do multiple
2231         math operations at once. Matching an address means making some instruction do extra work
2232         for free. Also, address matching can take advantage of the fact that the offset is already
2233         associated with the memory operation by strength reduction - lea matching can't do this; it
2234         has to figure out Add(@value, $const) on its own. This change makes the situation slightly
2235         more sane by adding a scaleForShl() helper that handles this weird case. It's based on the
2236         new Shl handling from r207039, and exposes it as an API for effectiveAddr() to use.
2237         
2238         The testLoadBaseIndexShift32() used to crash. I don't think that this case affects JS
2239         content, since <<32 is such a bizarre outlier. I don't think we even have a path along
2240         which the FTL would emit a 64-bit <<32. It probably won't even affect WebAssembly since
2241         that uses 32-bit pointers, so we won't see 64-bit <<32 in effectiveAddr() there.
2242
2243         * b3/B3LowerToAir.cpp:
2244         (JSC::B3::Air::LowerToAir::scaleForShl):
2245         (JSC::B3::Air::LowerToAir::effectiveAddr):
2246         (JSC::B3::Air::LowerToAir::tryAppendLea):
2247         (JSC::B3::Air::LowerToAir::crossesInterference): Deleted.
2248         * b3/testb3.cpp:
2249         (JSC::B3::testLoadBaseIndexShift2):
2250         (JSC::B3::testLoadBaseIndexShift32):
2251         (JSC::B3::run):
2252
2253 2016-10-11  Saam Barati  <sbarati@apple.com>
2254
2255         ValueAdd should be constant folded if the operands are constant String,Primitive or Primitive,String
2256         https://bugs.webkit.org/show_bug.cgi?id=163182
2257
2258         Reviewed by Filip Pizlo.
2259
2260         This code pattern shows up in Dromaeo, so it's worth optimizing for.
2261         This might also show up in real world JS code due to inlining and other
2262         types of constant folding.
2263
2264         * dfg/DFGByteCodeParser.cpp:
2265         (JSC::DFG::ByteCodeParser::parseBlock):
2266         * dfg/DFGLazyJSValue.cpp:
2267         (JSC::DFG::LazyJSValue::getValue):
2268         * dfg/DFGStrengthReductionPhase.cpp:
2269         (JSC::DFG::StrengthReductionPhase::handleNode):
2270
2271 2016-10-10  Zan Dobersek  <zdobersek@igalia.com>
2272
2273         Add ENABLE_ENCRYPTED_MEDIA configuration option
2274         https://bugs.webkit.org/show_bug.cgi?id=163219
2275
2276         Reviewed by Darin Adler.
2277
2278         * Configurations/FeatureDefines.xcconfig:
2279         Add the ENABLE_ENCRYPTED_MEDIA configuration option. It will be used
2280         to enable or disable the new EME implementation at build-time.
2281
2282 2016-10-10  Filip Pizlo  <fpizlo@apple.com>
2283
2284         B3->Air lowering should be able to emit complex leas on x86
2285         https://bugs.webkit.org/show_bug.cgi?id=163234
2286
2287         Reviewed by Saam Barati.
2288         
2289         This adds comprehensive support for emitting lea on x86.
2290         
2291         When adding this, I found that it was useful to also finally add more reassociation. That
2292         reduces the amount of patterns that the instruction selector has to deal with.
2293
2294         * assembler/MacroAssembler.h:
2295         (JSC::MacroAssembler::lea32):
2296         (JSC::MacroAssembler::lea64):
2297         (JSC::MacroAssembler::lea): Deleted.
2298         * b3/B3LowerToAir.cpp:
2299         (JSC::B3::Air::LowerToAir::commitInternal):
2300         (JSC::B3::Air::LowerToAir::tryAppendLea):
2301         (JSC::B3::Air::LowerToAir::lower):
2302         (JSC::B3::Air::LowerToAir::createSelect): Deleted.
2303         * b3/B3ReduceStrength.cpp:
2304         * b3/B3Value.h:
2305         * b3/B3ValueInlines.h:
2306         (JSC::B3::Value::isRepresentableAs):
2307         (JSC::B3::Value::representableAs): Deleted.
2308         * b3/air/AirOpcode.opcodes:
2309         * b3/testb3.cpp: Lots of tests for lea and reassociation.
2310
2311 2016-10-10  Mark Lam  <mark.lam@apple.com>
2312
2313         Change ArrayPrototype.cpp's putLength() and setLength() to take a VM& so that we can use vm.propertyNames.
2314         https://bugs.webkit.org/show_bug.cgi?id=163260
2315
2316         Reviewed by Saam Barati.
2317
2318         In all cases where we call these, we already have the VM& anyway.
2319
2320         * runtime/ArrayPrototype.cpp:
2321         (JSC::putLength):
2322         (JSC::setLength):
2323         (JSC::arrayProtoFuncPop):
2324         (JSC::arrayProtoFuncPush):
2325         (JSC::arrayProtoFuncShift):
2326         (JSC::arrayProtoFuncSlice):
2327         (JSC::arrayProtoFuncSplice):
2328         (JSC::arrayProtoFuncUnShift):
2329
2330 2016-10-10  Mark Lam  <mark.lam@apple.com>
2331
2332         Rename the StrictModeReadonlyPropertyWriteError string to ReadonlyPropertyWriteError.
2333         https://bugs.webkit.org/show_bug.cgi?id=163239
2334
2335         Reviewed by Filip Pizlo.
2336
2337         This string is also used for reporting the same error in cases which have nothing
2338         to do with strict mode.
2339
2340         * bytecompiler/BytecodeGenerator.cpp:
2341         (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
2342         * runtime/CommonSlowPaths.cpp:
2343         (JSC::SLOW_PATH_DECL):
2344         * runtime/GetterSetter.cpp:
2345         (JSC::callSetter):
2346         * runtime/JSArray.cpp:
2347         (JSC::JSArray::setLengthWithArrayStorage):
2348         (JSC::JSArray::pop):
2349         * runtime/JSCJSValue.cpp:
2350         (JSC::JSValue::putToPrimitive):
2351         (JSC::JSValue::putToPrimitiveByIndex):
2352         * runtime/JSFunction.cpp:
2353         (JSC::JSFunction::put):
2354         * runtime/JSModuleEnvironment.cpp:
2355         (JSC::JSModuleEnvironment::put):
2356         * runtime/JSModuleNamespaceObject.cpp:
2357         (JSC::JSModuleNamespaceObject::put):
2358         (JSC::JSModuleNamespaceObject::putByIndex):
2359         * runtime/JSObject.cpp:
2360         (JSC::ordinarySetSlow):
2361         (JSC::JSObject::putInlineSlow):
2362         (JSC::JSObject::setPrototypeWithCycleCheck):
2363         (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
2364         (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
2365         * runtime/JSObject.h:
2366         * runtime/JSObjectInlines.h:
2367         (JSC::JSObject::putInline):
2368         * runtime/JSSymbolTableObject.h:
2369         (JSC::symbolTablePut):
2370         * runtime/Lookup.h:
2371         (JSC::putEntry):
2372         * runtime/RegExpObject.h:
2373         (JSC::RegExpObject::setLastIndex):
2374         * runtime/SparseArrayValueMap.cpp:
2375         (JSC::SparseArrayValueMap::putEntry):
2376         (JSC::SparseArrayEntry::put):
2377         * runtime/StringObject.cpp:
2378         (JSC::StringObject::put):
2379         (JSC::StringObject::putByIndex):
2380
2381 2016-10-10  Saam Barati  <sbarati@apple.com>
2382
2383         compileCheckStringIdent in the FTL is wrong
2384         https://bugs.webkit.org/show_bug.cgi?id=163215
2385
2386         Reviewed by Mark Lam and Filip Pizlo.
2387
2388         lowStringIdent() returns the StringImpl pointer. The compileCheckStringIdent()
2389         was treating its return value as the actual JSString. This is wrong.
2390
2391         * ftl/FTLLowerDFGToB3.cpp:
2392         (JSC::FTL::DFG::LowerDFGToB3::compileCheckStringIdent):
2393
2394 2016-10-10  Yusuke Suzuki  <utatane.tea@gmail.com>
2395
2396         [DOMJIT] Implement Node accessors in DOMJIT
2397         https://bugs.webkit.org/show_bug.cgi?id=163005
2398
2399         Reviewed by Filip Pizlo.
2400
2401         Add some helper methods and offsetOfXXX for JSC::Weak since it is used
2402         for DOM wrapper caching.
2403
2404         And make DOMJIT::Patchpoint in FTL closer to one in DFG. We add resultConstraint
2405         to avoid the situation that the same register is allocated to child and result.
2406
2407         We also extend DOMJIT::Patchpoint to tell useTagTypeNumberRegister / useTagMaskRegister.
2408
2409         * dfg/DFGSpeculativeJIT.h:
2410         (JSC::DFG::SpeculativeJIT::callOperation):
2411         * domjit/DOMJITSlowPathCalls.h:
2412         * ftl/FTLLowerDFGToB3.cpp:
2413         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
2414         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
2415         * heap/WeakImpl.h:
2416         (JSC::WeakImpl::offsetOfJSValue):
2417         (JSC::WeakImpl::offsetOfWeakHandleOwner):
2418         * jit/AssemblyHelpers.h:
2419         (JSC::AssemblyHelpers::boxCell):
2420         (JSC::AssemblyHelpers::boxInt32): Deleted.
2421         * jit/JITOperations.h:
2422
2423 2016-10-09  Filip Pizlo  <fpizlo@apple.com>
2424
2425         Air should expose API for pinning registers
2426         https://bugs.webkit.org/show_bug.cgi?id=163175
2427
2428         Reviewed by Keith Miller.
2429         
2430         You can now call Procedure::pinRegister(), or Code::pinRegister(), and it will make this
2431         register behave as follows:
2432         
2433         - B3 and Air will emit no code that modifies the value in this register, except if that
2434           happens via a Patchpoint or stackmap constraint (i.e. the user explicitly asked for it).
2435         - B3 and Air will allow others to modify the register. For example, if the register is not
2436           callee-save, then the compiler knows that the register's value will be trashed by any
2437           C-style call.
2438         - Air will be happy to emit code that reads from this register, including coalescing tmps
2439           with it, so longer as there is no interference (i.e. no chance of the register's value
2440           changing). For example, if we went back to having pinned tag registers, we would tell B3
2441           to use them by (1) excluding them from any clobber set (easy, since they're callee save)
2442           and (2) emitting ArgumentReg to grab their value. There's a test that does this.
2443         
2444         This is accomplished by taking regsInPriorityOrder() and making it a method of Code. Air 
2445         already used this API when choosing registers in register allocation. Code now also vends a
2446         mutableRegs() set, which is derived from regsInPriorityOrder(), that can quickly tell you if
2447         a register can be mutated. Doing it this way means that most of this is a purely mechanical
2448         change. The calls to mutableRegs() are the places where we had to change logic:
2449         
2450         - The register allocators needs to know that coalescing with a precolored pinned tmp is free.
2451         - The callee-save handler needs to know that we're not supposed to save/restore pinned
2452           registers.
2453         
2454         Note that in this scheme, pinned registers are simply registers that do not appear in
2455         regsInPriorityOrder(). This means, for example, that we will now say that FP is pinned. So,
2456         this means that you can also pin registers by calling setRegsInPriorityOrder() and passing a
2457         vector that excludes some registers. More generally, this means that clients can now tweak
2458         the register allocator's register preferences, since the ordering in that list reflects the
2459         order in which the allocator will try registers.
2460
2461         * CMakeLists.txt:
2462         * JavaScriptCore.xcodeproj/project.pbxproj:
2463         * b3/B3Procedure.cpp:
2464         (JSC::B3::Procedure::pinRegister):
2465         * b3/B3Procedure.h:
2466         * b3/air/AirCode.cpp:
2467         (JSC::B3::Air::Code::Code):
2468         (JSC::B3::Air::Code::setRegsInPriorityOrder):
2469         (JSC::B3::Air::Code::pinRegister):
2470         * b3/air/AirCode.h:
2471         (JSC::B3::Air::Code::regsInPriorityOrder):
2472         (JSC::B3::Air::Code::mutableRegs):
2473         (JSC::B3::Air::Code::isPinned):
2474         (JSC::B3::Air::Code::regsInPriorityOrderImpl):
2475         (JSC::B3::Air::Code::proc): Deleted.
2476         * b3/air/AirEmitShuffle.cpp:
2477         (JSC::B3::Air::emitShuffle):
2478         * b3/air/AirEmitShuffle.h:
2479         * b3/air/AirHandleCalleeSaves.cpp:
2480         (JSC::B3::Air::handleCalleeSaves):
2481         * b3/air/AirIteratedRegisterCoalescing.cpp:
2482         * b3/air/AirLowerAfterRegAlloc.cpp:
2483         (JSC::B3::Air::lowerAfterRegAlloc):
2484         * b3/air/AirRegisterPriority.cpp: Removed.
2485         * b3/air/AirRegisterPriority.h: Removed.
2486         * b3/air/AirSpillEverything.cpp:
2487         (JSC::B3::Air::spillEverything):
2488         * b3/air/testair.cpp:
2489         (JSC::B3::Air::testShuffleBroadcastAllRegs):
2490         (JSC::B3::Air::testShuffleShiftAllRegs):
2491         (JSC::B3::Air::testShuffleRotateAllRegs):
2492         (JSC::B3::Air::testShuffleShiftMemoryAllRegs):
2493         (JSC::B3::Air::testShuffleShiftMemoryAllRegs64):
2494         (JSC::B3::Air::testShuffleShiftMemoryAllRegsMixedWidth):
2495         (JSC::B3::Air::testShuffleRotateMemoryAllRegs64):
2496         (JSC::B3::Air::testShuffleRotateMemoryAllRegsMixedWidth):
2497         * b3/testb3.cpp:
2498         (JSC::B3::testPinRegisters):
2499         (JSC::B3::run):
2500         * jit/RegisterSet.h:
2501
2502 2016-10-08  Filip Pizlo  <fpizlo@apple.com>
2503
2504         B3 should know about mutable pinned registers
2505         https://bugs.webkit.org/show_bug.cgi?id=163172
2506
2507         Reviewed by Keith Miller.
2508         
2509         If we have mutable pinned registers then we need to know which operations mutate them. At
2510         first I considered making this into a heap range thing, but I think that this would be very
2511         confusing. Also, in the future, we might want to make Effects track register sets of
2512         clobbered registers (see bug 163173).
2513
2514         * b3/B3Effects.cpp:
2515         (JSC::B3::Effects::interferes):
2516         (JSC::B3::Effects::operator==):
2517         (JSC::B3::Effects::dump):
2518         * b3/B3Effects.h:
2519         (JSC::B3::Effects::forCall):
2520         (JSC::B3::Effects::mustExecute):
2521
2522 2016-10-08  Saam Barati  <sbarati@apple.com>
2523
2524         HasIndexedProperty clobberize rule is wrong for Array::ForceOSRExit
2525         https://bugs.webkit.org/show_bug.cgi?id=159942
2526         <rdar://problem/27328836>
2527
2528         Reviewed by Filip Pizlo.
2529
2530         When HasIndexedProperty has a ForceOSRExit array mode, it should
2531         report to write to side state, like the ForceOSRExit node, and the
2532         other nodes with ForceOSRExit array mode.
2533
2534         * dfg/DFGClobberize.h:
2535         (JSC::DFG::clobberize):
2536
2537 2016-10-07  Mark Lam  <mark.lam@apple.com>
2538
2539         Object.freeze() and seal() should throw if [[PreventExtensions]]() fails.
2540         https://bugs.webkit.org/show_bug.cgi?id=163160
2541
2542         Reviewed by Saam Barati.
2543
2544         See https://tc39.github.io/ecma262/#sec-object.freeze,
2545         https://tc39.github.io/ecma262/#sec-object.seal, and
2546         https://tc39.github.io/ecma262/#sec-setintegritylevel.  We need to call
2547         preventExtensions first before proceeding to freeze / seal the object.  If
2548         preventExtensions fails, we should throw a TypeError.
2549
2550         * runtime/ObjectConstructor.cpp:
2551         (JSC::setIntegrityLevel):
2552         (JSC::objectConstructorSeal):
2553         (JSC::objectConstructorFreeze):
2554
2555 2016-10-06  Yusuke Suzuki  <utatane.tea@gmail.com>
2556
2557         [DOMJIT] Support slow path call
2558         https://bugs.webkit.org/show_bug.cgi?id=162978
2559
2560         Reviewed by Saam Barati.
2561
2562         One of the most important features required in DOMJIT::Patchpoint is slow path calls.
2563         DOM operation typically returns DOMWrapper object. At that time, if wrapper cache hits, we can go
2564         to the fast path. However, if we cannot use the cache, we need to go to the slow path to call toJS function.
2565         At that time, slow path call functionality is necessary.
2566
2567         This patch expose DOMJIT::PatchpointParams::addSlowPathCall. We can request slow path call code generation
2568         through this interface. DOMJIT::PatchpointParams automatically leverages appropriate slow path call systems
2569         in each tier. In DFG, we use slow path call system. In FTL, we implement slow path call by using addLatePath
2570         to construct slow path call. But these details are completely hidden by DOMJIT::PatchpointParams. Users can
2571         just use addSlowPathCall.
2572
2573         Since DFG and FTL slow path call systems are implemented in variadic templates, directly using this means
2574         that we need to expose core part of DFG and FTL. For example, DFG::SpeculativeJIT need to be exposed in
2575         such a design. That is too bad. Instead, we use magical macro in DOMJITSlowPathCalls.h. We can list up the
2576         call signatures in DOMJIT_SLOW_PATH_CALLS. DOMJIT uses these signatures to generate an interface to request
2577         slow path calls inside DFG and FTL instead of exposing everything.
2578
2579         * CMakeLists.txt:
2580         * JavaScriptCore.xcodeproj/project.pbxproj:
2581         * dfg/DFGCommon.h:
2582         * dfg/DFGDOMJITPatchpointParams.cpp: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
2583         (JSC::DFG::dispatch):
2584         * dfg/DFGDOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
2585         (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
2586         * dfg/DFGSpeculativeJIT.cpp:
2587         (JSC::DFG::SpeculativeJIT::compileCallDOM):
2588         (JSC::DFG::SpeculativeJIT::compileCheckDOM):
2589         * dfg/DFGSpeculativeJIT.h:
2590         (JSC::DFG::extractResult): Deleted.
2591         * domjit/DOMJITPatchpointParams.h:
2592         (JSC::DOMJIT::PatchpointParams::addSlowPathCall):
2593         * domjit/DOMJITSlowPathCalls.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
2594         * ftl/FTLDOMJITPatchpointParams.cpp: Added.
2595         (JSC::FTL::dispatch):
2596         * ftl/FTLDOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
2597         (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
2598         * ftl/FTLLowerDFGToB3.cpp:
2599         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
2600         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
2601         * jit/GPRInfo.h:
2602         (JSC::extractResult):
2603         * jsc.cpp:
2604
2605 2016-10-06  Saam Barati  <sbarati@apple.com>
2606
2607         HasOwnPropertyCache flattening dictionaries is causing insane memory usage with the uBlock Safari extension
2608         https://bugs.webkit.org/show_bug.cgi?id=163091
2609
2610         Reviewed by Mark Lam.
2611
2612         I'm investigating a real fix for this in:
2613         https://bugs.webkit.org/show_bug.cgi?id=163092
2614         However, it's best to get this out of trunk for now.
2615
2616         * runtime/HasOwnPropertyCache.h:
2617         (JSC::HasOwnPropertyCache::tryAdd):
2618
2619 2016-10-06  Keith Miller  <keith_miller@apple.com>
2620
2621         getInternalObjcObject should validate the JSManagedObject's value.
2622         https://bugs.webkit.org/show_bug.cgi?id=162985
2623
2624         Reviewed by Geoffrey Garen.
2625
2626         Previously, if, for instance, the JSManagedObject's weak value had been
2627         cleared we would call tryUnwrapObjcObject with a nil context and value.
2628         This triggered assertions failures as those functions expect their inputs
2629         to be valid.
2630
2631         * API/JSVirtualMachine.mm:
2632         (getInternalObjcObject):
2633
2634 2016-10-06  Brian Burg  <bburg@apple.com>
2635
2636         Web Inspector: RemoteInspector should cache client capabilities for off-main thread usage
2637         https://bugs.webkit.org/show_bug.cgi?id=163039
2638         <rdar://problem/28571460>
2639
2640         Reviewed by Timothy Hatcher.
2641
2642         The fix in r206797 was incorrect because listings are always pushed out on the XPC connection queue.
2643         Instead of delaying the listing needlessly, RemoteInspector should cache the capabilities of its
2644         client while on the main thread, then use the cached struct data on the XPC connection queue rather
2645         than directly accessing m_client. This is similar to how RemoteConnectionToTarget marshalls listing
2646         information from arbitrary queues into m_targetListingMap, which can then be read from any queue.
2647
2648         * inspector/remote/RemoteInspector.h:
2649         * inspector/remote/RemoteInspector.mm:
2650         (Inspector::RemoteInspector::updateClientCapabilities): Cache the capabilities.
2651         (Inspector::RemoteInspector::setRemoteInspectorClient):
2652         Re-cache the capabilities. Scope the lock to avoid reentrant locking.
2653
2654         (Inspector::RemoteInspector::clientCapabilitiesDidChange): Cache the capabilities.
2655         (Inspector::RemoteInspector::pushListingsNow): Use cached client capabilities.
2656         (Inspector::RemoteInspector::receivedGetListingMessage): Revert the change in r206797.
2657         (Inspector::RemoteInspector::receivedAutomationSessionRequestMessage):
2658
2659 2016-10-06  Yusuke Suzuki  <utatane.tea@gmail.com>
2660
2661         [WebCore][JSC] Use new @throwTypeError and @throwRangeError intrinsics
2662         https://bugs.webkit.org/show_bug.cgi?id=163001
2663
2664         Reviewed by Keith Miller.
2665
2666         Previously, the argument of @throwXXXError intrinsics must be string literal.
2667         But it is error-prone restriction. This patch relaxes the restriction to accept
2668         arbitrary values. To keep emitted bytecode small, if the argument is string literal,
2669         we generate the same bytecode as before. If the argument is not string literal,
2670         we evaluate it and perform to_string before passing to throw_static_error.
2671
2672         * bytecompiler/BytecodeGenerator.cpp:
2673         (JSC::BytecodeGenerator::emitThrowStaticError):
2674         * bytecompiler/BytecodeGenerator.h:
2675         * bytecompiler/NodesCodegen.cpp:
2676         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwTypeError):
2677         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwRangeError):
2678         * dfg/DFGByteCodeParser.cpp:
2679         (JSC::DFG::ByteCodeParser::parseBlock):
2680
2681 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
2682
2683         [JSC] Add @throwXXXError bytecode intrinsic
2684         https://bugs.webkit.org/show_bug.cgi?id=162995
2685
2686         Reviewed by Saam Barati.
2687
2688         Builtin JS code need to check arguments carefully since it is somewhat standard library for JS.
2689         So bunch of `throw new @TypeError("...")` exists while usual code does not have so many.
2690         However the above code bloats 32 instructions per site, enlarges the size of bytecodes of builtins,
2691         and prevent us from inlining. We should have a way to reduce this size.
2692
2693         Fortunately, we already have such a opcode: op_throw_static_error. In this patch,
2694         1. We extends op_throw_static_error to throw arbitrary errors. Previously, only TypeError and ReferenceError are allowed.
2695            We can embed ErrorType enum in op_throw_static_error to throw any types of errors.
2696         2. We introduce several new bytecode intrinsics, `@throwTypeError("...")`, `@throwRangeError("...")`,
2697            and `@throwOutOfMemoryError()`. And use it inside builtin JS instead of `throw new @TypeError("...")` thingy.
2698         3. DFG Node for throw_static_error is incorrectly named as "ThrowReferenceError". This patch renames it to "ThrowStaticError".
2699
2700         * builtins/ArrayConstructor.js:
2701         * builtins/ArrayIteratorPrototype.js:
2702         (next):
2703         * builtins/ArrayPrototype.js:
2704         (values):
2705         (keys):
2706         (entries):
2707         (reduce):
2708         (reduceRight):
2709         (every):
2710         (forEach):
2711         (filter):
2712         (map):
2713         (some):
2714         (fill):
2715         (find):
2716         (findIndex):
2717         (includes):
2718         (sort):
2719         (concatSlowPath):
2720         (copyWithin):
2721         * builtins/DatePrototype.js:
2722         (toLocaleString.toDateTimeOptionsAnyAll):
2723         (toLocaleString):
2724         (toLocaleDateString.toDateTimeOptionsDateDate):
2725         (toLocaleDateString):
2726         (toLocaleTimeString.toDateTimeOptionsTimeTime):
2727         (toLocaleTimeString):
2728         * builtins/FunctionPrototype.js:
2729         (bind):
2730         * builtins/GeneratorPrototype.js:
2731         (globalPrivate.generatorResume):
2732         * builtins/GlobalOperations.js:
2733         (globalPrivate.speciesConstructor):
2734         * builtins/MapPrototype.js:
2735         (forEach):
2736         * builtins/ModuleLoaderPrototype.js:
2737         (provide):
2738         * builtins/ObjectConstructor.js:
2739         (values):
2740         (entries):
2741         (assign):
2742         * builtins/PromiseConstructor.js:
2743         (race):
2744         (reject):
2745         (resolve):
2746         * builtins/PromiseOperations.js:
2747         (globalPrivate.newPromiseCapability.executor):
2748         (globalPrivate.newPromiseCapability):
2749         (globalPrivate.initializePromise):
2750         * builtins/PromisePrototype.js:
2751         * builtins/ReflectObject.js:
2752         (apply):
2753         (deleteProperty):
2754         (has):
2755         * builtins/RegExpPrototype.js:
2756         (globalPrivate.regExpExec):
2757         (match):
2758         (replace):
2759         (search):
2760         (split):
2761         (intrinsic.RegExpTestIntrinsic.test):
2762         * builtins/SetPrototype.js:
2763         (forEach):
2764         * builtins/StringConstructor.js:
2765         (raw):
2766         * builtins/StringIteratorPrototype.js:
2767         (next):
2768         * builtins/StringPrototype.js:
2769         (match):
2770         (globalPrivate.repeatSlowPath):
2771         (repeat):
2772         (padStart):
2773         (padEnd):
2774         (intrinsic.StringPrototypeReplaceIntrinsic.replace):
2775         (localeCompare):
2776         (search):
2777         (split):
2778         * builtins/TypedArrayConstructor.js:
2779         (of):
2780         (from):
2781         * builtins/TypedArrayPrototype.js:
2782         (globalPrivate.typedArraySpeciesConstructor):
2783         (every):
2784         (find):
2785         (findIndex):
2786         (forEach):
2787         (some):
2788         (subarray):
2789         (reduce):
2790         (reduceRight):
2791         (map):
2792         (filter):
2793         * bytecode/BytecodeIntrinsicRegistry.h:
2794         * bytecode/CodeBlock.cpp:
2795         (JSC::CodeBlock::dumpBytecode):
2796         * bytecompiler/BytecodeGenerator.cpp:
2797         (JSC::BytecodeGenerator::emitThrowStaticError):
2798         (JSC::BytecodeGenerator::emitThrowReferenceError):
2799         (JSC::BytecodeGenerator::emitThrowTypeError):
2800         (JSC::BytecodeGenerator::emitThrowRangeError):
2801         (JSC::BytecodeGenerator::emitThrowOutOfMemoryError):
2802         (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
2803         * bytecompiler/BytecodeGenerator.h:
2804         * bytecompiler/NodesCodegen.cpp:
2805         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwTypeError):
2806         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwRangeError):
2807         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwOutOfMemoryError):
2808         * dfg/DFGAbstractInterpreterInlines.h:
2809         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2810         * dfg/DFGByteCodeParser.cpp:
2811         (JSC::DFG::ByteCodeParser::parseBlock):
2812         * dfg/DFGClobberize.h:
2813         (JSC::DFG::clobberize):
2814         * dfg/DFGDoesGC.cpp:
2815         (JSC::DFG::doesGC):
2816         * dfg/DFGFixupPhase.cpp:
2817         (JSC::DFG::FixupPhase::fixupNode):
2818         * dfg/DFGNodeType.h:
2819         * dfg/DFGPredictionPropagationPhase.cpp:
2820         * dfg/DFGSafeToExecute.h:
2821         (JSC::DFG::safeToExecute):
2822         * dfg/DFGSpeculativeJIT32_64.cpp:
2823         (JSC::DFG::SpeculativeJIT::compile):
2824         * dfg/DFGSpeculativeJIT64.cpp:
2825         (JSC::DFG::SpeculativeJIT::compile):
2826         * ftl/FTLCapabilities.cpp:
2827         (JSC::FTL::canCompile):
2828         * ftl/FTLLowerDFGToB3.cpp:
2829         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2830         * jit/JITOpcodes.cpp:
2831         (JSC::JIT::emit_op_throw_static_error):
2832         * jit/JITOpcodes32_64.cpp:
2833         (JSC::JIT::emit_op_throw_static_error): Deleted.
2834         * jit/JITOperations.cpp:
2835         * jit/JITOperations.h:
2836         * llint/LLIntSlowPaths.cpp:
2837         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
2838         * llint/LLIntSlowPaths.h:
2839         * llint/LowLevelInterpreter.asm:
2840         * runtime/CommonSlowPaths.cpp:
2841         (JSC::SLOW_PATH_DECL):
2842         * runtime/CommonSlowPaths.h:
2843         * runtime/Error.cpp:
2844         (JSC::createError):
2845         (WTF::printInternal):
2846         * runtime/Error.h:
2847
2848 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
2849
2850         Unreviewed, attempt to fix CLoop build after r206846
2851         https://bugs.webkit.org/show_bug.cgi?id=162941
2852
2853         Attempt to fix CLoop build part 2. r206847 was not valid.
2854
2855         * jsc.cpp:
2856
2857 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
2858
2859         Unreviewed, build fix after r206846
2860         https://bugs.webkit.org/show_bug.cgi?id=162941
2861
2862         DOMJIT::Patchpoint part should be guarded by ENABLE(JIT).
2863
2864         * jsc.cpp:
2865
2866 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
2867
2868         [DOMJIT] Add initial CheckDOM and CallDOM implementations
2869         https://bugs.webkit.org/show_bug.cgi?id=162941
2870
2871         Reviewed by Filip Pizlo.
2872
2873         This patch implements a prototype of DOMJIT accelerated getter.
2874         We add two new DFG nodes, CheckDOM and CallDOM.
2875
2876         CheckDOM is used to filter inappropriate |this| object for DOM getter. Its functionality
2877         is equivalent to jsDynamicCast's Check. You can use like "CheckDOM, @1, JSNode::info()",
2878         and this CheckDOM incurs a BadType exit if the class of the given @1 is not a subclass of
2879         JSNode::info().
2880
2881         CallDOM is used to emit actual DOM operations. It takes GlobalObject and checked DOM
2882         object. And it returns JSValue as its result.
2883
2884         Both CheckDOM and CallDOM can take a DOMJIT::Patchpoint. This is somewhat code snippet
2885         generator, and is injectable to DFG and FTL. DFG and FTL set up registers correctly
2886         according to DOMJIT::Patchpoint's requirement and invoke this patchpoint generator to emit code.
2887         While CallDOM always requires a patchpoint, ideally CheckDOM does not require it since
2888         isSubclassOf check can be implemented in DFG / FTL side. However, some classes have a
2889         faster way to query isSubclassOf. For example, JSNode in WebCore introduces a special
2890         JSType to optimize this query. CheckDOM's patchpoint gives us a chance to emit special
2891         faster code for such a case.
2892
2893         By leveraging above nodes, we can construct DOMJIT accelerated getter. When DFG recognizes the
2894         given getter call is CustomGetter and it has DOMJIT::GetterSetter information, DFG emits the above nodes.
2895         We implemented a prototype in jsc.cpp shell as DOMJITGetter to test the functionality.
2896
2897         Notes about the future extensions.
2898
2899         1. Currently, we do not allow CallDOM to emit any function calls. This will be extended by
2900            adding `addSlowPathCall` functionality to DOMJIT::Patchpoint later. Interesting thing is that
2901            we need to create an abstraction over DFG slow path call and FTL slow path call!
2902
2903         2. CheckDOM is not handled in DFGTypeCheckHoistingPhase yet. And we have a chance to merge several CheckDOM into one.
2904            For example, given CheckDOM A and CheckDOM B to the same target. If A is subclass of B, we can merge them to CheckDOM A.
2905
2906         * JavaScriptCore.xcodeproj/project.pbxproj:
2907         * b3/B3Effects.h:
2908         (JSC::B3::Effects::forCheck):
2909         * b3/B3Value.cpp:
2910         (JSC::B3::Value::effects):
2911         * bytecode/GetByIdStatus.cpp:
2912         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
2913         (JSC::GetByIdStatus::makesCalls):
2914         (JSC::GetByIdStatus::dump):
2915         * bytecode/GetByIdStatus.h:
2916         (JSC::GetByIdStatus::GetByIdStatus):
2917         (JSC::GetByIdStatus::isCustom):
2918         (JSC::GetByIdStatus::takesSlowPath):
2919         (JSC::GetByIdStatus::isSimple): Deleted.
2920         * bytecode/SpeculatedType.cpp:
2921         (JSC::speculationFromClassInfo):
2922         * dfg/DFGAbstractInterpreter.h:
2923         (JSC::DFG::AbstractInterpreter::filterClassInfo):
2924         * dfg/DFGAbstractInterpreterInlines.h:
2925         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2926         (JSC::DFG::AbstractInterpreter<AbstractStateType>::filterClassInfo):
2927         * dfg/DFGAbstractValue.cpp:
2928         (JSC::DFG::AbstractValue::filterClassInfo):
2929         * dfg/DFGAbstractValue.h:
2930         * dfg/DFGByteCodeParser.cpp:
2931         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
2932         (JSC::DFG::ByteCodeParser::handleGetById):
2933         * dfg/DFGClobberize.h:
2934         (JSC::DFG::clobberize):
2935         * dfg/DFGConstantFoldingPhase.cpp:
2936         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2937         * dfg/DFGDoesGC.cpp:
2938         (JSC::DFG::doesGC):
2939         * dfg/DFGFixupPhase.cpp:
2940         (JSC::DFG::FixupPhase::fixupNode):
2941         * dfg/DFGNode.h:
2942         (JSC::DFG::Node::hasHeapPrediction):
2943         (JSC::DFG::Node::hasDOMJIT):
2944         (JSC::DFG::Node::domJIT):
2945         (JSC::DFG::Node::hasClassInfo):
2946         (JSC::DFG::Node::classInfo):
2947         (JSC::DFG::Node::OpInfoWrapper::OpInfoWrapper):
2948         (JSC::DFG::Node::OpInfoWrapper::operator=):
2949         * dfg/DFGNodeType.h:
2950         * dfg/DFGOpInfo.h:
2951         (JSC::DFG::OpInfo::OpInfo):
2952         * dfg/DFGPredictionPropagationPhase.cpp:
2953         * dfg/DFGSafeToExecute.h:
2954         (JSC::DFG::safeToExecute):
2955         * dfg/DFGSpeculativeJIT.cpp:
2956         (JSC::DFG::allocateTemporaryRegistersForPatchpoint):
2957         (JSC::DFG::SpeculativeJIT::compileCallDOM):
2958         (JSC::DFG::SpeculativeJIT::compileCheckDOM):
2959         * dfg/DFGSpeculativeJIT.h:
2960         * dfg/DFGSpeculativeJIT32_64.cpp:
2961         (JSC::DFG::SpeculativeJIT::compile):
2962         * dfg/DFGSpeculativeJIT64.cpp:
2963         (JSC::DFG::SpeculativeJIT::compile):
2964         * dfg/DFGStructureAbstractValue.cpp:
2965         (JSC::DFG::StructureAbstractValue::filterClassInfoSlow):
2966         (JSC::DFG::StructureAbstractValue::isSubClassOf):
2967         * dfg/DFGStructureAbstractValue.h:
2968         (JSC::DFG::StructureAbstractValue::filterClassInfo):
2969         (JSC::DFG::StructureAbstractValue::filter): Deleted.
2970         * domjit/DOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/dfg/DFGOpInfo.h.
2971         (JSC::DOMJIT::PatchpointParams::~PatchpointParams):
2972         (JSC::DOMJIT::PatchpointParams::size):
2973         (JSC::DOMJIT::PatchpointParams::at):
2974         (JSC::DOMJIT::PatchpointParams::operator[]):
2975         (JSC::DOMJIT::PatchpointParams::gpScratch):
2976         (JSC::DOMJIT::PatchpointParams::fpScratch):
2977         (JSC::DOMJIT::PatchpointParams::PatchpointParams):
2978         * domjit/DOMJITReg.h: Added.
2979         (JSC::DOMJIT::Reg::Reg):
2980         (JSC::DOMJIT::Reg::isGPR):
2981         (JSC::DOMJIT::Reg::isFPR):
2982         (JSC::DOMJIT::Reg::isJSValueRegs):
2983         (JSC::DOMJIT::Reg::gpr):
2984         (JSC::DOMJIT::Reg::fpr):
2985         (JSC::DOMJIT::Reg::jsValueRegs):
2986         * ftl/FTLCapabilities.cpp:
2987         (JSC::FTL::canCompile):
2988         * ftl/FTLLowerDFGToB3.cpp:
2989         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2990         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
2991         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
2992         (JSC::FTL::DFG::LowerDFGToB3::compileUnreachable): Deleted.
2993         * jit/AssemblyHelpers.h:
2994         * jsc.cpp:
2995         (WTF::DOMJITNode::DOMJITNode):
2996         (WTF::DOMJITNode::createStructure):
2997         (WTF::DOMJITNode::create):
2998         (WTF::DOMJITNode::value):
2999         (WTF::DOMJITNode::offsetOfValue):
3000         (WTF::DOMJITGetter::DOMJITGetter):
3001         (WTF::DOMJITGetter::createStructure):
3002         (WTF::DOMJITGetter::create):
3003         (WTF::DOMJITGetter::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT):
3004         (WTF::DOMJITGetter::domJITNodeGetterSetter):
3005         (WTF::DOMJITGetter::finishCreation):
3006         (WTF::DOMJITGetter::customGetter):
3007         (GlobalObject::finishCreation):
3008         (functionCreateDOMJITNodeObject):
3009         (functionCreateDOMJITGetterObject):
3010
3011 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
3012
3013         [JSC] Do not construct Simple GetByIdStatus against self-custom-accessor case
3014         https://bugs.webkit.org/show_bug.cgi?id=162993
3015
3016         Reviewed by Filip Pizlo.
3017
3018         We accidentally created a Simple GetByIdStatus against self-custom-accessor case: the object has own custom accessor property and get_by_id hits.
3019         If we returned such a result, the GetById will be turned to GetByOffset and it looks up incorrect thing like CustomGetterSetter object.
3020         We do not hit this bug before since maybe there is no object that has own custom-accessor and this custom-accessor does not raise an error.
3021         For example, "Node.prototype" has "firstChild" custom accessor. But since "Node.prototype" itself does not have Node::info(), "Node.prototype.firstChild"
3022         access always raises an error. I guess all the custom accessors follow this pattern. This bug is uncovered when testing DOMJIT (This bug causes crash and
3023         it can occur even if we disabled DOMJIT).
3024
3025         But such a assumption is not guaranteed. In this patch, we fix this by not returning Simple GetById.
3026
3027         * bytecode/GetByIdStatus.cpp:
3028         (JSC::GetByIdStatus::computeFromLLInt):
3029         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
3030         (JSC::GetByIdStatus::computeFor):
3031
3032 2016-10-05  Saam Barati  <sbarati@apple.com>
3033
3034         PCToCodeOriginMap builder should use labelIgnoringWatchpoints() inside the DFG
3035         https://bugs.webkit.org/show_bug.cgi?id=162936
3036
3037         Reviewed by Michael Saboff.
3038
3039         label() may insert nops because of an InvalidationPoint. It does that
3040         because we don't want code that comes after an InvalidationPoint that isn't
3041         effected by the invalidation point to be overwritten if we fire the
3042         InvalidationPoint. PCToCodeOriginMap just grabs labels to build
3043         a mapping, it never emits code that actually jumps to those labels.
3044         Therefore, it should never cause us to emit nops.
3045
3046         * dfg/DFGJITCompiler.cpp:
3047         (JSC::DFG::JITCompiler::compile):
3048         (JSC::DFG::JITCompiler::compileFunction):
3049         * dfg/DFGSpeculativeJIT.cpp:
3050         (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
3051         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
3052
3053 2016-10-05  Myles C. Maxfield  <mmaxfield@apple.com>
3054
3055         Put variation fonts work behind a compile-time flag
3056         https://bugs.webkit.org/show_bug.cgi?id=162949
3057
3058         Reviewed by Simon Fraser.
3059
3060         * Configurations/FeatureDefines.xcconfig:
3061
3062 2016-10-05  Andy VanWagoner  <thetalecrafter@gmail.com>
3063
3064         [INTL] Implement Intl.getCanonicalLocales
3065         https://bugs.webkit.org/show_bug.cgi?id=162768
3066
3067         Reviewed by Benjamin Poulain.
3068
3069         Implement Intl.getCanonicalLocales from ECMA 402 (3rd edition)
3070         http://ecma-international.org/ecma-402/3.0/index.html#sec-intl.getcanonicallocales
3071
3072         Reuse canonicalizeLocaleList and copy the results into a new JSArray.
3073
3074         * runtime/IntlObject.cpp:
3075         (JSC::IntlObject::finishCreation):
3076         (JSC::intlObjectFuncGetCanonicalLocales):
3077
3078 2016-10-05  Michael Saboff  <msaboff@apple.com>
3079
3080         Bad ASSERT in ClonedArguments::createByCopyingFrom()
3081         https://bugs.webkit.org/show_bug.cgi?id=162988
3082
3083         Reviewed by Keith Miller.
3084
3085         Removed bogus assert.
3086
3087         * runtime/ClonedArguments.cpp:
3088         (JSC::ClonedArguments::createByCopyingFrom):
3089
3090 2016-10-05  Zan Dobersek  <zdobersek@igalia.com>
3091
3092         Rename ENABLE_ENCRYPTED_MEDIA_V2 to ENABLE_LEGACY_ENCRYPTED_MEDIA
3093         https://bugs.webkit.org/show_bug.cgi?id=162903
3094
3095         Reviewed by Alex Christensen.
3096
3097         Rename build guards for the remaining implementation of the legacy EME API
3098         to ENABLE_LEGACY_ENCRYPTED_MEDIA. This will allow for the future implementation
3099         of the near-finished API to be guarded with the simple ENABLE_ENCRYPTED_MEDIA guards.
3100
3101         * Configurations/FeatureDefines.xcconfig:
3102
3103 2016-10-05  Csaba Osztrogonác  <ossy@webkit.org>
3104
3105         ARM EABI buildfix after r206778
3106         https://bugs.webkit.org/show_bug.cgi?id=162964
3107
3108         Unreviewed trivial fix.
3109
3110         * jit/CCallHelpers.h:
3111         (JSC::CCallHelpers::setupArgumentsWithExecState):
3112
3113 2016-10-04  Saam Barati  <sbarati@apple.com>
3114
3115         String.prototype.toLowerCase should be a DFG/FTL intrinsic
3116         https://bugs.webkit.org/show_bug.cgi?id=162887
3117
3118         Reviewed by Filip Pizlo and Yusuke Suzuki.
3119
3120         This patch makes ToLowerCase an intrinsic in the DFG/FTL. On the fast
3121         path, the intrinsic will loop over an 8-bit string ensuring it's already
3122         lower case, and simply return the string. In the slow path, it'll call
3123         into C code to make a new string.
3124
3125         This is a 7-8% speedup on ES6SampleBench/Basic.
3126
3127         * dfg/DFGAbstractInterpreterInlines.h:
3128         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3129         * dfg/DFGByteCodeParser.cpp:
3130         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
3131         * dfg/DFGClobberize.h:
3132         (JSC::DFG::clobberize):
3133         * dfg/DFGDoesGC.cpp:
3134         (JSC::DFG::doesGC):
3135         * dfg/DFGFixupPhase.cpp:
3136         (JSC::DFG::FixupPhase::fixupNode):
3137         * dfg/DFGNodeType.h:
3138         * dfg/DFGOperations.cpp:
3139         * dfg/DFGOperations.h:
3140         * dfg/DFGPredictionPropagationPhase.cpp:
3141         * dfg/DFGSafeToExecute.h:
3142         (JSC::DFG::safeToExecute):
3143         * dfg/DFGSpeculativeJIT.cpp:
3144         (JSC::DFG::SpeculativeJIT::compileToLowerCase):
3145         * dfg/DFGSpeculativeJIT.h:
3146         (JSC::DFG::SpeculativeJIT::callOperation):
3147         * dfg/DFGSpeculativeJIT32_64.cpp:
3148         (JSC::DFG::SpeculativeJIT::compile):
3149         * dfg/DFGSpeculativeJIT64.cpp:
3150         (JSC::DFG::SpeculativeJIT::compile):
3151         * ftl/FTLAbstractHeapRepository.h:
3152         * ftl/FTLCapabilities.cpp:
3153         (JSC::FTL::canCompile):
3154         * ftl/FTLLowerDFGToB3.cpp:
3155         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3156         (JSC::FTL::DFG::LowerDFGToB3::compileToLowerCase):
3157         * jit/JITOperations.h:
3158         * runtime/Intrinsic.h:
3159         * runtime/StringPrototype.cpp:
3160         (JSC::StringPrototype::finishCreation):
3161
3162 2016-10-04  Brian Burg  <bburg@apple.com>
3163
3164         Web Inspector: don't synchronously send a listing message if we might need to query _WKAutomationDelegate
3165         https://bugs.webkit.org/show_bug.cgi?id=162810
3166         <rdar://problem/28571460>
3167
3168         Reviewed by Timothy Hatcher.
3169
3170         We shouldn't ever access the _WKAutomationDelegate through RemoteInspector::Client methods
3171         off of the main thread, because it could cause problems. This happens when we pushListingsNow()
3172         in response to a WIRApplicationGetListingMessage XPC message. In this case, just use
3173         pushListingsSoon() since it dispatches on the correct (main) queue to gather listing information.
3174
3175         This may induce a slight update delay when first connecting to the UIProcess through RemoteInspector,
3176         but this is at most 200ms and will coalesce with other updates that happen when UIProcess gets set up.
3177
3178         There are no other code paths through RemoteInspector (for UIProcess) that could cause a call
3179         to pushListingsNow(), so this only needs to be changed in the XPC message handler.
3180
3181         * inspector/remote/RemoteInspector.mm:
3182         (Inspector::RemoteInspector::receivedGetListingMessage):
3183
3184 2016-10-04  JF Bastien  <jfbastien@apple.com>
3185
3186         WebAssembly: handle a few corner cases
3187         https://bugs.webkit.org/show_bug.cgi?id=162884
3188
3189         Reviewed by Keith Miller.
3190
3191         * wasm/JSWASMModule.cpp: missing include broke cmake build
3192         * wasm/WASMFunctionParser.h:
3193         (JSC::WASM::FunctionParser<Context>::parseBlock): check op is valid
3194         (JSC::WASM::FunctionParser<Context>::parseExpression): switch covers all cases
3195         * wasm/WASMOps.h:
3196         (JSC::WASM::isValidOpType): op is valid
3197         * wasm/WASMParser.h:
3198         (JSC::WASM::Parser::consumeString): avoid str[i] being one-past-the-end
3199         (JSC::WASM::Parser::parseUInt32): shift math around to avoid overflow
3200
3201 2016-10-04  Yusuke Suzuki  <utatane.tea@gmail.com>
3202
3203         REGRESSION (r206778): Release JSC test ChakraCore.yaml/ChakraCore/test/Error/validate_line_column.js.default failing
3204         https://bugs.webkit.org/show_bug.cgi?id=162937
3205
3206         Reviewed by Saam Barati.
3207
3208         We dropped expression info accidentally at r206777.
3209
3210         * bytecompiler/BytecodeGenerator.cpp:
3211         (JSC::BytecodeGenerator::emitCallDefineProperty):
3212         * bytecompiler/BytecodeGenerator.h:
3213         * bytecompiler/NodesCodegen.cpp:
3214         (JSC::PropertyListNode::emitPutConstantProperty):
3215         (JSC::ClassExprNode::emitBytecode):
3216
3217 2016-10-04  Yusuke Suzuki  <utatane.tea@gmail.com>
3218
3219         [DOMJIT] Introduce DOMJIT::GetterSetter to tell JIT information
3220         https://bugs.webkit.org/show_bug.cgi?id=162916
3221
3222         Reviewed by Filip Pizlo.
3223
3224         In this patch, we introduce DOMJIT::GetterSetter.
3225         This class maintains information required to emit JIT code in DFG and FTL.
3226         DOMJIT::GetterSetter has 2 virtual functions: checkDOM and callDOM.
3227         These functions can return a DOMJIT::Patchpoint that allows us to inject
3228         appropriate machine code during DFG and FTL phases. DFG and FTL will invoke
3229         these functions to get a patchpoint. And this patchpoint will be used to
3230         emit code corresponding to CheckDOM and CallDOM DFG nodes, which will be added
3231         in subsqeunt patch.
3232
3233         We propagate DOMJIT::GetterSetter through PropertySlot, AccessCase, GetByIdVariant,
3234         and GetByIdStatus along with CustomGetter to teach DFG that this custom access
3235         code has a chance to be inlined with this DOMJIT::GetterSetter information.
3236         Instead of propagating CustomGetterSetter holding DOMJIT::GetterSetter and CustomGetter,
3237         we propagate CustomGetter and DOMJIT::GetterSetter. This is because of the current
3238         CustomGetterSetter design that we reify CustomGetterSetters only when we need to reify
3239         all the properties. This design allows us to avoid frequent CustomGetterSetter allocations
3240         and structure transitions.
3241
3242         Currently, domJIT field is always nullptr since there is no DOMJITAttribute user.
3243         When we add this, we will add code handling this DOMJIT::GetterSetter in DFG::ByteCodeParser.
3244
3245         * CMakeLists.txt:
3246         * JavaScriptCore.xcodeproj/project.pbxproj:
3247         * bytecode/GetByIdStatus.cpp:
3248         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
3249         * bytecode/GetByIdVariant.cpp:
3250         (JSC::GetByIdVariant::GetByIdVariant):
3251         (JSC::GetByIdVariant::operator=):
3252         (JSC::GetByIdVariant::attemptToMerge):
3253         (JSC::GetByIdVariant::dumpInContext):
3254         * bytecode/GetByIdVariant.h:
3255         (JSC::GetByIdVariant::domJIT):
3256         (JSC::GetByIdVariant::intrinsic): Deleted.
3257         * bytecode/PolymorphicAccess.cpp:
3258         (JSC::AccessCase::get):
3259         (JSC::AccessCase::clone):
3260         * bytecode/PolymorphicAccess.h:
3261         (JSC::AccessCase::domJIT):
3262         (JSC::AccessCase::RareData::RareData):
3263         * dfg/DFGNode.h:
3264         * domjit/DOMJITGetterSetter.h: Added.
3265         (JSC::DOMJIT::GetterSetter::GetterSetter):
3266         (JSC::DOMJIT::GetterSetter::~GetterSetter):
3267         (JSC::DOMJIT::GetterSetter::getter):
3268         (JSC::DOMJIT::GetterSetter::setter):
3269         (JSC::DOMJIT::GetterSetter::thisClassInfo):
3270         * domjit/DOMJITPatchpoint.h: Added.
3271         (JSC::DOMJIT::Patchpoint::create):
3272         (JSC::DOMJIT::Patchpoint::setGenerator):
3273         (JSC::DOMJIT::Patchpoint::generator):
3274         * jit/Repatch.cpp:
3275         (JSC::tryCacheGetByID):
3276         * runtime/CustomGetterSetter.h:
3277         * runtime/JSObject.h:
3278         (JSC::JSObject::fillCustomGetterPropertySlot):
3279         * runtime/Lookup.h:
3280         (JSC::HashTableValue::domJIT):
3281         (JSC::getStaticPropertySlotFromTable):
3282         (JSC::putEntry):
3283         (JSC::reifyStaticProperty):
3284         * runtime/PropertySlot.h:
3285         (JSC::PropertySlot::domJIT):
3286         (JSC::PropertySlot::setCacheableCustom):
3287
3288 2016-09-27  Yusuke Suzuki  <utatane.tea@gmail.com>
3289
3290         [JSC] Add a new byte code op_define_property instead of calling defineProperty
3291         https://bugs.webkit.org/show_bug.cgi?id=162108
3292
3293         Reviewed by Saam Barati.
3294
3295         To construct ES6 class, we emitted bytecode that performs the following operations.
3296
3297             1. construct a new object
3298             2. put "configurable", "enumerable" etc. fields
3299             3. call "defineProperty" function
3300
3301         However, this approach has problems. Every time we define a class method, we need to create
3302         a new object to represent property descriptor. This can be removed if we can introduce
3303         a special bytecode or special function.
3304
3305         This patch introduces new bytecodes, op_define_data_property and op_define_accessor_property.
3306         Instead of taking an object, they takes several registers to avoid object allocations.
3307         We're planning to use